November 2025 - Devel - libvirt List Archives

[PATCH v2 1/2] docs: bhyve: document VNC's wait attribute
by Roman Bogorodskiy 24 Nov '25

24 Nov '25

Document the new VNC's 'wait' attribute in formatdomain.rst and drvbhyve.rst. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- docs/drvbhyve.rst | 10 ++++++++++ docs/formatdomain.rst | 4 ++++ 2 files changed, 14 insertions(+) diff --git a/docs/drvbhyve.rst b/docs/drvbhyve.rst index 73372ff7cf..c0f4cd8a1f 100644 --- a/docs/drvbhyve.rst +++ b/docs/drvbhyve.rst @@ -429,6 +429,16 @@ Note: VNC password authentication is known to be cryptographically weak. Additionally, the password is passed as a command line argument in clear text. Make sure you understand the risks associated with this feature before using it. +:since:`Since 11.10.0`, the guest can be configured to wait for an incoming +VNC connection before booting: + +:: + + <graphics type='vnc' port='5904' wait='yes'> + <listen type='address' address='127.0.0.1'/> + </graphics> + + Clock configuration ~~~~~~~~~~~~~~~~~~~ diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index c6d0b183d0..3d3a6b5a6e 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -6902,6 +6902,10 @@ interaction with the admin. ID is specified, then the default audio backend will be used. :since:`Since 7.2.0, qemu`. + The optional ``wait`` attribute, when set to ``yes``, causes the guest + to wait for an incoming VNC connection before booting. + :since:`Since 11.10.0, bhyve`. + ``spice`` :since:`Since 0.8.6` Starts a SPICE server. The ``port`` attribute specifies the TCP port number (with -1 as legacy syntax indicating that it should be -- 2.51.2

2 3

[PATCH] ci: refresh with 'lcitool manifest'
by Michal Privoznik 24 Nov '25

24 Nov '25

From: Michal Privoznik <mprivozn(a)redhat.com> - Add Fedora 43 - Remove EOL Fedora 41 - Switch mingw from Fedora 42 to Fedora 43 - Switch integration tests from Fedora 41 to Fedora 43 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Depends on the following MRs: https://gitlab.com/libvirt/libvirt-python/-/merge_requests/181 https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/141 Green pipeline: https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/2172379522 ...-mingw32.sh => fedora-43-cross-mingw32.sh} | 0 ...-mingw64.sh => fedora-43-cross-mingw64.sh} | 0 ci/buildenv/{fedora-41.sh => fedora-43.sh} | 0 ...ile => fedora-43-cross-mingw32.Dockerfile} | 2 +- ...ile => fedora-43-cross-mingw64.Dockerfile} | 2 +- ...ora-41.Dockerfile => fedora-43.Dockerfile} | 2 +- ci/gitlab/builds.yml | 46 +++++++++---------- ci/gitlab/containers.yml | 22 ++++----- ci/integration.yml | 20 ++++---- ci/manifest.yml | 16 +++---- 10 files changed, 55 insertions(+), 55 deletions(-) rename ci/buildenv/{fedora-42-cross-mingw32.sh => fedora-43-cross-mingw32.sh} (100%) rename ci/buildenv/{fedora-42-cross-mingw64.sh => fedora-43-cross-mingw64.sh} (100%) rename ci/buildenv/{fedora-41.sh => fedora-43.sh} (100%) rename ci/containers/{fedora-42-cross-mingw32.Dockerfile => fedora-43-cross-mingw32.Dockerfile} (98%) rename ci/containers/{fedora-42-cross-mingw64.Dockerfile => fedora-43-cross-mingw64.Dockerfile} (98%) rename ci/containers/{fedora-41.Dockerfile => fedora-43.Dockerfile} (98%) diff --git a/ci/buildenv/fedora-42-cross-mingw32.sh b/ci/buildenv/fedora-43-cross-mingw32.sh similarity index 100% rename from ci/buildenv/fedora-42-cross-mingw32.sh rename to ci/buildenv/fedora-43-cross-mingw32.sh diff --git a/ci/buildenv/fedora-42-cross-mingw64.sh b/ci/buildenv/fedora-43-cross-mingw64.sh similarity index 100% rename from ci/buildenv/fedora-42-cross-mingw64.sh rename to ci/buildenv/fedora-43-cross-mingw64.sh diff --git a/ci/buildenv/fedora-41.sh b/ci/buildenv/fedora-43.sh similarity index 100% rename from ci/buildenv/fedora-41.sh rename to ci/buildenv/fedora-43.sh diff --git a/ci/containers/fedora-42-cross-mingw32.Dockerfile b/ci/containers/fedora-43-cross-mingw32.Dockerfile similarity index 98% rename from ci/containers/fedora-42-cross-mingw32.Dockerfile rename to ci/containers/fedora-43-cross-mingw32.Dockerfile index 94d9378850..de7bee20e1 100644 --- a/ci/containers/fedora-42-cross-mingw32.Dockerfile +++ b/ci/containers/fedora-43-cross-mingw32.Dockerfile @@ -4,7 +4,7 @@ # # https://gitlab.com/libvirt/libvirt-ci -FROM registry.fedoraproject.org/fedora:42 +FROM registry.fedoraproject.org/fedora:43 RUN dnf install -y nosync && \ printf '#!/bin/sh\n\ diff --git a/ci/containers/fedora-42-cross-mingw64.Dockerfile b/ci/containers/fedora-43-cross-mingw64.Dockerfile similarity index 98% rename from ci/containers/fedora-42-cross-mingw64.Dockerfile rename to ci/containers/fedora-43-cross-mingw64.Dockerfile index 9d59a70975..ff6c3f8aa9 100644 --- a/ci/containers/fedora-42-cross-mingw64.Dockerfile +++ b/ci/containers/fedora-43-cross-mingw64.Dockerfile @@ -4,7 +4,7 @@ # # https://gitlab.com/libvirt/libvirt-ci -FROM registry.fedoraproject.org/fedora:42 +FROM registry.fedoraproject.org/fedora:43 RUN dnf install -y nosync && \ printf '#!/bin/sh\n\ diff --git a/ci/containers/fedora-41.Dockerfile b/ci/containers/fedora-43.Dockerfile similarity index 98% rename from ci/containers/fedora-41.Dockerfile rename to ci/containers/fedora-43.Dockerfile index 89732dd529..55f68a5839 100644 --- a/ci/containers/fedora-41.Dockerfile +++ b/ci/containers/fedora-43.Dockerfile @@ -4,7 +4,7 @@ # # https://gitlab.com/libvirt/libvirt-ci -FROM registry.fedoraproject.org/fedora:41 +FROM registry.fedoraproject.org/fedora:43 RUN dnf install -y nosync && \ printf '#!/bin/sh\n\ diff --git a/ci/gitlab/builds.yml b/ci/gitlab/builds.yml index ae691862c2..950b7b9282 100644 --- a/ci/gitlab/builds.yml +++ b/ci/gitlab/builds.yml @@ -103,21 +103,6 @@ x86_64-debian-sid: TARGET_BASE_IMAGE: docker.io/library/debian:sid-slim -x86_64-fedora-41: - extends: .native_build_job - needs: - - job: x86_64-fedora-41-container - optional: true - allow_failure: false - variables: - NAME: fedora-41 - TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:41 - artifacts: - expire_in: 1 day - paths: - - libvirt-rpms - - x86_64-fedora-42: extends: .native_build_job needs: @@ -133,6 +118,21 @@ x86_64-fedora-42: - libvirt-rpms +x86_64-fedora-43: + extends: .native_build_job + needs: + - job: x86_64-fedora-43-container + optional: true + allow_failure: false + variables: + NAME: fedora-43 + TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:43 + artifacts: + expire_in: 1 day + paths: + - libvirt-rpms + + x86_64-fedora-rawhide: extends: .native_build_job needs: @@ -416,29 +416,29 @@ s390x-debian-sid: TARGET_BASE_IMAGE: docker.io/library/debian:sid-slim -mingw32-fedora-42: +mingw32-fedora-43: extends: .cross_build_job needs: - - job: mingw32-fedora-42-container + - job: mingw32-fedora-43-container optional: true allow_failure: false variables: CROSS: mingw32 JOB_OPTIONAL: 1 - NAME: fedora-42 - TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:42 + NAME: fedora-43 + TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:43 -mingw64-fedora-42: +mingw64-fedora-43: extends: .cross_build_job needs: - - job: mingw64-fedora-42-container + - job: mingw64-fedora-43-container optional: true allow_failure: false variables: CROSS: mingw64 - NAME: fedora-42 - TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:42 + NAME: fedora-43 + TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:43 mingw32-fedora-rawhide: diff --git a/ci/gitlab/containers.yml b/ci/gitlab/containers.yml index 0650e4781c..cd2262e273 100644 --- a/ci/gitlab/containers.yml +++ b/ci/gitlab/containers.yml @@ -49,13 +49,6 @@ x86_64-debian-sid-container: NAME: debian-sid -x86_64-fedora-41-container: - extends: .container_job - allow_failure: false - variables: - NAME: fedora-41 - - x86_64-fedora-42-container: extends: .container_job allow_failure: false @@ -63,6 +56,13 @@ x86_64-fedora-42-container: NAME: fedora-42 +x86_64-fedora-43-container: + extends: .container_job + allow_failure: false + variables: + NAME: fedora-43 + + x86_64-fedora-rawhide-container: extends: .container_job allow_failure: true @@ -220,19 +220,19 @@ s390x-debian-sid-container: NAME: debian-sid-cross-s390x -mingw32-fedora-42-container: +mingw32-fedora-43-container: extends: .container_job allow_failure: false variables: JOB_OPTIONAL: 1 - NAME: fedora-42-cross-mingw32 + NAME: fedora-43-cross-mingw32 -mingw64-fedora-42-container: +mingw64-fedora-43-container: extends: .container_job allow_failure: false variables: - NAME: fedora-42-cross-mingw64 + NAME: fedora-43-cross-mingw64 mingw32-fedora-rawhide-container: diff --git a/ci/integration.yml b/ci/integration.yml index 2c5e5a65bc..b7e301b4c0 100644 --- a/ci/integration.yml +++ b/ci/integration.yml @@ -29,23 +29,23 @@ centos-stream-9-tests: # and libvirt-python CI jobs, so the new target needs to be introduced # there before it can be used here. The VM template for the target # also needs to be created on the runner host. -fedora-41-tests: +fedora-43-tests: extends: .integration_tests variables: # needed by libvirt-gitlab-executor - DISTRO: fedora-41 + DISTRO: fedora-43 # can be overridden in forks to set a different runner tag LIBVIRT_CI_INTEGRATION_RUNNER_TAG: redhat-vm-host tags: - $LIBVIRT_CI_INTEGRATION_RUNNER_TAG needs: - - x86_64-fedora-41 + - x86_64-fedora-43 - project: libvirt/libvirt-perl - job: x86_64-fedora-41 + job: x86_64-fedora-43 ref: master artifacts: true - project: libvirt/libvirt-python - job: x86_64-fedora-41 + job: x86_64-fedora-43 ref: master artifacts: true @@ -53,22 +53,22 @@ fedora-41-tests: # and libvirt-python CI jobs, so the new target needs to be introduced # there before it can be used here. The VM template for the target # also needs to be created on the runner host. -.fedora-41-upstream-qemu-tests: +.fedora-43-upstream-qemu-tests: extends: .integration_tests variables: # needed by libvirt-gitlab-executor - DISTRO: fedora-41 + DISTRO: fedora-43 # can be overridden in forks to set a different runner tag LIBVIRT_CI_INTEGRATION_RUNNER_TAG: redhat-vm-host tags: - $LIBVIRT_CI_INTEGRATION_RUNNER_TAG needs: - - x86_64-fedora-41 + - x86_64-fedora-43 - project: libvirt/libvirt-perl - job: x86_64-fedora-41 + job: x86_64-fedora-43 ref: master artifacts: true - project: libvirt/libvirt-python - job: x86_64-fedora-41 + job: x86_64-fedora-43 ref: master artifacts: true diff --git a/ci/manifest.yml b/ci/manifest.yml index 21d570cb00..e41cbfaf62 100644 --- a/ci/manifest.yml +++ b/ci/manifest.yml @@ -104,14 +104,6 @@ targets: containers: false builds: false - fedora-41: - jobs: - - arch: x86_64 - artifacts: - expire_in: 1 day - paths: - - libvirt-rpms - fedora-42: jobs: - arch: x86_64 @@ -120,6 +112,14 @@ targets: paths: - libvirt-rpms + fedora-43: + jobs: + - arch: x86_64 + artifacts: + expire_in: 1 day + paths: + - libvirt-rpms + - arch: mingw32 builds: false -- 2.51.0

3 2

[PATCH v2 0/5] qemu: Implement support for iommufd
by Nathan Chen 22 Nov '25

22 Nov '25

Hi, This is a follow up to the first patch series [0] for using iommufd to propagate DMA mappings to the kernel for VM-assigned host devices in a qemu VM. We add a new 'iommufd' attribute for hostdev devices to be associated with the iommufd object. For instance, specifying the iommufd object and associated hostdev in a VM definition: <devices> ... <hostdev mode='subsystem' type='pci' managed='no'> <driver iommufd='yes'/> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='no'> <driver iommufd='yes'/> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> ... </devices> This would get translated to a qemu command line with the arguments below. Note that libvirt will open the /dev/iommu and VFIO cdev, passing the associated fd number to qemu: -object '{"qom-type":"iommufd","id":"iommufd0","fd":"24"}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","iommufd":"iommufd0","fd":"22","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","iommufd":"iommufd0","fd":"25","bus":"pci.22","addr":"0x0"}' \ Note that when Libvirt launches the qemu process as an unprivileged user, i.e. libvirt-qemu, it is bound by the RLIMIT_MEMLOCK limit calculated based on how much RAM is assigned to the VM. IOMMUFD's unified memory accounting causes ENOMEM errors for large device BARs that exceed the process memlock limit. VFIO without IOMMUFD does not check device memory against the limit and therefore does not show this behavior. To work around the issue, we can specify CAP_IPC_LOCK=ep capability for the qemu binary to bypass the RLIMIT_MEMLOCK limit. I am working on a long-term fix in the kernel to mark device memory regions so they do not count against the RLIMIT_MEMLOCK limit for how much memory can be locked/pinned, as I/O device BARs do not consume host RAM. This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/iommufd-11-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/MYPM… Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (5): qemu: Implement support for associating iommufd to hostdev qemu: open VFIO FDs from libvirt backend qemu: open iommufd FD from libvirt backend qemu: Update Cgroup, namespace, and seclabel for iommufd tests: qemuxmlconfdata: provide iommufd sample XML and CLI args docs/formatdomain.rst | 8 + src/conf/device_conf.c | 12 ++ src/conf/device_conf.h | 1 + src/conf/domain_conf.h | 2 + src/conf/schemas/basictypes.rng | 5 + src/libvirt_private.syms | 1 + src/qemu/qemu_cgroup.c | 26 +-- src/qemu/qemu_command.c | 53 ++++- src/qemu/qemu_domain.c | 40 ++++ src/qemu/qemu_domain.h | 19 ++ src/qemu/qemu_namespace.c | 16 +- src/qemu/qemu_process.c | 186 ++++++++++++++++++ src/security/security_apparmor.c | 18 +- src/security/security_dac.c | 28 ++- src/security/security_selinux.c | 28 ++- src/security/virt-aa-helper.c | 11 +- src/util/virpci.c | 69 +++++++ src/util/virpci.h | 2 + .../iommufd-q35.x86_64-latest.args | 41 ++++ .../iommufd-q35.x86_64-latest.xml | 60 ++++++ tests/qemuxmlconfdata/iommufd-q35.xml | 38 ++++ .../iommufd-virt.aarch64-latest.args | 33 ++++ .../iommufd-virt.aarch64-latest.xml | 34 ++++ tests/qemuxmlconfdata/iommufd-virt.xml | 22 +++ .../iommufd.x86_64-latest.args | 35 ++++ .../qemuxmlconfdata/iommufd.x86_64-latest.xml | 38 ++++ tests/qemuxmlconfdata/iommufd.xml | 30 +++ tests/qemuxmlconftest.c | 33 ++++ 28 files changed, 839 insertions(+), 50 deletions(-) create mode 100644 tests/qemuxmlconfdata/iommufd-q35.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd-q35.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd-q35.xml create mode 100644 tests/qemuxmlconfdata/iommufd-virt.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd-virt.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd-virt.xml create mode 100644 tests/qemuxmlconfdata/iommufd.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd.xml -- 2.43.0

1 5

[PATCH 0/4] cover letter: qemu: Implement support for iommufd
by Nathan Chen 22 Nov '25

22 Nov '25

Hi, This series implements support for using iommufd to propagate DMA mappings to the kernel for VM-assigned host devices in a qemu VM. We add a new 'iommufd' attribute for hostdev devices to be associated with the iommufd object. For instance, specifying the iommufd object and associated hostdev in a VM definition: <devices> ... <hostdev mode='subsystem' type='pci' managed='no'> <driver iommufd='yes'/> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='no'> <driver iommufd='yes'/> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> ... </devices> This would get translated to a qemu command line with the arguments below. Note that libvirt will open the /dev/iommu and VFIO cdev, passing the associated fd number to qemu: -object '{"qom-type":"iommufd","id":"iommufd0","fd":"24"}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","iommufd":"iommufd0","fd":"22","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","iommufd":"iommufd0","fd":"25","bus":"pci.22","addr":"0x0"}' \ This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/iommufd-10-23-25 Thanks, Nathan Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (4): qemu: Implement support for associating iommufd to hostdev qemu: open iommufd FDs from libvirt backend qemu: Update Cgroup, namespace, and seclabel for qemu to access iommufd paths tests: qemuxmlconfdata: provide iommufd sample XML and CLI args docs/formatdomain.rst | 8 + src/conf/device_conf.c | 9 + src/conf/device_conf.h | 1 + src/conf/schemas/basictypes.rng | 5 + src/qemu/qemu_cgroup.c | 61 +++++ src/qemu/qemu_cgroup.h | 1 + src/qemu/qemu_command.c | 62 ++++- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_domain.c | 8 + src/qemu/qemu_domain.h | 7 + src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_namespace.c | 44 ++++ src/qemu/qemu_process.c | 232 ++++++++++++++++++ src/security/security_apparmor.c | 15 ++ src/security/security_dac.c | 34 +++ src/security/security_selinux.c | 34 +++ src/security/virt-aa-helper.c | 11 +- src/util/virpci.c | 68 +++++ src/util/virpci.h | 1 + .../iommufd-q35.x86_64-latest.args | 41 ++++ .../iommufd-q35.x86_64-latest.xml | 60 +++++ tests/qemuxmlconfdata/iommufd-q35.xml | 38 +++ .../iommufd-virt.aarch64-latest.args | 33 +++ .../iommufd-virt.aarch64-latest.xml | 34 +++ tests/qemuxmlconfdata/iommufd-virt.xml | 22 ++ .../iommufd.x86_64-latest.args | 35 +++ .../qemuxmlconfdata/iommufd.x86_64-latest.xml | 38 +++ tests/qemuxmlconfdata/iommufd.xml | 30 +++ tests/qemuxmlconftest.c | 4 + 29 files changed, 934 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxmlconfdata/iommufd-q35.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd-q35.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd-q35.xml create mode 100644 tests/qemuxmlconfdata/iommufd-virt.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd-virt.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd-virt.xml create mode 100644 tests/qemuxmlconfdata/iommufd.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd.xml -- 2.43.0

4 20

[PATCH] docs: bhyve: document VNC's wait attribute
by Roman Bogorodskiy 21 Nov '25

21 Nov '25

Document the new VNC's 'wait' attribute in: - drvbhyve.rst - formatdomain.rst - NEWS.rst Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- NEWS.rst | 5 +++++ docs/drvbhyve.rst | 10 ++++++++++ docs/formatdomain.rst | 4 ++++ 3 files changed, 19 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 3c3a88ba5b..e2d382d5f8 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -19,6 +19,11 @@ v11.10.0 (unreleased) * **Improvements** + * bhyve: VNC ``wait`` attribute support + + Bhyve guests can now be configured to wait for a VNC connection before + booting. + * **Bug fixes** diff --git a/docs/drvbhyve.rst b/docs/drvbhyve.rst index 73372ff7cf..c0f4cd8a1f 100644 --- a/docs/drvbhyve.rst +++ b/docs/drvbhyve.rst @@ -429,6 +429,16 @@ Note: VNC password authentication is known to be cryptographically weak. Additionally, the password is passed as a command line argument in clear text. Make sure you understand the risks associated with this feature before using it. +:since:`Since 11.10.0`, the guest can be configured to wait for an incoming +VNC connection before booting: + +:: + + <graphics type='vnc' port='5904' wait='yes'> + <listen type='address' address='127.0.0.1'/> + </graphics> + + Clock configuration ~~~~~~~~~~~~~~~~~~~ diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index c6d0b183d0..3d3a6b5a6e 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -6902,6 +6902,10 @@ interaction with the admin. ID is specified, then the default audio backend will be used. :since:`Since 7.2.0, qemu`. + The optional ``wait`` attribute, when set to ``yes``, causes the guest + to wait for an incoming VNC connection before booting. + :since:`Since 11.10.0, bhyve`. + ``spice`` :since:`Since 0.8.6` Starts a SPICE server. The ``port`` attribute specifies the TCP port number (with -1 as legacy syntax indicating that it should be -- 2.51.2

2 1

[PATCH] tests: Don't link vmx2xmltest with esx_lib
by Michal Privoznik 21 Nov '25

21 Nov '25

From: Michal Privoznik <mprivozn(a)redhat.com> When reworking the vmx2xmltest to call esxParseVMXFileName() from the ESX driver I also made the test link with the driver statically. But the function then calls some other functions which are mocked in vmx2xmlmock. Now, on many systems this works just fine as the dynamic linker finds the mocked functions first. But on Fedora 41 and Fedora 42 the dynamic linker resolves the symbols to those from statically linked library rendering our mock ineffective. Just don't link in the esx_lib. Fixes: f82d30307da8bea396a32dcab2ba9be5c3236b7c Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Green pipeline: https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/2172179136 tests/meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/meson.build b/tests/meson.build index 1f25f674f4..bb6ee6b4ee 100644 --- a/tests/meson.build +++ b/tests/meson.build @@ -550,7 +550,7 @@ endif if conf.has('WITH_VMX') and conf.has('WITH_ESX') tests += [ - { 'name': 'vmx2xmltest', 'include': [ esx_inc_dir ], 'link_with': [ esx_lib ] }, + { 'name': 'vmx2xmltest', 'include': [ esx_inc_dir ] }, { 'name': 'xml2vmxtest' }, ] mock_libs += [ -- 2.51.0

2 1

[PATCH RESEND] qemu: Remove redundant kvm group config in sysusers.d
by Achill Gilgenast 21 Nov '25

21 Nov '25

It's already defined by default in systemd: https://github.com/systemd/systemd/blob/v257.6/sysusers.d/basic.conf.in#L32 Adding it again here in libvirt-qemu.sysusers.conf causes the following warning by validating it with sd-sysuers: /usr/lib/sysusers.d/libvirt-qemu.conf:1: Conflict with earlier configuration for group 'kvm' in /usr/lib/sysusers.d/basic.conf:32, ignoring line. I don't know if the GID is important, but from simple grepping around it doesn't seem that way. Signed-off-by: Achill Gilgenast <achill(a)achill.org> --- src/qemu/libvirt-qemu.sysusers.conf | 1 - 1 file changed, 1 deletion(-) diff --git a/src/qemu/libvirt-qemu.sysusers.conf b/src/qemu/libvirt-qemu.sysusers.conf index 3189191e738a..05c35f94d814 100644 --- a/src/qemu/libvirt-qemu.sysusers.conf +++ b/src/qemu/libvirt-qemu.sysusers.conf @@ -1,4 +1,3 @@ -g kvm 36 g qemu 107 u qemu 107:qemu "qemu user" - - m qemu kvm -- 2.51.2

2 1

[PATCH 0/2] bhyve: support VNC 'wait' attribute
by Roman Bogorodskiy 21 Nov '25

21 Nov '25

Roman Bogorodskiy (2): conf: introduce 'wait' attribute for VNC bhyve: support VNC 'wait' attribute src/bhyve/bhyve_command.c | 3 ++ src/conf/domain_conf.c | 11 +++++ src/conf/domain_conf.h | 1 + src/conf/schemas/domaincommon.rng | 5 +++ .../bhyvexml2argv-vnc-wait-no.args | 13 ++++++ .../bhyvexml2argv-vnc-wait-no.ldargs | 1 + .../bhyvexml2argv-vnc-wait-no.xml | 26 +++++++++++ .../bhyvexml2argv-vnc-wait.args | 13 ++++++ .../bhyvexml2argv-vnc-wait.ldargs | 1 + .../bhyvexml2argv-vnc-wait.xml | 26 +++++++++++ tests/bhyvexml2argvtest.c | 2 + .../bhyvexml2xmlout-vnc-wait-no.xml | 44 +++++++++++++++++++ .../bhyvexml2xmlout-vnc-wait.xml | 44 +++++++++++++++++++ tests/bhyvexml2xmltest.c | 2 + 14 files changed, 192 insertions(+) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-wait-no.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-wait-no.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-wait-no.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-wait.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-wait.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-wait.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-vnc-wait-no.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-vnc-wait.xml -- 2.51.2

3 8

[PATCH] cputest: Skip test for Intel(R) Xeon(R) 6788P CPU when QEMU driver is disabled
by Jaroslav Suchanek 21 Nov '25

21 Nov '25

From: Jaroslav Suchanek <jsuchane(a)redhat.com> Commit 034f02d25cd8de8c7875d7b12e762df4809a8418 added new test for the Intel(R) Xeon(R) 6788P cpu model. The test depends on QEMU driver. If the driver is not available, then skip it. Similarly as in commit c22b73411732b9a135923c19b7784c7c48729042. Signed-off-by: Jaroslav Suchanek <jsuchane(a)redhat.com> --- tests/cputest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/cputest.c b/tests/cputest.c index 16bbae7ba5..a7d6ea8736 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -1226,7 +1226,7 @@ mymain(void) DO_TEST_CPUID(VIR_ARCH_X86_64, "Ryzen-9-9950X-16-Core", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-5110", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-6731E", JSON_MODELS); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-6788P", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-6788P", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Bronze-3408U", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1225-v5", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1245-v5", JSON_MODELS); -- 2.50.1 (Apple Git-155)

2 1

[PATCH] tests: skip vmx tests when ESX is disabled
by Daniel P. Berrangé 21 Nov '25

21 Nov '25

From: Daniel P. Berrangé <berrange(a)redhat.com> Since the recent change: commit f82d30307da8bea396a32dcab2ba9be5c3236b7c Author: Michal Prívozník <mprivozn(a)redhat.com> Date: Fri Nov 14 10:35:14 2025 +0100 vmx2xmltest: Drop custom file name parse function The VMX parsing uses the esxParseVMXFileName() function in the ESX library. This is unavailable when the ESX driver is disabled, so the tests must be skipped too. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- tests/meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/meson.build b/tests/meson.build index cd53e48aa4..1f25f674f4 100644 --- a/tests/meson.build +++ b/tests/meson.build @@ -548,7 +548,7 @@ if conf.has('WITH_VMWARE') ] endif -if conf.has('WITH_VMX') +if conf.has('WITH_VMX') and conf.has('WITH_ESX') tests += [ { 'name': 'vmx2xmltest', 'include': [ esx_inc_dir ], 'link_with': [ esx_lib ] }, { 'name': 'xml2vmxtest' }, -- 2.51.1

2 1

[PATCH] Allow passt to create user namespaces
by Daniel P. Berrangé 21 Nov '25

21 Nov '25

From: BlueC0re <bluecore90(a)googlemail.com> Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- This comes from https://gitlab.com/libvirt/libvirt/-/merge_requests/493 I'm willing to add my own SoB since it is trivial, but I would like a sanity-check from someone more familiar with AppArmor so re-posting here before pushing. src/security/apparmor/libvirt-qemu | 1 + 1 file changed, 1 insertion(+) diff --git a/src/security/apparmor/libvirt-qemu b/src/security/apparmor/libvirt-qemu index e4aceacd70..f736b37fe5 100644 --- a/src/security/apparmor/libvirt-qemu +++ b/src/security/apparmor/libvirt-qemu @@ -194,6 +194,7 @@ /usr/bin/passt Cx -> passt, profile passt { + userns, /usr/bin/passt r, signal (receive) set=("term") peer=/usr/sbin/libvirtd, -- 2.51.1

1 0

[PATCH 0/9] esx: Allow disk images in subdirectories
by Michal Privoznik 21 Nov '25

21 Nov '25

*** BLURB HERE *** Michal Prívozník (9): libvirt_esx.syms: Put proper header file name into comment esx: Expose esxParseVMXFileName() for tests esx: Make esxVI_LookupDatastoreList() mockable esx: Make esxVI_LookupDatastoreHostMount() mockable esx: Make esxVI_LookupDatastoreByName() mockable tests: Introduce vmx2xmlmock vmx2xmltest: Drop custom file name parse function esx: Allow disk images in subdirectories vmx2xmltest: Add a test case for disks in subfolder src/esx/esx_driver.c | 24 +++-- src/esx/esx_driverpriv.h | 27 ++++++ src/esx/esx_vi.h | 6 +- src/libvirt_esx.syms | 23 +++++ tests/meson.build | 5 +- tests/vmx2xmldata/esx-in-the-wild-17.vmx | 106 +++++++++++++++++++++++ tests/vmx2xmldata/esx-in-the-wild-17.xml | 46 ++++++++++ tests/vmx2xmlmock.c | 79 +++++++++++++++++ tests/vmx2xmltest.c | 62 +++---------- 9 files changed, 308 insertions(+), 70 deletions(-) create mode 100644 src/esx/esx_driverpriv.h create mode 100644 tests/vmx2xmldata/esx-in-the-wild-17.vmx create mode 100644 tests/vmx2xmldata/esx-in-the-wild-17.xml create mode 100644 tests/vmx2xmlmock.c -- 2.51.0

3 14

[RFC PATCH] qemu_validate: Fix aarch64 ACPI firmware type check
by Kazuhiro Abe 21 Nov '25

21 Nov '25

Although QEMU allows ACPI with UEFI firmware via the '-bios' option on aarch64, libvirt rejected such configurations through its validation. Therefore, the conditional statement was changed to allow the following settings: <os> <type arch='aarch64' machine='virt-4.0'>hvm</type> <loader type="rom">/usr/share/qemu-efi-aarch64/QEMU_EFI.fd</loader> </os> <features> <acpi/> </features> Specifying <os firmware='bios'> still results in error, as before. Signed-off-by: Kazuhiro Abe <fj1078ii(a)aa.jp.fujitsu.com> --- src/qemu/qemu_validate.c | 2 +- ...auto-bios-acpi-aarch64.aarch64-latest.err} | 0 .../firmware-auto-bios-acpi-aarch64.xml | 17 ++++++++++ ...ual-noefi-acpi-aarch64.aarch64-latest.args | 31 +++++++++++++++++++ ...nual-noefi-acpi-aarch64.aarch64-latest.xml | 29 +++++++++++++++++ tests/qemuxmlconftest.c | 3 +- 6 files changed, 80 insertions(+), 2 deletions(-) rename tests/qemuxmlconfdata/{firmware-manual-noefi-acpi-aarch64.aarch64-latest.err => firmware-auto-bios-acpi-aarch64.aarch64-latest.err} (100%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-bios-acpi-aarch64.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.xml diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c index 3b0f2b50a5..263aaa25a2 100644 --- a/src/qemu/qemu_validate.c +++ b/src/qemu/qemu_validate.c @@ -1341,7 +1341,7 @@ qemuValidateDomainDef(const virDomainDef *def, /* On aarch64, ACPI requires UEFI */ if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON && def->os.arch == VIR_ARCH_AARCH64 && - (def->os.firmware != VIR_DOMAIN_OS_DEF_FIRMWARE_EFI && + (def->os.firmware == VIR_DOMAIN_OS_DEF_FIRMWARE_BIOS && !virDomainDefHasOldStyleUEFI(def))) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("ACPI requires UEFI on this architecture")); diff --git a/tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.err b/tests/qemuxmlconfdata/firmware-auto-bios-acpi-aarch64.aarch64-latest.err similarity index 100% rename from tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.err rename to tests/qemuxmlconfdata/firmware-auto-bios-acpi-aarch64.aarch64-latest.err diff --git a/tests/qemuxmlconfdata/firmware-auto-bios-acpi-aarch64.xml b/tests/qemuxmlconfdata/firmware-auto-bios-acpi-aarch64.xml new file mode 100644 index 0000000000..37c4efdb80 --- /dev/null +++ b/tests/qemuxmlconfdata/firmware-auto-bios-acpi-aarch64.xml @@ -0,0 +1,17 @@ +<domain type='qemu'> + <name>guest</name> + <uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid> + <memory unit='KiB'>1048576</memory> + <vcpu placement='static'>1</vcpu> + <os firmware='bios'> + <type arch='aarch64' machine='virt-4.0'>hvm</type> + </os> + <features> + <acpi/> + </features> + <devices> + <emulator>/usr/bin/qemu-system-aarch64</emulator> + <controller type='usb' model='none'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.args b/tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.args new file mode 100644 index 0000000000..fe79a7e746 --- /dev/null +++ b/tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.args @@ -0,0 +1,31 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/var/lib/libvirt/qemu/domain--1-guest \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-guest/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-guest/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-guest/.config \ +/usr/bin/qemu-system-aarch64 \ +-name guest=guest,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-guest/master-key.aes"}' \ +-machine virt-4.0,usb=off,gic-version=2,dump-guest-core=off,memory-backend=mach-virt.ram,acpi=on \ +-accel tcg \ +-cpu cortex-a15 \ +-m size=1048576k \ +-object '{"qom-type":"memory-backend-ram","id":"mach-virt.ram","size":1073741824}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 63840878-0deb-4095-97e6-fc444d9bc9fa \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.xml b/tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.xml new file mode 100644 index 0000000000..b713a65714 --- /dev/null +++ b/tests/qemuxmlconfdata/firmware-manual-noefi-acpi-aarch64.aarch64-latest.xml @@ -0,0 +1,29 @@ +<domain type='qemu'> + <name>guest</name> + <uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid> + <memory unit='KiB'>1048576</memory> + <currentMemory unit='KiB'>1048576</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='aarch64' machine='virt-4.0'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <gic version='2'/> + </features> + <cpu mode='custom' match='exact' check='none'> + <model fallback='forbid'>cortex-a15</model> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-aarch64</emulator> + <controller type='usb' index='0' model='none'/> + <controller type='pci' index='0' model='pcie-root'/> + <audio id='1' type='none'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c index dd55c1ef28..122e644caf 100644 --- a/tests/qemuxmlconftest.c +++ b/tests/qemuxmlconftest.c @@ -1554,10 +1554,11 @@ mymain(void) DO_TEST_CAPS_LATEST("firmware-manual-efi-acpi-q35"); DO_TEST_CAPS_ARCH_LATEST("firmware-manual-efi-noacpi-aarch64", "aarch64"); DO_TEST_CAPS_LATEST_PARSE_ERROR("firmware-manual-efi-noacpi-q35"); - DO_TEST_CAPS_ARCH_LATEST_PARSE_ERROR("firmware-manual-noefi-acpi-aarch64", "aarch64"); + DO_TEST_CAPS_ARCH_LATEST("firmware-manual-noefi-acpi-aarch64", "aarch64"); DO_TEST_CAPS_LATEST("firmware-manual-noefi-acpi-q35"); DO_TEST_CAPS_ARCH_LATEST("firmware-manual-noefi-noacpi-aarch64", "aarch64"); DO_TEST_CAPS_LATEST("firmware-manual-noefi-noacpi-q35"); + DO_TEST_CAPS_ARCH_LATEST_PARSE_ERROR("firmware-auto-bios-acpi-aarch64", "aarch64"); /* Ensure that legacy firmware paths keep working */ DO_TEST_CAPS_LATEST("firmware-manual-efi-secboot-legacy-paths"); -- 2.43.0

3 2

[PATCH v4 0/4] cover letter: qemu: Implement support for multiple device-pluggable SMMUv3s
by Nathan Chen 20 Nov '25

20 Nov '25

Hi, This is a follow up to the third patchset [0] for supporting multiple device-pluggable vSMMU instances. This patchset implements support for specifying multiple <iommu> devices within the VM definition when smmuv3 IOMMU model is specified with a pciBus driver attribute, and is tested with Shameer's recently accepted qemu series for user-creatable vSMMU devices [1] For instance, specifying the associated emulated device in a VM definition with multiple IOMMUs, configured to be routed to pcie-expander-bus or pcie-root controllers: <devices> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='252'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> ... <rng model='virtio'> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </rng> <rng model='virtio'> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </rng> <iommu model='smmuv3'> <driver pciBus='0'/> </iommu> <iommu model='smmuv3'> <driver pciBus='1'/> </iommu> </devices> This would get translated to a qemu command line with the arguments below. -device '{"driver":"pxb-pcie","bus_nr":252,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \ -device '{"driver":"pcie-root-port","port":0,"chassis":2,"id":"pci.2","bus":"pci.1","addr":"0x0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pcie.0","id":"smmuv3.0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.1","id":"smmuv3.1"}' \ ... -object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ -device '{"driver":"virtio-rng-pci","rng":"objrng0","id":"rng0","bus":"pci.2","addr":"0x0"}' \ -object '{"qom-type":"rng-random","id":"objrng1","filename":"/dev/urandom"}' \ -device '{"driver":"virtio-rng-pci","rng":"objrng1","id":"rng1","bus":"pcie.0","addr":"0x4"}' \ Changes from v3: - Fixed formatting and removed unnecessary logic - Break instead of returning in switch statement for qemuBuildIOMMUCommandLine - Create a separate commit for formatting IOMMU devices after controllers in qemu command - Included Reviewed-by tag on qemuxmlconftest commit Changes from v2: - Make multi-iommu adoption the first commit - Consolidate smmuv3Dev into smmuv3 model - Change 'parentIdx' attribute name to 'pciBus' - Change naming of virDomainDef 'iommu' attribute to 'iommus' - Move multi-iommu check to validation code - Move qemu dev props function to device-pluggable smmuv3 commit - Fix conditional statements per feedback Changes from v1: - Moved parentIdx attribute under <driver> - Revised qemuxmlconfdata test cases to attach emulated devices This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/nestedsmmuv3-no-accel-11-1… Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5MHA… [1] https://lore.kernel.org/qemu-devel/20250829082543.7680-1-skolothumtho@nvidi… Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (4): conf: Support multiple device-pluggable smmuv3 IOMMUs qemu: Implement pluggable-device smmuv3 qemu: Format IOMMU devices after controllers tests: qemuxmlconfdata: provide device-pluggable smmuv3 sample XML and CLI args docs/formatdomain.rst | 4 + src/conf/domain_conf.c | 100 ++++++++-- src/conf/domain_conf.h | 10 +- src/conf/domain_validate.c | 61 ++++-- src/conf/schemas/domaincommon.rng | 9 +- src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 15 +- src/qemu/qemu_command.c | 184 +++++++++++------- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_domain_address.c | 5 +- src/qemu/qemu_driver.c | 8 +- src/qemu/qemu_postparse.c | 9 +- src/qemu/qemu_validate.c | 2 +- .../iommu-smmuv3-pci-bus.aarch64-latest.args | 41 ++++ .../iommu-smmuv3-pci-bus.aarch64-latest.xml | 62 ++++++ .../qemuxmlconfdata/iommu-smmuv3-pci-bus.xml | 49 +++++ tests/qemuxmlconftest.c | 1 + 17 files changed, 440 insertions(+), 124 deletions(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus.xml -- 2.43.0

2 10

[PATCH 0/5] tools: improve virt-host-validate output
by Daniel P. Berrangé 20 Nov '25

20 Nov '25

It now gives some details for certain checks: QEMU: Checking for hardware virtualization : PASS (VMX) QEMU: Checking if device '/dev/kvm' exists : PASS QEMU: Checking if device '/dev/kvm' is accessible : PASS QEMU: Checking if device '/dev/vhost-net' exists : PASS QEMU: Checking if device '/dev/net/tun' exists : PASS QEMU: Checking for cgroup 'cpu' controller support : PASS QEMU: Checking for cgroup 'cpuacct' controller support : PASS QEMU: Checking for cgroup 'cpuset' controller support : PASS QEMU: Checking for cgroup 'memory' controller support : PASS QEMU: Checking for cgroup 'devices' controller support : PASS QEMU: Checking for cgroup 'blkio' controller support : PASS QEMU: Checking for device assignment IOMMU support : PASS (DMAR) QEMU: Checking if IOMMU is enabled by kernel : PASS QEMU: Checking for secure guest support : PASS (TDX) Daniel P. Berrangé (5): tools: allow passing details for passed validation tests tools: inform user which IOMMU was found during validation tools: inform user which CVM is found during validation tools: be explicit about failure to find x86 secure virt tools: inform user which hardware virt was found during validation tools/virt-host-validate-common.c | 60 ++++++++++++------------------- tools/virt-host-validate-qemu.c | 16 ++++++--- tools/virt-validate-common.c | 12 ++++++- tools/virt-validate-common.h | 1 + 4 files changed, 47 insertions(+), 42 deletions(-) -- 2.51.1

2 12

[libvirt PATCH] qemu: make qemuBuildDeviceAddressPCIGetBus more generic
by Ján Tomko 20 Nov '25

20 Nov '25

From: Ján Tomko <jtomko(a)redhat.com> Operate on a virPCIDeviceAddress, not virDomainDeviceInfo so that this can be reused to look for buses that are not stored in the device info. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- A prerequisite for the SMMUv3 series src/qemu/qemu_command.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index c56c321a6e..d5a4201e12 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -332,7 +332,7 @@ qemuBuildMasterKeyCommandLine(virCommand *cmd, static char * qemuBuildDeviceAddressPCIGetBus(const virDomainDef *domainDef, - const virDomainDeviceInfo *info) + const virPCIDeviceAddress *pci) { g_autofree char *devStr = NULL; const char *contAlias = NULL; @@ -340,14 +340,14 @@ qemuBuildDeviceAddressPCIGetBus(const virDomainDef *domainDef, int contTargetIndex = 0; size_t i; - if (!(devStr = virPCIDeviceAddressAsString(&info->addr.pci))) + if (!(devStr = virPCIDeviceAddressAsString(pci))) return NULL; for (i = 0; i < domainDef->ncontrollers; i++) { virDomainControllerDef *cont = domainDef->controllers[i]; if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_PCI && - cont->idx == info->addr.pci.bus) { + cont->idx == pci->bus) { contAlias = cont->info.alias; contIsPHB = virDomainControllerIsPSeriesPHB(cont); contTargetIndex = cont->opts.pciopts.targetIndex; @@ -355,7 +355,7 @@ qemuBuildDeviceAddressPCIGetBus(const virDomainDef *domainDef, if (!contAlias) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Device alias was not set for PCI controller with index '%1$u' required for device at address '%2$s'"), - info->addr.pci.bus, devStr); + pci->bus, devStr); return NULL; } @@ -397,7 +397,7 @@ qemuBuildDeviceAddressPCIGetBus(const virDomainDef *domainDef, if (!contAlias) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Could not find PCI controller with index '%1$u' required for device at address '%2$s'"), - info->addr.pci.bus, devStr); + pci->bus, devStr); return NULL; } @@ -584,7 +584,7 @@ qemuBuildDeviceAddressProps(virJSONValue *props, switch (info->type) { case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI: { g_autofree char *pciaddr = NULL; - g_autofree char *bus = qemuBuildDeviceAddressPCIGetBus(domainDef, info); + g_autofree char *bus = qemuBuildDeviceAddressPCIGetBus(domainDef, &info->addr.pci); if (!bus) return -1; -- 2.51.1

2 1

[PATCH 0/2] qemu: fix capabilities reporting for TDX
by Daniel P. Berrangé 20 Nov '25

20 Nov '25

The capabilities reporting merged for TDX was flawed because it would always report TDX as supported simply if QEMU was new enough to have 'tdx-guest'. IOW, all x86 hosts currently report 'tdx' as fully supported which is a regression for AMD hosts, as we're now reporting incorrect data there which can confuse mgmt apps. Unfortunately the 'query-tdx-capabilities' QMP command that was in early postings: https://mail.gnu.org/archive/html/qemu-devel/2021-07/msg01689.html went missing and I'm not seeing an alternative way to query QEMU to see if TDX is actually launchable. So in these patches I open /dev/kvm and directly ask of the 'TDX' VM type is supported by KVM, which IIUC is equivalent to waht the original 'query-tdx-capabilities' patch was doing. Daniel P. Berrangé (2): qemu: correctly detect working TDX support qemu: always report TDX feature caps on x86 src/qemu/qemu_capabilities.c | 71 +++++++++++++++++-- src/qemu/qemu_capabilities.h | 3 + .../qemu_10.0.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 1 + .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 1 + .../qemu_10.0.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 1 + .../qemu_10.1.0-tcg.x86_64+inteltdx.xml | 1 + .../domaincapsdata/qemu_10.1.0-tcg.x86_64.xml | 1 + .../domaincapsdata/qemu_10.2.0-tcg.x86_64.xml | 1 + .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.x86_64.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.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.x86_64.xml | 1 + .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.2.0-tcg.x86_64.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.x86_64.xml | 1 + .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 1 + .../qemu_9.2.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 1 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 1 + .../qemu_9.2.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 1 + tests/domaincapsmock.c | 6 ++ 47 files changed, 120 insertions(+), 4 deletions(-) -- 2.51.1

3 10

[libvirt PATCH 0/3] build: drop userfaultfd_sysctl option
by Ján Tomko 20 Nov '25

20 Nov '25

Ján Tomko (3): qemu: drop postcopy-migration.sysctl spec: drop with_userfaultfd_sysctl build: drop userfaultfd_sysctl option libvirt.spec.in | 18 ------------------ meson.build | 7 ------- meson_options.txt | 2 -- src/qemu/meson.build | 8 -------- src/qemu/postcopy-migration.sysctl | 6 ------ 5 files changed, 41 deletions(-) delete mode 100644 src/qemu/postcopy-migration.sysctl -- 2.51.1

2 4

[PATCH v3 0/3] qemu: Implement support for multiple device-pluggable SMMUv3s
by Nathan Chen 20 Nov '25

20 Nov '25

Hi, This is a follow up to the second patchset [0] for supporting multiple device-pluggable vSMMU instances. (re-sending this series for review) This patchset implements support for specifying multiple <iommu> devices within the VM definition when smmuv3 IOMMU model is specified with a pciBus driver attribute, and is tested with Shameer's recently accepted qemu series for user-creatable vSMMU devices [1] For instance, specifying the associated emulated device in a VM definition with multiple IOMMUs, configured to be routed to pcie-expander-bus or pcie-root controllers: <devices> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='252'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> ... <rng model='virtio'> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </rng> <rng model='virtio'> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </rng> <iommu model='smmuv3'> <driver pciBus='0'/> </iommu> <iommu model='smmuv3'> <driver pciBus='1'/> </iommu> </devices> This would get translated to a qemu command line with the arguments below. -device '{"driver":"pxb-pcie","bus_nr":252,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \ -device '{"driver":"pcie-root-port","port":0,"chassis":2,"id":"pci.2","bus":"pci.1","addr":"0x0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pcie.0","id":"smmuv3.0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.1","id":"smmuv3.1"}' \ ... -object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ -device '{"driver":"virtio-rng-pci","rng":"objrng0","id":"rng0","bus":"pci.2","addr":"0x0"}' \ -object '{"qom-type":"rng-random","id":"objrng1","filename":"/dev/urandom"}' \ -device '{"driver":"virtio-rng-pci","rng":"objrng1","id":"rng1","bus":"pcie.0","addr":"0x4"}' \ Changes from v2: - Make multi-iommu adoption the first commit - Consolidate smmuv3Dev into smmuv3 model - Change 'parentIdx' attribute name to 'pciBus' - Change naming of virDomainDef 'iommu' attribute to 'iommus' - Move multi-iommu check to validation code - Move qemu dev props function to device-pluggable smmuv3 commit - Fix conditional statements per feedback Changes from v1: - Moved parentIdx attribute under <driver> - Revised qemuxmlconfdata test cases to attach emulated devices This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/nestedsmmuv3-no-accel-10-2… Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/IF6O… [1] https://lore.kernel.org/qemu-devel/20250829082543.7680-1-skolothumtho@nvidi… Nathan Chen (3): conf: Support multiple device-pluggable smmuv3 IOMMUs qemu: Implement pluggable-device smmuv3 tests: qemuxmlconfdata: provide device-pluggable smmuv3 sample XML and CLI args docs/formatdomain.rst | 4 + src/conf/domain_conf.c | 100 +++++++-- src/conf/domain_conf.h | 10 +- src/conf/domain_validate.c | 61 ++++-- src/conf/schemas/domaincommon.rng | 9 +- src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 15 +- src/qemu/qemu_command.c | 197 ++++++++++++------ src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_domain_address.c | 5 +- src/qemu/qemu_driver.c | 8 +- src/qemu/qemu_postparse.c | 11 +- src/qemu/qemu_validate.c | 2 +- .../iommu-smmuv3-pci-bus.aarch64-latest.args | 41 ++++ .../iommu-smmuv3-pci-bus.aarch64-latest.xml | 62 ++++++ .../qemuxmlconfdata/iommu-smmuv3-pci-bus.xml | 49 +++++ tests/qemuxmlconftest.c | 1 + 17 files changed, 455 insertions(+), 124 deletions(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus.xml -- 2.43.0

2 7

[PATCH v3 0/7] USB hostdev: allow addressing by port
by Maximilian Martin 19 Nov '25

19 Nov '25

Currently, only vendor/product and bus/device matching are supported for USB host devices. Neither of these provide a stable and persistent way of assigning a guest a specific host device. Vendor/product can be ambiguous. Device numbers change on every enumeration. This patch adds a bus/port matching, which allows a specific port on the host to be specified using the dotted notation found in Linux's "devpath" sysfs attribute. The path series is based on the previous work of Thomas Hebb: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7U3… This resubmission includes Daniel's patch which extends the USB hostdev test logic. Maximilian Martin (7): tests: validate an XML config with USB vendor/product set virusb test data: add devpath files for port addressing domain_conf, virhostdev, virusb, virusb test: add bus/port matching schema: add USB port attribute tests: validate an XML config with USB bus/port set nodedev: add USB port to nodedev XML docs: add description for USB port matching docs/formatdomain.rst | 29 ++-- src/conf/domain_conf.c | 58 ++++++- src/conf/domain_conf.h | 1 + src/conf/node_device_conf.c | 5 + src/conf/node_device_conf.h | 1 + src/conf/schemas/basictypes.rng | 31 ++++ src/conf/schemas/domaincommon.rng | 41 +---- src/conf/schemas/nodedev.rng | 3 + src/hypervisor/virhostdev.c | 131 ++++++++------ src/libvirt_private.syms | 2 - src/node_device/node_device_udev.c | 4 + src/util/virusb.c | 160 ++++++------------ src/util/virusb.h | 22 +-- .../usb_device_1d6b_1_0000_00_1d_0.xml | 1 + ...ostdev-usb-address-port.x86_64-latest.args | 36 ++++ ...hostdev-usb-address-port.x86_64-latest.xml | 45 +++++ .../hostdev-usb-address-port.xml | 28 +++ ...tdev-usb-vendor-product.x86_64-latest.args | 35 ++++ ...stdev-usb-vendor-product.x86_64-latest.xml | 44 +++++ .../hostdev-usb-vendor-product.xml | 36 ++++ tests/qemuxmlconftest.c | 25 +++ tests/virusbtest.c | 149 +++++++++++----- .../sys_bus_usb/devices/1-1.5.3.1/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.4/devpath | 1 + .../sys_bus_usb/devices/1-1.5.5/devpath | 1 + .../sys_bus_usb/devices/1-1.5.6/devpath | 1 + .../sys_bus_usb/devices/1-1.5/devpath | 1 + .../sys_bus_usb/devices/1-1.6/devpath | 1 + .../sys_bus_usb/devices/1-1/devpath | 1 + .../sys_bus_usb/devices/2-1.2/devpath | 1 + .../sys_bus_usb/devices/2-1/devpath | 1 + .../sys_bus_usb/devices/usb1/devpath | 1 + .../sys_bus_usb/devices/usb2/devpath | 1 + .../sys_bus_usb/devices/usb3/devpath | 1 + .../sys_bus_usb/devices/usb4/devpath | 1 + 37 files changed, 631 insertions(+), 271 deletions(-) create mode 100644 tests/qemuxmlconfdata/hostdev-usb-address-port.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/hostdev-usb-address-port.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/hostdev-usb-address-port.xml create mode 100644 tests/qemuxmlconfdata/hostdev-usb-vendor-product.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/hostdev-usb-vendor-product.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/hostdev-usb-vendor-product.xml create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.4/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1.2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb4/devpath -- 2.39.5

2 11

RFC Gitlab #692
by Wesley Hershberger 19 Nov '25

19 Nov '25

Hi all, I'm working on Gitlab #692 [1] and would appreciate a quick discussion/review/sanity check of the direction I'm planning to take before I invest many days in a solution that misses some major consideration. I'll provide a summary of the issue here and then lay out the two approaches I'm considering. The AppArmor sVirt driver creates & loads a dynamic AppArmor profile by passing a domain's XML description to a separate program `virt-aa-helper` (see [2] for more details). When a device is hotplugged to a domain, the `virt-aa-helper` is called with a flag (`-F`) which appends a rule for that device's backing resource to the profile. The profile is reloaded from the XML description whenever a device is hotunplugged. However, the XML description for some devices does not contain enough information to create the corresponding AppArmor rule. When a profile containing a dynamic rule is reloaded, the dynamic rule is lost, and the device fails (this has been observed with macvtap devices). A similar situation occurs when temporary write access to snapshot layers is needed during block-commit; the `virt-aa-helper` is called with `-F` to add the temporary access and the profile is reloaded at the end of the operation to remove it again. However, this can have the unintended side-effect of wiping out other temporary accesses (for concurrent blockcommits) or removing access for devices added with `-F` (macvtap). A solution must: - Be persistent across libvirtd restarts - Correctly synchronize concurrent profile modifications We've conceived of two broad approaches to this issue: 1. Add fields to the domain XML schema (and persist them) so that the profile can be correctly generated using only the domain's XML description. 2. Create a separate XML file `/etc/apparmor.d/libvirt/libvirt-UUID-dynamic.xml` with only the information needed to produce the dynamic rules; access would be synchronized by a lock in libvirtd. `virt-aa-helper` would consume this file every time it runs; the file would be removed on Domain shutdown. Option 1 (Add fields to Domain schema) Concerns: ================================================ - User-visible schema changes - Do additional fields make sense in the domain schema? e.g. - a macvtap device path `/dev/tapX` - permissions info in `backingStore` elements - It may be non-trivial to chase down every device that could be affected by this issue and plumb through the additional fields (i.e. a complete solution may not be possible) Option 2 (Separate AppArmor XML) Concerns: ========================================== - User-visible additional file - Not generalizable for (future) sVirt drivers that depend on synchronizing a global resource - May require adding remove/restore hooks for the following sVirt interfaces: - virSecurityDomainSetImageFDLabel domainSetSecurityImageFDLabel; - virSecurityDomainSetTapFDLabel domainSetSecurityTapFDLabel; I'd appreciate any input you'd be able to provide regarding the above trade-offs; specifically looking for guidance on what you would consider merging (in contrast to previous approaches [3]). Thanks very much for taking the time to review this, ~Wesley Hershberger Canonical Support [1] https://gitlab.com/libvirt/libvirt/-/issues/692 [2] https://gitlab.com/apparmor/apparmor/-/wikis/Libvirt [3] https://www.mail-archive.com/devel@lists.libvirt.org/msg07703.html

2 1

[PATCH 0/8] qemu: Add option to preserve shutdown VM during backup job and job/reconnection fixes
by Peter Krempa 19 Nov '25

19 Nov '25

This series first fixes few job handling, reconnection and backup job bugs and then implements an option to keep the VM process around when the guest OS shuts down during backup, so that the backup doesn't need to be restarted. Peter Krempa (8): virDomainNestedJobAllowed: Allow VIR_JOB_MODIFY_MIGRATION_SAFE if VIR_JOB_MODIFY is allowed qemuProcessReconnect: Continue reconnection if VM untergoes fake-reboot qemu: backup: Don't attempt to stop the NBD server twice qemuBlockJobProcessEventConcludedBackup: Notify the backup job later lib: Introduce VIR_DOMAIN_EVENT_SUSPENDED_GUEST_SHUTDOWN event reason lib: Introduce VIR_DOMAIN_BACKUP_BEGIN_PRESERVE_SHUTDOWN_DOMAIN flag qemu: backup: Add support for VIR_DOMAIN_BACKUP_BEGIN_PRESERVE_SHUTDOWN_DOMAIN kbase: Add note about preserving VM on shutdown to backup article docs/kbase/live_full_disk_backup.rst | 18 +++++ docs/manpages/virsh.rst | 6 ++ examples/c/misc/event-test.c | 3 + include/libvirt/libvirt-domain.h | 7 +- src/conf/backup_conf.h | 4 ++ src/conf/virdomainjob.c | 1 + src/libvirt-domain.c | 5 ++ src/qemu/qemu_backup.c | 61 +++++++++++++--- src/qemu/qemu_backup.h | 4 ++ src/qemu/qemu_blockjob.c | 7 +- src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_process.c | 101 +++++++++++++++++++++++++-- src/qemu/qemu_process.h | 3 +- tools/virsh-backup.c | 7 ++ tools/virsh-domain-event.c | 3 +- 15 files changed, 210 insertions(+), 22 deletions(-) -- 2.51.1

2 11

[PATCH] docs: domain: add watchdog notification support
by Massimiliano Minella via B4 Relay 19 Nov '25

19 Nov '25

From: Massimiliano Minella <massimiliano.minella(a)se.com> Since v0.8.0 a watchdog notification is available under event ID VIR_DOMAIN_EVENT_ID_WATCHDOG, update the documentation to remove the previous limitation. Signed-off-by: Massimiliano Minella <massimiliano.minella(a)se.com> --- Remove limitation on notification support for watchdog. --- docs/formatdomain.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git docs/formatdomain.rst docs/formatdomain.rst index f50dce477f..d70022a239 100644 --- docs/formatdomain.rst +++ docs/formatdomain.rst @@ -8350,8 +8350,8 @@ The watchdog device requires an additional driver and management daemon in the guest. Just enabling the watchdog in the libvirt configuration does not do anything useful on its own. -Currently libvirt does not support notification when the watchdog fires. This -feature is planned for a future version of libvirt. +:since:`Since 0.8.0`, a notification is available when the watchdog fires, using +the event ID ``VIR_DOMAIN_EVENT_ID_WATCHDOG``. Having multiple watchdogs is usually not something very common, but be aware that this might happen, for example, when an implicit watchdog device is added --- base-commit: eb99bbaf2e5b1e91f4999c7a1ccc90d67dfbe471 change-id: 20251003-update_wd_doc-5aa9b43be09a Best regards, -- Massimiliano Minella <massimiliano.minella(a)se.com>

2 1

RE: [PATCH] docs: domain: add watchdog notification support
by Massimiliano MINELLA 19 Nov '25

19 Nov '25

Hello, do you have any feedback on this patch? Best regards, Massimiliano General -----Original Message----- From: Massimiliano Minella via B4 Relay <devnull+massimiliano.minella.se.com(a)kernel.org> Sent: vendredi 3 octobre 2025 10:45 To: devel(a)lists.libvirt.org Cc: Massimiliano MINELLA <massimiliano.minella(a)se.com> Subject: [PATCH] docs: domain: add watchdog notification support [External email: Use caution with links and attachments] ________________________________ From: Massimiliano Minella <massimiliano.minella(a)se.com> Since v0.8.0 a watchdog notification is available under event ID VIR_DOMAIN_EVENT_ID_WATCHDOG, update the documentation to remove the previous limitation. Signed-off-by: Massimiliano Minella <massimiliano.minella(a)se.com> --- Remove limitation on notification support for watchdog. --- docs/formatdomain.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git docs/formatdomain.rst docs/formatdomain.rst index f50dce477f..c99560a3bd 100644 --- docs/formatdomain.rst +++ docs/formatdomain.rst @@ -8350,8 +8350,8 @@ The watchdog device requires an additional driver and management daemon in the guest. Just enabling the watchdog in the libvirt configuration does not do anything useful on its own. -Currently libvirt does not support notification when the watchdog fires. This -feature is planned for a future version of libvirt. +:since:`Since 0.8.0` a notification when the watchdog fires is +available using the event ID ``VIR_DOMAIN_EVENT_ID_WATCHDOG``. Having multiple watchdogs is usually not something very common, but be aware that this might happen, for example, when an implicit watchdog device is added --- base-commit: eb99bbaf2e5b1e91f4999c7a1ccc90d67dfbe471 change-id: 20251003-update_wd_doc-5aa9b43be09a Best regards, -- Massimiliano Minella <massimiliano.minella(a)se.com>

1 0

[PATCH 0/2] Fix detect_zeroes setup in qemu and improve tests
by Peter Krempa 18 Nov '25

18 Nov '25

See 2/2 for explanation. Peter Krempa (2): qemuxmlconftest: Improve coverage of 'disk-detect-zeroes' test case qemuDomainPrepareDiskSourceData: Setup 'detect_zeroes' for all layers src/qemu/qemu_domain.c | 6 +--- .../xml2json/file-backing_basic-detect.json | 3 ++ .../file-backing_basic-unmap-detect.json | 3 ++ .../file-backing_basic-unmap-ignore.json | 3 ++ .../disk-detect-zeroes.x86_64-latest.args | 20 +++++++++--- tests/qemuxmlconfdata/disk-detect-zeroes.xml | 31 +++++++++++++++++-- 6 files changed, 55 insertions(+), 11 deletions(-) -- 2.51.1

3 4