September 2020 - Devel - libvirt List Archives

large number of hot plug disks
by Alexander Wels 08 Sep '20

08 Sep '20

Hi, I am working on a project, and one of the requirements is that I can hotplug a large number of disks. Think several dozens to potentially 100+. The guest OS will be some linux flavor so it should have no problem with a large number of disks. During my experimentation I quickly ran into the "No available PCI slots" limit. I found https://libvirt.org/pci-hotplug.html explaining to me why the limit is there. Now I could add a bunch of pcie-root-ports ahead of time, but there is likely a limit to that as well. So before I go down some crazy paths, I figured I would ask on here if there is a better plan than adding a bunch of root ports for adding a large number of hotplugged disks? Thanks, Alexander

3 4

[libvirt PATCH] docs: Rephrase the video 'none' type to clarify the reasoning
by Erik Skultety 08 Sep '20

08 Sep '20

Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- docs/formatdomain.rst | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) This is a tiny follow-up improvement resulting from [1] as I felt the paragraph wasn't clear enough + there were a couple of typographical issues. [1] https://www.redhat.com/archives/libvir-list/2020-September/msg00329.html diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 1979dfb8d3..cf3ccbecc5 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -5784,13 +5784,16 @@ A video device. value "vga", "cirrus", "vmvga", "xen", "vbox", "qxl" ( :since:`since 0.8.6` ), "virtio" ( :since:`since 1.3.0` ), "gop" ( :since:`since 3.2.0` ), "bochs" ( :since:`since 5.6.0` ), "ramfb" ( :since:`since 5.9.0` ), or "none" ( - :since:`since 4.6.0` , depending on the hypervisor features available. The - purpose of the type ``none`` is to instruct libvirt not to add a default - video device in the guest (see the paragraph above). This legacy behaviour - can be inconvenient in cases where GPU mediated devices are meant to be the - only rendering device within a guest and so specifying another ``video`` - device along with type ``none``. Refer to Host device assignment to see how - to add a mediated device into a guest. + :since:`since 4.6.0`) , depending on the hypervisor features available. + + Note: The purpose of the type ``none`` is to instruct libvirt not to add a + default video device in the guest (see the ``video`` element description + above), since such behaviour is inconvenient in cases where GPU mediated + devices are meant to be the only rendering device within a guest. If this + is your use case specify a ``none`` type ``video`` device in the XML to stop + the default behaviour. Refer to `Host device assignment + <#host-device-assignment>`__ to see how to add a mediated device into a + guest. You can provide the amount of video memory in kibibytes (blocks of 1024 bytes) using ``vram``. This is supported only for guest type of "vz", "qemu", -- 2.26.2

3 3

[PATCH] rpm: Remove pointless explicit dependency on 'readline'
by Neal Gompa 08 Sep '20

08 Sep '20

The 'readline' package only contains the library, which rpm is already generating the (stricter) correct dependency for. Signed-off-by: Neal Gompa <ngompa13(a)gmail.com> --- libvirt.spec.in | 2 -- 1 file changed, 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index d124a7ce45..379cf0d9be 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -891,7 +891,6 @@ capabilities of VirtualBox %package client Summary: Client side utilities of the libvirt library Requires: %{name}-libs = %{version}-%{release} -Requires: readline # Needed by /usr/libexec/libvirt-guests.sh script. Requires: gettext # Needed by virt-pki-validate script. @@ -918,7 +917,6 @@ Shared libraries for accessing the libvirt daemon. %package admin Summary: Set of tools to control libvirt daemon Requires: %{name}-libs = %{version}-%{release} -Requires: readline %if %{with_bash_completion} Requires: %{name}-bash-completion = %{version}-%{release} %endif -- 2.26.2

2 1

[PATCH] wireshark: Prefer ws_version.h over config.h
by Michal Privoznik 08 Sep '20

08 Sep '20

A wireshark plugin must declare what major and minor version it was built with as these are checked when wireshark loads plugins. On the top of that, we use major + minor + micro to adapt to changed API between releases. So far, we were getting these version numbers from wireshark/config.h. And while most distributions install wireshark/config.h file some don't. On distros shipping it it's hack^Wsaved during built by packaging system and installed later. But some distros are not doing that. At least not for new enough wireshark because as of wireshark's commit v2.9.0~1273 the ws_version.h is installed which contains the version macros we need and is installed by wireshark itself. But of course, some distros which have new enough wireshark packaged do not ship ws_version.h and stick to the hack. That is why we can't simply bump the minimal version and switch to the new header file. We need a configure check and adopt our code to deal with both ways. At least for the time being. Based on Andrea's original patch: https://www.redhat.com/archives/libvir-list/2020-September/msg00156.html Closes: https://gitlab.com/libvirt/libvirt/-/issues/74 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- meson.build | 6 ++++++ tools/wireshark/src/packet-libvirt.c | 1 - tools/wireshark/src/plugin.c | 21 +++++++++++++++------ 3 files changed, 21 insertions(+), 7 deletions(-) diff --git a/meson.build b/meson.build index 1eadea33bf..33eaa9ff56 100644 --- a/meson.build +++ b/meson.build @@ -1472,6 +1472,12 @@ if wireshark_dep.found() # Since wireshark 2.5.0 plugins can't live in top level plugindir but have # to be under one of ["epan", "wiretap", "codecs"] subdir. The first one looks okay. wireshark_plugindir = wireshark_plugindir / 'epan' + + # Wireshark is installing ws_version.h since v2.9.0, but some distributions + # are not shipping it. + if cc.has_header('wireshark/ws_version.h') + conf.set('WITH_WS_VERSION', 1) + endif endif # On MinGW portablexdr provides XDR functions, on linux they are diff --git a/tools/wireshark/src/packet-libvirt.c b/tools/wireshark/src/packet-libvirt.c index 9f3c7f650d..965f1f5482 100644 --- a/tools/wireshark/src/packet-libvirt.c +++ b/tools/wireshark/src/packet-libvirt.c @@ -18,7 +18,6 @@ */ #include <config.h> -#include <wireshark/config.h> #include <wireshark/epan/proto.h> #include <wireshark/epan/packet.h> #include <wireshark/epan/dissectors/packet-tcp.h> diff --git a/tools/wireshark/src/plugin.c b/tools/wireshark/src/plugin.c index 504e4383a7..13af1b6a73 100644 --- a/tools/wireshark/src/plugin.c +++ b/tools/wireshark/src/plugin.c @@ -14,7 +14,16 @@ #include <gmodule.h> -#include <wireshark/config.h> +#ifdef WITH_WS_VERSION +# include <wireshark/ws_version.h> +#else +# include <wireshark/config.h> +# define WIRESHARK_VERSION_MAJOR VERSION_MAJOR +# define WIRESHARK_VERSION_MINOR VERSION_MINOR +# define WIRESHARK_VERSION_MICRO VERSION_MICRO +#endif + +#define HAVE_PLUGINS 1 #include <wireshark/epan/proto.h> /* plugins are DLLs */ #define WS_BUILD_DLL @@ -26,9 +35,9 @@ #define PLUGIN_VERSION VERSION #define WIRESHARK_VERSION \ - ((VERSION_MAJOR * 1000 * 1000) + \ - (VERSION_MINOR * 1000) + \ - (VERSION_MICRO)) + ((WIRESHARK_VERSION_MAJOR * 1000 * 1000) + \ + (WIRESHARK_VERSION_MINOR * 1000) + \ + (WIRESHARK_VERSION_MICRO)) #if WIRESHARK_VERSION < 2005000 @@ -69,8 +78,8 @@ void proto_register_libvirt(void); void proto_reg_handoff_libvirt(void); WS_DLL_PUBLIC_DEF const gchar plugin_version[] = PLUGIN_VERSION; -WS_DLL_PUBLIC_DEF const int plugin_want_major = VERSION_MAJOR; -WS_DLL_PUBLIC_DEF const int plugin_want_minor = VERSION_MINOR; +WS_DLL_PUBLIC_DEF const int plugin_want_major = WIRESHARK_VERSION_MAJOR; +WS_DLL_PUBLIC_DEF const int plugin_want_minor = WIRESHARK_VERSION_MINOR; WS_DLL_PUBLIC void plugin_register(void); -- 2.26.2

3 2

[PATCH] virnuma: Report error when NUMA -> CPUs translation fails
by Michal Privoznik 08 Sep '20

08 Sep '20

When starting a domain with <numatune/> set libvirt translates given NUMA nodes into a set of host CPUs which is then used to QEMU process affinity. But, if the numatune contains a non-existent NUMA node then the translation fails with no error reported. This is because virNumaNodesetToCPUset() calls virNumaGetNodeCPUs() and expects it to report an error on failure. Well, it does except for non-existent NUMA nodes. While this behaviour might look strange it is actually desired because of how we construct host capabilities. The virNumaGetNodeCPUs() is called from virCapabilitiesHostNUMAInitReal() where we do not want any error reported for non-existent NUMA nodes. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1724866 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virnuma.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/util/virnuma.c b/src/util/virnuma.c index ba1e4363d6..2872ce3c5e 100644 --- a/src/util/virnuma.c +++ b/src/util/virnuma.c @@ -316,12 +316,21 @@ virNumaNodesetToCPUset(virBitmapPtr nodeset, for (i = 0; i < nodesetSize; i++) { g_autoptr(virBitmap) nodeCPUs = NULL; + int rc; if (!virBitmapIsBitSet(nodeset, i)) continue; - if (virNumaGetNodeCPUs(i, &nodeCPUs) < 0) + rc = virNumaGetNodeCPUs(i, &nodeCPUs); + if (rc < 0) { + /* Error is reported for cases other than non-existent NUMA node. */ + if (rc == -2) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("NUMA node %zu is not available"), + i); + } return -1; + } if (virBitmapUnion(allNodesCPUs, nodeCPUs) < 0) return -1; -- 2.26.2

2 1

[RFC PATCH 0/3] qemu: Propagate cluster size to new qcow2 images
by Peter Krempa 08 Sep '20

08 Sep '20

Cluster size may have performatnce implications. Propagate the cluster size used by the original image to any copy or overlay. Peter Krempa (3): qemu: monitor: Detect image cluster size from 'query-named-block-nodes' qemu: block: Allow specifying cluster size when using 'blockdev-create' qemuBlockStorageSourceCreateDetectSize: Propagate cluster size for 'qcow2' src/qemu/qemu_block.c | 6 ++++++ src/qemu/qemu_monitor.h | 3 +++ src/qemu/qemu_monitor_json.c | 3 +++ src/util/virstoragefile.h | 1 + 4 files changed, 13 insertions(+) -- 2.26.2

2 5

[PATCH] qemu_process: Separate VIR_PERF_EVENT_* setting into a function
by Michal Privoznik 07 Sep '20

07 Sep '20

When starting a domain, qemuProcessLaunch() iterates over all VIR_PERF_EVENT_* values and (possibly) enables them. While there is nothing wrong with the code, the for loop where its done makes it harder to jump onto next block of code. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Is this trivial enough to be pushed as such? src/qemu/qemu_process.c | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 6b1644880a..dd60fb0ddf 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -6700,6 +6700,25 @@ qemuProcessEnableDomainNamespaces(virQEMUDriverPtr driver, } +static int +qemuProcessEnablePerf(virDomainObjPtr vm) +{ + qemuDomainObjPrivatePtr priv = vm->privateData; + size_t i; + + if (!(priv->perf = virPerfNew())) + return -1; + + for (i = 0; i < VIR_PERF_EVENT_LAST; i++) { + if (vm->def->perf.events[i] == VIR_TRISTATE_BOOL_YES && + virPerfEventEnable(priv->perf, i, vm->pid) < 0) + return -1; + } + + return 0; +} + + /** * qemuProcessLaunch: * @@ -6733,7 +6752,6 @@ qemuProcessLaunch(virConnectPtr conn, g_autoptr(virQEMUDriverConfig) cfg = NULL; size_t nnicindexes = 0; g_autofree int *nicindexes = NULL; - size_t i; VIR_DEBUG("conn=%p driver=%p vm=%p name=%s if=%d asyncJob=%d " "incoming.launchURI=%s incoming.deferredURI=%s " @@ -6885,15 +6903,10 @@ qemuProcessLaunch(virConnectPtr conn, if (qemuSetupCgroup(vm, nnicindexes, nicindexes) < 0) goto cleanup; - if (!(priv->perf = virPerfNew())) + VIR_DEBUG("Setting up domain perf (if required)"); + if (qemuProcessEnablePerf(vm) < 0) goto cleanup; - for (i = 0; i < VIR_PERF_EVENT_LAST; i++) { - if (vm->def->perf.events[i] == VIR_TRISTATE_BOOL_YES && - virPerfEventEnable(priv->perf, i, vm->pid) < 0) - goto cleanup; - } - /* This must be done after cgroup placement to avoid resetting CPU * affinity */ if (qemuProcessInitCpuAffinity(vm) < 0) -- 2.26.2

2 1

[RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation
by Alex Bennée 07 Sep '20

07 Sep '20

It's buggy and we are not sure anyone uses it. Cc: David Gibson <david(a)gibson.dropbear.id.au> Cc: Richard Henderson <rth(a)twiddle.net> Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> --- docs/system/deprecated.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 851dbdeb8ab..11c763383d9 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -424,6 +424,15 @@ linux-user mode) is deprecated and will be removed in a future version of QEMU. Support for this CPU was removed from the upstream Linux kernel in 2018, and has also been dropped from glibc. +``ppc64abi32`` CPUs (since 5.2.0) +''''''''''''''''''''''''''''''''' + +The ``ppc64abi32`` architecture has a number of issues which regularly +trip up our CI testing and is suspected to be quite broken. +Furthermore the maintainers are unsure what the correct behaviour +should be and strongly suspect no one actually uses it. + + Related binaries ---------------- -- 2.20.1

4 6

[PATCH] news: add 1 improvement for v6.6.0
by Yanqiu Zhang 07 Sep '20

07 Sep '20

Support TLS for NBD connections for pull mode backup. Signed-off-by: Yanqiu Zhang <yanqzhan(a)redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index e4b71e6563..d0b16e28fc 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -161,6 +161,12 @@ v6.6.0 (2020-08-02) The secret key used for disks can now be encrypted similarly to TLS keys used for migration, chardev and others. + * qemu: Support TLS for NBD connections for pull mode backup + + Use the configured TLS env to setup encryption of the TLS transport. Add 'tls' + attribute for 'server' element to enable tls. Possible values are ``yes`` + or ``no``. + * qemu: ``VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD`` can now be registered for ``<mirror>`` The event can now be used also for block copy destinations by using the -- 2.25.4

4 7

[PATCH] Revert "news: qemu: Support TLS for NBD connections for pull mode backup"
by Peter Krempa 07 Sep '20

07 Sep '20

Incremental backups are not enabled. There's no point documenting individual patches implementing an incomplete feature. This reverts commit e6285f84faeacccdef12b69a7bc38975230d6662. --- NEWS.rst | 6 ------ 1 file changed, 6 deletions(-) diff --git a/NEWS.rst b/NEWS.rst index 008a6358c6..14f098b1f6 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -167,12 +167,6 @@ v6.6.0 (2020-08-02) The secret key used for disks can now be encrypted similarly to TLS keys used for migration, chardev and others. - * qemu: Support TLS for NBD connections for pull mode backup - - Use the configured TLS env to setup encryption of the TLS transport. Add - 'tls' attribute for 'server' element to enable TLS. Possible values are - ``yes`` or ``no``. - * qemu: ``VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD`` can now be registered for ``<mirror>`` The event can now be used also for block copy destinations by using the -- 2.26.2

3 2