- Devel - libvirt List Archives

[PATCH] tls: Don't require 'keyEncipherment' to be enabled altoghther
by Peter Krempa 01 Jul '25

01 Jul '25

From: Peter Krempa <pkrempa(a)redhat.com> Key encipherment is required only for RSA key exchange algorithm. With TLS 1.3 this is not even used as RSA is used only for authentication. Since we can't really check when it's required ahead of time drop the check completely. GnuTLS will moan if it will not be able to use RSA key exchange. In commit 11867b0224a2 I tried to relax the check for some eliptic curve algorithm that explicitly forbid it. Based on the above the proper solution is to completely remove it. Resolves: https://issues.redhat.com/browse/RHEL-100711 Fixes: 11867b0224a2b8dc34755ff0ace446b6842df1c1 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/rpc/virnettlscert.c | 28 ---------------------------- 1 file changed, 28 deletions(-) diff --git a/src/rpc/virnettlscert.c b/src/rpc/virnettlscert.c index f197995633..7024e858f0 100644 --- a/src/rpc/virnettlscert.c +++ b/src/rpc/virnettlscert.c @@ -162,34 +162,6 @@ static int virNetTLSCertCheckKeyUsage(gnutls_x509_crt_t cert, certFile); } } - if (!(usage & GNUTLS_KEY_KEY_ENCIPHERMENT)) { - int alg = gnutls_x509_crt_get_pk_algorithm(cert, NULL); - - /* Per RFC8813 [1] which amends RFC5580 [2] ECDSA, ECDH, and ECMQV - * algorithms must not have 'keyEncipherment' present. - * - * [1] https://datatracker.ietf.org/doc/rfc8813/ - * [2] https://datatracker.ietf.org/doc/rfc5480 - */ - - switch (alg) { - case GNUTLS_PK_ECDSA: - case GNUTLS_PK_ECDH_X25519: - case GNUTLS_PK_ECDH_X448: - break; - - default: - if (critical) { - virReportError(VIR_ERR_SYSTEM_ERROR, - _("Certificate %1$s usage does not permit key encipherment"), - certFile); - return -1; - } else { - VIR_WARN("Certificate %s usage does not permit key encipherment", - certFile); - } - } - } } return 0; -- 2.49.0

2 7

Release of libvirt-11.5.0
by Jiri Denemark 01 Jul '25

01 Jul '25

The 11.5.0 release of both libvirt and libvirt-python is tagged and signed tarballs are available at https://download.libvirt.org/ https://download.libvirt.org/python/ Thanks everybody who helped with this release by sending patches, reviewing, testing, or providing feedback. Your work is greatly appreciated. * Removed features * qemu: Don't accept VIR_DUMP_LIVE flag in virDomainCoreDumpWithFormat() Unfortunately, QEMU always pauses vCPUs when doing a core dump. Therefore, there is no way for Libvirt to honor VIR_DUMP_LIVE flag semantics. Instead of silently pretending the flag works, an appropriate error is now reported. * New features * vmx: Add support for reporting NVMe disks in the domain XML * qemu: Add support for NVMe disks NVMe disks can now be emulated by using an ``nvme`` bus, but require a serial due to the hypervisor:: <target dev='nvme0n1' bus='nvme'/> <serial>qwertyuiop</serial> Multiple disks can be represented as different namespaces on the same controller, but they cannot have a different serial number due to the fact that it is the controller which ultimately has the serial number attached to it, but for ease of use it is automatically copied from the disk serial. * esx: Add support for specifying alternative CA bundle for remote peer verification Users can now use ``cacert`` parameter in the URI to specify a file path with CA certificate(s) that will be used for remote peer certificate validation. * qemu: add support for AMD IOMMU device The ``amd`` model for the ``<iommu>`` device is now supported. New attributes ``passtrhough`` and ``xtsup`` are also supported for this model. * Improvements * Include supported console types in domain capabilities Domain capabilities now include information about supported console types, such as:: <console supported='yes'> <enum name='type'> <value>pty</value> <value>tcp</value> </enum> </console> * virsh: Add waiting for domain state via ``virsh await`` The new helper command ``virsh await`` simplifies waiting on domain state which is normally announced via events. Currently two waiting conditions are implemented: ``domain-inactive``, and ``guest-agent-available``. * Bug fixes * qemu: Be more forgiving when acquiring QUERY job when formatting domain XML Since ``libvirt-11.0.0`` the ``virDomainGetXMLDesc()`` API used to format domain XML acquires QUERY job. But this caused a regression when the API might timeout for incoming migration. This is now fixed. * qemu: Fix shared filesystem detection on nonexistent paths Since ``libvirt-11.1.0`` nonexistent paths within directories marked as shared filesystem (via the ``shared_filesystems`` option in ``qemu.conf`` would not be properly detected as being on a shared filesystem. * qemu: Properly emulate USB cdrom device CD-ROM devices on USB bus are now properly emulated as such which was not the case since libvirt switched to the modern qemu commandline sytnax for storage backends. Enjoy. Jirka

1 0

pci-hole64-size on q35 questions
by mitchell.augustin＠canonical.com 30 Jun '25

30 Jun '25

Hi, I'm trying to get a better understanding of how libvirt VMs interact with the default QEMU setting for pci-hole64-size on q35 hosts, to assess why my libvirt VMs behave differently from a similarly configured lxd VM. As I understand, both libvirt and lxd are using qemu q35 VMs under the hood, and both are inheriting their pci-hole64-size from qemu's default setting (correct me if that's wrong), but in my tests, I'm getting different behavior from them. I know lxd is probably out of scope from the libvirt project perspective, so consider this more of a libvirt question w/ some added lxd context. All of this is on a DGX B200 host, which contains large (~180GB VRAM) GPUs. With libvirt/virt-install, I created a q35 virtual machine with CPU host passthrough and 1 or more GPUs passed-through via --host-device. Without additional modifications, this works as expected, and I can initialize the GPU driver in the VM and run nvidia-smi. With lxd (which creates a q35 virtual machine with CPU host passthrough by default), I attached 1 GPU via "lxc config device add passthroughtest gpu gpu pci=1b:00.0". On that machine, the pci-hole64-size is too small by default, since I see these in my dmesg: [ 1.099110] pci 0000:00:01.5: bridge window [mem size 0x6000000000 64bit pref]: can't assign; no space [ 1.120274] pci 0000:00:01.5: bridge window [mem size 0x6000000000 64bit pref]: can't assign; no space [ 1.183281] pci 0000:06:00.0: BAR 2 [mem size 0x4000000000 64bit pref]: can't assign; no space [ 1.186320] pci 0000:06:00.0: BAR 0 [mem size 0x04000000 64bit pref]: can't assign; no space [ 1.189340] pci 0000:06:00.0: BAR 4 [mem size 0x02000000 64bit pref]: can't assign; no space and I cannot initialize the GPU driver since the BARs weren't mapped correctly. When I apply a larger hole size to my lxd VM via `lxc config set passthroughtest raw.qemu=' -global q35-pcihost.pci-hole64-size=8192G'`, I don't see any "can't assign; no space" messages, and the driver works as expected. My question about libvirt is - where (if at all) does libvirt interact with qemu's pci-hole64-size value? If libvirt does not automatically do something functionally similar to changing the hole size like I need to do above for lxd, and is in fact just using a qemu default value, is there some other related interaction happening in libvirt that might explain why my libvirt VMs don't require a manual change to pci-hole64-size, despite the fact that the relevant parts of the underlying qemu machine should be the same?

2 1

[libvirt PATCH] NEWS: document new AMD IOMMU device
by Ján Tomko 30 Jun '25

30 Jun '25

From: Ján Tomko <jtomko(a)redhat.com> Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- Applies on top of Peter's NEWS patch NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 3ffdceda81..fd2d68a600 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -45,6 +45,12 @@ v11.5.0 (unreleased) with CA certificate(s) that will be used for remote peer certificate validation. + * qemu: add support for AMD IOMMU device + + The ``amd`` model for the ``<iommu>`` device is now supported. + New attributes ``passtrhough`` and ``xtsup`` are also supported for this + model. + * **Improvements** * Include supported console types in domain capabilities -- 2.49.0

2 1

Re: [PATCH v2 09/10] net: Add passt network backend
by Markus Armbruster 30 Jun '25

30 Jun '25

Laurent Vivier <lvivier(a)redhat.com> writes: > On 24/06/2025 10:16, Markus Armbruster wrote: >> Laurent Vivier <lvivier(a)redhat.com> writes: >> >>> This commit introduces support for passt as a new network backend. >>> passt is an unprivileged, user-mode networking solution that provides >>> connectivity for virtual machines by launching an external helper process. >>> >>> The implementation reuses the generic stream data handling logic. It >>> launches the passt binary using GSubprocess, passing it a file >>> descriptor from a socketpair() for communication. QEMU connects to >>> the other end of the socket pair to establish the network data stream. >>> >>> The PID of the passt daemon is tracked via a temporary file to >>> ensure it is terminated when QEMU exits. >>> >>> Signed-off-by: Laurent Vivier <lvivier(a)redhat.com> >> >> [...] >> >>> diff --git a/qapi/net.json b/qapi/net.json >>> index 97ea1839813b..76d7654414f7 100644 >>> --- a/qapi/net.json >>> +++ b/qapi/net.json >>> @@ -112,6 +112,125 @@ >>> 'data': { >>> 'str': 'str' } } >>> >>> +## >>> +# @NetDevPasstOptions: >>> +# >>> +# Unprivileged user-mode network connectivity using passt >>> +# >>> +# @path: path to passt binary >> >> I'd prefer a more descriptive name. >> >> Elsewhere in this file, we refer to programs like this: >> >> # @script: script to initialize the interface >> # >> # @downscript: script to shut down the interface >> >> passt isn't a script, of course. >> >> I don't know, perhaps >> >> # @passt-filename: the passt program to run. >> >> or even >> >> # @passt: Filename of the passt program to run. >> >>> +# >>> +# @quiet: don't print informational messages >> >> What does the printing? A peek at the code I snipped suggests this flag >> is passed to the passt binary as --quiet. Correct? >> >>> +# >>> +# @debug: be verbose >>> +# >>> +# @trace: extra verbose >> >> Likewise for these two. >> >>> +# >>> +# @vhost-user: enable vhost-user [...] >>> +# @udp-ports: UDP ports to forward >> >> Is there anything in this struct that configures qemu-system-FOO itself, >> i.e. isn't just passed to passt? >> > > Yes, all parameters are just passed to passt. > > Do you think it's better not to add all these parameters to netdev backend but only one > generic containing the passt command line parameters? I'm not sure. Thoughts from libvirt's perspective?

4 4

[PATCH v3] remote/stream-event: Fix a memory leak in remoteStreamCallbackFree()
by liu.xuemei1＠zte.com.cn 30 Jun '25

30 Jun '25

From: Liu Song <liu.song13(a)zte.com.cn> The ff callback is never called in remoteStreamCallbackFree() because cbdata->cb can not be NULL. This causes a leak of 'cbdata->opaque'. The leak can be reproduced by attaching and detaching to the console of an VM using `virsh console`. ASAN reports the leak stack as: Direct leak of 288 byte(s) in 1 object(s) allocated from: #0 0x7f6edf6ba0c7 in calloc (/lib64/libasan.so.8+0xba0c7) #1 0x7f6edf5175b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x615b0) #2 0x7f6ede6d0be3 in g_type_create_instance (/lib64/libgobject-2.0.so.0+0x3cbe3) #3 0x7f6ede6b82cf in g_object_new_internal (/lib64/libgobject-2.0.so.0+0x242cf) #4 0x7f6ede6b9877 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x25877) #5 0x7f6ede6ba620 in g_object_new (/lib64/libgobject-2.0.so.0+0x26620) #6 0x7f6edeb78138 in virObjectNew ../src/util/virobject.c:252 #7 0x7f6edeb7a78b in virObjectLockableNew ../src/util/virobject.c:274 #8 0x558251e427e1 in virConsoleNew ../tools/virsh-console.c:369 #9 0x558251e427e1 in virshRunConsole ../tools/virsh-console.c:427 Signed-off-by: Liu Song <liu.song13(a)zte.com.cn> --- Changes in v3: - Remove the second reference to 'client', and unref 'client' in error path. src/remote/remote_daemon_stream.c | 7 ++++--- src/remote/remote_driver.c | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/remote/remote_daemon_stream.c b/src/remote/remote_daemon_stream.c index 453728a66b..b6099e3bc7 100644 --- a/src/remote/remote_daemon_stream.c +++ b/src/remote/remote_daemon_stream.c @@ -437,12 +437,13 @@ int daemonAddClientStream(virNetServerClient *client, return -1; } + virObjectRef(client); if (virStreamEventAddCallback(stream->st, 0, daemonStreamEvent, client, - virObjectUnref) < 0) + virObjectUnref) < 0) { + virObjectUnref(client); return -1; - - virObjectRef(client); + } if ((stream->filterID = virNetServerClientAddFilter(client, daemonStreamFilter, diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 2690c05267..9ac13469e9 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -5336,7 +5336,7 @@ static void remoteStreamCallbackFree(void *opaque) { struct remoteStreamCallbackData *cbdata = opaque; - if (!cbdata->cb && cbdata->ff) + if (cbdata->ff) (cbdata->ff)(cbdata->opaque); virObjectUnref(cbdata->st); -- 2.27.0

1 0

[PATCH] NEWS: Mention 'virsh await' and proper emulation of USB cdroms
by Peter Krempa 30 Jun '25

30 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 089224cbe3..3ffdceda81 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -58,6 +58,12 @@ v11.5.0 (unreleased) </enum> </console> + * virsh: Add waiting for domain state via ``virsh await`` + + The new helper command ``virsh await`` simplifies waiting on domain state + which is normally announced via events. Currently two waiting conditions are + implemented: ``domain-inactive``, and ``guest-agent-available``. + * **Bug fixes** * qemu: Be more forgiving when acquiring QUERY job when formatting domain XML @@ -72,6 +78,12 @@ v11.5.0 (unreleased) shared filesystem (via the ``shared_filesystems`` option in ``qemu.conf`` would not be properly detected as being on a shared filesystem. + * qemu: Properly emulate USB cdrom device + + CD-ROM devices on USB bus are now properly emulated as such which was not + the case since libvirt switched to the modern qemu commandline sytnax for + storage backends. + v11.4.0 (2025-06-02) ==================== -- 2.49.0

2 1

[PATCH] NEWS: Mention shared filesystem detection fix
by Jiri Denemark 30 Jun '25

30 Jun '25

From: Jiri Denemark <jdenemar(a)redhat.com> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index ee4e9a022e..089224cbe3 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -66,6 +66,12 @@ v11.5.0 (unreleased) domain XML acquires QUERY job. But this caused a regression when the API might timeout for incoming migration. This is now fixed. + * qemu: Fix shared filesystem detection on nonexistent paths + + Since ``libvirt-11.1.0`` nonexistent paths within directories marked as + shared filesystem (via the ``shared_filesystems`` option in ``qemu.conf`` + would not be properly detected as being on a shared filesystem. + v11.4.0 (2025-06-02) ==================== -- 2.49.0

2 1

[PATCH] NEWS: Document features/improvements/bug fixes I've participated in
by Michal Privoznik 30 Jun '25

30 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> There are some features/improvements/bug fixes I've either contributed or reviewed/merged. Document them for upcoming release. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 184df16547..ee4e9a022e 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -60,6 +60,12 @@ v11.5.0 (unreleased) * **Bug fixes** + * qemu: Be more forgiving when acquiring QUERY job when formatting domain XML + + Since ``libvirt-11.0.0`` the ``virDomainGetXMLDesc()`` API used to format + domain XML acquires QUERY job. But this caused a regression when the API + might timeout for incoming migration. This is now fixed. + v11.4.0 (2025-06-02) ==================== -- 2.49.0

2 1

Re: [PATCH v3 2/2] virt-aa-helper: Allow SR-IOV VF PCI for hostdev networks
by Michal Prívozník 30 Jun '25

30 Jun '25

On 6/25/25 18:49, Tim Small wrote: > > > On 09/06/2025 13:51, Michal Prívozník wrote: > >> But this new IPC got me thinking - the XML we're parsing here in the aa >> helper is formatted by libvirtd who already know the actual type of each >> net. But looking into the code - this is lost when the daemon talks to >> the helper. I'm not on an AppArmor machine right now, so can you please >> check whether the following change (applied on the top of this very >> patch) works? It would save us from those IPCs. > > Thanks Michal. The additional patches which you posted (below) did not > work in isolation, but with an additional change to the src/qemu/ > qemu_process.c to ensure that the network is resolved before the > apparmor helper is called, it works. > > I've updated my branch and tested, and will post the updated patch to > the mailing list, but before I do-so... > > What would you like me to do with regard to the changes with you proposed? > > . Post with credit in the patch commentary. > . Post with credit in the commit message. If you want, then you can put Suggested-by: Michal Privoznik <mprivozn(a)redhat.com> line just above your SoB line. Thanks! > . Something else? > > Thanks for the tip! No problem. Introducing new RPC call always sets my alarm off :-D Michal

1 0