May 2026 - Devel - libvirt List Archives

Release of libvirt-12.2.0
by Jiri Denemark 10 Sep '26

10 Sep '26

The 12.2.0 release of both libvirt and libvirt-python is tagged and signed tarballs are available at https://download.libvirt.org/ https://download.libvirt.org/python/ Thanks everybody who helped with this release by sending patches, reviewing, testing, or providing feedback. Your work is greatly appreciated. * Removed features * qemu: Stop advertising support for ``handle`` backend of 9p filesystems QEMU removed the feature in the 4.0 release, but our capability XML still reported it. * New features * qemu: Add support to configure IOMMUFD backend for whole VM In addition to setting IOMMUFD backend for each device it is possible to use the new ``<iommufd>`` element to enable IOMMUFD backend for all host devices. Users can still change it per device. * qemu: Add support to pass FD for IOMMUFD when starting VM Management applications running unprivileged libvirt can open /dev/iommu and pass FD to libvirt in order to change locked memory accounting. This is done via new ``<iommufd>`` element. * qemu: Add support for declaring that storage was zeroed for storage copy APIs The qemu driver now can skip zeroing of the storage during ``virDomainBlockCopy`` or migration with non-shared storage with the appropriate flags. This can be used for storage technologies which lack efficient zeroing support. * hyperv: Add basic snapshot functionality The hyperv driver now implements the following libvirt APIs: ``virDomainDefineXMLFlags()``, ``virDomainSnapshotLookupByName()``, ``virDomainListAllSnapshots()``, ``virDomainSnapshotNum()``, ``virDomainSnapshotGetXMLDesc()``, ``virDomainSnapshotCurrent()``, ``virDomainHasCurrentSnapshot()``, ``virDomainSnapshotGetParent()``. * Improvements * conf: support more than 255 vCPUs with amd-iommu With 256 or more vCPUs libvirt previously required EIM enabled for all models of IOMMU. This is not valid for AMD model and validation was changed so that XTSup is required there. Additionally, it is automatically enabled if needed. * Introduce VIR_CONNECT_GET_DOMAIN_CAPABILITIES_EXPAND_CPU_FEATURES flag This new flag for virConnectGetDomainCapabilities can be used to request the host-model CPU definition to include all supported features (normally only extra features relative to the selected CPU model are listed). * qemu: Add statistics for ``<dataStore>`` storage The bulk statistics (``virsh domstats --block --backing``) now report also information about the ``<dataStore>`` if given disk uses this feature. * hyperv: Hyper-V guests now report TPM device status in their domain xml definition. * Bug fixes * qemu: Fix crash when attaching network inteface with hostdev network Introduced in v12.1.0 by implementing IOMMUFD backend support for host devices. Enjoy. Jirka

1 0

[PATCH v2 00/21] qom: introduce property flags to track external user input
by Zhao Liu 13 Aug '26

13 Aug '26

Hi, This is the v2 trying to introduce property flags to detect user's property setting (from CLI/QMP/HMP). I dropped RFC tag since previous RFC v1 [1]. Though this work the follow-up of v2.6 & v2.7 machines' removal [2], now it is decoupled from [2] totally since v2 doesn't detect compat property and only focuses on external user setting, so this series is based on master branch at the commit 28a6ca268c2c ("Merge tag 'single- binary-20260203' of https://github.com/philmd/qemu into staging"). And you can also find the code here: https://gitlab.com/zhao.liu/qemu/-/tree/prop-flags-v2.3-02-08-2026 This series introduces 3 property flags: * USER_SET: Any external user property setting (from CLI/HMP/QMP) is marked as USER_SET. * DEPRECATED: Once a property is marked as DEPRECATED, any external user property setting will trigger a warning. * INTERNAL: Once a property is marked as INTERNAL, any external user property setting will cause an error. More details or document for these 3 flags, you can refer patch 7. Compared with RFC v1, v2 mainly: * introduce USER_SET property flag to identify all user's setting. - patch 7 for document. * construct DEPRECATED & INTERNAL flag on USER_SET. - patch 7 for document. * cover more comprehensive user set cases. - patch 8-13. * provide examples about new flags (USER_SET/DEPRECATED/INTELNAL). - patch 15/16/17 are examples for DEPRECATED flag. - patch 18 is the example for INTERNAL flag. - patch 20 is the example for USER_SET flag. I think v2 should now cover "nearly" all cases (patch 8-13) where users set properties: one approach is to trace the call chain of object_property_set(). Even if there are cases that were missed, they can be easily addressed based on this series: object_property_set(obj, ...); /* Insert this call after object_property_set(). */ object_property_set_flags(obj, ..., OBJ_PROP_FLAG_USER_SET, ...); [1]: RFC v1: https://lore.kernel.org/qemu-devel/20251202170502.3228625-1-zhao1.liu@intel… [2]: hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines https://lore.kernel.org/qemu-devel/20260108033051.777361-1-zhao1.liu@intel.… Thanks and Best Regards, Zhao --- Zhao Liu (21): qom/object: use BIT macro for ObjectPropertyFlags qom/object: cache ObjectPropertyFlags in ObjectProperty qom/object: factor out object_class_property_try_add() qom/object: add flags argument in object_{class_}property_try_add() qom/object: rename object_{class_}property_try_add() to object_{class_}property_add_full() qom/object: add helpers to set/get/clear property flags qom/object: introduce user interaction flags for properties qom/object: add from_user argument in object_property_parse() qom/object: mark global property set from CLI as USER_SET qom/qom-hmp-cmd: mark properties set from HMP (non-JSON) "qom-set" as USER_SET qom/qom-qmp-cmd: mark properties set from QMP/HMP (JSON) "qom-set" as USER_SET qom/object_interfaces: mark properties set from qdict & keyval as USER_SET system/vl: mark property set in object_parse_property_opt() as USER_SET hw/core/qdev-properties: allow qdev properties accept flags target/i386: deprecate fill-mtrr-mask property target/i386: deprecate cpuid-0xb property hw/intc/ioapic: deprecate version property target/i386: mark x-consistent-cache property as internal-only target/i386: remove redundant validation for lbr-fmt property target/i386: detect user provided lbr-fmt via property flag hw/core/qdev-properties: support valid default value for DEFINE_PROP_UINT64_CHECKMASK docs/about/deprecated.rst | 31 +++++ hw/core/qdev-properties.c | 29 ++-- hw/i386/sgx.c | 2 +- hw/intc/ioapic.c | 3 +- include/hw/core/qdev-properties.h | 38 +++--- include/qom/object.h | 215 +++++++++++++++++++++++++++--- qom/object.c | 177 ++++++++++++++++++++---- qom/object_interfaces.c | 5 + qom/qom-hmp-cmds.c | 2 +- qom/qom-qmp-cmds.c | 7 +- system/vl.c | 6 +- target/i386/cpu.c | 28 ++-- 12 files changed, 448 insertions(+), 95 deletions(-) -- 2.34.1

10 45

[PATCH v8 0/4] nwfilter: add nwfilter nftables driver
by Dion Bosschieter 11 Aug '26

11 Aug '26

This series aims to implement nftables as a backend driver for the nwfilter feature. The idea is that it will replace the ebiptables driver and provide an easy way for users to switch from one driver to another. The 1st patch introduces the new nwfilter driver. After which nwfilter allows users to choose it in the 2nd patch. The third patch introduces unit testing of the new nftables driver. Finally the last patch introduces a new element to the nwfilterbinding XML which is used to detect and run a cleanup on the old firewall rules defined via the previous used nwfilter firewall backend. - Implemented very basic nwfilter.conf reading, choosing a nwfilter driver based on the name of the drivers (nftables/ebiptables). Defaults to the nftables driver, based on the firewall_backend_priority meson option, following the bridge driver logic. - Implemented nft tracing and counters usable via nwfilter.conf options "enable_trace" and "enable_counters" - Resolves issue https://gitlab.com/libvirt/libvirt/-/issues/603, benchmarks showed that the amount of iifname jumps for each interface in the root chains is the cause for this. Switched the nftables driver towards a vmap (verdict map) so we can have 1 rule that jumps to the correct root input/output chain per interface. Which improves throughput as when the number of interface check and jump rules increases the throughput decreases. The issue describes the interface matching works using the interface name and the majority of the effort is the strncpy, this patch also switches nftables to an interface_index compare instead. However, just using the interface_index is not enough, the amount of oif and iif jump rules causes quite the performance degradation, the vmap instead solves this. - Split rules into separate tables: "libvirt_nwfilter_ethernet" and "libvirt_nwfilter_inet" to preserve existing firewall behavior. - Reworked chain logic for clarity with root -input/-output chains per interface. input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). - Stuck with prerouting and postrouting as hooks for input / output on the _ethernet and _inet table. This makes it easier to merge the tables in the future. Saving management of two tables and decreasing the amount of tables a packet sees. Currently ebtables filtering happens via PREROUTING and POSTROUTING hooks, while ip/ip6tables filtering happens in the output/forward hooks. - Stuck with 2 tables for compatibility reasons with eb iptables, unifying into 1 table will break users firewall definitions, which depend on being able to do accepts on ethernet rules (which currently get defined via ebtables) and additional filtering via the ip rules (which currently get defined via ip(6)tables). The nwfilter_nftables_driver keeps splitting the ethernet and inet rules in seperate tables "libvirt_nwfilter_ethernet" and "libvirt_nwfilter_inet". - Rewrote chain logic, so it is easier to understand, input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). _ethernet and _inet table follow the same style and hook in the same way. - Simplified conntrack handling: rules with accept+conntrack are duplicated to the opposite chain for symmetric behavior, to support the existing ebiptables logic. - Firewall updates continue use tmp names for atomic replacement. Unsupported nwfilter features (for now): - IPSets (potential future support via nft sets) - Reject due to filtering in pre/postrouting, using drop instead of reject, copying logic from existing ebiptables ebtables actions Future improvements: - Use `nft -f` for atomic rule application. - Optional single-table mode via nwfilter.conf. - Optimize boot phase with chain hash comparison. --- Changes in v8: - Fix incompatibility issue with ebiptables driver for inet rules Inet rules in nftables are now placed on the root chains following iptables logic inside the ebiptables driver. Introducing subchains for inet caused sorting problems, subchains can accept or drop a packet which on the ebiptables driver inet rules would have been filtered out by rules that were sorted differently. Changes in v7: - Add backend XML element to virnwfilterbinding, to support switching from nwfilter firewall backend Changes in v6: - Add STP support - Add GARP support - Remove comment "priority=%" leftover from debugging Changes in v5: - Fix rarp support via nft raw payload expression Changes in v4: - Fix rarp nft commands "arp saddr ether" "arp daddr ether" - Filter chain creation, don't create unnecessary chains - Apply danpb seperate argument suggestion - Fix table not existing errors in drop all rules - Fix table not existing errors in apply basic rules Changes in v3: - Renamed -other to -inet - Renamed - to _ in table names - Updated rule / chain sorting on ethernet table to to copy ebtables logic - Fix possible broken revert path - Fix remove rules not working in some cases, EBUSY - Shared functions camel case commit - Rename config option - Add extra config params, enable_trace, enable_counters This required passing the config struct to the ebip/nft nwfilter drivers - Add extra augeaus files Changes in v2: - Rename {ebip,nf}tables specific test files in 1 directory instead of seperating them in different directories. - Added default nwfilter.conf file in git, documented including augeas files - Replaced hardcoding of default driver based on existing firewall_backend_priority meson option. - Added nwfilter_driver_conf.{h,c} for configuration handling, to match the common pattern used in other drivers. Dion Bosschieter (4): nwfilter: add nwfilter nftables driver nwfilter: allow use of nftables nwfilter driver via nwfilter.conf nwfilter: add unit tests and test data for nwfilter nftables driver nwfilter: add used firewall backend to nwfilterbinding libvirt.spec.in | 7 + po/POTFILES | 2 + src/conf/schemas/nwfilterbinding.rng | 7 + src/conf/virnwfilterbindingdef.c | 17 +- src/conf/virnwfilterbindingdef.h | 1 + src/conf/virnwfilterobj.h | 20 - src/nwfilter/libvirtd_nwfilter.aug | 45 + src/nwfilter/meson.build | 38 + src/nwfilter/nwfilter.conf.in | 50 + src/nwfilter/nwfilter_driver.c | 67 +- src/nwfilter/nwfilter_driver_conf.c | 214 + src/nwfilter/nwfilter_driver_conf.h | 69 + src/nwfilter/nwfilter_ebiptables_driver.c | 4 +- src/nwfilter/nwfilter_ebiptables_driver.h | 2 +- src/nwfilter/nwfilter_gentech_driver.c | 144 +- src/nwfilter/nwfilter_gentech_driver.h | 5 +- src/nwfilter/nwfilter_nftables_driver.c | 2864 +++++++++++++ src/nwfilter/nwfilter_nftables_driver.h | 28 + src/nwfilter/nwfilter_tech_driver.h | 3 +- src/nwfilter/test_libvirtd_nwfilter.aug.in | 7 + tests/meson.build | 2 + tests/nwfilternftablestest.c | 426 ++ .../ah-ipv6-linux.nftables.args | 298 ++ .../ah-linux.nftables.args | 292 ++ .../all-ipv6-linux.nftables.args | 280 ++ .../all-linux.nftables.args | 274 ++ .../arp-linux.nftables.args | 285 ++ .../comment-linux.nftables.args | 502 +++ .../conntrack-linux.nftables.args | 190 + .../esp-ipv6-linux.nftables.args | 298 ++ .../esp-linux.nftables.args | 292 ++ .../example-1-linux.nftables.args | 252 ++ .../example-2-linux.nftables.args | 352 ++ .../hex-data-linux.nftables.args | 368 ++ .../icmp-direction-linux.nftables.args | 226 ++ .../icmp-direction2-linux.nftables.args | 226 ++ .../icmp-direction3-linux.nftables.args | 176 + .../icmp-linux.nftables.args | 248 ++ .../icmpv6-linux.nftables.args | 316 ++ .../igmp-linux.nftables.args | 292 ++ .../ip-linux.nftables.args | 199 + .../ipt-no-macspoof-linux.nftables.args | 166 + .../ipv6-linux.nftables.args | 481 +++ .../iter1-linux.nftables.args | 292 ++ .../iter2-linux.nftables.args | 3532 +++++++++++++++++ .../iter3-linux.nftables.args | 410 ++ .../mac-linux.nftables.args | 176 + .../rarp-linux.nftables.args | 207 + .../sctp-ipv6-linux.nftables.args | 316 ++ .../sctp-linux.nftables.args | 316 ++ .../stp-linux.nftables.args | 233 ++ .../target-linux.nftables.args | 454 +++ .../target2-linux.nftables.args | 302 ++ .../tcp-ipv6-linux.nftables.args | 316 ++ .../tcp-linux.nftables.args | 452 +++ .../udp-ipv6-linux.nftables.args | 316 ++ .../udp-linux.nftables.args | 316 ++ .../udplite-ipv6-linux.nftables.args | 298 ++ .../udplite-linux.nftables.args | 292 ++ .../vlan-linux.nftables.args | 257 ++ tests/nwfilterxml2nftfirewalltest.c | 432 ++ .../filter-vars.xml | 1 + .../simple-backend.xml | 10 + tests/virnwfilterbindingxml2xmltest.c | 1 + 64 files changed, 18845 insertions(+), 119 deletions(-) create mode 100644 src/nwfilter/libvirtd_nwfilter.aug create mode 100644 src/nwfilter/nwfilter.conf.in create mode 100644 src/nwfilter/nwfilter_driver_conf.c create mode 100644 src/nwfilter/nwfilter_driver_conf.h create mode 100644 src/nwfilter/nwfilter_nftables_driver.c create mode 100644 src/nwfilter/nwfilter_nftables_driver.h create mode 100644 src/nwfilter/test_libvirtd_nwfilter.aug.in create mode 100644 tests/nwfilternftablestest.c create mode 100755 tests/nwfilterxml2firewalldata/ah-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ah-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/arp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/comment-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/conntrack-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/hex-data-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmpv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/igmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ip-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipt-no-macspoof-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/mac-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/rarp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-linux.nftables.args create mode 100644 tests/nwfilterxml2firewalldata/stp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/vlan-linux.nftables.args create mode 100644 tests/nwfilterxml2nftfirewalltest.c create mode 100644 tests/virnwfilterbindingxml2xmldata/simple-backend.xml -- 2.43.0

3 9

Limit USB 1.0 (UHCI/OCHI) and 2.0 (EHCI) to non-virt use cases
by Daniel P. Berrangé 09 Jul '26

09 Jul '26

QEMU has implemented four generic USB controllers * UHCI - USB 1.0 only * OHCI - USB 1.0 only * EHCI - USB 2.0 only (must have UHCI companions for 1.0 compat) * XHCI - All of USB 3.0, 2.0, 1.0 in one controller We have two variants of XHCI, the generic one (hcd-xhci.c) and the NEC one (hcd-xhci-nec.c) Historically for security reports we have considered all of them in scope of virtualization, since initially with KVM the XHCI impl was not present in QEMU & thus KVM guests used UHCI/EHCI with USB tablet for a period of time All of the USB subsystem is currently orphaned, so we have no dedicated maintainer available to deal with bug reports (volunteers welcome to step up here...) While the need for USB is reduced given the availability of virtio-input, not all guests have drivers out of the box, so at least USB tablet is still interesting for KVM use cases with some modern OS. It is also not that unusual for people to need USB host device assignment with KVM virt to make various pieces of specialized hardware (security tokens, smart cards, custom dongles, etc) available directly to guests. IOW, we can't entirely exclude USB from virtualization use cases IMHO. In terms of virtualization, XHCI is the only impl that is sensible to use. UHCI/OHCI/EHCI all impose an unreasonable CPU load on any guest usage of USB. XHCI should be supported by any guest OS approx the last 15 years, which should be sufficient for virtualization use cases with OS that are not EOL by their vendor. Thus to reduce our maint burden around security bug handling, it is proposed henceforth to classify UHCI, OHCI and EHCI under the non- virtualization use case and thus be excluded from security bug triage processes. No CVEs would be assigned, bugs would be reported publically in gitlab: https://www.qemu.org/docs/master/system/security.html#non-virtualization-us… The XHCI controller (specifically the hcd-xhci.c variant) would remain as our only option for the virtualization use case, with security process applied to bugs & eligible for CVE assignment: https://www.qemu.org/docs/master/system/security.html#virtualization-use-ca… The other NEC XHCI variant (hcd-xhci-nec.c) would also be treated as non-virtualization use case, since it needlessly duplicates hcd-xhci.c impl and thus is only interesting for emulation of this specific HW variant. NB, there are no functional limitations / restrictions from this policy, it is largely just a semantic exercise. From a management application POV, however, it would strongly suggest that guests be configured with XHCI as the default choice if the user asks for USB, and in turn also imply that '-usb' not be used since that is UHCI/OHCI typically. CC'ing libvirt, though it is really a matter for virt-install/virt-manager/ openstack/kubevirt etc above libvirt to pick their defaults for USB controllers. None the less XHCI would still be in search of a maintainer to step forward and handle ongoing development and maint work. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|

5 7

[PATCH v1 0/7] Add TLS-PSK support for migration
by Abhisek Panda 23 Jun '26

23 Jun '26

QEMU provides the ability to encrypt the migration data stream using two transport layer security (TLS) authentication schemes: X.509 certificates and pre-shared keys (PSK). Currently, Libvirt only supports the X.509-based TLS authentication scheme. In TLS X.509 certificates, a set of live migrations utilize a fixed set of static certificates for encrypted migration. In this authentication scheme, users require to deploy a certificate authority and monitor the certificate expiration window. In case certificates are compromised all the future live migrations are vulnerable. To resolve this, the patch series introduce the alternative pre-shared key-based authentication scheme. This mechanism relies on symmetric pre-shared keys (a secret key that is known to both sender and receiver prior to secure communication) for providing secure transfer of data. During a migration, the parties negotiate which unique key to utilize for encrypting the migration data. To improve the security further, we utilize different key files for each migration session. Abhisek Panda (7): conf: Add configuration params for TLS-PSK include: define VIR_MIGRATE_TLS_PSK flag qemu: Add support to build the tls-creds-psk object qemu: rename tls-creds-x509 obj related functions qemu: Manage tls-creds-psk object lifecycle qemu: Set up the migrate TLS-PSK objects include: define VIR_MIGRATE_PARAM_TLS_PSK_DIRECTORY include/libvirt/libvirt-domain.h | 31 ++- src/qemu/libvirtd_qemu.aug | 2 + src/qemu/qemu.conf.in | 27 ++- src/qemu/qemu_alias.c | 19 +- src/qemu/qemu_alias.h | 5 +- src/qemu/qemu_backup.c | 2 +- src/qemu/qemu_command.c | 31 ++- src/qemu/qemu_command.h | 8 + src/qemu/qemu_conf.c | 55 ++++- src/qemu/qemu_conf.h | 3 + src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 24 ++- src/qemu/qemu_hotplug.c | 125 +++++++---- src/qemu/qemu_hotplug.h | 43 ++-- src/qemu/qemu_migration.c | 194 ++++++++++++------ src/qemu/qemu_migration.h | 3 + src/qemu/qemu_migration_params.c | 138 ++++++++++--- src/qemu/qemu_migration_params.h | 28 ++- src/qemu/qemu_postparse.c | 2 +- src/qemu/test_libvirtd_qemu.aug.in | 2 + tests/qemumigparamsdata/tls-enabled.json | 2 +- tests/qemumigparamsdata/tls-enabled.reply | 2 +- tests/qemumigparamsdata/tls-enabled.xml | 2 +- tests/qemumigparamsdata/tls-hostname.json | 2 +- tests/qemumigparamsdata/tls-hostname.reply | 2 +- tests/qemumigparamsdata/tls-hostname.xml | 2 +- tests/qemumonitorjsontest.c | 4 +- tests/qemustatusxml2xmldata/upgrade-out.xml | 2 +- .../chardev-backends-json.x86_64-9.1.0.args | 8 +- .../chardev-backends-json.x86_64-latest.args | 8 +- .../chardev-backends.x86_64-9.1.0.args | 8 +- .../chardev-backends.x86_64-latest.args | 8 +- ...rk-tlsx509-nbd-hostname.x86_64-latest.args | 6 +- ...isk-network-tlsx509-nbd.x86_64-latest.args | 6 +- ...-tlsx509-chardev-verify.x86_64-latest.args | 4 +- ...ial-tcp-tlsx509-chardev.x86_64-latest.args | 4 +- ...-tlsx509-secret-chardev.x86_64-latest.args | 4 +- tests/testutilsqemu.c | 2 + tools/virsh-domain.c | 12 ++ 39 files changed, 623 insertions(+), 209 deletions(-) -- 2.39.3

4 18

[PATCH 0/6] qemu: Add infrastructure to prevent accidental disk shrink via 'virDomainBlockResize'
by Peter Krempa 22 Jun '26

22 Jun '26

Shrinking a disk accidentally equals data loss and thus very bad time for anyone mis-typing. This series adds a new flag to virDomainBlockResize to prevent such a thing if the user only intends to extend the disk. In virsh I've went a bit further and actually change the behaviour of 'virsh blockresize' to use the new feature if available to prevent mishaps. Peter Krempa (6): virDomainBlockResizeFlags: Convert to prefix-style docs API/qemu: Introduce 'VIR_DOMAIN_BLOCK_RESIZE_EXTEND' for 'virDomainBlockResize' virsh: blockresize: Introduce '--extend' flag API: Introduce 'VIR_DOMAIN_BLOCK_RESIZE_PROBE_FLAGS' for 'virDomainBlockResize' virsh/virt-admin: Add possibility to probe for new arguments virsh: blockresize: Use VIR_DOMAIN_BLOCK_RESIZE_EXTEND when available and introduce --allow-shrink docs/manpages/virsh.rst | 31 +++++++++++++++++++++++++- include/libvirt/libvirt-domain.h | 19 ++++++++++++++-- src/libvirt-domain.c | 17 +++++++++++++++ src/qemu/qemu_driver.c | 37 +++++++++++++++++++++++++++++++- src/vz/vz_driver.c | 7 +++++- tools/virsh-domain.c | 23 ++++++++++++++++++++ tools/virsh.c | 4 ++++ tools/virt-admin.c | 9 ++++++++ tools/vsh.c | 3 +++ tools/vsh.h | 1 + 10 files changed, 146 insertions(+), 5 deletions(-) -- 2.53.0

3 13

[PATCH 1/1] qemu: stop silently narrowing the guest CPU during live migration
by Denis V. Lunev 18 Jun '26

18 Jun '26

qemuDomainMakeCPUMigratable() strips features marked added='yes' (in src/cpu_map/x86_*.xml) from the migration cookie when the source CPU was specified as host-model. The intent was libvirt-protocol compat with older destinations; the cost is guest CPU compat, paid silently on every migration. Every Intel x86 CPU model from Westmere through Sapphire Rapids carries 60+ added='yes' features, including vmx-exit-load-perf-global-ctrl and vmx-entry-load-perf-global-ctrl that control the LOAD_IA32_PERF_GLOBAL_CTRL allowed-1 bits of MSR_IA32_VMX_{EXIT,ENTRY}_CTLS. A host-model live migration on any of these models drops those features from the destination's qemu argv. Modern qemu gates the nested VMX capability MSRs on the explicit -cpu list, so the guest's MSR view shifts. Linux distributions that load kvm_intel by default snapshot those MSRs at module-load time and validate every newly online CPU against that snapshot. An automated test that boots a guest, live-migrates it, and hot-plugs additional vCPUs reliably trips kvm_intel: Inconsistent VMCS config on CPU N kvm: enabling virtualization on CPUN failed smpboot: CPU N is now offline the guest agent's online attempt returns -EIO and the hot-plug fails. Live migration must preserve the guest's CPU specification bit for bit -- this is a hard contract, not an optimisation target. Drop the strip. If a destination libvirt does not know a feature in the cookie, its parser rejects the migration with a precise unknown-feature error: operators can upgrade or narrow the source CPU definition. Either is visible; the status quo is not. This effectively reverts 14d3517410 ("qemu: domain: Drop added features from migratable CPU") together with its follow-up aae8a5774b ("qemu: Drop vmx-* from migratable CPU model only when origCPU is set"), and removes the now-unused origCPU plumbing in qemuDomainMakeCPUMigratable() and its callers. Signed-off-by: Denis V. Lunev <den(a)openvz.org> --- src/qemu/qemu_domain.c | 46 ++------------------------------ src/qemu/qemu_domain.h | 3 +-- src/qemu/qemu_migration_cookie.c | 5 +--- 3 files changed, 4 insertions(+), 50 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 84c8645259..eccd279bbe 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -5307,36 +5307,10 @@ qemuDomainDefCopy(virQEMUDriver *driver, } -typedef struct { - const char * const *added; - GStrv keep; -} qemuDomainDropAddedCPUFeaturesData; - - -static bool -qemuDomainDropAddedCPUFeatures(const char *name, - virCPUFeaturePolicy policy G_GNUC_UNUSED, - void *opaque) -{ - qemuDomainDropAddedCPUFeaturesData *data = opaque; - - if (!g_strv_contains(data->added, name)) - return true; - - if (data->keep && g_strv_contains((const char **) data->keep, name)) - return true; - - return false; -} - - int qemuDomainMakeCPUMigratable(virArch arch, - virCPUDef *cpu, - virCPUDef *origCPU) + virCPUDef *cpu) { - qemuDomainDropAddedCPUFeaturesData data = { 0 }; - if (cpu->mode != VIR_CPU_MODE_CUSTOM || !cpu->model || !ARCH_IS_X86(arch)) @@ -5353,22 +5327,6 @@ qemuDomainMakeCPUMigratable(virArch arch, virCPUDefUpdateFeature(cpu, "pconfig", VIR_CPU_FEATURE_DISABLE); } - if (origCPU) { - if (virCPUx86GetAddedFeatures(cpu->model, &data.added) < 0) - return -1; - - /* Drop features marked as added in a cpu model, but only - * when they are not mentioned in origCPU, i.e., when they were not - * explicitly mentioned by the user. - */ - if (data.added) { - g_auto(GStrv) keep = virCPUDefListExplicitFeatures(origCPU); - data.keep = keep; - - virCPUDefFilterFeatures(cpu, qemuDomainDropAddedCPUFeatures, &data); - } - } - return 0; } @@ -5569,7 +5527,7 @@ qemuDomainDefFormatBufInternal(virQEMUDriver *driver, } if (def->cpu && - qemuDomainMakeCPUMigratable(def->os.arch, def->cpu, origCPU) < 0) + qemuDomainMakeCPUMigratable(def->os.arch, def->cpu) < 0) return -1; /* Old libvirt doesn't understand <audio> elements so diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index b321a64e96..0600af8b7c 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -1066,8 +1066,7 @@ qemuDomainValidateActualNetDef(const virDomainNetDef *net, int qemuDomainMakeCPUMigratable(virArch arch, - virCPUDef *cpu, - virCPUDef *origCPU); + virCPUDef *cpu); int qemuDomainInitializePflashStorageSource(virDomainObj *vm, diff --git a/src/qemu/qemu_migration_cookie.c b/src/qemu/qemu_migration_cookie.c index 7311a8294b..ebc2072ab0 100644 --- a/src/qemu/qemu_migration_cookie.c +++ b/src/qemu/qemu_migration_cookie.c @@ -535,15 +535,12 @@ static int qemuMigrationCookieAddCPU(qemuMigrationCookie *mig, virDomainObj *vm) { - qemuDomainObjPrivate *priv = vm->privateData; - if (mig->cpu) return 0; mig->cpu = virCPUDefCopy(vm->def->cpu); - if (qemuDomainMakeCPUMigratable(vm->def->os.arch, mig->cpu, - priv->origCPU) < 0) + if (qemuDomainMakeCPUMigratable(vm->def->os.arch, mig->cpu) < 0) return -1; mig->flags |= QEMU_MIGRATION_COOKIE_CPU; -- 2.51.0

4 7

[PATCH 0/7] qemu: add async vCPU unplug coverage
by Akash Kulhalli 10 Jun '26

10 Jun '26

This series adds qemuhotplugtest coverage for async vCPU unplug. Async vCPU unplug does not complete at the device_del reply. The guest CPU remains in a pending removal state until QEMU reports DEVICE_DELETED and the QEMU driver handles the resulting process event. The new harness support lets the tests observe that intermediate state and then complete the unplug through the same process-event path used by the driver. The setvcpu coverage exercises both a single-vCPU x86 hotplug entity and a grouped ppc64 hotplug entity. These cases check the pending live XML before completion and the final live/config XML after completion, while also validating the expected vcpu-removed domain events. The setvcpus coverage adds a separate count-based x86 downscale case. This keeps the independent count-to-entity selection path covered without duplicating the grouped-entity coverage from setvcpu. The series also includes a small domain API cleanup to use the vCPU-specific flag aliases consistently in the vCPU entry points. This keeps the implementation and diagnostics aligned with the API being handled. This is a cosmetic change only, since the underlying values are all mapped to their equivalent enums. While adding this coverage, I realised that virsh was being too restrictive in its parameter combination validation; only QEMU does not support both `--async` and `--guest`. Other drivers may wish to support this behaviour. Accordingly, I've changed the behaviour so that virsh now lets the drivers reject the combination if they're unsupported. The decision now rests with the driver, which is more appropriate. Akash Kulhalli (7): qemu: expose process event handler to tests tests: add helper for DEVICE_DELETED events qemuhotplugtest: support async vcpu unplug completion qemuhotplugtest: test setvcpu async unplug qemuhotplugtest: test setvcpus async downscale domain: use vcpu-specific flag aliases consistently virsh: allow async vcpu options to reach drivers -- 2.49.0

2 16

[PATCH 0/3] qemuxmlconftest: Error out if invalid FDs will be passed
by Peter Krempa 10 Jun '26

10 Jun '26

As promised in: [PATCH 00/30] qemuxmlconftest: Use real FDs in test cases these patches make qemuxmlconftest error out if fake FDs are passed to virCommandPassFD. Peter Krempa (3): testutils: Turn 'virTestDummyFDContext' into a proper type virTestDummyFDContext: Add fields to track errors and 'virTestDummyFDContextMarkError' qemuxmlconftest: Fail if test case tried to pass STDIO or invalid fds to 'virCommandPassFD' tests/qemuxml2argvmock.c | 3 +++ tests/qemuxmlconftest.c | 12 +++++++++- tests/testutils.c | 47 ++++++++++++++++++++++++++++++++++------ tests/testutils.h | 8 ++++++- tests/testutilsqemu.h | 4 +++- 5 files changed, 64 insertions(+), 10 deletions(-) -- 2.54.0

2 4

[PATCH] qemu: validate: treat only real backing chains as NVRAM backingStore
by Efim Shevrin 10 Jun '26

10 Jun '26

qemuDomainInitializePflashStorageSource() always attaches a non-NULL src->backingStore used as an empty virStorageSource chain terminator (type VIR_STORAGE_TYPE_NONE). qemuValidateDomainDefNvram() incorrectly interpreted every non-NULL backingStore as a genuine backing overlay and reported VIR_ERR_CONFIG_UNSUPPORTED, so legitimate UEFI/NVRAM setups were rejected. Check virStorageSourceIsBacking(src->backingStore) instead of a plain pointer test so only a real backing node is rejected. Regression introduced in commit bca731d0f562f0842f56ec2206fdbd721a468f5b. Signed-off-by: Fima Shevrin <efim.shevrin(a)virtuozzo.com> --- src/qemu/qemu_validate.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c index 642244b62e..d8347d1964 100644 --- a/src/qemu/qemu_validate.c +++ b/src/qemu/qemu_validate.c @@ -740,7 +740,14 @@ qemuValidateDomainDefNvram(const virDomainDef *def, return -1; } - if (src->backingStore) { + /* qemuDomainInitializePflashStorageSource() always sets + * src->backingStore to a fresh empty virStorageSource as a + * chain terminator, so a plain `if (src->backingStore)` check + * is always true and rejects every UEFI/NVRAM domain after + * upstream commit that introduced the terminator. Use + * virStorageSourceIsBacking() (type != VIR_STORAGE_TYPE_NONE) + * so we only reject genuine backing chains. */ + if (virStorageSourceIsBacking(src->backingStore)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("backingStore is not supported with NVRAM")); return -1; -- 2.47.1

2 3