- Devel - libvirt List Archives

[libvirt] [PATCH v4 0/4] Implement migrate-getmaxdowntime command
by Scott Garfinkle 26 Aug '17

26 Aug '17

Currently, the maximum tolerable downtime for a domain being migrated is write-only. This patch implements a way to query that value nondestructively. I've tried to incorporate the feedback from v3; however, I've left alone a couple of places where the feedback would have diverged from parallelism with the existing migrate-setdowntime help/info. Also, since the main use of this new command is likely to be (as in virt-manager) in combination with migrate-setmaxdowntime, I don't think it's going to really help to add an options to report this in some other unit other than milliseconds. To-do: Ought to revisit setmaxdowntime to use the new preferred qemu interface. Changes from [v3]: * Incorporated suggestions, including adding an error message * Added a patch to the news.xml file [v1} https://www.redhat.com/archives/libvir-list/2017-July/msg00908.html [v2} https://www.redhat.com/archives/libvir-list/2017-July/msg01010.html [v3} https://www.redhat.com/archives/libvir-list/2017-July/msg01301.html Scott Garfinkle (4) Add virDomainMigrateGetMaxDowntime public API qemu: Implement virDomainMigrateGetMaxDowntime virsh: Add support for virDomainMigrateGetMaxDowntime docs: document migrate-getmaxdowntime support --- docs/news.xml | 10 +++++++ include/libvirt/libvirt-domain.h | 4 +++ src/driver-hypervisor.h | 6 +++++ src/libvirt-domain.c | 41 ++++++++++++++++++++++++++++ src/libvirt_public.syms | 4 +++ src/qemu/qemu_driver.c | 58 ++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_monitor.h | 3 +++ src/qemu/qemu_monitor_json.c | 4 +++ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 16 ++++++++++- src/remote_protocol-structs | 8 ++++++ tools/virsh-domain.c | 42 +++++++++++++++++++++++++++++ tools/virsh.pod | 6 +++++ 13 files changed, 202 insertions(+), 1 deletion(-)

3 10

[libvirt] [PATCH 0/2] Some domain name handing improvements
by Martin Kletzander 25 Aug '17

25 Aug '17

It's not like anyone would hit any of those limitations, almost... Martin Kletzander (3): conf: Properly truncate wide character names in virDomainObjGetShortName qemu: Use short domain name in qemuDomainGetPreservedMountPath docs: Update news with domain name bug fixes docs/news.xml | 20 +++++++++++++++ src/conf/domain_conf.c | 30 +++++++++++++++++++--- src/qemu/qemu_domain.c | 10 ++++++-- .../qemuxml2argv-aarch64-virt-default-nic.args | 2 +- .../qemuxml2argv-hugepages-pages2.args | 4 +-- .../qemuxml2argv-hugepages-pages3.args | 5 ++-- .../qemuxml2argv-hugepages-pages5.args | 4 +-- .../qemuxml2argv-hugepages-pages6.args | 2 +- .../qemuxml2argv-pcie-expander-bus.args | 2 +- 9 files changed, 65 insertions(+), 14 deletions(-) -- 2.14.1

2 7

[libvirt] [PATCH 0/4] Make it easier to clean up after using virBuffer
by Martin Kletzander 25 Aug '17

25 Aug '17

There are many places in the code where virBufferCheckError() is used and then, right after that, virBufferContentAndReset() is called. The former has ATTRIBUTE_RETURN_CHECK, so every occurrence just checks that. However, if the return value of the latter is also the return value of the current function, there is no need to duplicate the work and act upon the error twice. This series proposes the idea of virCheckError being used for only reporting the error [1/4] and shows an example commit on how to clean up existing functions [2/4] so that it can be posted to our wiki under https://wiki.libvirt.org/page/BiteSizedTasks and linked from there. Further enhancements could go a step further and create one function (actually a macro the same way CheckError is done) and wrap those two lines in one so that it is even shorter. This, however, is not meant to be part of this series. Patches [3/4] and [4/4] utilize this for miscellaneous clean-ups in src/conf/. Martin Kletzander (4): util: Umark virBufferCheckErrorInternal as ATTRIBUTE_RETURN_CHECK util: Use virBufferCheckError to its full potential. conf: Clean up and report error in virDomainCapsFormat conf: Clean up and report error in virDomainGenerateMachineName src/conf/domain_capabilities.c | 68 +++++++++++++++++------------------------- src/conf/domain_conf.c | 16 +++++----- src/util/virbitmap.c | 6 +--- src/util/virbuffer.h | 2 +- 4 files changed, 37 insertions(+), 55 deletions(-) -- 2.14.1

2 8

[libvirt] [PATCH] qemu: Prevent isolation group-related guest disappearance
by Andrea Bolognani 25 Aug '17

25 Aug '17

We can't retrieve the isolation group of a device that's not present in the system. However, it's very common for VFs to be created late in the boot, so they might not be present yet when libvirtd starts, which would cause the guests using them to disappear. If a PCI address has already been set for the host device in question, we can assume that it either existed at some point in the past or the user is assigning addresses manually: in both cases, we should not error out and just ignore the (temporary) failure. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1484254 Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/qemu/qemu_domain_address.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index 16bf0cdf9..7f12f186b 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -1012,6 +1012,18 @@ qemuDomainFillDeviceIsolationGroup(virDomainDefPtr def, tmp = virPCIDeviceAddressGetIOMMUGroupNum(hostAddr); if (tmp < 0) { + /* If there's already a PCI address assigned to the device + * we move on instead of erroring out. + * + * This means we still don't allow non-existing host + * devices to be assigned to guests; however, if the host + * device existed at some point in the past but no longer + * does, which can happen very easily when dealing with VFs, + * we prevent the guest from disappearing and give the user + * an opportunity to edit its configuration */ + if (virDeviceInfoPCIAddressPresent(info)) + goto skip; + virReportError(VIR_ERR_INTERNAL_ERROR, _("Can't look up isolation group for host device " "%04x:%02x:%02x.%x"), -- 2.13.5

3 3

[libvirt] [PATCH] Revert "maint: Update to latest gnulib"
by Erik Skultety 25 Aug '17

25 Aug '17

Revert @f8172388c which broke the build on Centos 6, because of old autoconf (< 2.63b) not properly quoting arguments for shell. --- So, the last working commit is cbc700208, but I didn't want to revert to that one directly, since I'd like to poke gnulib about the issue first and find a proper solution. Anyhow, pushed under the build breaker rule. .gnulib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gnulib b/.gnulib index 47c634c05..ce4ee4cbb 160000 --- a/.gnulib +++ b/.gnulib @@ -1 +1 @@ -Subproject commit 47c634c05a946651e2834dcf0cd7cd0dc7a21d3c +Subproject commit ce4ee4cbb596a9d7de2786cf8c48cf62a4edede7 -- 2.13.3

2 3

[libvirt] libvirt 3.5.0 locks
by Vasiliy Tolstov 25 Aug '17

25 Aug '17

Hi. I'm testing libvirt 3.5.0 and have many issues like this: Jul 14 09:47:25 cn25 libvirtd[18820]: 2017-07-14 06:47:25.598+0000: 18841: error : qemuDomainObjBeginJobInternal:3872 : Timed out during operation: cannot acquire state change lock (held by remoteDispatchConnectGetAllDomainStats) Jul 14 09:47:25 cn25 libvirtd[18820]: 2017-07-14 06:47:25.598+0000: 18841: warning : qemuDomainObjBeginJobInternal:3860 : Cannot start job (query, none) for domain 147565; current job is (query, none) owned by (18828 remoteDispatchConnectGetAllDomainStats, 0 <null>) for (53670s, 0s) Jul 14 09:46:55 cn25 libvirtd[18820]: 2017-07-14 06:46:55.576+0000: 18836: error : virNetDevTapInterfaceStats:751 : internal error: /proc/net/dev: Interface not found Jul 14 09:46:55 cn25 libvirtd[18820]: 2017-07-14 06:46:55.542+0000: 18832: warning : qemuGetProcessInfo:1428 : cannot parse process status data Jul 14 09:46:31 cn25 libvirtd[18820]: 2017-07-14 06:46:31.050+0000: 18838: warning : qemuGetProcessInfo:1428 : cannot parse process status data Domain in status in shutdown as i see tap device already removed from the system, so virNetDevTapInterfaceStats says right info. My question - why lock now released and why only libvirt restart can helps in this case -- Vasiliy Tolstov, e-mail: v.tolstov(a)selfip.ru

2 8

[libvirt] [PATCH v2] virt-host-validate: Fix warning for IOMMU detection on PPC
by Nitesh Konkar 25 Aug '17

25 Aug '17

Fix the warning generated on PPC by virt-host-validate for IOMMU Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com> --- tools/virt-host-validate-common.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/tools/virt-host-validate-common.c b/tools/virt-host-validate-common.c index 6faed04..51fa8c0 100644 --- a/tools/virt-host-validate-common.c +++ b/tools/virt-host-validate-common.c @@ -35,6 +35,7 @@ #include "virfile.h" #include "virt-host-validate-common.h" #include "virstring.h" +#include "virarch.h" #define VIR_FROM_THIS VIR_FROM_NONE @@ -442,8 +443,7 @@ int virHostValidateIOMMU(const char *hvname, virBitmapPtr flags; struct stat sb; const char *bootarg = NULL; - bool isAMD = false, isIntel = false; - + bool isAMD = false, isIntel = false, isPPC = false; flags = virHostValidateGetCPUFlags(); if (flags && virBitmapIsBitSet(flags, VIR_HOST_VALIDATE_CPU_FLAG_VMX)) @@ -453,9 +453,10 @@ int virHostValidateIOMMU(const char *hvname, virBitmapFree(flags); - virHostMsgCheck(hvname, "%s", _("for device assignment IOMMU support")); + isPPC = ARCH_IS_PPC64(virArchFromHost()); if (isIntel) { + virHostMsgCheck(hvname, "%s", _("for device assignment IOMMU support")); if (access("/sys/firmware/acpi/tables/DMAR", F_OK) == 0) { virHostMsgPass(); bootarg = "intel_iommu=on"; @@ -467,6 +468,7 @@ int virHostValidateIOMMU(const char *hvname, return -1; } } else if (isAMD) { + virHostMsgCheck(hvname, "%s", _("for device assignment IOMMU support")); if (access("/sys/firmware/acpi/tables/IVRS", F_OK) == 0) { virHostMsgPass(); bootarg = "iommu=pt iommu=1"; @@ -477,6 +479,8 @@ int virHostValidateIOMMU(const char *hvname, "hardware platform"); return -1; } + } else if (isPPC) { + /* Empty Block */ } else { virHostMsgFail(level, "Unknown if this platform has IOMMU support"); -- 2.7.4

2 3

[libvirt] [PATCH] libxl: Avoid a variable named 'stat'
by George Dunlap 24 Aug '17

24 Aug '17

Using a variable named 'stat' clashes with the system function 'stat()' causing compiler warnings on some platforms: libxl/libxl_driver.c: In function 'libxlDomainBlockStatsVBD': libxl/libxl_driver.c:5387: error: declaration of 'stat' shadows a global declaration [-Wshadow] /usr/include/sys/stat.h:455: error: shadowed declaration is here [-Wshadow] Signed-off-by: George Dunlap <george.dunlap(a)citrix.com> --- CC: Daniel P. Berrange <berrange(a)redhat.com> CC: Jim Fehlig <jfehlig(a)suse.com> CC: xen-devel(a)xenproject.org CC: libvir-list(a)redhat.com --- src/libxl/libxl_driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index c261e2155..4c7775358 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -5374,7 +5374,7 @@ libxlDomainBlockStatsVBD(virDomainObjPtr vm, int devno = libxlDiskPathToID(dev); int size; char *path, *name, *val; - unsigned long long stat; + unsigned long long status; path = name = val = NULL; if (devno < 0) { @@ -5401,12 +5401,12 @@ libxlDomainBlockStatsVBD(virDomainObjPtr vm, # define LIBXL_SET_VBDSTAT(FIELD, VAR, MUL) \ if ((virAsprintf(&name, "%s/"FIELD, path) < 0) || \ (virFileReadAll(name, 256, &val) < 0) || \ - (sscanf(val, "%llu", &stat) != 1)) { \ + (sscanf(val, "%llu", &status) != 1)) { \ virReportError(VIR_ERR_OPERATION_FAILED, \ _("cannot read %s"), name); \ goto cleanup; \ } \ - VAR += (stat * MUL); \ + VAR += (status * MUL); \ VIR_FREE(name); \ VIR_FREE(val); -- 2.14.1

3 2

[libvirt] [PATCH] qemu: Report error on failure to set isolation group
by Andrea Bolognani 24 Aug '17

24 Aug '17

This is more user-friendly because the error will be displayed directly instead of being buried in the log. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/qemu/qemu_domain_address.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index 8066ed123..16bf0cdf9 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -1012,10 +1012,11 @@ qemuDomainFillDeviceIsolationGroup(virDomainDefPtr def, tmp = virPCIDeviceAddressGetIOMMUGroupNum(hostAddr); if (tmp < 0) { - VIR_WARN("Can't look up isolation group for host device " - "%04x:%02x:%02x.%x", - hostAddr->domain, hostAddr->bus, - hostAddr->slot, hostAddr->function); + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Can't look up isolation group for host device " + "%04x:%02x:%02x.%x"), + hostAddr->domain, hostAddr->bus, + hostAddr->slot, hostAddr->function); goto cleanup; } @@ -1056,9 +1057,11 @@ qemuDomainFillDeviceIsolationGroup(virDomainDefPtr def, tmp = qemuDomainFindUnusedIsolationGroup(def); if (tmp == 0) { - VIR_WARN("Can't obtain usable isolation group for interface " - "configured to use hostdev-backed network '%s'", - iface->data.network.name); + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Can't obtain usable isolation group for " + "interface configured to use hostdev-backed " + "network '%s'"), + iface->data.network.name); goto cleanup; } -- 2.13.5

2 1

[libvirt] Question about "f16c", "rdrand" and "vme" in cpu_map.xml
by Jay Zhou 24 Aug '17

24 Aug '17

Hi all, "f16c", "rdrand" and "vme" are all standard features, the IvyBridge CPU model has these three features in the file of src/cpu/cpu_map.xml, but the higher model of Haswell-noTSX, Haswell, Broadwell-noTSX and Broadwell do not, which makes it incompatible. BTW, I noticed that "f16c", "rdrand" and "vme" are a part of features of Haswell-noTSX, Haswell, Broadwell-noTSX and Broadwell in QEMU. The commit 732d3d147adecb867f62c67ab3743c0aefd87e50(which introduces the Haswell-noTSX CPU model in libvirt) said that: "Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant." I do not get the point "it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant" clearly. Could anyone explain it more explicitly? Looking forward to your replay. Thanks, Jay

2 1