April 2016 - Devel - libvirt List Archives

[libvirt] [PATCH] nwfilter: fix lock order deadlock
by Maxim Nestratov 24 May '16

24 May '16

Below is backtraces of two deadlocked threads: thread #1: virDomainConfVMNWFilterTeardown virNWFilterTeardownFilter lock updateMutex <------------ _virNWFilterTeardownFilter try to lock interface <---------- thread #2: learnIPAddressThread lock interface <------- virNWFilterInstantiateFilterLate try to lock updateMutex <---------- The problem is fixed by unlocking interface before calling virNWFilterInstantiateFilterLate to avoid updateMutex and interface ordering deadlocks. Otherwise we are going to instantiate the filter while holding interface lock, which will try to lock updateMutex, and if some other thread instantiating a filter in parallel is holding updateMutex and is trying to lock interface, both will deadlock. Also it is safe to unlock interface before virNWFilterInstantiateFilterLate because learnIPAddressThread stopped capturing packets and applied necessary rules on the interface, while instantiating a new filter doesn't require a locked interface. Signed-off-by: Maxim Nestratov <mnestratov(a)virtuozzo.com> --- src/nwfilter/nwfilter_learnipaddr.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/nwfilter/nwfilter_learnipaddr.c b/src/nwfilter/nwfilter_learnipaddr.c index 1adbadb..cfd92d9 100644 --- a/src/nwfilter/nwfilter_learnipaddr.c +++ b/src/nwfilter/nwfilter_learnipaddr.c @@ -611,6 +611,16 @@ learnIPAddressThread(void *arg) sa.data.inet4.sin_addr.s_addr = vmaddr; char *inetaddr; + /* It is necessary to unlock interface here to avoid updateMutex and + * interface ordering deadlocks. Otherwise we are going to + * instantiate the filter, which will try to lock updateMutex, and + * some other thread instantiating a filter in parallel is holding + * updateMutex and is trying to lock interface, both will deadlock. + * Also it is safe to unlock interface here because we stopped + * capturing and applied necessary rules on the interface, while + * instantiating a new filter doesn't require a locked interface.*/ + virNWFilterUnlockIface(req->ifname); + if ((inetaddr = virSocketAddrFormat(&sa)) != NULL) { if (virNWFilterIPAddrMapAddIPAddr(req->ifname, inetaddr) < 0) { VIR_ERROR(_("Failed to add IP address %s to IP address " @@ -636,11 +646,11 @@ learnIPAddressThread(void *arg) req->ifname, req->ifindex); techdriver->applyDropAllRules(req->ifname); + virNWFilterUnlockIface(req->ifname); } VIR_DEBUG("pcap thread terminating for interface %s", req->ifname); - virNWFilterUnlockIface(req->ifname); err_no_lock: virNWFilterDeregisterLearnReq(req->ifindex); -- 2.4.3

5 10

[libvirt] [PATCH] qemu: don't refuse to undefine a guest with NVRAM file
by Daniel P. Berrange 23 May '16

23 May '16

The undefine operation should always be allowed to succeed regardless of whether any NVRAM file exists. ie we should not force the application to use the VIR_DOMAIN_UNDEFINE_NVRAM flag. It is valid for the app to decide it wants the NVRAM file left on disk, in the same way that disk images are left on disk at undefine. --- src/qemu/qemu_driver.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index bec05d4..302bf48 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6985,19 +6985,13 @@ qemuDomainUndefineFlags(virDomainPtr dom, if (!virDomainObjIsActive(vm) && vm->def->os.loader && vm->def->os.loader->nvram && - virFileExists(vm->def->os.loader->nvram)) { - if (!(flags & VIR_DOMAIN_UNDEFINE_NVRAM)) { - virReportError(VIR_ERR_OPERATION_INVALID, "%s", - _("cannot delete inactive domain with nvram")); - goto cleanup; - } - - if (unlink(vm->def->os.loader->nvram) < 0) { - virReportSystemError(errno, - _("failed to remove nvram: %s"), - vm->def->os.loader->nvram); - goto cleanup; - } + virFileExists(vm->def->os.loader->nvram) && + (flags & VIR_DOMAIN_UNDEFINE_NVRAM) && + (unlink(vm->def->os.loader->nvram) < 0)) { + virReportSystemError(errno, + _("failed to remove nvram: %s"), + vm->def->os.loader->nvram); + goto cleanup; } if (virDomainDeleteConfig(cfg->configDir, cfg->autostartDir, vm) < 0) -- 2.1.0

6 17

[libvirt] [PATCH v6 REBASE 0/5] vz: add migration support
by Nikolay Shirokovskiy 18 May '16

18 May '16

Difference from v5 ================== 1. managed case is implemented 2. p2p follows managed migration flow now 3. 'vz: fix const correctness case' is needed to implement managed case. 4. misc options that are always on for vz (--live, --compressed) are not required to be set explicitly. 5. --offline is not supported anymore but migration of inactive domains is possible without this option set. Nikolay Shirokovskiy (5): vz: save session uuid on login vz: fix const correctness case vz: implement managed migration vz: implement p2p migration vz: cleanup: define vz format of uuids src/vz/vz_driver.c | 557 +++++++++++++++++++++++++++++++++++++++++++++++++++++ src/vz/vz_sdk.c | 90 +++++++-- src/vz/vz_sdk.h | 6 + src/vz/vz_utils.c | 2 +- src/vz/vz_utils.h | 6 +- 5 files changed, 645 insertions(+), 16 deletions(-) -- 1.8.3.1

2 14

[libvirt] [PATCH v2 0/3] Cosmetic changes to SPICE QEMU commandline
by Christophe Fergeau 17 May '16

17 May '16

Hey, This is a v2 of the series I previously sent. Changes since v1: - much nicer cmdline generation in patch 1/3 - improved commit log in 1/3 - moved part of patch 1/3 to 3/3 - added test case in 3/3 Christophe

3 14

[libvirt] [PATCH 0/2] correct libxl config file convert
by Chunyan Liu 17 May '16

17 May '16

Correct libxl config file type=vif handling. Chunyan Liu (2): xenFormatNet: correct `type=netfront' to 'type=vif' to match libxl xlconfigtest: add test case for type=vif in xl format src/xenconfig/xen_common.c | 38 ++++++++++++++++++----------- src/xenconfig/xen_common.h | 7 +++--- src/xenconfig/xen_xl.c | 4 +-- src/xenconfig/xen_xm.c | 8 +++--- tests/xlconfigdata/test-vif-typename.cfg | 25 +++++++++++++++++++ tests/xlconfigdata/test-vif-typename.xml | 42 ++++++++++++++++++++++++++++++++ tests/xlconfigtest.c | 1 + 7 files changed, 102 insertions(+), 23 deletions(-) create mode 100644 tests/xlconfigdata/test-vif-typename.cfg create mode 100644 tests/xlconfigdata/test-vif-typename.xml -- 2.1.4

4 17

[libvirt] [PATCH 0/2] libxl: support pvusb
by Chunyan Liu 16 May '16

16 May '16

This patch series is to support pvusb in libxl driver. Chunyan Liu (2): libxl: support creating guest with USB hostdev libxl: support hotplug USB host device src/libxl/libxl_conf.c | 71 +++++++++++++++++++++++++ src/libxl/libxl_conf.h | 3 ++ src/libxl/libxl_domain.c | 4 +- src/libxl/libxl_driver.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 206 insertions(+), 4 deletions(-) -- 2.1.4

4 10

[libvirt] [PATCH 0/8] domain: Support <address type='pci'/> allocation
by Cole Robinson 15 May '16

15 May '16

This patch series allows the user to specify bare device <address type='pci'/> to explicitly request PCI address allocation. This has several uses, but the motivating one is providing an easy way to request PCI address allocation where it normally isn't the default address type, like for aarch64 VMs. Cole Robinson (8): domain: Add virDomainDefAddImplicitDevices domain: conf: Export virDomainDefPostParseDevices qemu: Assign device addresses in PostParse util: xml: add virXMLPropertyCount tests: Add failure flags to CompareDomainXML2XML domain: Make <address type='pci'/> request address allocation qemu: Wire up address type=pci auto_allocate tests: qemu: test <address type='pci'/> with aarch64 docs/schemas/domaincommon.rng | 5 +- src/conf/domain_conf.c | 81 +++++++++++++++++----- src/conf/domain_conf.h | 8 ++- src/libvirt_private.syms | 3 +- src/qemu/qemu_domain.c | 13 +++- src/qemu/qemu_domain_address.c | 47 +++++++++++++ src/qemu/qemu_driver.c | 6 +- src/util/virxml.c | 17 +++++ src/util/virxml.h | 1 + src/vmx/vmx.c | 2 +- src/vz/vz_sdk.c | 2 +- tests/bhyvexml2xmltest.c | 2 +- .../generic-pci-autofill-addr.xml | 27 ++++++++ tests/genericxml2xmltest.c | 17 +++-- tests/lxcxml2xmltest.c | 2 +- .../qemuargv2xmldata/qemuargv2xml-pseries-disk.xml | 4 +- ...l2argv-aarch64-virtio-pci-manual-addresses.args | 4 +- ...ml2argv-aarch64-virtio-pci-manual-addresses.xml | 5 ++ .../qemuxml2argv-pci-autofill-addr.args | 24 +++++++ .../qemuxml2argv-pci-autofill-addr.xml | 44 ++++++++++++ tests/qemuxml2argvtest.c | 21 +++--- ...2xmlout-aarch64-virtio-pci-manual-addresses.xml | 5 ++ .../qemuxml2xmlout-pci-autofill-addr.xml | 46 ++++++++++++ tests/qemuxml2xmltest.c | 18 +++-- tests/testutils.c | 10 ++- tests/testutils.h | 4 ++ 26 files changed, 359 insertions(+), 59 deletions(-) create mode 100644 tests/genericxml2xmlindata/generic-pci-autofill-addr.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-autofill-addr.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-autofill-addr.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pci-autofill-addr.xml -- 2.5.0

3 21

[libvirt] [PATCH v2 0/3] qemu: Fix hotplug of guest agent
by Martin Kletzander 14 May '16

14 May '16

v2: - mostly a rebase, it was almost ACKed but not completely, just to make sure let's see it again with everything done. - use /tmp for paths in tests (automatically fixed by rebasing on top of commit 1893b6df117b) v1: - https://www.redhat.com/archives/libvir-list/2016-March/msg01454.html Martin Kletzander (3): qemuhotplugtest: Allow testing of live data qemu: Move channel path generation out of command creation qemu: Generate channel target paths on hotplug as well src/qemu/qemu_command.c | 25 ++-------- src/qemu/qemu_command.h | 5 +- src/qemu/qemu_domain.c | 20 ++++++++ src/qemu/qemu_domain.h | 4 ++ src/qemu/qemu_hotplug.c | 3 ++ src/qemu/qemu_process.c | 12 +++-- tests/qemuhotplugtest.c | 37 ++++++++++---- .../qemuhotplug-hotplug-base+qemu-agent-detach.xml | 58 ++++++++++++++++++++++ .../qemuhotplug-hotplug-base+qemu-agent.xml | 58 ++++++++++++++++++++++ .../qemuhotplug-qemu-agent-detach.xml | 5 ++ .../qemuhotplugtestdata/qemuhotplug-qemu-agent.xml | 5 ++ 11 files changed, 193 insertions(+), 39 deletions(-) create mode 100644 tests/qemuhotplugtestdata/qemuhotplug-hotplug-base+qemu-agent-detach.xml create mode 100644 tests/qemuhotplugtestdata/qemuhotplug-hotplug-base+qemu-agent.xml create mode 100644 tests/qemuhotplugtestdata/qemuhotplug-qemu-agent-detach.xml create mode 100644 tests/qemuhotplugtestdata/qemuhotplug-qemu-agent.xml -- 2.8.1

2 8

[libvirt] [PATCH 0/7] Introduce APIs to get/set client processing controls
by Erik Skultety 10 May '16

10 May '16

- APIs enable retrieval of values for maximum number of clients allowed to be connected, maximum number of clients allowed to wait for authentication, as well as current (dynamic) values for both cases; expectedly, setter only allows to set the limits available through libvirtd.conf - until patch "makefile: Move include/Makefile.am to include/libvirt/Makefile.am" is reviewed an pushed, config.status must be run after after 1/7 for a successful build. Erik Skultety (7): libvirt-host: Move virTypedParam* to libvirt-common admin: Enable usage of typed parameters virnetserver: Introduce client processing controls getters admin: Introduce some public constants related to client processing controls admin: Introduce virAdmServerGetClientProcessingControls admin: Introduce virAdmServerSetClientProcessingControls virt-admin: Introduce commands srv-clients-info and srv-clients-set cfg.mk | 2 +- daemon/admin.c | 85 ++++++++++++++++ daemon/admin_server.c | 77 +++++++++++++++ daemon/admin_server.h | 10 ++ include/libvirt/libvirt-admin.h | 52 ++++++++++ include/libvirt/libvirt-common.h.in | 185 +++++++++++++++++++++++++++++++++++ include/libvirt/libvirt-host.h | 186 ------------------------------------ src/admin/admin_protocol.x | 54 ++++++++++- src/admin/admin_remote.c | 81 ++++++++++++++++ src/admin_protocol-structs | 45 +++++++++ src/libvirt-admin.c | 89 +++++++++++++++++ src/libvirt_admin_private.syms | 3 + src/libvirt_admin_public.syms | 2 + src/rpc/virnetserver.c | 82 ++++++++++++++++ src/rpc/virnetserver.h | 9 ++ tools/virt-admin.c | 182 +++++++++++++++++++++++++++++++++++ 16 files changed, 956 insertions(+), 188 deletions(-) -- 2.4.11

2 9

[libvirt] [PATCH] storage: Fix regression cloning volume into a logical pool
by John Ferlan 10 May '16

10 May '16

https://bugzilla.redhat.com/show_bug.cgi?id=1318993 Commit id 'dd519a294' caused a regression cloning a volume into a logical pool by removing just the 'allocation' adjustment during storageVolCreateXMLFrom. Combined with the change to not require the new volume input XML to have a capacity listed (commit id 'e3f1d2a8') left the possibility that a copy from a larger volume into a smaller volume would create a thin/sparse logical volume. If a thin lv becomes fully populated, then LVM will set the partition 'inactive' and the subsequent fdatasync() would fail. In order to fix this in a backend agnostic manner, only adjust the new capacity if not provided. Likewise, if the new allocation is not provided, then use the capacity value as we document that if omitted, the volume will be fully allocated at time of creation. For a logical backend, that creation time is 'createVol', while for a file backend, creation doesn't set the size, but the 'createRaw' called during buildVolFrom will decide whether the file is sparse or not based on the provided capacity and allocation value. For volume clones that provide different allocation and capacity values to allow for sparse files, there is no change. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- NOTE: Related bz's to previous changes: https://bugzilla.redhat.com/show_bug.cgi?id=1130739 https://bugzilla.redhat.com/show_bug.cgi?id=1298065 I have tested using 'virsh vol-clone' and 'virt-clone' with and without this patch applied. Both tests have the same results for the 'qemu-img info' on the cloned file. src/storage/storage_driver.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index fcc0991..4415a4c 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2034,11 +2034,22 @@ storageVolCreateXMLFrom(virStoragePoolPtr obj, goto cleanup; } - /* Use the original volume's capacity in case the new capacity - * is less than that, or it was omitted */ - if (newvol->target.capacity < origvol->target.capacity) + /* Use the original volume's capacity if the new capacity was omitted. + * If the provided newvol capacity is less than original, we cannot just + * use the original since the subsequent createVol has "competing needs" + * for backends. A logical volume backend could then create a thin lv + * that has different characteristics when copying from the original + * volume than perhaps a raw disk file. */ + if (newvol->target.capacity == 0) newvol->target.capacity = origvol->target.capacity; + /* If the new allocation is 0, then use capacity as it's specifically + * documented "If omitted when creating a volume, the volume will be + * fully allocated at time of creation.". This is especially important + * for logical volume creation. */ + if (newvol->target.allocation == 0) + newvol->target.allocation = newvol->target.capacity; + if (!backend->buildVolFrom) { virReportError(VIR_ERR_NO_SUPPORT, "%s", _("storage pool does not support" -- 2.5.5

3 5