August 2026 - Devel - libvirt List Archives

Plans for 12.7.0 release (freeze on 2026-08-24)
by Jiri Denemark 29 Oct '26

29 Oct '26

We are getting close to 12.7.0 release of libvirt. To aim for the release on Tuesday 01 Sep I suggest entering the freeze on Monday 24 Aug and tagging RC2 on Thursday 27 Aug. I hope this works for everyone. Jirka

2 1

[RFC PATCH v5 0/5] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe 27 Oct '26

27 Oct '26

Hi, all. This patch adds Arm CCA support to QEMU driver for aarch64 system. CCA is an abbreviation for Arm Confidential Compute Architecture feature, it enhances the virtualization capabilities of the platform by separating the management of resources from access to those resources. We are not yet at the stage where we can merge this patch as host Linux/QEMU support is not yet merged, but I would like to receive reviews and comments on the overall direction. Changes in v5: - Changed the target QEMU binary (Linaro's CCA/v10 version with added QMP functionality) - Changed the following changes to the CCA QMP command definitions: - QMP command name: query-rme-guest-capabilities - CCA capabilities info - Add ARM CCA support to firmware feature. [summary] At this stage, all you can do is getting the CCA capability with the virsh domcapabilities command and start the CCA VM with the virsh create command. capability info uses QEMU QMP to query QEMU options. The option that exists now is for selecting a hash algorithm. QEMU QMP sections currently only contains a single member, but is wrapped in sections for expansion. [Capability example] Execution results of 'virsh domcapability" on QEMU <domaincapabilities> ... <features> ... </sgx> <cca supported='yes'> <enum name='measurement-algo'> <value>sha256</value> <value>sha512</value> </enum> </cca> <hyperv supported='yes'> ... </features> </domaincapabilities> [XML example] <domain> ... <launchsecurity type='cca'> <measurement-algo>sha256</measurement-algo> </launchsecurity> ... </domain> [limitations/tests] To obtain capability info, it is necessary to support the QEMU QMP command, (See "[software version]"below). The JSON file for the CCA firmware feature has not yet been provided by the distributor. For CCA support, the equivalent of the following JSON file must be placed in /usr/share/qemu: tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json We have confirmed that the added tests (qemucapabilitiestest, domaincapstest and qemuxmlconftest) and the CCA VM startup test (starting the CCA VM from the virsh create command) passed. The "personalization-value" and "measurement-log" parameters that exist in the current Linaro QEMU cca/latest branch will not be specified as CCA VM startup parameters with the virsh create command. [software version] I followed the steps in Linaro's blog below. https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an… The QEMU used was enhanced with CCA QMP command and found at: https://gitlab.com/Linaro/dcap/qemu/-/commits/cca/latest RFC v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/V4S5… RFC v2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5VZ… RFC v3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LLWA… RFC v4 https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3WAW… Signed-off-by: Kazuhiro Abe fj1078ii(a)aa.jp.fujitsu.com Akio Kakuno (3): src: Add ARM CCA support in qemu driver to launch VM src: Add ARM CCA support in domain capabilities command src: Add ARM CCA support in domain schema Kazuhiro Abe (2): src: Add ARM CCA support in firmware feature tests: Adds Arm CCA support docs/formatdomain.rst | 46 + docs/formatdomaincaps.rst | 27 +- src/conf/domain_capabilities.c | 48 + src/conf/domain_capabilities.h | 12 + src/conf/domain_conf.c | 25 + src/conf/domain_conf.h | 9 + src/conf/domain_validate.c | 1 + src/conf/schemas/domaincaps.rng | 36 + src/conf/schemas/domaincommon.rng | 26 + src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 146 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 30 + src/qemu/qemu_driver.c | 2 + src/qemu/qemu_firmware.c | 18 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 111 + src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 4 + src/security/security_dac.c | 2 + .../qemu_10.1.0-virt.aarch64+armrme.xml | 250 + .../qemu_10.1.0.aarch64+armrme.xml | 250 + tests/qemucapabilitiesdata/README.rst | 5 + .../caps_10.1.0_aarch64+armrme.replies | 37727 ++++++++++++++++ .../caps_10.1.0_aarch64+armrme.xml | 518 + .../qemu/firmware/50-edk2-aarch64-armcca.json | 24 + tests/qemufirmwaretest.c | 3 + ...ch-security-cca.aarch64-latest+armrme.args | 30 + ...nch-security-cca.aarch64-latest+armrme.xml | 24 + tests/qemuxmlconfdata/launch-security-cca.xml | 16 + tests/qemuxmlconftest.c | 2 + 36 files changed, 39423 insertions(+), 1 deletion(-) create mode 100644 tests/domaincapsdata/qemu_10.1.0-virt.aarch64+armrme.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0.aarch64+armrme.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.xml create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml -- 2.43.0

2 6

[libvirt] [PATCH 00/23] Fix host-model if the chosen CPU model has more features in QEMU compared to our cpu_map.xml
by Jiri Denemark 15 Oct '26

15 Oct '26

When decoding CPUID data to virCPUDef we need to be careful about using a CPU model which cannot be directly used on the current host. Normally, libvirt would notice the features which prevent the model from being usable and it would disable them in the computed virCPUDef, but this won't work in case the definition of the CPU model in QEMU contains more features than what we have in cpu_map.xml. We need to count with the usability blockers we got from QEMU and explicitly disable all of them to make the computed virCPUDef usable. https://bugzilla.redhat.com/show_bug.cgi?id=1464832 Jiri Denemark (23): util: Introduce virStringListCopy conf: Add usability blockers to virDomainCapsCPUModel qemu: Store CPU usability blockers in caps cache qemu: Parse unavailable features for CPU models cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs cpu: Drop unused parameter from cpuDecode cpu: Return model from virCPUModelIsAllowed cpu_x86: Move x86FeatureFind* to avoid forward prototypes cpu_x86: Disable blockers from unusable CPU models cputest: Replace json bool with enum cputest: Avoid calling json_reformat in cpu-parse.sh cputest: Print correct feature in virCPUUpdateLive test cputest: Test CPU usability blockers cputest: Separate QEMUCaps creation from cpuTestCPUIDJson build: Export virCPUModelIsAllowed private API cputest: Use CPU models from QEMU when available cputest: Add query-cpu-definitions reply for Core-i5-2540M cputest: Add CPUID data for Intel(R) Xeon(R) CPU E7-4830 cputest: Add query-cpu-definitions reply for Xeon-E7-4830 cputest: Update Xeon-E3-1245 data cputest: Add query-cpu-definitions reply for Xeon-E3-1245 cputest: Update Core-i7-2600 data cputest: Make a crippled version of Core-i7-2600 src/conf/domain_capabilities.c | 30 +- src/conf/domain_capabilities.h | 7 +- src/cpu/cpu.c | 95 +- src/cpu/cpu.h | 31 +- src/cpu/cpu_arm.c | 3 +- src/cpu/cpu_ppc64.c | 14 +- src/cpu/cpu_x86.c | 108 +- src/libvirt_private.syms | 1 + src/libxl/libxl_capabilities.c | 2 +- src/libxl/libxl_driver.c | 2 +- src/qemu/qemu_capabilities.c | 123 +-- src/qemu/qemu_capabilities.h | 6 +- src/qemu/qemu_capspriv.h | 5 + src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_monitor.c | 2 + src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 26 +- src/qemu/qemu_process.c | 9 +- src/test/test_driver.c | 2 +- src/util/virstring.c | 37 + src/util/virstring.h | 3 + tests/cputest.c | 324 ++++-- tests/cputestdata/cpu-cpuid.py | 26 +- tests/cputestdata/cpu-gather.sh | 1 + tests/cputestdata/cpu-parse.sh | 2 +- tests/cputestdata/cpu-reformat.py | 9 + tests/cputestdata/x86_64-cpuid-Core-i5-2540M.json | 362 +++++++ .../x86_64-cpuid-Core-i7-2600-disabled.xml | 1 - .../x86_64-cpuid-Core-i7-2600-enabled.xml | 1 + .../cputestdata/x86_64-cpuid-Core-i7-2600-json.xml | 1 + ...x86_64-cpuid-Core-i7-2600-xsaveopt-disabled.xml | 6 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-enabled.xml | 8 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-guest.xml | 25 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-host.xml | 25 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-json.xml | 11 + .../x86_64-cpuid-Core-i7-2600-xsaveopt.json | 615 +++++++++++ .../x86_64-cpuid-Core-i7-2600-xsaveopt.xml | 33 + tests/cputestdata/x86_64-cpuid-Core-i7-2600.json | 496 ++++++++- tests/cputestdata/x86_64-cpuid-Core-i7-2600.xml | 6 +- .../x86_64-cpuid-Xeon-E3-1245-disabled.xml | 1 - .../x86_64-cpuid-Xeon-E3-1245-enabled.xml | 2 +- .../cputestdata/x86_64-cpuid-Xeon-E3-1245-json.xml | 1 + tests/cputestdata/x86_64-cpuid-Xeon-E3-1245.json | 712 +++++++++---- tests/cputestdata/x86_64-cpuid-Xeon-E3-1245.xml | 7 +- .../x86_64-cpuid-Xeon-E7-4830-disabled.xml | 5 + .../x86_64-cpuid-Xeon-E7-4830-enabled.xml | 8 + .../x86_64-cpuid-Xeon-E7-4830-guest.xml | 28 + .../cputestdata/x86_64-cpuid-Xeon-E7-4830-host.xml | 29 + .../cputestdata/x86_64-cpuid-Xeon-E7-4830-json.xml | 14 + tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.json | 657 ++++++++++++ tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.xml | 30 + tests/domaincapstest.c | 6 +- tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1102 ++++++++++++++++++-- tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 236 ++++- tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 154 ++- tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 154 ++- 56 files changed, 4927 insertions(+), 680 deletions(-) create mode 100755 tests/cputestdata/cpu-reformat.py create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt.json create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.xml -- 2.14.2

3 66

[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 process_exit_wait configuration setting
by Jim Fehlig 15 Sep '26

15 Sep '26

From: Jim Fehlig <jfehlig(a)suse.com> When shutting down a VM, libvirt sends the associated QEMU process SIGTERM, waits 10 seconds for it to disappear, optionally sends SIGKILL, then waits up to another 30 seconds for the process to exit before reporting and returning an error. Commit be2ca04447 added 2 seconds per assigned host device to the total time libvirt waits for a QEMU process to terminate. Other scenarios than the one described in be2ca04447 could delay the clean exit of QEMU, e.g. reclaiming memory of VMs with large memory allocations backed by 4k pages on the host. Instead of trying to cover all such scenarios based on VM configuration, introduce a 'process_exit_wait' setting in qemu.conf to control how much additional time (in seconds) libvirt will wait for a QEMU process to terminate before reporting an error. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf.in | 12 ++++++++++++ src/qemu/qemu_conf.c | 3 +++ src/qemu/qemu_conf.h | 1 + src/qemu/qemu_process.c | 13 ++++++++++--- src/qemu/test_libvirtd_qemu.aug.in | 1 + 6 files changed, 28 insertions(+), 3 deletions(-) diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug index 311992e441..dc3d6d61df 100644 --- a/src/qemu/libvirtd_qemu.aug +++ b/src/qemu/libvirtd_qemu.aug @@ -132,6 +132,7 @@ module Libvirtd_qemu = | bool_entry "dump_guest_core" | str_entry "stdio_handler" | int_entry "max_threads_per_process" + | int_entry "process_exit_wait" | str_entry "sched_core" let device_entry = bool_entry "mac_filter" diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in index 97b0141cf6..2f24059053 100644 --- a/src/qemu/qemu.conf.in +++ b/src/qemu/qemu.conf.in @@ -844,6 +844,18 @@ #max_threads_per_process = 0 +# When shutting down a VM, libvirt will wait up to 40 seconds for +# the associated QEMU process to exit before reporting an error. +# For some VM configurations, QEMU might require more time to +# cleanup and exit, e.g. VMs with very large memory allocations. +# +# If process_exit_wait is set to a positive interger, libvirt +# will use the value as additional time to wait for the QEMU +# process to exit before reporting it cannot be terminated. +# +#process_exit_wait = 0 + + # If max_core is set to a non-zero integer, then QEMU will be # permitted to create core dumps when it crashes, provided its # RAM size is smaller than the limit set. diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index e30b146634..adcba137cc 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -934,6 +934,9 @@ virQEMUDriverConfigLoadProcessEntry(virQEMUDriverConfig *cfg, cfg->schedCore = val; } + if (virConfGetValueUInt(conf, "process_exit_wait", &cfg->processExitWait) < 0) + return -1; + return 0; } diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h index 1d29f35c5d..bc78982123 100644 --- a/src/qemu/qemu_conf.h +++ b/src/qemu/qemu_conf.h @@ -211,6 +211,7 @@ struct _virQEMUDriverConfig { unsigned int maxProcesses; unsigned int maxFiles; unsigned int maxThreadsPerProc; + unsigned int processExitWait; unsigned long long maxCore; bool dumpGuestCore; diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index b2506edce0..5042ffe339 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -9218,6 +9218,9 @@ qemuProcessInShutdownStartMonitor(virDomainObj *vm) int qemuProcessKill(virDomainObj *vm, unsigned int flags) { + qemuDomainObjPrivate *priv = vm->privateData; + g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(priv->driver); + unsigned int delay = cfg->processExitWait; int ret = -1; VIR_DEBUG("vm=%p name=%s pid=%lld flags=0x%x", @@ -9238,11 +9241,15 @@ qemuProcessKill(virDomainObj *vm, unsigned int flags) return 0; } - /* Request an extra delay of two seconds per current nhostdevs - * to be safe against stalls by the kernel freeing up the resources */ + /* If the administrator has not requested an explicit shutdown wait period, + * add an extra delay of two seconds per current nhostdevs to be safe against + * stalls by the kernel freeing up the resources */ + if (delay == 0) + delay = vm->def->nhostdevs * 2; + ret = virProcessKillPainfullyDelay(vm->pid, !!(flags & VIR_QEMU_PROCESS_KILL_FORCE), - vm->def->nhostdevs * 2, + delay, false); if (ret < 0 && (flags & VIR_QEMU_PROCESS_KILL_MONITOR_ON_ERROR)) { diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in index c4cf9cf634..fb6cb1a1d4 100644 --- a/src/qemu/test_libvirtd_qemu.aug.in +++ b/src/qemu/test_libvirtd_qemu.aug.in @@ -97,6 +97,7 @@ module Test_libvirtd_qemu = { "max_processes" = "0" } { "max_files" = "0" } { "max_threads_per_process" = "0" } +{ "process_exit_wait" = "0" } { "max_core" = "unlimited" } { "dump_guest_core" = "1" } { "mac_filter" = "1" } -- 2.51.0

4 13

Entering freeze for libvirt-12.7.0
by Jiri Denemark 10 Sep '26

10 Sep '26

I have just tagged v12.7.0-rc1 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Jirka

1 1

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 v3 0/7] Add TLS-PSK support for migration
by Abhisek Panda 10 Sep '26

10 Sep '26

QEMU provides the capability 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, this patch series introduce the support for 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. Libvirt solely manages the lifecycle of the ephemeral pre-shared keys, including, generation, persistent storage, and cleanup. Libvirt generates the key on the source machine, then transfers it to the destination machine using the migration cookie. To allow users to configure the size of the key, Libvirt provides the migrate_tls_psk_length configuration parameter in qemu.conf. To avoid introduction of an additional VIR_MIGRATE_* flag, we rely on existing the VIR_MIGRATE_TLS flag. If the VIR_MIGRATE_TLS flag is set but the necessary X.509 credential files are missing on the destination, then we fallback to using PSK-based authentication scheme during migration. v3: 1. Destination host decides which TLS authentication scheme to use. 2. The directory of the key file is set to <tls_psk_state_dir>/$ID-$VMNAME. 3. Use the same alias for both tls-creds-x509 and tls-creds-psk objects. 4. Validate the length of the pre-shared key. 5. Unit test to validate the pre-shared key in the migration cookie. v2: 1. Libvirt manages the lifecycle of pre-shared keys. 2. Transfer of keys to the destination via the migration cookie 3. Remove the VIR_MIGRATE_TLS_PSK flag instead rely on VIR_MIGRATE_TLS and availability of ca-cert.pem on source. 4. Drop VIR_MIGRATE_PARAM_TLS_PSK_DIRECTORY, Libvirt solely manages the pre-shared keys. Abhisek Panda (7): conf: Add a configuration param for TLS-PSK qemu: Manage a pre-shared key's lifecycle 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 tests: Add testing of pre-shared key lifecycle include/libvirt/libvirt-domain.h | 11 +- src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf.in | 8 ++ src/qemu/qemu_command.c | 26 ++++ src/qemu/qemu_command.h | 7 + src/qemu/qemu_conf.c | 22 ++++ src/qemu/qemu_conf.h | 2 + src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 6 + src/qemu/qemu_hotplug.c | 40 +++--- src/qemu/qemu_hotplug.h | 24 ++-- src/qemu/qemu_migration.c | 202 +++++++++++++++++++++++++---- src/qemu/qemu_migration_cookie.c | 94 +++++++++++++- src/qemu/qemu_migration_cookie.h | 5 + src/qemu/qemu_migration_params.c | 98 +++++++++++--- src/qemu/qemu_migration_params.h | 22 +++- src/qemu/test_libvirtd_qemu.aug.in | 1 + tests/qemumigrationcookiexmltest.c | 141 +++++++++++++++++++- tests/testutilsqemu.c | 12 ++ 20 files changed, 631 insertions(+), 93 deletions(-) -- 2.43.7

2 20

[PATCH 0/2] qemu: Fix hot plugged host CPUs not being used
by Ilya Leoshkevich 04 Sep '26

04 Sep '26

Hi, This series fixes hot plugged host CPUs not being used to schedule guest virtual CPUs. Patch 1 is the fix, patch 2 is the test. If the fix is acceptable and the test needs changes, it would be great to have the fix committed separately. Best regards, Ilya Boris Fiuczynski (1): tests: add qemuprocesstest for qemuProcessGetAllCpuAffinity Ilya Leoshkevich (1): qemu: Fix hot plugged host CPUs not being used src/qemu/qemu_process.c | 26 ++++++-- src/qemu/qemu_process.h | 2 + src/util/virhostcpu.h | 6 +- tests/meson.build | 1 + tests/qemuprocessmock.c | 65 ++++++++++++++++++ tests/qemuprocesstest.c | 144 ++++++++++++++++++++++++++++++++++++++++ tests/qemuprocesstest.h | 25 +++++++ 7 files changed, 261 insertions(+), 8 deletions(-) create mode 100644 tests/qemuprocessmock.c create mode 100644 tests/qemuprocesstest.c create mode 100644 tests/qemuprocesstest.h -- 2.55.0

3 5

[PATCH 0/2] ch: Fix validation and add persistent domain support
by shotor＠shotor.com 04 Sep '26

04 Sep '26

From: shotor <shotor(a)shotor.com> The first patch fixes the validation flag used by chDomainDefineXMLFlags(). The second patch adds persistent domain support to the Cloud Hypervisor driver, including saving and loading domain definitions and reporting their persistence state. shotor (2): ch: Fix define validation flag ch: Add persistent domain support src/ch/ch_conf.c | 13 +++++++--- src/ch/ch_conf.h | 1 + src/ch/ch_driver.c | 65 ++++++++++++++++++++++++++++++++++++++++++---- 3 files changed, 70 insertions(+), 9 deletions(-) -- 2.55.0

4 11