October 2026 - Devel - libvirt List Archives

Add WebKVM to the "Applications using libvirt" page
by Alvin Enrique Perez Perdomo 12 Oct '26

12 Oct '26

Hello Libvirt developers, I have developed an open-source web interface for managing QEMU/KVM virtual machines called WebKVM, and I would love to propose adding it to the "Applications using libvirt" page on the official website. Project Details: Name: WebKVM Description: A lightweight, web-based management interface for QEMU/KVM built in Go. It connects directly to the standard libvirt daemon (qemu:///system) via the native libvirt Go bindings, offering domain management, resource metrics, storage/network visibility, and browser-based consoles (noVNC, SPICE, RDP, and serial). Repository: https://github.com/Slaker19/webkvm License: Open Source (GPLv3) Please let me know if WebKVM qualifies to be listed on the page, or if you prefer me to submit a patch / GitLab Merge Request against the documentation repository directly. Thank you for your time and for maintaining such a great ecosystem. Best regards, Alvin (Slaker19)

2 1

[PATCH 0/6] add LoongArch host model support
by Xianglai Li 10 Oct '26

10 Oct '26

Hi all, This patch series adds host model support for LoongArch. The current approach is to read cpucfg information from the physical machine and use it together with the CPU model information and feature information in the XML file to jointly determine which CPU features need to be enabled for the host model. The specific policy is as follows: features supported by both the physical machine and the CPU model in the XML file are enabled; otherwise, they are disabled. Features that exist in feature.xml but are not mentioned by either the physical machine's cpucfg or the CPU model in the XML file are also set to disabled. Cc: Bibo Mao <maobibo(a)loongson.cn> Xianglai Li (6): cpu_map: add LoongArch CPU map XML files cpu: add LoongArch CPU vendor parsing cpu: add LoongArch CPU feature parsing cpu: add LoongArch CPU model parsing cpu: add LoongArch CPU decode support cpu: add LoongArch host model support po/POTFILES | 1 + src/cpu/cpu.h | 2 + src/cpu/cpu_loongarch.c | 645 ++++++++++++++++++++++++++++- src/cpu/cpu_loongarch_data.h | 34 ++ src/cpu_map/index.xml | 13 + src/cpu_map/loongarch_features.xml | 26 ++ src/cpu_map/loongarch_la464.xml | 10 + src/cpu_map/loongarch_la664.xml | 11 + src/cpu_map/loongarch_vendors.xml | 3 + src/cpu_map/meson.build | 4 + src/qemu/qemu_capabilities.c | 2 +- 11 files changed, 745 insertions(+), 6 deletions(-) create mode 100644 src/cpu/cpu_loongarch_data.h create mode 100644 src/cpu_map/loongarch_features.xml create mode 100644 src/cpu_map/loongarch_la464.xml create mode 100644 src/cpu_map/loongarch_la664.xml create mode 100644 src/cpu_map/loongarch_vendors.xml -- 2.39.1

1 6

[PATCH] qemu: allow for 15 subordinate pci controllers under each pcie-expander-bus
by Laine Stump 08 Oct '26

08 Oct '26

From: Laine Stump <laine(a)redhat.com> A guest was created with PCIe bus and 2 PCIe devices attached to two separate pcie-root-ports that were themselves attached to a pcie-expander-bus. This guest was unable to boot from the 2nd device on the pcie-expander-bus. It turns out this failure was because not enough "bus numbers" were reserved for the pcie-expander-bus in the configuration, and this led to a failure of the system firmware to initialize those devices properly. Background: Each pci[e]-expander-bus has a busNr attribute that can be optionally specified in the <target> subelement; it defines the bus number of the expander bus itself. Any pci controller attached to that expander bus is then assigned a bus number between busNr+1 and the busNr of the next higher expander bus (or 255, if there are no expander buses with a higher busNr. The pci-root (or pcie-root) bus is bus number 0, and any pci controller attached to that bus (or its subordinate buses *except for pci[e]-expander-buses*) will be automatically numbered starting at 1, and continuing up until the lowest numbered expander bus. When libvirt originally added support for the pci-expander-bus, each pci-expander-bus' busNr was initialized by default to be the busNr of the current lowest expander bus - 2 (reserving one for the pci-expander-bus itself, and one for the implicit pci-bridge that is always added (by qemu) along with the pci-expander-bus). When pcie-expander-bus support was added, this logic was left untouched, but that is incorrect - a hotplug-supporting PCIe topology requires that each device have its own pcie-root-port, and so adding multiple hotpluggable devices to a pcie-expander-bus uses up one bus number for each device. So, the solution to the original problem is to just lower the busNr of each pcie-expander-bus by 16 (rather than 2) from the previous. This allows connection of up to 15 pcie-root-port controllers (and thus 15 hotpluggable endpoint devices) to each pcie-expander bus with the default setting of busNr. Resolves: https://redhat.atlassian.net/browse/RHEL-144343 Signed-off-by: Laine Stump <laine(a)redhat.com> -- Note that I could have chosen 32 or 8 or any other number, and no matter which I chose it would be likely to not work for *somebody*. Anyway, if this scheme ever doesn't work out, manual intervention is always possible, either by manually setting busNr, or by putting multiple endpoint devices on different functions of the same pcie-root-port (which is completely unproblematic if the device will never be unplugged at runtime). Signed-off-by: Laine Stump <laine(a)redhat.com> --- src/qemu/qemu_domain_address.c | 85 ++++++++++++------- ...e-expander-bus-aarch64.aarch64-latest.args | 2 +- ...ie-expander-bus-aarch64.aarch64-latest.xml | 2 +- 3 files changed, 57 insertions(+), 32 deletions(-) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index a8292a9782..81cf34fe86 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -2567,43 +2567,63 @@ qemuDomainAddressFindNewTargetIndex(virDomainDef *def) static int -qemuDomainAddressFindNewBusNr(virDomainDef *def) +qemuDomainAddressFindNewBusNr(virDomainDef *def, + virDomainControllerModelPCI model) { /* Try to find a nice default for busNr for a new pci-expander-bus. * This is a bit tricky, since you need to satisfy the following: * - * 1) There need to be enough unused bus numbers between busNr of this - * bus and busNr of the next highest bus for the guest to assign a - * unique bus number to each PCI bus that is a child of this - * bus. Each PCI controller. On top of this, the pxb device (which - * implements the pci-expander-bus) includes a pci-bridge within - * it, and that bridge also uses one bus number (so each pxb device - * requires at least 2 bus numbers). + * 1) There need to be enough unused bus numbers between busNr of + * this bus and busNr of the next highest bus for the guest to + * assign a unique bus number to each PCI bus that is a child + * of this bus. * * 2) There need to be enough bus numbers *below* this for all the - * child controllers of the pci-expander-bus with the next lower + * child controllers of the pci[e]-expander-bus with the next lower * busNr (or the pci-root bus if there are no lower - * pci-expander-buses). + * pci[e]-expander-buses). * * 3) If at all possible, we want to avoid needing to change the busNr * of a bus in the future, as that changes the guest's device ABI, * which could potentially lead to issues with a guest OS that is * picky about such things. * - * Due to the impossibility of predicting what might be added to the - * config in the future, we can't make a foolproof choice, but since - * a pci-expander-bus (pxb) has slots for 32 devices, and the only - * practical use for it is to assign real devices on a particular - * NUMA node in the host, it's reasonably safe to assume it should - * never need any additional child buses (probably only a few of the - * 32 will ever be used). So for pci-expander-bus we find the lowest - * existing busNr, and set this one to the current lowest - 2 (one - * for the pxb, one for the integrated pci-bridge), thus leaving the - * maximum possible bus numbers available for other buses plugged - * into pci-root (i.e. pci-bridges and other - * pci-expander-buses). Anyone who needs more than 32 devices - * descended from one pci-expander-bus should set the busNr manually - * in the config. + * Due to the impossibility of predicting what might be added to + * the config in the future, we can't make a foolproof choice, + * and the parameters are different for a pci-expander-bus and a + * pcie-expander-bus. + * + * pci-expander-bus: the pxb device (which implements the + * pci-expander-bus) includes a pci-bridge within it, and that + * bridge uuses one bus number, so each pxb device requires at + * least 2 bus numbers. That bridge has slots for 32 devices, and + * its only practical use is to assign real physical devices on a + * particular NUMA node in the host. It's reasonably safe to + * assume no guest should never have more than 32 physical + * devices on a single NUMA node that need to be assigned to a + * guest (probably only a few of the 32 will ever be used), and + * so we shouldn't need more than 2 bus numbers for each + * pci-expander-bus. So we find the lowest existing busNr, and + * set busNr of the new pci-expander-bus to that value - + * 2. Anyone who needs more than 32 devices descended from one + * pci-expander-bus should set the busNr manually in the config. + * + * pcie-expander-bus: this is (as you'd expect) a more + * complicated story - if you want to support hotplugging on a + * pcie based machinetype, then each endpoint device needs its + * own pcie-root-port, and each root port uses up one bus number + * in the range available to its parent pcie-expander-bus. Taking + * a very generous example of a guest that has 8 GPUs, 8 NICs, + * and 8 NVME drives split between two NUMA nodes, giving 16 bus + * numbers to each pcie-expander-bus gives plenty of bus number + * space for all the controllers needed for each device in this + * extreme config, while still leaving plenty of overhead for 1) + * lots of devices on NUMA node 0 and 2) more than 2 NUMA nodes + * in the unlikely case that someone was forced to create a guest + * with more than 2 NUMA nodes. Again, if someone has a config + * more extreme than this, they should just set busNr manually + * (after all, the pci addresses of all these devices are already + * all being set manually, so that shouldn't be a huge burden). * * There is room for more error checking here - in particular we * can/should determine the ultimate parent (root-bus) of each PCI @@ -2614,6 +2634,10 @@ qemuDomainAddressFindNewBusNr(virDomainDef *def) size_t i; int lowestBusNr = 256; + int maxChildControllers = 1; /* default for pci-expander-bus */ + + if (model == VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS) + maxChildControllers = 15; for (i = 0; i < def->ncontrollers; i++) { virDomainControllerDef *cont = def->controllers[i]; @@ -2626,14 +2650,15 @@ qemuDomainAddressFindNewBusNr(virDomainDef *def) } } - /* If we already have a busNR = 1, then we can't auto-assign (0 is - * the pci[e]-root, and the others may have been assigned - * purposefully). + /* If we already have a controller with busNR <= + * maxChildControllers+1, then we can't auto-assign busNr to this + * new expander bus (0 is the pci[e]-root, and the others may have + * been assigned purposefully). */ - if (lowestBusNr <= 2) + if (lowestBusNr <= (maxChildControllers + 1)) return -1; - return lowestBusNr - 2; + return lowestBusNr - (maxChildControllers + 1); } @@ -2877,7 +2902,7 @@ qemuDomainAssignPCIAddresses(virDomainDef *def, case VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS: case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS: if (options->busNr == -1) - options->busNr = qemuDomainAddressFindNewBusNr(def); + options->busNr = qemuDomainAddressFindNewBusNr(def, cont->model); if (options->busNr == -1) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("No free busNr lower than current lowest busNr is available to auto-assign to bus %1$d. Must be manually assigned"), diff --git a/tests/qemuxmlconfdata/pcie-expander-bus-aarch64.aarch64-latest.args b/tests/qemuxmlconfdata/pcie-expander-bus-aarch64.aarch64-latest.args index e76510dbbb..52011865a0 100644 --- a/tests/qemuxmlconfdata/pcie-expander-bus-aarch64.aarch64-latest.args +++ b/tests/qemuxmlconfdata/pcie-expander-bus-aarch64.aarch64-latest.args @@ -25,7 +25,7 @@ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-pcie-expander-bus-te/.config \ -rtc base=utc \ -no-shutdown \ -boot strict=on \ --device '{"driver":"pxb-pcie","bus_nr":254,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \ +-device '{"driver":"pxb-pcie","bus_nr":240,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \ -audiodev '{"id":"audio1","driver":"none"}' \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -msg timestamp=on diff --git a/tests/qemuxmlconfdata/pcie-expander-bus-aarch64.aarch64-latest.xml b/tests/qemuxmlconfdata/pcie-expander-bus-aarch64.aarch64-latest.xml index ce88da574f..0d0cac7653 100644 --- a/tests/qemuxmlconfdata/pcie-expander-bus-aarch64.aarch64-latest.xml +++ b/tests/qemuxmlconfdata/pcie-expander-bus-aarch64.aarch64-latest.xml @@ -20,7 +20,7 @@ <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> - <target busNr='254'/> + <target busNr='240'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </controller> <audio id='1' type='none'/> -- 2.55.0

3 4

[PATCH 0/9] bhyve: session mode support
by Roman Bogorodskiy 08 Oct '26

08 Oct '26

This series implements user session support (bhyve:///session) for the bhyve driver. Roman Bogorodskiy (9): bhyve: move paths to driver configuration bhyve: capabilities: probe monitor mode support bhyve: initial unprivileged mode support bhyve: implement virDomainReset() bhyve: implement process management for monitor mode bhyve: implement reconnect for unprivileged mode bhyve: cleanup IPC sockets bhyve: bhyvexml2argvtest: test unprivileged mode docs: drvbhyve: document session mode docs/drvbhyve.rst | 24 ++- src/bhyve/bhyve_capabilities.c | 29 +++ src/bhyve/bhyve_capabilities.h | 2 + src/bhyve/bhyve_command.c | 32 +++ src/bhyve/bhyve_command.h | 6 + src/bhyve/bhyve_conf.c | 47 +++- src/bhyve/bhyve_conf.h | 2 +- src/bhyve/bhyve_domain.c | 30 ++- src/bhyve/bhyve_domain.h | 4 +- src/bhyve/bhyve_driver.c | 173 ++++++++++----- src/bhyve/bhyve_process.c | 201 ++++++++++++++---- src/bhyve/bhyve_process.h | 5 + src/bhyve/bhyve_utils.h | 13 +- .../bhyvexml2argv-uefi-unprivileged.args | 14 ++ tests/bhyvexml2argvtest.c | 35 ++- tests/bhyvexml2xmltest.c | 4 +- 16 files changed, 506 insertions(+), 115 deletions(-) create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-uefi-unprivileged.args -- 2.55.0

2 13

[PATCH v3 00/10] conf, qemu: Add scalable_mode, fsts, pasid_bits, and svm support for intel-iommu
by Zhenzhong Duan 08 Oct '26

08 Oct '26

Hi, This series adds support for configuring Intel vIOMMU (VT-d) in domain XML and formatting them onto the QEMU command line: * scalable_mode: Configures scalable mode support ('on'/'off'). * fsts: Enables First-Stage Translation support ('on'/'off'). * pasid_bits: Sets the number of supported PASID bits. * svm: Enables Shared Virtual Memory (SVM) / PRQ support ('on'/'off'). With these attributes, users can configure advanced vIOMMU features for both emulated devices and assigned host devices (e.g., vSVA / nested translation via iommufd and first-stage translation). Example domain XML configuration: <iommu model='intel'> <driver caching_mode='on' iotlb='on' scalable_mode='on' fsts='on' pasid_bits='6' svm='on'/> </iommu> Which formats the following QEMU command line options: -device {"driver":"intel-iommu","id":"iommu0","caching-mode":true,"device-iotlb":true,"scalable-mode":true,"fsts":true,"pasid-bits":6,"svm":true} Testing: - Validated with libvirt test suite (ninja test). - Tested DSA card passthrough and SVM/vSVA with iommufd backend. Changelog: v3: - merge qemu patch into conf patch (Peter Krempa) - fix pasid_bits type definition (Peter Krempa) - fix doc to use 'pasid_bits' rather than 'pasid-bits' (Peter Krempa) - add patch10 to print attribute name in error message (Peter Krempa) - add patch5 for missing validations v2: - Added support for 'pasid_bits' and 'svm' attributes. - rebased to master branch newest Thanks, Zhenzhong Zhenzhong Duan (10): qemu_capabilities: Introduce QEMU_CAPS_INTEL_IOMMU_SCALABLE_MODE qemu: Add scalable_mode attribute to iommu qemu_capabilities: Introduce QEMU_CAPS_INTEL_IOMMU_FSTS qemu: Add fsts attribute to iommu qemu: Validate PCI hostdev assignment against intel-iommu 'fsts' qemu_capabilities: Introduce QEMU_CAPS_INTEL_IOMMU_PASID_BITS qemu: add pasid_bits attribute to iommu qemu_capabilities: Introduce QEMU_CAPS_INTEL_IOMMU_SVM qemu: add svm attribute to iommu conf: qemu: Standardize IOMMU error messages to use XML attribute names docs/formatdomain.rst | 19 +++ src/conf/domain_conf.c | 120 +++++++++++++++--- src/conf/domain_conf.h | 7 + src/conf/domain_validate.c | 55 +++++++- src/conf/schemas/domaincommon.rng | 20 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 10 ++ src/qemu/qemu_capabilities.h | 6 + src/qemu/qemu_command.c | 4 + src/qemu/qemu_validate.c | 59 +++++++-- .../caps_11.0.0_x86_64+sgx.xml | 1 + .../caps_11.0.0_x86_64.xml | 1 + .../caps_11.1.0_x86_64.xml | 4 + .../intel-iommu-fsts.x86_64-latest.args | 34 +++++ .../intel-iommu-fsts.x86_64-latest.xml | 37 ++++++ tests/qemuxmlconfdata/intel-iommu-fsts.xml | 37 ++++++ .../intel-iommu-pasid-bits.x86_64-latest.args | 34 +++++ .../intel-iommu-pasid-bits.x86_64-latest.xml | 37 ++++++ .../intel-iommu-pasid-bits.xml | 37 ++++++ ...tel-iommu-scalable-mode.x86_64-latest.args | 34 +++++ ...ntel-iommu-scalable-mode.x86_64-latest.xml | 37 ++++++ .../intel-iommu-scalable-mode.xml | 37 ++++++ .../intel-iommu-svm.x86_64-latest.args | 34 +++++ .../intel-iommu-svm.x86_64-latest.xml | 37 ++++++ tests/qemuxmlconfdata/intel-iommu-svm.xml | 37 ++++++ tests/qemuxmlconftest.c | 4 + 26 files changed, 712 insertions(+), 31 deletions(-) create mode 100644 tests/qemuxmlconfdata/intel-iommu-fsts.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/intel-iommu-fsts.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/intel-iommu-fsts.xml create mode 100644 tests/qemuxmlconfdata/intel-iommu-pasid-bits.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/intel-iommu-pasid-bits.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/intel-iommu-pasid-bits.xml create mode 100644 tests/qemuxmlconfdata/intel-iommu-scalable-mode.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/intel-iommu-scalable-mode.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/intel-iommu-scalable-mode.xml create mode 100644 tests/qemuxmlconfdata/intel-iommu-svm.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/intel-iommu-svm.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/intel-iommu-svm.xml -- 2.52.0

2 11

[PATCH 0/7] Add hook support for session daemons
by Marc-André Lureau 07 Oct '26

07 Oct '26

Currently, libvirt hook scripts are only searched in the system-wide directory /etc/libvirt/hooks/, which is typically not accessible to non-root users running session daemons. This series adds support for user-level hook scripts located in $XDG_CONFIG_HOME/libvirt/hooks/ (typically ~/.config/libvirt/hooks/). When running as a non-root session daemon, hooks are searched in both the system directory (if accessible) and the user directory, with system hooks executed first. A new "skip_system_hooks" daemon configuration option allows session daemons to skip the system hooks directory entirely, using only user hooks. Plus a preliminary patch to enable b4 usage. --- Marc-André Lureau (7): Add .b4-config util: extract virHookCheckDir from virHookCheck util: handle EACCES when opening hook directories util: search hooks in both system and user directories util: add virHookSetSkipSystemHooks API remote: add skip_system_hooks daemon config option docs: document session hooks support .b4-config | 9 ++ NEWS.rst | 7 ++ docs/hooks.rst | 10 ++ src/libvirt_private.syms | 1 + src/remote/libvirtd.aug.in | 1 + src/remote/libvirtd.conf.in | 9 ++ src/remote/remote_daemon.c | 1 + src/remote/remote_daemon_config.c | 3 + src/remote/remote_daemon_config.h | 2 + src/remote/test_libvirtd.aug.in | 1 + src/util/virhook.c | 243 +++++++++++++++++++++++++++----------- src/util/virhook.h | 1 + 12 files changed, 218 insertions(+), 70 deletions(-) --- base-commit: 9ecbf2a65454704240170676b94b65866b352a34 change-id: 20261006-session-hook-b2fe660603f0 Best regards, -- Marc-André Lureau <marcandre.lureau(a)redhat.com>

1 7

[PATCH] qemuDomainRestoreInternal: Preserve error on cleanup path
by Peter Krempa 07 Oct '26

07 Oct '26

From: Peter Krempa <pkrempa(a)redhat.com> Preserve the error on cleanup path as cleanup of the 'libivrt_iohelper' process may overwrite it with an unactionable error, such as when attempting to restore a save image while the VM is already running: $ virsh list Id Name State -------------------------- 9 cd running $ virsh restore /tmp/cd.save error: Failed to restore domain from /tmp/cd.save error: internal error: Child process (LIBVIRT_LOG_OUTPUTS=1:stderr /home/pipo/build/libvirt/gcc/src/libvirt_iohelper /tmp/cd.save 0) unexpected fatal signal 13 After this patch the original error is reported: $ virsh restore /tmp/cd.save error: Failed to restore domain from /tmp/cd.save error: Requested operation is not valid: domain 'cd' is already active Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 61d95bfbbf..25ba6695bb 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -5985,6 +5985,7 @@ qemuDomainRestoreInternal(virQEMUDriver *driver, bool sparse = false; bool bypass_cache = (flags & VIR_DOMAIN_SAVE_BYPASS_CACHE) != 0; g_autoptr(qemuMigrationParams) restoreParams = NULL; + virErrorPtr save_err = NULL; virCheckFlags(QEMU_DOMAIN_RESTORE_FLAGS, -1); @@ -6109,6 +6110,7 @@ qemuDomainRestoreInternal(virQEMUDriver *driver, qemuProcessEndJob(vmNew); cleanup: + virErrorPreserveLast(&save_err); VIR_FORCE_CLOSE(fd); if (virFileWrapperFdClose(wrapperFd) < 0) ret = -1; @@ -6117,6 +6119,7 @@ qemuDomainRestoreInternal(virQEMUDriver *driver, if (vmNew && ret < 0) qemuDomainRemoveInactive(vmNew, 0, false); virDomainObjEndAPI(&vmNew); + virErrorRestore(&save_err); return ret; } -- 2.55.0

4 3

[PATCH] qemu: add support for postcopy-device migration state
by Denis V. Lunev 06 Oct '26

06 Oct '26

From: Denis V. Lunev <den(a)openvz.org> QEMU 10.2 added a postcopy-device migration state between active and postcopy-active. The source stays in it from the moment it has sent the device state until the destination confirms it has loaded it, and the destination is in it while loading. libvirt does not know the state: the MIGRATION event is dropped with a warning and query-migrate fails with unexpected migration status in postcopy-device so virDomainGetJobInfo and virDomainGetJobStats fail for that whole phase. OpenStack nova polls job stats during a live migration and aborts it on that error. Treat postcopy-device as part of the migrating phase. A failure in it still lets the source resume, which is what QEMU added the state for, so the source keeps waiting for postcopy-active before it reports post-copy. Signed-off-by: Denis V. Lunev <den(a)openvz.org> --- src/qemu/qemu_migration.c | 2 ++ src/qemu/qemu_monitor.c | 1 + src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 1 + src/qemu/qemu_process.c | 1 + tests/qemumonitorjsontest.c | 25 +++++++++++++++++++++++++ 6 files changed, 31 insertions(+) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 4a43ab83b0..797f83ca0d 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2004,6 +2004,7 @@ qemuMigrationUpdateJobType(virDomainJobData *jobData) break; case QEMU_MONITOR_MIGRATION_STATUS_DEVICE: + case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_DEVICE: jobData->status = VIR_DOMAIN_JOB_STATUS_MIGRATING; break; @@ -4895,6 +4896,7 @@ qemuMigrationSrcIsCanceled(virDomainObj *vm) qemuMonitorMigrationStatusTypeToString(status)); return true; + case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_DEVICE: case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY: case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_RECOVER: case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_RECOVER_SETUP: diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 2c86cd1971..1216681ac5 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -148,6 +148,7 @@ VIR_ENUM_IMPL(qemuMonitorMigrationStatus, "active", "pre-switchover", "device", + "postcopy-device", "postcopy-active", "postcopy-paused", "postcopy-recover", diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index e9b6a25f0c..d69335a27d 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -995,6 +995,7 @@ typedef enum { QEMU_MONITOR_MIGRATION_STATUS_ACTIVE, QEMU_MONITOR_MIGRATION_STATUS_PRE_SWITCHOVER, QEMU_MONITOR_MIGRATION_STATUS_DEVICE, + QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_DEVICE, QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY, QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_PAUSED, QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_RECOVER, diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 8e88dc9442..29c42f7dd5 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -3286,6 +3286,7 @@ qemuMonitorJSONGetMigrationStatsReply(virJSONValue *reply, break; case QEMU_MONITOR_MIGRATION_STATUS_ACTIVE: + case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_DEVICE: case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY: case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_PAUSED: case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_RECOVER: diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 57a3ed3720..f99a4c3b37 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -1771,6 +1771,7 @@ qemuProcessHandleMigrationStatus(qemuMonitor *mon G_GNUC_UNUSED, case QEMU_MONITOR_MIGRATION_STATUS_ACTIVE: case QEMU_MONITOR_MIGRATION_STATUS_PRE_SWITCHOVER: case QEMU_MONITOR_MIGRATION_STATUS_DEVICE: + case QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_DEVICE: case QEMU_MONITOR_MIGRATION_STATUS_ERROR: case QEMU_MONITOR_MIGRATION_STATUS_CANCELLING: case QEMU_MONITOR_MIGRATION_STATUS_CANCELLED: diff --git a/tests/qemumonitorjsontest.c b/tests/qemumonitorjsontest.c index a963029c69..a38d63c22c 100644 --- a/tests/qemumonitorjsontest.c +++ b/tests/qemumonitorjsontest.c @@ -1674,6 +1674,19 @@ testQemuMonitorJSONqemuMonitorJSONGetMigrationStats(const void *opaque) " \"error-desc\": \"It's broken\"" " }," " \"id\": \"libvirt-14\"" + "}") < 0 || + qemuMonitorTestAddItem(test, "query-migrate", + "{" + " \"return\": {" + " \"status\": \"postcopy-device\"," + " \"total-time\": 52," + " \"ram\": {" + " \"total\": 1611038720," + " \"remaining\": 0," + " \"transferred\": 1611038720" + " }" + " }," + " \"id\": \"libvirt-15\"" "}") < 0) return -1; @@ -1699,6 +1712,18 @@ testQemuMonitorJSONqemuMonitorJSONGetMigrationStats(const void *opaque) return -1; } + memset(&stats, 0, sizeof(stats)); + if (qemuMonitorJSONGetMigrationStats(qemuMonitorTestGetMonitor(test), + &stats, NULL) < 0) + return -1; + + if (stats.status != QEMU_MONITOR_MIGRATION_STATUS_POSTCOPY_DEVICE || + stats.ram_transferred != 1611038720) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + "Invalid postcopy-device migration statistics"); + return -1; + } + return 0; } base-commit: 215fab8ab1d912f6b25e60ab4d2ad59000f2eaff -- 2.53.0

2 1

[PATCH] apparmor: Add attach_disconnected flag to passt libvirt-qemu subprofile
by Stefano Brivio 05 Oct '26

05 Oct '26

With passt commit 7bf1595c9242 ("isolation: Don't create our userns as nobody"), instead of a direct unshare() to detach the isolating user namespace, we now have a two-step process where we join the namespace by opening its procfs entry. After detaching the isolated namespace, AppArmor considers its procfs entry a disconnected object, so we don't have a way to refer to it unless we use the attach_disconnected flag in the relevant profile. For stand-alone passt(1) usage, this is taken care of in passt commit 032f082ffad0 ("apparmor: Fixes for new user namespace detaching procedure"), but libvirt (as non-root) runs passt as a separate subprofile, and that's where we need to add that flag. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149683 Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> --- src/security/apparmor/libvirt-qemu | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/security/apparmor/libvirt-qemu b/src/security/apparmor/libvirt-qemu index 9bf572692b..4c6e5689c8 100644 --- a/src/security/apparmor/libvirt-qemu +++ b/src/security/apparmor/libvirt-qemu @@ -209,7 +209,7 @@ # support for passt network back-end /usr/bin/passt Cx -> passt, - profile passt { + profile passt flags=(attach_disconnected) { /usr/bin/passt r, signal (receive) set=("term") peer=/usr/sbin/libvirtd, -- 2.43.0

2 1

[PATCH 0/2] qemucapabilitiestest: Add data for the qemu-11.2
by Peter Krempa 05 Oct '26

05 Oct '26

Peter Krempa (2): qemucapabilitiestest: Add data for the qemu-11.2 dev cycle (x86_64) qemucapabilitiestest: Add data for the qemu-11.2 dev cycle (aarch64) .../qemu_11.2.0-q35.x86_64-expanded.xml | 1858 + .../qemu_11.2.0-q35.x86_64-supported.xml | 1740 + .../domaincapsdata/qemu_11.2.0-q35.x86_64.xml | 1733 + .../domaincapsdata/qemu_11.2.0-tcg.x86_64.xml | 2856 + .../qemu_11.2.0-virt.aarch64.xml | 268 + tests/domaincapsdata/qemu_11.2.0.aarch64.xml | 268 + tests/domaincapsdata/qemu_11.2.0.x86_64.xml | 1731 + .../caps_11.2.0_aarch64.replies | 40208 +++++++++++++ .../caps_11.2.0_aarch64.xml | 552 + .../caps_11.2.0_x86_64.replies | 49897 ++++++++++++++++ .../caps_11.2.0_x86_64.xml | 5769 ++ ...host-model-fallback-kvm.x86_64-latest.args | 2 +- ...cpu-host-model-features.x86_64-latest.args | 2 +- .../cpu-host-model-kvm.x86_64-latest.args | 2 +- ...st-model-nofallback-kvm.x86_64-latest.args | 2 +- 15 files changed, 106884 insertions(+), 4 deletions(-) create mode 100644 tests/domaincapsdata/qemu_11.2.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_11.2.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_11.2.0-q35.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_11.2.0-tcg.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_11.2.0-virt.aarch64.xml create mode 100644 tests/domaincapsdata/qemu_11.2.0.aarch64.xml create mode 100644 tests/domaincapsdata/qemu_11.2.0.x86_64.xml create mode 100644 tests/qemucapabilitiesdata/caps_11.2.0_aarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_11.2.0_aarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_11.2.0_x86_64.replies create mode 100644 tests/qemucapabilitiesdata/caps_11.2.0_x86_64.xml -- 2.55.0

2 3