[libvirt] [PATCH] nwfilter: fix lock order deadlock
by Maxim Nestratov
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
9 years
[libvirt] [PATCH] qemu: don't refuse to undefine a guest with NVRAM file
by Daniel P. Berrange
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
9 years
[libvirt] [PATCH v6 REBASE 0/5] vz: add migration support
by Nikolay Shirokovskiy
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
9 years
[libvirt] [PATCH 0/2] correct libxl config file convert
by Chunyan Liu
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
9 years
[libvirt] [PATCH 0/2] libxl: support pvusb
by Chunyan Liu
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
9 years
[libvirt] [PATCH 0/8] domain: Support <address type='pci'/> allocation
by Cole Robinson
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
9 years
[libvirt] [PATCH v2 0/3] qemu: Fix hotplug of guest agent
by Martin Kletzander
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
9 years
[libvirt] [PATCH 0/7] Introduce APIs to get/set client processing controls
by Erik Skultety
- 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
9 years
[libvirt] [PATCH] storage: Fix regression cloning volume into a logical pool
by John Ferlan
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
9 years
