July 2014 - Devel - libvirt List Archives

[libvirt] [PATCH] Do not allow changing the UUID of a nwfilter
by Ján Tomko 07 Jul '14

07 Jul '14

From: Hu Jianwei <jiahu(a)redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1077009 --- src/conf/nwfilter_conf.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/conf/nwfilter_conf.c b/src/conf/nwfilter_conf.c index 0f633da..52f24e4 100644 --- a/src/conf/nwfilter_conf.c +++ b/src/conf/nwfilter_conf.c @@ -3058,6 +3058,17 @@ virNWFilterObjAssignDef(virNWFilterObjListPtr nwfilters, return NULL; } virNWFilterObjUnlock(nwfilter); + } else { + nwfilter = virNWFilterObjFindByName(nwfilters, def->name); + if (nwfilter) { + char uuidstr[VIR_UUID_STRING_BUFLEN]; + virUUIDFormat(nwfilter->def->uuid, uuidstr); + virReportError(VIR_ERR_OPERATION_FAILED, + _("filter '%s' already exists with uuid %s"), + def->name, uuidstr); + virNWFilterObjUnlock(nwfilter); + return NULL; + } } if (virNWFilterDefLoopDetect(nwfilters, def) < 0) { -- 1.8.5.5

2 1

[libvirt] Regression with 79f11b35
by Cole Robinson 07 Jul '14

07 Jul '14

I'm seeing a regression with: commit 79f11b35c77b3c286c84312dc9737c2ccbf67ed5 Author: Eric Blake <eblake(a)redhat.com> Date: Tue Apr 8 14:26:02 2014 -0600 conf: track user vs. canonical name through full chain lookup Setup info: $ ls -ld /mnt/data lrwxrwxrwx. 1 root root 17 Oct 24 2011 /mnt/data -> terabytedrv/data/ $ ls -l /mnt/data/devel/images/f18* -rw-r--r--. 1 qemu qemu 9316335616 Mar 30 18:36 /mnt/data/devel/images/f18-backing-img.qcow2 -rw-r--r--. 1 root root 6848249856 Apr 25 19:11 /mnt/data/devel/images/f18.qcow2 $ qemu-img info /mnt/data/devel/images/f18-backing-img.qcow2 image: /mnt/data/devel/images/f18-backing-img.qcow2 file format: qcow2 virtual size: 9.8G (10485760000 bytes) disk size: 8.7G cluster_size: 65536 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 snapshot1 0 2014-01-13 18:48:43 00:00:00.000 2 snapshot2 0 2014-01-13 18:49:39 00:00:00.000 Format specific information: compat: 0.10 $ qemu-img info /mnt/data/devel/images/f18.qcow2 image: /mnt/data/devel/images/f18.qcow2 file format: qcow2 virtual size: 9.8G (10485760000 bytes) disk size: 6.4G cluster_size: 65536 backing file: f18-backing-img.qcow2 (actual path: /mnt/data/devel/images/f18-backing-img.qcow2) Format specific information: compat: 0.10 Before the patch: $ sudo virsh vol-dumpxml /mnt/data/devel/images/f18.qcow2 [full xml with backing image info] After the patch: $ sudo virsh vol-dumpxml /mnt/data/devel/images/f18.qcow2 [xml minus xml for the backing image] And these errors are on the console when the daemon starts: 2014-05-03 20:52:34.970+0000: 20600: error : virFindBackingFile:590 : Cannot access backing file './f18-backing-img.qcow2': No such file or directory 2014-05-03 20:52:34.970+0000: 20600: warning : virStorageFileGetMetadataInternal:868 : Backing file 'f18-backing-img.qcow2' of image '/mnt/data/devel/images/ztester-serial-f18.qcow2' is missing. On git head actually the vol-dumpxml explicitly fails, but I don't have the error handy. - Cole

1 1

[libvirt] QEMU snapshots on ZFS
by Arunas Ruksnaitis 07 Jul '14

07 Jul '14

I have a libvirt to control qemu domains with various flavours of Windows on Ubuntu 14.04 Trusty. The disk images are ZFS volumes. After I have resolved scheduling problems related to kernel (latest 3.15.3-031503-lowlatency kernel seems to have resolved scheduling and BSOD issues), I have never seen Windows to run this fast, even on bare iron. This is a WONDERFUL combination. Now I am starting to move forward, and have discovered that snapshot is only supported as QEMU native "savevm" command, which only works on QCOW2 backing image. Is there any chance to include support for ZFS native snapshots? I.e. do a coordinated RAM snapshot in a separate file, snapshot ZFS volume and tie these two together in a snapshot XML file. A related, but different question: any chance to support ZFS-backed storage pools, so that ZFS volumes could be created, and not QCOW images in ZFS file system (this is a waste of ZFS, as ZFS already has native COW, snapshots, cloning, migration and much more). Should I start a separate thread for this topic?

2 1

[libvirt] [PATCH] Free the return value of virFileFindResource
by Ján Tomko 07 Jul '14

07 Jul '14

Commits e18a80a and 57e5c3c switched from a getenv wrapper which does not allocate a string to virFileFindResource which does not, without freeing it. https://bugzilla.redhat.com/show_bug.cgi?id=1116427 --- src/locking/lock_driver_lockd.c | 2 ++ src/remote/remote_driver.c | 3 +++ 2 files changed, 5 insertions(+) diff --git a/src/locking/lock_driver_lockd.c b/src/locking/lock_driver_lockd.c index c67bda6..1ca7772 100644 --- a/src/locking/lock_driver_lockd.c +++ b/src/locking/lock_driver_lockd.c @@ -273,11 +273,13 @@ static virNetClientPtr virLockManagerLockDaemonConnectionNew(bool privileged, if (virNetClientAddProgram(client, *prog) < 0) goto error; + VIR_FREE(daemonPath); VIR_FREE(lockdpath); return client; error: + VIR_FREE(daemonPath); VIR_FREE(lockdpath); virNetClientClose(client); virObjectUnref(client); diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 88fc977..9d8120f 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -1068,6 +1068,9 @@ doRemoteOpen(virConnectPtr conn, VIR_FREE(pkipath); VIR_FREE(knownHostsVerify); VIR_FREE(knownHosts); +#ifndef WIN32 + VIR_FREE(daemonPath); +#endif return retcode; -- 1.8.5.5

4 3

[libvirt] Where to get precompiled qga-vss.dll from ?
by Puneet Bakshi 07 Jul '14

07 Jul '14

Hi, I want to work with "guest-fsfreeze-*" commands in Windows 2008 guest VM. Host is CentOS 6.4. Windows 2008 is running QEMU VSS provider. When "guest-fsfreeze-*" commands are invoked from host, response received is "This is not supported". I am following http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg01963.html. Regards, ~Puneet

2 1

[libvirt] [PATCHv2 0/2] smartcard/serial/parallel/console/channel auditing
by Peter Krempa 07 Jul '14

07 Jul '14

V2 adds docs to docs/auditlog.html.in and doesn't log the shared serial/console def twice. Sending for sanity review of language :) Peter Krempa (2): audit: Add auditing for serial/parallel/channel/console character devs audit: Audit smartcard devices docs/auditlog.html.in | 35 +++++++++++++++++++ src/conf/domain_audit.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++ src/conf/domain_audit.h | 7 ++++ src/libvirt_private.syms | 1 + src/qemu/qemu_hotplug.c | 17 +++++---- 5 files changed, 144 insertions(+), 6 deletions(-) -- 1.9.3

3 6

[libvirt] [PATCH] doc: Be more specific about semantics of _REUSE_EXT flag
by Peter Krempa 07 Jul '14

07 Jul '14

Snapshots and block-copy have a flag that forces qemu to re-use existing file. Our docs weren't exactly clear on what the existing file should contain for this to actually work. Re-word the docs a bit to state that the file needs to be pre-created in the desired format and the backing chain metadata needs to be set prior to handing it over to qemu. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1084360 --- src/libvirt.c | 12 +++++++----- tools/virsh.pod | 12 +++++++----- 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index b80b484..e7a6aca 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -18274,10 +18274,12 @@ virDomainSnapshotGetConnect(virDomainSnapshotPtr snapshot) * destination files already exist as a non-empty regular file, the * snapshot is rejected to avoid losing contents of those files. * However, if @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT, - * then the destination files must already exist and contain content - * identical to the source files (this allows a management app to - * pre-create files with relative backing file names, rather than the - * default of creating with absolute backing file names). + * then the destination files must be pre-created manually with + * the correct image format and metadata including backing store path. + * (this allows a management app to pre-create files with relative backing + * file names, rather than the default of creating with absolute backing + * file names). Note that setting incorrect metadata in the pre-created + * image may lead to the VM being unable to start. * * Be aware that although libvirt prefers to report errors up front with * no other effect, some hypervisors have certain types of failures where @@ -19731,7 +19733,7 @@ virDomainBlockPull(virDomainPtr dom, const char *disk, * by adding VIR_DOMAIN_BLOCK_REBASE_COPY_RAW to force the copy to be raw * (does not make sense with the shallow flag unless the source is also raw), * or by using VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT to reuse an existing file - * with initial contents identical to the backing file of the source (this + * which was pre-created with the correct format and metadata (this * allows a management app to pre-create files with relative backing file * names, rather than the default of absolute backing file names; as a * security precaution, you should generally only use reuse_ext with the diff --git a/tools/virsh.pod b/tools/virsh.pod index 1b6f3c4..39fe423 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -875,8 +875,8 @@ flattens the entire chain; but if I<--shallow> is specified, the copy shares the backing chain. If I<--reuse-external> is specified, then I<dest> must exist and have -contents identical to the resulting backing file (that is, it must -start with contents matching the backing file I<disk> if I<--shallow> +metadata identical to the resulting backing file (that is, it must +start with metadata matching the backing file I<disk> if I<--shallow> is used, otherwise it must start empty); this option is typically used to set up a relative backing file name in the destination. @@ -3165,7 +3165,8 @@ metadata again). If I<--reuse-external> is specified, and the snapshot XML requests an external snapshot with a destination of an existing file, then the -destination must exist, and is reused; otherwise, a snapshot is refused +destination must exist and be pre-created with correct format and +metadata. The file is then reused; otherwise, a snapshot is refused to avoid losing contents of the existing files. If I<--quiesce> is specified, libvirt will try to use guest agent @@ -3224,8 +3225,9 @@ results in the following XML: If I<--reuse-external> is specified, and the domain XML or I<diskspec> option requests an external snapshot with a destination of an existing -file, then the destination must exist, and is reused; otherwise, a -snapshot is refused to avoid losing contents of the existing files. +file, then the destination must exist and be pre-created with correct +format and metadata. The file is then reused; otherwise, a snapshot +is refused to avoid losing contents of the existing files. If I<--quiesce> is specified, libvirt will try to use guest agent to freeze and unfreeze domain's mounted file systems. However, -- 2.0.0

2 1

[libvirt] Follow-up on .so version number question
by Tony Asleson 07 Jul '14

07 Jul '14

Eric posted this a while back (ref: http://www.redhat.com/archives/libvir-list/2010-April/msg00226.html) without any apparent response/discussion. Can someone please elaborate on this? Thanks, Tony

2 1

[libvirt] new openvz driver (bossonvz)
by Bosson VZ 07 Jul '14

07 Jul '14

Hello, in the company I work for, we use openvz and qemu/kvm on our clusters side-by-side. To manage our domains, we used libvirt/qemu for qemu/kvm domains and vz tools for openvz domains in the past. This was very inconvinient since the management differed in many ways. So we have decided to unify our management and use libvirt exclusively. Since the openvz driver already included in libvirt lacks features that need, we have implemented a new libvirt backend driver for openvz called the bossonvz driver. Unlike the openvz driver, bossonvz is a complete, feature-rich stateful libvirt driver. It uses the libvirt driver API exclusively and communicates with the kernel directly, much like the LXC driver. The code is hugely inspired by the LXC driver and the Qemu driver, but adds a bit of functionality to the libvirt core too. More details and the source code can be found at http://bossonvz.bosson.eu/ The driver is completely independent of vz tools, it needs only a running vz kernel. One of the things, we are most proud of, is the possibility to access the domain's tty via VNC (hurray to uniform management web interfaces). Since the code was developed in-house (primarily for internal purposes), it is based on an older libvirt release (1.1.2). There are also some modifications to the libvirt core (virCommand) and the domain file (mount options syntax) which might need some redesign. At the moment I would like to get some feedback on the driver. In the future, I would like to see the driver merged upstream, and am prepared to do the work but I need to know if there is any interest in doing so. -- Cluster Design, s.r.o.

5 14

[libvirt] [PATCH v2] libxl: add discard support to libxl_device_disk
by Olaf Hering 07 Jul '14

07 Jul '14

Translate libvirt discard settings into libxl-4.5 discard settings. Signed-off-by: Olaf Hering <olaf(a)aepfle.de> --- v2: add cast to switch variable to let compiler check if the code handles all enum values src/libxl/libxl_conf.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 8eeaf82..bb9b53d 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -715,6 +715,33 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, return -1; } +static void +libxlDiskSetDiscard(libxl_device_disk *x_disk, int discard) +{ + if (!x_disk->readwrite) + return; +#if defined(LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_ENABLE) + switch ((enum virDomainDiskDiscard)discard) { + case VIR_DOMAIN_DISK_DISCARD_DEFAULT: + case VIR_DOMAIN_DISK_DISCARD_LAST: + break; + case VIR_DOMAIN_DISK_DISCARD_UNMAP: + libxl_defbool_set(&x_disk->discard_enable, true); + break; + case VIR_DOMAIN_DISK_DISCARD_IGNORE: + libxl_defbool_set(&x_disk->discard_enable, false); + break; + } +#else + if (discard == VIR_DOMAIN_DISK_DISCARD_DEFAULT) + return; + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("This version of libxenlight does not support " + "discard= option passing")); +#endif +} + + int libxlMakeDisk(virDomainDiskDefPtr l_disk, libxl_device_disk *x_disk) { @@ -829,6 +856,7 @@ libxlMakeDisk(virDomainDiskDefPtr l_disk, libxl_device_disk *x_disk) x_disk->removable = 1; x_disk->readwrite = !l_disk->readonly; x_disk->is_cdrom = l_disk->device == VIR_DOMAIN_DISK_DEVICE_CDROM ? 1 : 0; + libxlDiskSetDiscard(x_disk, l_disk->discard); /* An empty CDROM must have the empty format, otherwise libxl fails. */ if (x_disk->is_cdrom && !x_disk->pdev_path) x_disk->format = LIBXL_DISK_FORMAT_EMPTY;

2 1