- Devel - libvirt List Archives

[PATCH 0/1] Support Windows 10 Arm64 ISO installations
by Jan-Marek Glogowski 08 Sep '20

08 Sep '20

This patch was originally submitted via https://gitlab.com/libvirt/libvirt/-/merge_requests/19 That merge request contains additional information, if you find the commit message of the patch lacking in some way. It did pass CI and the test suite four weeks ago, seems small enough, and the rebase had no conflicts, so I didn't run the tests again on current master. And based on the comment from Peter Krempa in that merge request, it probably needs further discussion with QEMU developers. FWIW: while the installer generally works, I'm experiencing massive timeouts from the "Out of Box Experience" (OOBE) part of the Windows configuration after the install. And the latest ISOs don't even start in QEMU (5.1 and older) for me on Debian, so I used 1909 instead of the 2004 ISO "releases". I'm running the aarch64 system QEMU on x86_64 Debian Buster with my current QEMU build. Jan-Marek Glogowski (1): QEMU: support USB cdrom devices src/qemu/qemu_command.c | 21 ++++++++++++++++++- src/qemu/qemu_command.h | 1 + src/qemu/qemu_domain.c | 2 +- .../disk-cdrom-bus-other.x86_64-latest.args | 12 +++++------ 4 files changed, 28 insertions(+), 8 deletions(-) -- 2.20.1

4 10

[libvirt PATCH] conf: Add support for GlusterFS volumes as disk
by Vincent Vanlaer 08 Sep '20

08 Sep '20

While libvirt has support for GlusterFS pools and volumes, they cannot be added to a domain. This commit adds the necessary translation between the pool definition and the disk definition, allowing volumes in a domain to be backed by a gluster pool. Signed-off-by: Vincent Vanlaer <libvirt(a)volkihar.be> --- src/conf/domain_conf.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 72ac4f4191..c872d02200 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -32620,6 +32620,32 @@ virDomainDiskTranslateISCSIDirect(virStorageSourcePtr src, } +static int +virDomainDiskTranslateGluster(virStorageSourcePtr src, + virStoragePoolDefPtr pooldef) +{ + size_t i; + + src->srcpool->actualtype = VIR_STORAGE_TYPE_NETWORK; + src->protocol = VIR_STORAGE_NET_PROTOCOL_GLUSTER; + + src->nhosts = pooldef->source.nhost; + src->hosts = g_new0(virStorageNetHostDef, src->nhosts); + + for (i = 0; i < src->nhosts; i++) { + src->hosts[i].socket = NULL; + src->hosts[i].transport = VIR_STORAGE_NET_HOST_TRANS_TCP; + src->hosts[i].name = g_strdup(pooldef->source.hosts[i].name); + src->hosts[i].port = pooldef->source.hosts[i].port; + } + + src->volume = g_strdup(pooldef->source.name); + src->path = g_strdup_printf("%s/%s", pooldef->source.dir, src->srcpool->volume); + + return 0; +} + + static int virDomainStorageSourceTranslateSourcePool(virStorageSourcePtr src, virConnectPtr conn) @@ -32736,10 +32762,14 @@ virDomainStorageSourceTranslateSourcePool(virStorageSourcePtr src, } break; + case VIR_STORAGE_POOL_GLUSTER: + if (virDomainDiskTranslateGluster(src, pooldef) < 0) + return -1; + break; + case VIR_STORAGE_POOL_MPATH: case VIR_STORAGE_POOL_RBD: case VIR_STORAGE_POOL_SHEEPDOG: - case VIR_STORAGE_POOL_GLUSTER: case VIR_STORAGE_POOL_LAST: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("using '%s' pools for backing 'volume' disks " -- 2.28.0

2 1

[libvirt PATCH] check for NULL before calling g_regex_unref
by Ján Tomko 08 Sep '20

08 Sep '20

g_regex_unref reports an error if called with a NULL argument. We have two cases in the code where we (possibly) call it on a NULL argument. The interesting one is in virDomainQemuMonitorEventCleanup. Based on VIR_CONNECT_DOMAIN_QEMU_MONITOR_EVENT_REGISTER_REGEX, we unref data->regex, which has two problems: * On the client side, flags is -1 so the comparison is true even if no regex was used, reproducible by: $ virsh qemu-monitor-event --timeout 1 which results in an ugly error: (process:1289846): GLib-CRITICAL **: 14:58:42.631: g_regex_unref: assertion 'regex != NULL' failed * On the server side, we only create the regex if both the flag and the string are present, so it's possible to trigger this message by: $ virsh qemu-monitor-event --regex --timeout 1 Use a non-NULL comparison instead of the flag to decide whether we need to unref the regex. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> Fixes: 71efb59a4de7c51b1bc889a316f1796ebf55738f https://bugzilla.redhat.com/show_bug.cgi?id=1861176 --- src/conf/domain_event.c | 2 +- tests/vboxsnapshotxmltest.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_event.c b/src/conf/domain_event.c index 33fbf10406..d3acde0236 100644 --- a/src/conf/domain_event.c +++ b/src/conf/domain_event.c @@ -2194,7 +2194,7 @@ virDomainQemuMonitorEventCleanup(void *opaque) virDomainQemuMonitorEventData *data = opaque; VIR_FREE(data->event); - if (data->flags & VIR_CONNECT_DOMAIN_QEMU_MONITOR_EVENT_REGISTER_REGEX) + if (data->regex) g_regex_unref(data->regex); if (data->freecb) (data->freecb)(data->opaque); diff --git a/tests/vboxsnapshotxmltest.c b/tests/vboxsnapshotxmltest.c index 7e3f85cc58..d2beb7858d 100644 --- a/tests/vboxsnapshotxmltest.c +++ b/tests/vboxsnapshotxmltest.c @@ -135,7 +135,8 @@ mymain(void) DO_TEST("2disks-3snap-brother"); cleanup: - g_regex_unref(testSnapshotXMLVariableLineRegex); + if (testSnapshotXMLVariableLineRegex) + g_regex_unref(testSnapshotXMLVariableLineRegex); return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; } -- 2.26.2

3 2

[PATCH v5 0/4] qemu: Support rbd namespace in rbd source name
by Han Han 08 Sep '20

08 Sep '20

v4: https://www.redhat.com/archives/libvir-list/2020-August/msg00351.html Difference from v4: - rebase to last master tree - parse namspace from name attribute and update the documents - add caps test xml for 5.2.0 x86_64 - adapt to DO_TEST_CAPS_ARCH_LATEST in qemuxml2xmltest in case of the test failure caused by missing caps test xml of 5.x at s390. git branch: https://gitlab.com/hhan2/libvirt/-/tree/rbd-namespace-v5 Han Han (4): qemu_capabilities: Add QEMU_CAPS_RBD_NAMESPACE conf: Support to parse rbd namespace from source name qemu: Implement rbd namespace to the source name attribute news: qemu: Support rbd namespace NEWS.rst | 8 ++++ docs/formatdomain.rst | 12 ++++-- src/conf/domain_conf.c | 35 ++++++++++++++-- src/qemu/qemu_block.c | 1 + src/qemu/qemu_capabilities.c | 4 ++ src/qemu/qemu_capabilities.h | 3 ++ src/qemu/qemu_domain.c | 8 ++++ src/util/virstoragefile.c | 1 + src/util/virstoragefile.h | 1 + .../caps_5.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + .../caps_5.0.0.riscv64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + ...k-network-rbd-namespace.x86_64-latest.args | 41 +++++++++++++++++++ .../disk-network-rbd-namespace.xml | 33 +++++++++++++++ tests/qemuxml2argvtest.c | 1 + ...sk-network-rbd-namespace.x86_64-latest.xml | 41 +++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 20 files changed, 189 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-namespace.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-namespace.xml create mode 100644 tests/qemuxml2xmloutdata/disk-network-rbd-namespace.x86_64-latest.xml -- 2.28.0

2 5

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