[libvirt] [PATCH] bhyve: domain autostart support
by Roman Bogorodskiy
Re-submit patch provided by David back in February when bhyve driver was not
in the tree. I did some changes to the patch on the way:
- rebase to the current master
- add ACL checks
- use bhyveDomObjFromDomain() instead of custom virDomainObjListFindByUUID()
- fix problems reported by 'syntax-check'
David Shane Holden (1):
bhyve: domain autostart support
src/bhyve/bhyve_driver.c | 135 ++++++++++++++++++++++++++++++++++++++++++++++-
src/bhyve/bhyve_utils.h | 5 ++
2 files changed, 139 insertions(+), 1 deletion(-)
--
1.8.4.2
10 years, 1 month
[libvirt] libxl fixes/improvements for libvirt
by Stefan Bader
Here several changes which improve the handling of Xen for me:
* 0001-libxl-Use-id-from-virDomainObj-inside-the-driver.patch
This is a re-send as I initially submitted that as a reply to some
discussion. Starting from the visibly broken libxlDomainGetInfo when
creating or rebooting a guest with virt-manager, I replaced all usage
of dom->id with the more stable vm->def->id.
* 0002-libxl-Set-disk-format-for-empty-cdrom-device.patch
Fixes start of a guest after ejecting the iso image from a virtual
CDROM drive (again using virt-manager).
* 0003-libxl-Implement-basic-video-device-selection.patch
Should fix the occasional disagreement about the used VNC port and
adds the ability to select the standard VGA graphics from Xen.
VRAM size seemed to work with that. Only for Cirrus, while the qemu
command-line looks good, ones seems to end up with 32M.
Note to people on the Xen list: I wonder whether libxenlight internally
should somehow should fix up the situation where a caller sets up the
video devices in the vfbs list but does not sync that with the information
in the build info. Question probably is what the semantics should be.
-Stefan
10 years, 1 month
[libvirt] libxl: Issues with virt-manager when used to manager Xen domains
by Stefan Bader
This started off with some regression testing after going forward to Xen-4.4. We
currently would pair that with a libvirt version 1.2.2 and right now operations
through virsh seem to be working (mostly) well. But when using virt-manager (not
the most up-to-date versions but some combinations that quite likely will occur
(0.9.1 and 0.9.5)) there are some issues.
Two symptoms seem to be caused by the same underlying problem which is caused by
the way virt-manager interacts with libvirt. That seems to be that virt-manager
acquires a reference to virDomainPtr only once and then uses that for subsequent
call. This is a problem because both virDomainPtr object and virDomainObjPtr
objects contains a domid but only the latter gets updated.
So both, creating a new guest (which must be a define step and then use the
handle to start the guest) as well as rebooting a guest cause problems for
virt-manager. Mainly because of libxlDomainGetInfo() which retrieves the
virDomainObjPtr for a given virDommainPtr. Then checks the domain object to be
active or not but uses the domid from the domain to call into libxl:
if (!(vm = libxlDomObjFromDomain(dom)))
goto cleanup;
...
if (!virDomainObjIsActive(vm)) {
info->cpuTime = 0;
info->memory = vm->def->mem.cur_balloon;
info->maxMem = vm->def->mem.max_balloon;
} else {
if (libxl_domain_info(priv->ctx, &d_info, dom->id) != 0) {
This fails either with dom->id being -1 (still) or using the old id from before
the reboot. A dirty hack seems to avoid this:
static virDomainObjPtr
libxlDomObjFromDomain(virDomainPtr dom)
{
virDomainObjPtr vm;
libxlDriverPrivatePtr driver = dom->conn->privateData;
char uuidstr[VIR_UUID_STRING_BUFLEN];
vm = virDomainObjListFindByUUID(driver->domains, dom->uuid);
if (!vm) {
virUUIDFormat(dom->uuid, uuidstr);
virReportError(VIR_ERR_NO_DOMAIN,
_("no domain with matching uuid '%s' (%s)"),
uuidstr, dom->name);
return NULL;
- }
+ } else {
+ if (dom->id != vm->def->id) {
+ VIR_WARN("libxlDomObjFromDomain: domid changed (%d->%d)",
+ dom->id, vm->def->id);
+ dom->id = vm->def->id;
+ }
+ }
return vm;
}
Not really sure this is the right way to go. Also because that warning above
happens a lot more (repeatedly) than I would have expected. This may or may not
be related to the next question.
Not a problem but more a confusion on my side: virGetDomain() has commentary
that says it will return either a pointer to an existing object or one to a new
one. Its just, I cannot see that done in the code. Is that a future plan or was
that way but was removed?
I must admit I have not looked deeper into that but one explanation of the
repeated domid mismatch would be if the virDomainPtr that virt-manager uses to
communicate with libvirt would be cloned before doing things inside libvirt. And
holding that handle for so long and not obtaining a fresh one through the
various lookup interfaces each time could be a mistake of virt-manager.
Unfortunately one that needs to be handled in some way.
-Stefan
10 years, 1 month
[libvirt] [PATCH v4 0/5] Expose FSFreeze/FSThaw within the guest as API
by Tomoki Sekiyama
Hello,
This is patchset v4 to add FSFreeze/FSThaw API for custom disk snapshotting.
Changes to v3:
* fix typp and label spacing
* rebased to recent tree
(v3: http://www.redhat.com/archives/libvir-list/2014-March/msg01358.html )
=== Description ===
Currently FSFreeze and FSThaw are supported by qemu guest agent and they are
used internally in snapshot-create command with --quiesce option.
However, when users want to utilize the native snapshot feature of storage
devices (such as LVM over iSCSI, enterprise storage appliances, etc.),
they need to issue fsfreeze command separately from libvirt-driven snapshots.
(OpenStack cinder provides these storages' snapshot feature, but it cannot
quiesce the guest filesystems automatically for now.)
Although virDomainQemuGuestAgent() API could be used for this purpose, it
is only for debugging and is not supported officially.
This patchset adds virDomainFSFreeze()/virDomainFSThaw() APIs and virsh
domfsfreeze/domfsthaw commands to enable the users to freeze and thaw
domain's filesystems cleanly.
The APIs have flags option currently unsupported for future extension.
---
Tomoki Sekiyama (5):
Introduce virDomainFSFreeze() and virDomainFSThaw() public API
remote: Implement virDomainFSFreeze and virDomainFSThaw
qemu: Track domain quiesced status
qemu: Implement virDomainFSFreeze and virDomainFSThaw
virsh: Expose new virDomainFSFreeze and virDomainFSThaw API
include/libvirt/libvirt.h.in | 6 ++
src/access/viraccessperm.c | 2 -
src/access/viraccessperm.h | 6 ++
src/driver.h | 10 +++
src/libvirt.c | 70 ++++++++++++++++++++
src/libvirt_public.syms | 2 +
src/qemu/qemu_domain.c | 5 +
src/qemu/qemu_domain.h | 2 +
src/qemu/qemu_driver.c | 144 ++++++++++++++++++++++++++++++++++++++----
src/remote/remote_driver.c | 2 +
src/remote/remote_protocol.x | 25 +++++++
src/remote_protocol-structs | 9 +++
src/rpc/gendispatch.pl | 2 +
tools/virsh-domain.c | 92 +++++++++++++++++++++++++++
tools/virsh.pod | 15 ++++
15 files changed, 376 insertions(+), 16 deletions(-)
10 years, 1 month
Re: [libvirt] RFC: viridentitytest Failure on CentOS 6.5?
by Nehal J Wani
On Sun, Mar 16, 2014 at 1:28 PM, Nehal J Wani <nehaljw.kkd1(a)gmail.com> wrote:
> I followed the following steps to build a clean development version of
> libvirt from source. Can't seem to understand what is wrong. (Entire
> buildLog has been attached):
>
> ➜ /tmp cat /etc/issue
> CentOS release 6.5 (Final)
> Kernel \r on an \m
> ➜ /tmp sestatus
> SELinux status: enabled
> SELinuxfs mount: /selinux
> Current mode: enforcing
> Mode from config file: enforcing
> Policy version: 24
> Policy from config file: targeted
> ➜ /tmp git clone git://libvirt.org/libvirt.git
> Initialized empty Git repository in /tmp/libvirt/.git/
> remote: Counting objects: 138935, done.
> remote: Compressing objects: 100% (21143/21143), done.
> remote: Total 138935 (delta 117282), reused 138935 (delta 117282)
> Receiving objects: 100% (138935/138935), 137.72 MiB | 559 KiB/s, done.
> Resolving deltas: 100% (117282/117282), done.
> ➜ /tmp cd libvirt
> ➜ libvirt git:(master) ./autogen.sh --system
> Running ./configure with --prefix=/usr --sysconfdir=/etc
> --localstatedir=/var --libdir=/usr/lib64
> ..
> ..
> Now type 'make' to compile libvirt.
> ➜ libvirt git:(master) make
> ..
> ..
> make[1]: Leaving directory `/tmp/libvirt'
> ➜ libvirt git:(master) ✗ cd tests
> ➜ tests git:(master) ✗ ./viridentitytest
> /tmp/libvirt/tests/.libs/libsecurityselinuxhelper.so: No such file or directory
> ➜ tests git:(master) ✗
>
>
> --
> Nehal J Wani
Ping!
--
Nehal J Wani
10 years, 1 month
[libvirt] [PATCH] maint: ensure src/ directory includes are clean
by Eric Blake
In 'make syntax-check', we have a rule that prevents layering
violations between the various files in src. However, we
forgot to treat conf/ and the more recently-added access/ as
lower-level directories, and were not detecting cases where
they might have used a driver file. Also, it's not nice that
qemu can use storage/ but none of the other drivers could do so.
* cfg.mk (sc_prohibit_cross_inclusion): Tighten rules for conf/
and access/, let all other drivers use storage/.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
I noticed this because of my work on domain_conf.h: I want to share
a struct between util/virstoragefile and conf/domain_conf, and ran
into a syntax check when I tried to make util/ depend on conf/. I
fixed things to obey layering with conf/ depending on util/, but in
the process noticed that some layering violations went undetected.
cfg.mk | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/cfg.mk b/cfg.mk
index a4ae978..19537cf 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -760,17 +760,17 @@ sc_prohibit_gettext_markup:
# lower-level code must not include higher-level headers.
cross_dirs=$(patsubst $(srcdir)/src/%.,%,$(wildcard $(srcdir)/src/*/.))
cross_dirs_re=($(subst / ,/|,$(cross_dirs)))
+mid_dirs=access|conf|cpu|locking|network|node_device|rpc|security|storage
sc_prohibit_cross_inclusion:
@for dir in $(cross_dirs); do \
case $$dir in \
util/) safe="util";; \
- locking/) \
- safe="($$dir|util|conf|rpc)";; \
- cpu/ | locking/ | network/ | rpc/ | security/) \
+ access/ | conf/) safe="($$dir|conf|util)";; \
+ locking/) safe="($$dir|util|conf|rpc)";; \
+ cpu/| network/| node_device/| rpc/| security/| storage/) \
safe="($$dir|util|conf)";; \
xenapi/ | xenxs/ ) safe="($$dir|util|conf|xen)";; \
- qemu/ ) safe="($$dir|util|conf|cpu|network|locking|rpc|security|storage)";; \
- *) safe="($$dir|util|conf|cpu|network|locking|rpc|security)";; \
+ *) safe="($$dir|$(mid_dirs)|util)";; \
esac; \
in_vc_files="^src/$$dir" \
prohibit='^# *include .$(cross_dirs_re)' \
--
1.8.5.3
10 years, 1 month
[libvirt] [PATCH 0/n] round 2 of storage chain refactoring
by Eric Blake
In round 1, I split out a new struct in domain_conf.h. This starts
round 2: moving the struct into util/virstoragefile.h, so it can be
shared by domain, snapshot, and existing virstoragefile backing
chain operations. It's turned out to be a bigger process than I
first thought, so I've tried splitting it into smaller patches
to ease review. I also want to get review started on the parts
I have compiling, while still working on the rest of the series,
since I know that at least Peter will be heavily impacted by
some of the changes in this series.
Eric Blake (2):
conf: split security label structs to util/
conf: split network host structs to util/
src/Makefile.am | 1 +
src/conf/domain_conf.c | 139 +++-------------------------------
src/conf/domain_conf.h | 71 +----------------
src/conf/snapshot_conf.c | 5 +-
src/conf/snapshot_conf.h | 4 +-
src/libvirt_private.syms | 21 ++---
src/qemu/qemu_command.c | 38 +++++-----
src/qemu/qemu_command.h | 6 +-
src/qemu/qemu_conf.c | 4 +-
src/qemu/qemu_driver.c | 24 +++---
src/qemu/qemu_process.c | 2 +-
src/security/security_manager.c | 2 +-
src/security/security_selinux.c | 2 +-
src/storage/storage_backend_gluster.c | 8 +-
src/storage/storage_driver.c | 8 +-
src/storage/storage_driver.h | 2 +-
src/util/virseclabel.c | 82 ++++++++++++++++++++
src/util/virseclabel.h | 67 ++++++++++++++++
src/util/virstoragefile.c | 71 ++++++++++++++++-
src/util/virstoragefile.h | 30 +++++++-
20 files changed, 328 insertions(+), 259 deletions(-)
create mode 100644 src/util/virseclabel.c
create mode 100644 src/util/virseclabel.h
--
1.8.5.3
10 years, 1 month
[libvirt] [PATCH v2 0/4] Fix VolOpen error reporting
by Cole Robinson
In https://bugzilla.redhat.com/show_bug.cgi?id=1080613 , something is
causing StorageVolGetXML to fail, but it's not raising any error message.
Code inspection found that most users of VolOpen are susceptible to error
reporting issues.
The first 3 patches are some code reorganization and cleanups that make
it easier to identify the VolOpen callers. Patch 4 fixes up the reporting
issue.
v2:
Jan's suggestion to only report an error if caller passed in VOL_OPEN_ERROR
Cole Robinson (4):
storage: Rename UpdateVolInfoFlags to UpdateVolInfo
storage: move block format lookup to shared UpdateVolInfo
storage: Rename VolOpenCheckMode to VolOpen
storage: Report error from VolOpen if proper flag is passed
src/storage/storage_backend.c | 260 ++++++++++++++++++----------------
src/storage/storage_backend.h | 18 +--
src/storage/storage_backend_disk.c | 3 +-
src/storage/storage_backend_fs.c | 25 ++--
src/storage/storage_backend_logical.c | 11 +-
src/storage/storage_backend_mpath.c | 36 +----
src/storage/storage_backend_scsi.c | 43 +-----
7 files changed, 175 insertions(+), 221 deletions(-)
--
1.8.5.3
10 years, 1 month
[libvirt] [PATCH 0/6] Gluster pool lookup and few gluster related fixes
by Peter Krempa
Peter Krempa (6):
storage: pool: Fix XML indentation in pool source lookup
storage: netfs: Split up and tidy up NFS storage pool source function
storage: netfs: Support lookup of glusterfs pool sources
storage: gluster: Implement storage pool lookup
storage: gluster: Fix crash when initialization of storage backend
fails
util: storagefile: Don't pursue backing chain of NULL image
configure.ac | 6 +++
src/conf/storage_conf.c | 2 +
src/storage/storage_backend.c | 86 +++++++++++++++++++++++++++++++++++
src/storage/storage_backend.h | 4 ++
src/storage/storage_backend_fs.c | 54 ++++++++++++++--------
src/storage/storage_backend_gluster.c | 56 ++++++++++++++++++++++-
src/util/virstoragefile.c | 2 +-
7 files changed, 187 insertions(+), 23 deletions(-)
--
1.9.1
10 years, 1 month
[libvirt] [for-1.2.3 PATCHv3] gluster: Fix "key" attribute for gluster volumes
by Peter Krempa
According to our documentation the "key" value has the following
meaning: "Providing an identifier for the volume which identifies a
single volume." The currently used keys for gluster volumes consist of
the gluster volume name and file path. This can't be considered unique
as a different storage server can serve a volume with the same name.
Unfortunately I wasn't able to figure out a way to retrieve the gluster
volume UUID which would avoid the possibility of having two distinct
keys identifying a single volume.
Use the full URI as the key for the volume to avoid the more critical
ambiguity problem and document the possible change to UUID.
---
Notes:
Version 3:
- fix the example too, also state that UUID might be used
- repost so we don't have yet another release containing this
docs/storage.html.in | 8 +++++---
src/storage/storage_backend_gluster.c | 10 ++++++++--
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/docs/storage.html.in b/docs/storage.html.in
index 2706bc5..4bbf378 100644
--- a/docs/storage.html.in
+++ b/docs/storage.html.in
@@ -711,12 +711,14 @@
correspond to the files that can be found when mounting the
gluster volume. The <code>name</code> is the path relative to
the effective mount specified for the pool; and
- the <code>key</code> is a path including the gluster volume
- name and any subdirectory specified by the pool.</p>
+ the <code>key</code> is a string that identifies a single volume
+ uniquely. Currently the <code>key</code> attribute consists of the
+ URI of the volume but it may be changed to an UUID of the volume
+ in the future.</p>
<pre>
<volume>
<name>myfile</name>
- <key>volname/myfile</key>
+ <key>gluster://localhost/volname/myfile</key>
<source>
</source>
<capacity unit='bytes'>53687091200</capacity>
diff --git a/src/storage/storage_backend_gluster.c b/src/storage/storage_backend_gluster.c
index fe92f15..337ddf4 100644
--- a/src/storage/storage_backend_gluster.c
+++ b/src/storage/storage_backend_gluster.c
@@ -187,6 +187,7 @@ virStorageBackendGlusterSetMetadata(virStorageBackendGlusterStatePtr state,
const char *name)
{
int ret = -1;
+ char *path = NULL;
char *tmp;
VIR_FREE(vol->key);
@@ -201,12 +202,12 @@ virStorageBackendGlusterSetMetadata(virStorageBackendGlusterStatePtr state,
goto cleanup;
}
- if (virAsprintf(&vol->key, "%s%s%s", state->volname, state->dir,
+ if (virAsprintf(&path, "%s%s%s", state->volname, state->dir,
vol->name) < 0)
goto cleanup;
tmp = state->uri->path;
- if (virAsprintf(&state->uri->path, "/%s", vol->key) < 0) {
+ if (virAsprintf(&state->uri->path, "/%s", path) < 0) {
state->uri->path = tmp;
goto cleanup;
}
@@ -218,9 +219,14 @@ virStorageBackendGlusterSetMetadata(virStorageBackendGlusterStatePtr state,
VIR_FREE(state->uri->path);
state->uri->path = tmp;
+ /* the path is unique enough to serve as a volume key */
+ if (VIR_STRDUP(vol->key, vol->target.path) < 0)
+ goto cleanup;
+
ret = 0;
cleanup:
+ VIR_FREE(path);
return ret;
}
--
1.9.1
10 years, 1 month
