February 2025 - Devel - libvirt List Archives

Plans for 11.1.0 release (freeze on Monday 24 Feb)
by Jiri Denemark 18 Feb '25

18 Feb '25

We are getting close to 11.1.0 release of libvirt. To aim for the release on Monday 03 Mar I suggest entering the freeze on Monday 24 Feb and tagging RC2 on Thursday 27 Feb. I hope this works for everyone. Jirka

1 0

[PATCH] util: fix compile warning in virsystemd.c during mingw builds
by Laine Stump 18 Feb '25

18 Feb '25

A function was changed from having no arguments to having a single argument, but the entire body of the function was #ifdefed out for windows builds, leaving that new argument unused. Surprisingly this didn't cause the build to fail, but I happened to notice it flit by during an rpm build. Fixes: 785cd56e5803fbbf60715fb6c7536360df5b4b9e Signed-off-by: Laine Stump <laine(a)redhat.com> --- I'm pushing this as trivial (technically it's not a build breaker, since the build still continues even with the warning :-P) src/util/virsystemd.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c index 57fe409c57..92d2890360 100644 --- a/src/util/virsystemd.c +++ b/src/util/virsystemd.c @@ -624,10 +624,15 @@ int virSystemdTerminateMachine(const char *name) return 0; } +#ifdef WIN32 +static void +virSystemdNotify(const char *msg G_GNUC_UNUSED) +{ +} +#else static void virSystemdNotify(const char *msg) { -#ifndef WIN32 const char *path; int fd; struct sockaddr_un un = { @@ -672,8 +677,8 @@ virSystemdNotify(const char *msg) VIR_WARN("Failed to notify systemd"); VIR_FORCE_CLOSE(fd); -#endif /* !WIN32 */ } +#endif /* !WIN32 */ void virSystemdNotifyReady(void) { -- 2.47.1

1 0

[PATCH] utils: Canonicalize paths before comparing them
by Andrea Bolognani 18 Feb '25

18 Feb '25

Resolves: https://issues.redhat.com/browse/RHEL-79165 Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/util/virfile.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/util/virfile.c b/src/util/virfile.c index 6ac0f4efb3..7cab3d0cd6 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -3823,10 +3823,13 @@ virFileIsSharedFSOverride(const char *path, if (!path || path[0] != '/' || !overrides) return false; - if (g_strv_contains((const char *const *) overrides, path)) - return true; + /* Overrides have been canonicalized ahead of time, so we need to + * do the same for the provided path or we'll never be able to + * find a match if symlinks are involved */ + dirpath = virFileCanonicalizePath(path); - dirpath = g_strdup(path); + if (g_strv_contains((const char *const *) overrides, dirpath)) + return true; /* Continue until we've scanned the entire path */ while (p != dirpath) { -- 2.48.1

2 2

[PATCH 0/2] qemu: Support specifying save image format
by Jim Fehlig 17 Feb '25

17 Feb '25

This series is based on a cleanup of qemuSaveImageGetCompressionProgram [1] and demonstrates the usefulness of that cleanup. Patch1 adds the VIR_DOMAIN_SAVE_PARAM_IMAGE_FORMAT typed parameter to virDomainSaveParams, allowing to specify the image format on a per-operation basis. The format can still be set driver-wide in qemu.conf. Patch2 provides the implementation in the qemu driver. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/SKVP… Jim Fehlig (2): include: Define constant for save image format qemu: Add support for 'image_format' typed parameter include/libvirt/libvirt-domain.h | 13 +++++++++++++ src/libvirt-domain.c | 3 +++ src/qemu/qemu_driver.c | 12 ++++++++++-- 3 files changed, 26 insertions(+), 2 deletions(-) -- 2.43.0

2 4

[PATCH 0/3] qemu: Small cleanups to SaveImageGetCompressionProgram and callers
by Jim Fehlig 17 Feb '25

17 Feb '25

Even though my work on supporting mapped-ram is the main motivation for this small cleanup series, IMO is useful in its own right. Jim Fehlig (3): qemu: Move declaration of virQEMUSaveFormat to header file qemu: Move special handling of invalid dump format to only caller qemu: Change return value of SaveImageGetCompressionProgram src/qemu/qemu_driver.c | 52 ++++++++++++++-------- src/qemu/qemu_saveimage.c | 92 +++++++-------------------------------- src/qemu/qemu_saveimage.h | 24 ++++++++-- src/qemu/qemu_snapshot.c | 11 +++-- 4 files changed, 78 insertions(+), 101 deletions(-) -- 2.43.0

2 7

[PATCH 0/9] qemu: support passt as the backend for vhost-user network interfaces
by Laine Stump 15 Feb '25

15 Feb '25

passt (https://passt.top) provides a method of connecting QEMU virtual machines to the external network without requiring special privileges or capabilities of any participating processes - even libvirt itself can run unprivileged and create an instance of passt (which *always* runs unprivileged) that is then connected to the qemu process (and thus the virtual machine) with a unix socket. Originally passt used its own protocol for this socket, sending both control messages and data packets over the socket. This works, and is already much more efficient than the previously only-unprivileged-networking-solution slirp. But recently passt added support for using the vhost-user protocol for communication between the passt process (which is connected to the external network) and the QEMU process (and thus the VM). vhost-user also uses a unix socket, but only for control plane messages - all data packets are "sent" between the VM and passt process via a shared memory region. This is unsurprisingly much more efficient. From the point of view of QEMU, the passt process looks identical to any normal vhost-user backend, so we can run QEMU with exactly the same interface commandline options as normal vhost-user. Also, the passt process supports all of the same options as it does when used in its "traditional" mode, so really in the end all we need to do is twist libvirt around so that when <backend type='passt'/> is specified for an <interface type='vhostuser'>, it will run passt just as before (except with the added "--vhost-user" option so that passt will know to use that), and then force feed the vhost-user code in libvirt with the same ocket path used by passt. This series does that, while also switching up a few bits of code prior to adding in the new functionality. So far this has been tested both unprivileged and privileged on Fedora 40 (with latest passt packet) and selinux enabled (there are a couple of selinux policy tweaks that still need to be pushed to passt-selinux) as well as unprivileged on debian (I *think* with AppArmor enabled) and everything seems to work. (I haven't gotten to testing hotplug, but it *should* work, and I'll be testing it while (hopefully) someone is reviewing these patches.) I also need to make the patch to update formatdomain.rst before the rest of it can be pushed, but I wanted to get this posted to save time later. This series does require patch 1 of the series I posted a couple days ago that changes several functions that can't fail to return void. Also, you will need the latest (20250121) passt package. This Resolves: https://issues.redhat.com/browse/RHEL-69455 Laine Stump (9): conf: change virDomainHostdevInsert() to return void qemu: fix qemu validation to forbid guest-side IP address for type='vdpa' qemu: validate that model is virtio for vhostuser and vdpa interfaces in the same place qemu: automatically set model type='virtio' for interface type='vhostuser' qemu: do all vhostuser attribute validation in qemu driver conf/qemu: make <source> element *almost* optional for type=vhostuser qemu: use switch instead of if in qemuProcessPrepareDomainNetwork() qemu: make qemuPasstCreateSocketPath() public qemu: complete vhostuser + passt support src/conf/domain_conf.c | 107 +++++++++--------- src/conf/domain_conf.h | 2 +- src/conf/domain_validate.c | 83 ++++---------- src/conf/schemas/domaincommon.rng | 32 +++++- src/libxl/libxl_domain.c | 5 +- src/libxl/libxl_driver.c | 3 +- src/lxc/lxc_driver.c | 3 +- src/qemu/qemu_command.c | 7 +- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_extdevice.c | 6 +- src/qemu/qemu_hotplug.c | 21 +++- src/qemu/qemu_passt.c | 5 +- src/qemu/qemu_passt.h | 3 + src/qemu/qemu_postparse.c | 3 +- src/qemu/qemu_process.c | 84 +++++++++----- src/qemu/qemu_validate.c | 56 ++++++--- ...t-user-slirp-portforward.x86_64-latest.err | 2 +- .../net-vhostuser-passt.x86_64-latest.args | 42 +++++++ .../net-vhostuser-passt.x86_64-latest.xml | 72 ++++++++++++ tests/qemuxmlconfdata/net-vhostuser-passt.xml | 70 ++++++++++++ tests/qemuxmlconftest.c | 1 + 21 files changed, 429 insertions(+), 181 deletions(-) create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt.xml -- 2.47.1

6 23

[PATCH] NEWS: Document ccwgroup based qeth device support
by Boris Fiuczynski 15 Feb '25

15 Feb '25

Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> --- NEWS.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 7dc6a3fa37..4fc8a3bba0 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -31,6 +31,17 @@ v11.1.0 (unreleased) * **New features** + * nodedev: Support ccwgroup based qeth devices + + CCW group devices are devices that use multiple subchannels on the + mainframe's channel subsystem. A qeth group device maps to subchannels and + their corresponding device numbers and device bus-IDs. The ``ccwgroup`` + device nodes are placed besides the subchannel nodes under computer and list + the group members within a new ``ccwgroup`` capability. A new capability + ``ccwgroup_member`` is added into capability ``ccw`` to represent a device + membership to a ccwgroup. Filters are added to find ccwgroups as well as + ccwgroup members. + * ch: Support handling events from cloud-hypervisor The ch driver now supports handling events from the cloud-hypervisor. -- 2.47.0

2 1

[PATCH 00/19] Add qemu RDP server support
by marcandre.lureau＠redhat.com 14 Feb '25

14 Feb '25

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, This patch series offers an out-of-process Remote Desktop Protocol (RDP) server solution utilizing QEMU's -display dbus interface, offering improved modularity and potential security benefits compared to built-in server. This initiative was spearheaded by Mihnea Buzatu during the QEMU Summer of Code 2023. The project's goal was to develop an out-of-process RDP server using the -display dbus interface, implemented in Rust. Given that the IronRDP crate lacked some server support at the time, investments in IronRDP were required. I finally released an initial v0.1 version of qemu-rdp on crates.io (https://crates.io/crates/qemu-rdp) That should allow more people to review and evaluate the state of this work. On unix systems, with cargo/rust toolchain installed, it should be as easy as running "cargo install qemu-rdp", apply this patch series for libvirt, set the "rdp_tls_x509_cert_dir" location for your TLS certificates, and configure a VM with both dbus & rdp graphics (run "virsh domdisplay DOMAIN" to get the display connection details). Thanks for the reviews & feedback! Marc-André Lureau (19): build-sys: drop -Winline build: fix -Werror=maybe-uninitialized qemu-slirp: drop unneeded check for OOM util: add conn != NULL precondition in virGDBusCallMethod() qemu: report an error for unsupported graphics qemu: add rdp state directory qemu: add qemu RDP configuration conf: parse optional RDP username & password conf: generalize virDomainDefHasSpiceGraphics qemu: use virDomainDefHasGraphics qemu: add RDP ports range allocator qemu: limit to one <graphics type='rdp'> qemu/dbus: keep a connection to the VM D-Bus qemu/dbus: log daemon stdout/err qemu: validate RDP configuration qemu: if -display dbus capability is supported, accept rdp qemu: add qemu-rdp helper unit qemu: add RDP support tests: add qemu <graphics type='rdp'/> test docs/formatdomain.rst | 25 +- meson.build | 1 - po/POTFILES | 1 + src/conf/domain_conf.c | 28 +- src/conf/domain_conf.h | 5 +- src/conf/schemas/domaincommon.rng | 10 + src/libvirt_private.syms | 2 +- src/qemu/libvirtd_qemu.aug | 7 + src/qemu/meson.build | 1 + src/qemu/qemu.conf.in | 31 ++ src/qemu/qemu_capabilities.c | 7 +- src/qemu/qemu_command.c | 11 +- src/qemu/qemu_conf.c | 47 ++ src/qemu/qemu_conf.h | 13 + src/qemu/qemu_dbus.c | 83 +++- src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 4 + src/qemu/qemu_driver.c | 20 + src/qemu/qemu_extdevice.c | 46 +- src/qemu/qemu_hotplug.c | 49 +- src/qemu/qemu_hotplug.h | 1 + src/qemu/qemu_process.c | 167 ++++++- src/qemu/qemu_rdp.c | 427 ++++++++++++++++++ src/qemu/qemu_rdp.h | 71 +++ src/qemu/qemu_slirp.c | 6 - src/qemu/qemu_validate.c | 45 +- src/qemu/test_libvirtd_qemu.aug.in | 5 + src/util/virgdbus.c | 4 + tests/domaincapsdata/qemu_10.0.0.s390x.xml | 1 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 1 + .../qemu_7.2.0-hvf.x86_64+hvf.xml | 1 + .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 1 + .../qemu_7.2.0-tcg.x86_64+hvf.xml | 1 + .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.2.0.ppc.xml | 1 + tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 1 + .../qemu_8.2.0-tcg-virt.loongarch64.xml | 1 + .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 1 + .../qemu_8.2.0-virt.aarch64.xml | 1 + .../qemu_8.2.0-virt.loongarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 1 + tests/domaincapsdata/qemu_8.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.0.0.sparc.xml | 1 + tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 1 + .../qemu_9.1.0-tcg-virt.riscv64.xml | 1 + .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 1 + .../qemu_9.1.0-virt.riscv64.xml | 1 + tests/domaincapsdata/qemu_9.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 1 + .../graphics-rdp.x86_64-latest.args | 35 ++ .../graphics-rdp.x86_64-latest.xml | 1 + tests/qemuxmlconfdata/graphics-rdp.xml | 43 ++ tests/qemuxmlconftest.c | 2 + tests/testutilsqemu.c | 4 + tools/nss/libvirt_nss_leases.c | 2 +- tools/nss/libvirt_nss_macs.c | 2 +- 78 files changed, 1172 insertions(+), 78 deletions(-) create mode 100644 src/qemu/qemu_rdp.c create mode 100644 src/qemu/qemu_rdp.h create mode 100644 tests/qemuxmlconfdata/graphics-rdp.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/graphics-rdp.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/graphics-rdp.xml -- 2.47.0

4 46

Re: [PATCH 1/1] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Akio Kakuno (Fujitsu) 14 Feb '25

14 Feb '25

Hi, all! I'm adding three test for CCA compatibility: domaincapstest, qemucapabilitiestest, and qemuxmlconftest. This is because SEV-SNP added these three tests. I have three questions regarding these tests: 1. How to add tests to qemuxmlconftest 2. How to create launch-security-cca.xml 3. About the file output with VIR_TEST_REGENERATE_OUTPUT=1 1. How to add tests to qemuxmlconftest Following the example of launch-security-sev-snp tests, I've done the following. Is this correct? (1) Placed the following three files in tests/qemuxmlconfdata: launch-security-cca.xml launch-security-cca.aarch64-latest.xml launch-security-cca.aarch64-latest.args (2) Added the test processing to qemuxmlconftest.c's mymain() function: DO_TEST_CAPS_ARCH_LATEST_FULL("launch-security-cca", "aarch64", ARG_QEMU_CAPS, QEMU_CAPS_CCA_GUEST, QEMU_CAPS_LAST); 2. How to create launch-security-cca.xml Do I need to handmade this from scratch or is there an automated method? 3. About the file output with VIR_TEST_REGENERATE_OUTPUT=1 I created launch-security-cca.aarch64-latest.* using the method described in doc/advanced-tests.rst. And, I created the test data for qemucapabilitiestest and domaincapstest using the method described in tests/qemucapabilitiesdata/README.rst. VIR_TEST_REGENERATE_OUTPUT=1 ./qemuxmlconftest VIR_TEST_REGENERATE_OUTPUT=1 ./domaincapstest VIR_TEST_REGENERATE_OUTPUT=1 ./qemucapabilitiestest Can I use the generated file for testing as is? Because doc/advanced-tests.rst says: "VERY CAREFULLY to ensure they are correct" I assume that automatically generated expected values are checked for accuracy. If correct, they are adopted; otherwise, investigation and remediation are undertaken. However, due to the lack of explicit documentation, we require confirmation. Also, it appears to be generating expected values based on the execution environment. Do we need to worry about variations in execution environments? For example, executing qemuxmlconftest detects the following comparison errors, such as with aarch64-virt-minimal.aarch64-latest, etc. Expect [sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -m] Actual [m] Best Regards.

1 0

AppArmor confinement for qemu:///session VMs
by Andrea Bolognani 14 Feb '25

14 Feb '25

An issue was recently reported[1] with running unprivileged VMs configured to use passt on Debian with AppArmor confinement enabled. After looking into the situation, I am convinced that AppArmor confinement never really worked for unprivileged VMs. The whole mechanism is built around the concept of per-VM profiles that are dynamically generated and registered, but doing so requires write access to /etc/apparmor.d/ and in general permissions that unprivileged libvirt will by design not have. Of course it's unfortunate that unprivileged VMs would be forced to miss out on the potential benefits of AppArmor isolation, and even more unfortunate that passt won't work out of the box for unprivileged VMs, since those are the ones where it makes the most sense to use passt in the first place. Stefano suggested introducing a generic "libvirt-user" profile that would be attached to unprivileged VMs and would be more liberal than the one used for privileged VMs, since we wouldn't be able to tailor it to the specifics of the VM, but would at least prevent the worst of the abuse; specifically, it would only allow R/W access to files in the current user's home directory. Does that sound like a reasonable direction? Any other ideas? In the meantime, Stefano has posted a workaround[2] that, when applied to passt's AppArmor profile, would allow these VMs to at least start. CC'ing people with AppArmor knowledge for awareness. [1] https://archives.passt.top/passt-dev/20250129104112.0756df5c@elisabeth/T/#u [2] https://archives.passt.top/passt-dev/20250205163101.3793658-1-sbrivio@redha… -- Andrea Bolognani / Red Hat / Virtualization

4 5