January 2026 - Devel - libvirt List Archives

Questions about device attach/detach semantics
by pascal.scholz＠cyberus-technology.de 15 Jan '26

15 Jan '26

Hi all, I'm part of Cyberus Technology and currently working on the Cloud Hypervisor driver backend of libvirt. We are currently implementing a feature to fix device bus addresses in the domain definitions for PCI devices, guaranteeing that devices remain available at the same address even after live migration and restarts, and across libvirt versions. In doing so, some questions came up about the intended semantics of the `--persistent` and `--live` flags in virsh commands and the synchronization between runtime and persistent configuration. So we wanted to ask you these questions. Our first question revolves around `virsh mirgate --persistent`. The documentation says `leaves the domain persistent on the destination host physical machine`, but what domain definition is used from the source side to migrate the VM? Is it that the live definition is sent, then migrated, and persisted on the receiver side? Or is the source's persistent XML sent to the receiver, and the receiver’s live definition created from the persistent definition received? The second question is about synchronization between live and persistent configuration. To achieve the goal of keeping the same device at the same PCI bus address across restarts and live migrations, to our understanding, we have to ensure that one device is written to both domain definitions with the same PCI bus address. Is this right, or do we miss something? The next questions are about attaching/detaching devices (live). With respect to our intention to implement fixed PCI bus addresses for devices, what would be the right semantics for the following cases? Are they even valid? The source code of the qemu driver leaves those questions open: 1) We attach a device `A` with `--persistent`and remove it with `--live`. If we now attach `B`, either via `--persistent` and `--live`, we expect that the PCI bus address formerly assigned to `A` is not reused for `B`. Is this correct? 2) If we attach a device `A` with `--live` and a second device `B` with `--persistent`, then `A` will not be present in the persistent domain XML. Still, we expect that `B` is added to both live and persistent definitions, using the same PCI bus address. By doing so, we would expect the attachment routines for the persistent definition not to assign the address handed out by the attachment routines of the live configuration for device `A`. In other words, even if `A` is not present in the persistent configuration, we would expect the address of `A` not be reused when attaching `B` to the persistent definition. Are those semantics correct? The last question is about target names for network devices (`ifname`). libvirt does generate names for such devices in certain situations. Whenever a device definition is parsed that contains an `ifname` that matches libvirt's generation rules, e.g. vnet*, it is blanked out (see `virDomainNetDefParseXML`, in domain_conf.c). When writing code that tries to identify network devices by their `ifname`s, we found that this would be impossible because devices with an autogenerated name will have a blank `ifname` in the definition. What is the expected semantics around fixed PCI bus addresses for such devices? Would it be right to assign a custom `ifname` to them in this case? Thanks in advance! Pascal

3 4

Resolving issue 135 (Qemu under AppArmor can't access volume-type disks)
by Erik Huelsmann 15 Jan '26

15 Jan '26

Hi, Several months ago, I ran into issue #135 which says that Qemu under AppArmor can't access LVM volume disks. I have been studying the code and the invocation of virt-aa-helper. I'm using 11.3.0 and 10.0.0 -- I'm working to compile and run a development version, but have my progress to share in the mean time. So far, I'm finding that if I create a volume-based disk XML entry in my domain definition: <disk type='volume' device='disk'> <driver name='qemu' type='qcow2'/> <source pool='default' volume='cirros.img'/> <target dev='sda' bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> with this, there is *no* XML (at all) on standard input in the virt-aa-helper command, whereas when using effectively the same definition, resolving the file manually, like this: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/cirros.img'/> <target dev='sda' bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> I get full XML on standard input for virt-aa-helper, with this being the snippet for the disk definition: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/cirros.img' index='1'/> <backingStore/> <target dev='sda' bus='scsi'/> <alias name='scsi0-0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> I'm not asking for a fix, but would like to know if anybody has any "Ah hah!" moments about this - and if not, if there are some hints on how to test this, hopefully without needing to restart a VM over-and-over. Thanks in advance for any hints you may be able to provide! -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 7

[PATCH 0/3] qemu: capabilities: Fetch properties of 'scsi-block' and 'scsi-generic' and add caps_10.2.0_aarch64 test data
by Peter Krempa 15 Jan '26

15 Jan '26

Peter Krempa (3): qemu: capabilities: Probe properties of 'scsi-block' and 'scsi-generic' devices qemucapabilitiesdata: Regenerate 'caps_10.2.0_x86_64' replies qemucapabilitestest: Add 'caps_10.2.0_aarch64' test data src/qemu/qemu_capabilities.c | 12 + .../qemu_10.2.0-virt.aarch64.xml | 251 + tests/domaincapsdata/qemu_10.2.0.aarch64.xml | 251 + .../caps_10.0.0_aarch64.replies | 76 +- .../caps_10.0.0_ppc64.replies | 60 +- .../caps_10.0.0_s390x.replies | 64 +- .../caps_10.0.0_x86_64+amdsev.replies | 84 +- .../caps_10.0.0_x86_64.replies | 84 +- .../caps_10.1.0_s390x.replies | 64 +- .../caps_10.1.0_x86_64+inteltdx.replies | 88 +- .../caps_10.1.0_x86_64.replies | 88 +- .../caps_10.2.0_aarch64.replies | 39259 ++++++++++++++++ .../caps_10.2.0_aarch64.xml | 530 + .../caps_10.2.0_x86_64+mshv.replies | 88 +- .../caps_10.2.0_x86_64.replies | 186 +- .../caps_6.2.0_ppc64.replies | 60 +- .../caps_6.2.0_x86_64.replies | 84 +- .../caps_7.0.0_ppc64.replies | 60 +- .../caps_7.0.0_x86_64.replies | 84 +- .../caps_7.1.0_ppc64.replies | 60 +- .../caps_7.1.0_x86_64.replies | 84 +- .../caps_7.2.0_ppc.replies | 56 +- .../caps_7.2.0_x86_64+hvf.replies | 84 +- .../caps_7.2.0_x86_64.replies | 84 +- .../caps_8.0.0_x86_64.replies | 84 +- .../caps_8.1.0_s390x.replies | 60 +- .../caps_8.1.0_x86_64.replies | 84 +- .../caps_8.2.0_aarch64.replies | 76 +- .../caps_8.2.0_armv7l.replies | 76 +- .../caps_8.2.0_loongarch64.replies | 64 +- .../caps_8.2.0_s390x.replies | 60 +- .../caps_8.2.0_x86_64.replies | 84 +- .../caps_9.0.0_sparc.replies | 52 +- .../caps_9.0.0_x86_64.replies | 84 +- .../caps_9.1.0_riscv64.replies | 64 +- .../caps_9.1.0_s390x.replies | 64 +- .../caps_9.1.0_x86_64.replies | 84 +- .../caps_9.2.0_aarch64+hvf.replies | 72 +- .../caps_9.2.0_s390x.replies | 64 +- .../caps_9.2.0_x86_64+amdsev.replies | 84 +- .../caps_9.2.0_x86_64.replies | 84 +- ...arch64-cpu-passthrough.aarch64-latest.args | 2 +- ...aarch64-cpu-passthrough.aarch64-latest.xml | 2 +- ...ault-cpu-kvm-virt-10.0.aarch64-latest.args | 2 +- ...fault-cpu-kvm-virt-10.0.aarch64-latest.xml | 2 +- ...ault-cpu-tcg-virt-10.0.aarch64-latest.args | 1 - ...fault-cpu-tcg-virt-10.0.aarch64-latest.xml | 3 - ...aarch64-features-pauth.aarch64-latest.args | 2 +- .../aarch64-features-pauth.aarch64-latest.xml | 2 +- .../aarch64-features-sve.aarch64-latest.args | 2 +- .../aarch64-features-sve.aarch64-latest.xml | 2 +- .../aarch64-features-wrong.aarch64-latest.xml | 2 +- .../aarch64-gic-default.aarch64-latest.args | 2 +- .../aarch64-gic-default.aarch64-latest.xml | 2 +- .../aarch64-gic-none.aarch64-latest.args | 2 +- .../aarch64-gic-none.aarch64-latest.xml | 2 +- .../aarch64-kvm-32-on-64.aarch64-latest.args | 2 +- .../aarch64-kvm-32-on-64.aarch64-latest.xml | 2 +- .../aarch64-pci-serial.aarch64-latest.args | 1 - .../aarch64-pci-serial.aarch64-latest.xml | 3 - ...arch64-traditional-pci.aarch64-latest.args | 1 - ...aarch64-traditional-pci.aarch64-latest.xml | 3 - ...aarch64-usb-controller.aarch64-latest.args | 1 - .../aarch64-usb-controller.aarch64-latest.xml | 3 - ...ault-models.aarch64-latest.abi-update.args | 1 - ...fault-models.aarch64-latest.abi-update.xml | 3 - ...64-virt-default-models.aarch64-latest.args | 1 - ...h64-virt-default-models.aarch64-latest.xml | 3 - .../aarch64-virt-graphics.aarch64-latest.args | 1 - .../aarch64-virt-graphics.aarch64-latest.xml | 3 - ...h64-virt-headless-mmio.aarch64-latest.args | 1 - ...ch64-virt-headless-mmio.aarch64-latest.xml | 3 - .../aarch64-virt-headless.aarch64-latest.args | 1 - .../aarch64-virt-headless.aarch64-latest.xml | 3 - ...irt-minimal.aarch64-latest.abi-update.args | 1 - ...virt-minimal.aarch64-latest.abi-update.xml | 3 - .../aarch64-virt-minimal.aarch64-latest.args | 1 - .../aarch64-virt-minimal.aarch64-latest.xml | 3 - .../arm-vexpressa9-basic.aarch64-latest.args | 1 + .../arm-vexpressa9-basic.aarch64-latest.xml | 3 + .../arm-vexpressa9-nodevs.aarch64-latest.args | 1 + .../arm-vexpressa9-nodevs.aarch64-latest.xml | 3 + .../arm-vexpressa9-virtio.aarch64-latest.args | 1 + .../arm-vexpressa9-virtio.aarch64-latest.xml | 3 + .../cpu-topology5.aarch64-latest.args | 1 - .../cpu-topology5.aarch64-latest.xml | 3 +- ...ult-video-type-aarch64.aarch64-latest.args | 2 +- ...ault-video-type-aarch64.aarch64-latest.xml | 2 +- .../disk-arm-virtio-sd.aarch64-latest.args | 1 + .../disk-arm-virtio-sd.aarch64-latest.xml | 3 + ...efi-aarch64.aarch64-latest.abi-update.args | 1 - ...-efi-aarch64.aarch64-latest.abi-update.xml | 3 - ...mware-auto-efi-aarch64.aarch64-latest.args | 1 - ...rmware-auto-efi-aarch64.aarch64-latest.xml | 3 - ...-loader-raw.aarch64-latest.abi-update.args | 1 - ...t-loader-raw.aarch64-latest.abi-update.xml | 3 - ...-efi-format-loader-raw.aarch64-latest.args | 1 - ...o-efi-format-loader-raw.aarch64-latest.xml | 3 - ...i-aarch64-legacy-paths.aarch64-latest.args | 1 - ...fi-aarch64-legacy-paths.aarch64-latest.xml | 3 - ...anual-efi-acpi-aarch64.aarch64-latest.args | 1 - ...manual-efi-acpi-aarch64.aarch64-latest.xml | 3 - ...ual-efi-noacpi-aarch64.aarch64-latest.args | 1 - ...nual-efi-noacpi-aarch64.aarch64-latest.xml | 3 - ...l-noefi-noacpi-aarch64.aarch64-latest.args | 1 - ...al-noefi-noacpi-aarch64.aarch64-latest.xml | 3 - ...-smmuv3-pci-bus-single.aarch64-latest.args | 1 - ...u-smmuv3-pci-bus-single.aarch64-latest.xml | 3 - .../iommu-smmuv3-pci-bus.aarch64-latest.args | 1 - .../iommu-smmuv3-pci-bus.aarch64-latest.xml | 3 - .../iommu-smmuv3.aarch64-latest.args | 1 - .../iommu-smmuv3.aarch64-latest.xml | 3 - ...ch-virt-console-native.aarch64-latest.args | 1 - ...ach-virt-console-native.aarch64-latest.xml | 3 - ...ch-virt-console-virtio.aarch64-latest.args | 1 - ...ach-virt-console-virtio.aarch64-latest.xml | 3 - ...-serial+console-native.aarch64-latest.args | 1 - ...t-serial+console-native.aarch64-latest.xml | 3 - ...ach-virt-serial-compat.aarch64-latest.args | 1 - ...mach-virt-serial-compat.aarch64-latest.xml | 3 - ...ach-virt-serial-native.aarch64-latest.args | 1 - ...mach-virt-serial-native.aarch64-latest.xml | 3 - .../mach-virt-serial-pci.aarch64-latest.args | 1 - .../mach-virt-serial-pci.aarch64-latest.xml | 3 - .../mach-virt-serial-usb.aarch64-latest.args | 1 - .../mach-virt-serial-usb.aarch64-latest.xml | 3 - ...e-expander-bus-aarch64.aarch64-latest.args | 1 - ...ie-expander-bus-aarch64.aarch64-latest.xml | 3 - .../pcihole64-virt.aarch64-latest.args | 1 - .../pcihole64-virt.aarch64-latest.xml | 3 - .../pvpanic-pci-aarch64.aarch64-latest.args | 1 - .../pvpanic-pci-aarch64.aarch64-latest.xml | 3 - ...pci-no-address-aarch64.aarch64-latest.args | 1 - ...-pci-no-address-aarch64.aarch64-latest.xml | 3 - ...automatic-virt-aarch64.aarch64-latest.args | 1 - ...-automatic-virt-aarch64.aarch64-latest.xml | 3 - ...-fallback-virt-aarch64.aarch64-latest.args | 1 - ...t-fallback-virt-aarch64.aarch64-latest.xml | 3 - ...r-default-virt-aarch64.aarch64-latest.args | 1 - ...er-default-virt-aarch64.aarch64-latest.xml | 3 - .../virtio-iommu-aarch64.aarch64-latest.args | 1 - .../virtio-iommu-aarch64.aarch64-latest.xml | 3 - 142 files changed, 42351 insertions(+), 932 deletions(-) create mode 100644 tests/domaincapsdata/qemu_10.2.0-virt.aarch64.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0.aarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.2.0_aarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.2.0_aarch64.xml -- 2.52.0

2 4

[PATCH] qemuSecurityMoveImageMetadata: Move seclabels only to virStorageSource of same type
by Peter Krempa 15 Jan '26

15 Jan '26

From: Peter Krempa <pkrempa(a)redhat.com> The concept of moving a seclabel is used e.g. when a new image is introduced to the backing chain (or one of the existing ones becomes active during block commit). What it does is that it moves the metedata remembering the original seclabel to the new image. That idea works reasonably well if both the original and new image are of same type e.g. a file, where they have comparable seclabel. It breaks down though when you e.g. create a snapshot stored in a 'file' on top of a disk originally backed by a 'block' storage source, since the seclabels differ quite siginificantly. This patch restricts the seclabel move in qemuSecurityMoveImageMetadata to happen only if the storage sources are of same type to avoid the issue. This means that the seclabels will not be remebered and will be restored to the default but it's better than to transfer wrong labels. Resolves: https://issues.redhat.com/browse/RHEL-114412 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_security.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_security.c index 6bb0f9170d..84cb981a96 100644 --- a/src/qemu/qemu_security.c +++ b/src/qemu/qemu_security.c @@ -201,6 +201,16 @@ qemuSecurityMoveImageMetadata(virQEMUDriver *driver, if (qemuDomainNamespaceEnabled(vm, QEMU_DOMAIN_NS_MOUNT)) pid = vm->pid; + /* Moving seclabel metadata makes sense only when 'src' and 'dst' are of + * the same type. Otherwise 'dst' could end up with a seclabel that doesn't + * make sense for it (e.g. a seclabel originating from a block device /dev + * node moved to a file), once the seclabels are restored for it */ + if (src && dst && src->type != dst->type) { + VIR_DEBUG("dropping security label metadata instead of moving it from '%s' to '%s' due to type mismatch", + NULLSTR(src->path), NULLSTR(dst->path)); + dst = NULL; + } + return virSecurityManagerMoveImageMetadata(driver->securityManager, cfg->sharedFilesystems, pid, src, dst); -- 2.52.0

2 1

Release of libvirt-12.0.0
by Jiri Denemark 15 Jan '26

15 Jan '26

The 12.0.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. * New features * bhyve: SLIRP networking support Domain XMLs now can use SLIRP user-mode networking:: <interface type='user'> <model type='virtio'/> </interface> * bhyve: virtio-scsi support Domain XMLs now can use ``virtio-scsi`` devices:: <disk type='ctl'> <source dev='/dev/cam/ctl'/> <target dev='sda' bus='scsi'/> </disk> * bhyve: initial ARM64 support The bhyve driver now supports booting ARM64 domains on ARM64 hosts. This support is still in early stage of development and has some limitations. For example, it requires using ``<clock offset='localtime'/>`` in domain XMLs, and bootrom autofill is not implemented. * Improvements * qemu: Improvements and fixes to firmware selection Firmware selection now works more reliably and predictably in many scenarios. Notably, issues that were preventing the use of firmware designed for confidential VMs on aarch64 have been addressed. * network: Introduce port for DNS forwarder In the ``<dns/>`` section of network configuration users can set up forwarding of DNS requests to custom DNS servers. These are specified using ``addr`` attribute. But configuring port wasn't possible, until now. New ``port`` attribute is introduced, which allows overriding the default DNS port for given address. * Bug fixes * qemu: Fix startup of VMs with more than ~25 external snapshots After switch to json-c VMs with too deeply nested image chains would fail to start due to nesting depth limit in json-c, which is now increased to once again support backing chains up to 200 images deep. * qemu: TPM: Properly handle migration when storage resides on NFS The VM now can be properly migrated in scenarios where TPM data is stored on a shared filesystem on the destination but on the source it's either on a different NFS or unshared completely. * qemu: Treat memory device source nodemask as strict NUMA policy Until now, the NUMA policy for ``<memory/>`` devices was taken either from the guest NUMA node or ``<numatune/>``. But this may lead to discrepancies, where the memory device is configured to bind to a set of host NUMA nodes, but the guest NUMA node is to bind to a disjoint set of host NUMA nodes. To resolve this, specifying ``<nodemask/>`` for a memory device implies ``strict`` policy. * qemu: Relax validation of some hyperv features Since 11.9.0 release, libvirt performs dependency checks for hyperv features, for instance ``stimer`` requires ``synic``. But as it turned out, for some ancient machine types (e.g. 'pc-i440fx-3.0' or 'pc-q35-3.0') some dependencies are not true. Corresponding checks were removed. * esx: URI encode inventory objects twice Formatting domain XML for domains on an ESX server might fail if corresponding datacenter or datastore contained special characters (e.g. '+'). This is now fixed. * Fix race when checking whether a path is on a shared file system Finding an existing parent of a given path and checking whether it's on a shared file system was not atomic and thus the path could have been misinterpreted as non-shared if it was removed between these two operations. This could cause migration with an emulated TPM device stored on a shared file system to fail with the following bogus error:: Operation not supported: the running swtpm does not support migration with shared storage Enjoy. Jirka

1 0

[PATCH 0/3] apparmor: Separate seclabel generation and profile loading
by Michal Privoznik 14 Jan '26

14 Jan '26

See 3/3 for explanation. Michal Prívozník (3): security: Introduce virSecurityDomainLoadProfile() qemu: Call virSecurityManagerLoadProfile() at the end of qemuProcessPrepareDomain() security_apparmor: Move profile loading into .domainLoadProfile callback src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 7 +++++++ src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 31 +++++++++++++++++++++++-------- src/security/security_driver.h | 4 ++++ src/security/security_manager.c | 13 +++++++++++++ src/security/security_manager.h | 2 ++ src/security/security_stack.c | 15 +++++++++++++++ 8 files changed, 66 insertions(+), 8 deletions(-) -- 2.52.0

1 3

[PATCH] NEWS: Mention shared FS detection race
by Jiri Denemark 14 Jan '26

14 Jan '26

From: Jiri Denemark <jdenemar(a)redhat.com> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- NEWS.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 9fff3173ec..958ce71375 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -96,6 +96,16 @@ v12.0.0 (unreleased) corresponding datacenter or datastore contained special characters (e.g. '+'). This is now fixed. + * Fix race when checking whether a path is on a shared file system + + Finding an existing parent of a given path and checking whether it's on a + shared file system was not atomic and thus the path could have been + misinterpreted as non-shared if it was removed between these two + operations. This could cause migration with an emulated TPM device stored + on a shared file system to fail with the following bogus error:: + + Operation not supported: the running swtpm does not support migration with shared storage + v11.10.0 (2025-12-01) ===================== -- 2.52.0

2 1

[PATCH v5 00/24] util: sync error_report & qemu_log output more closely
by Daniel P. Berrangé 14 Jan '26

14 Jan '26

This series is a tangent that came out of discussion in https://lists.nongnu.org/archive/html/qemu-devel/2025-08/msg00903.html In thinking about adding thread info to error_report, I came to realize we should likely make qemu_log behave consistently with error_report & friends. We already honour '-msg timestamp=on', but don't honour 'guest-name=on' and also don't include the binary name. As an example of the current state, consider mixing error and log output today: - Default context: # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ -d 'trace:qcrypto*' qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55ac6d97f700 dir=fish qcrypto_tls_creds_get_path TLS creds path creds=0x55ac6d97f700 filename=ca-cert.pem path=<none> qemu-system-x86_64: Unable to access credentials fish/ca-cert.pem: No such file or directory - Full context: # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ -d 'trace:qcrypto*' \ -msg guest-name=on,timestamp=on \ -name "fish food" 2025-08-19T20:14:16.791413Z qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55e9a3458d10 dir=fish 2025-08-19T20:14:16.791429Z qcrypto_tls_creds_get_path TLS creds path creds=0x55e9a3458d10 filename=ca-cert.pem path=<none> 2025-08-19T20:14:16.791433Z fish food qemu-system-x86_64: Unable to access credentials fish/ca-cert.pem: No such file or directory And after this series is complete: - Default context: # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ -d 'trace:qcrypto*' qemu-system-x86_64(1184284:main): qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55a24ad5cb30 dir=fish qemu-system-x86_64(1184284:main): qcrypto_tls_creds_get_path TLS creds path creds=0x55a24ad5cb30 filename=ca-cert.pem path=<none> qemu-system-x86_64(1184284:main): Unable to access credentials fish/ca-cert.pem: No such file or directory - Full context: # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ -d 'trace:qcrypto*' \ -msg guest-name=on,timestamp=on \ -name "fish food" 2025-08-19T20:12:50.211823Z [fish food] qemu-system-x86_64(1168876:main): qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x5582183d8760 dir=fish 2025-08-19T20:12:50.211842Z [fish food] qemu-system-x86_64(1168876:main): qcrypto_tls_creds_get_path TLS creds path creds=0x5582183d8760 filename=ca-cert.pem +path=<none> 2025-08-19T20:12:50.211846Z [fish food] qemu-system-x86_64(1168876:main): Unable to access credentials fish/ca-cert.pem: No such file or directory The main things to note: * error_report/warn_report/qemu_log share the same output format and -msg applies to both * -msg debug-threads=on is now unconditionally enabled and thus the param is deprecated & ignored * Thread ID and name are unconditionally enabled * Guest name is surrounded in [...] brackets * The default output lines are typically 15 chars wider given that we always include the thread ID + name now * This takes the liberty of assigning the new file to the existing error-report.c maintainer (Markus) Since splitting it off into message.c instead of putting it all in error-report.c felt slightly nicer. One thing I didn't tackle is making the location info get reported for qemu_log. This is used to give context for error messages when parsing some CLI args, and could be interesting for log messages associated with those same CLI args. Changes in v5: - Remove redundant [] around values in qemu-options.hx - Use g_strlcpy instead of strlcpy - Remove redundant !! around a value that was already bool - Improve the qemu_lock_trylock() API docs to encourage use of fprintf() instead of further qemu_log() calls - Add a qemu_log_trylock_context() counterpart for qemu_log_trylock that includes the message context - Don't scan for \n to determine whether we can output a message context prefix or not. Instead track call depth on qemu_log_trylock() and only output it when the depth was initially zero. This fixes linux-user -strace output formatting which was mangled by v4 - Use fprintf(stderr) instead of error_printf_mon in cases where mon would be NULL - Use fputs/fputc in simple cases where we don't need the full power of fprintf - Use qemu_f{un}lockfile instead of f{un}lockfile - Add -msg thread-info=on|off,program-name=on|off args to allow default message prefixes to be optionally disabled Changes in v4: - Re-architected the way error_vprintf() operates to simplify monitor dependency - Fixed the move of error_vprintf from monitor.c to error-report.c so that unit tests can still get a stub to capture messages to g_test_message - Simplify changes to vreport() to avoid passing around function pointers - Add locking of stderr to vreport() to serialize incremental output - Fix thread naming logic changes on Windows - Change deprecation warning messages Changes in v3: - Stop formatting a string in qmessage_context, instead output directly to a "FILE *" stream - Fix pre-existing bug interleaving qemu_log and vreport when the trace 'log' backend has mutex probes enabled Changes in v2: - Re-use existing qemu_get_thread_id rather than re-inventing it as qemu_thread_get_id. - Expose qemu_thread_set_name and use it from all locations needing to set thread names - Fix qemu_log() to skip context prefix when emitting a log message in fragments across multiple calls - Skip allocating memory for empty context messages - Fix leak in win32 impl of qemu_thread_get_name - Use g_strlcpy where possible Daniel P. Berrangé (24): qemu-options: remove extraneous [] around arg values include: define constant for early constructor priority monitor: initialize global data from a constructor system: unconditionally enable thread naming util: expose qemu_thread_set_name audio: make jackaudio use qemu_thread_set_name util: set the name for the 'main' thread util: add API to fetch the current thread name util: introduce some API docs for logging APIs util: avoid repeated prefix on incremental qemu_log calls ui/vnc: remove use of error_printf_unless_qmp() monitor: remove redundant error_[v]printf_unless_qmp monitor: refactor error_vprintf() monitor: move error_vprintf back to error-report.c monitor: introduce monitor_cur_is_hmp() helper util: don't skip error prefixes when QMP is active util: fix interleaving of error & trace output util: fix interleaving of error prefixes util: introduce common helper for error-report & log code util: convert error-report & log to message API for timestamp util: add support for formatting a workload name in messages util: add support for formatting a program name in messages util: add support for formatting thread info in messages util: add brackets around guest name in message context MAINTAINERS | 2 + audio/jackaudio.c | 30 +++++-- docs/about/deprecated.rst | 7 ++ include/monitor/monitor.h | 4 +- include/qemu/compiler.h | 8 ++ include/qemu/error-report.h | 4 - include/qemu/log-for-trace.h | 17 +++- include/qemu/log.h | 38 +++++++++ include/qemu/message.h | 40 +++++++++ include/qemu/thread.h | 3 +- meson.build | 21 +++++ monitor/monitor.c | 61 +++++--------- qemu-options.hx | 121 ++++++++++++++------------- rust/util/src/log.rs | 6 ++ storage-daemon/qemu-storage-daemon.c | 6 ++ stubs/error-printf.c | 23 ----- stubs/meson.build | 1 - stubs/monitor-core.c | 20 ++++- system/vl.c | 49 +++++++++-- tests/qemu-iotests/041 | 2 +- tests/qemu-iotests/common.filter | 2 +- tests/unit/test-error-report.c | 6 +- tests/unit/test-util-sockets.c | 1 + ui/vnc.c | 14 ++-- util/error-report.c | 97 ++++++++++++--------- util/log.c | 47 ++++++----- util/meson.build | 1 + util/message.c | 51 +++++++++++ util/qemu-thread-posix.c | 77 +++++++++++------ util/qemu-thread-win32.c | 87 +++++++++++++------ 30 files changed, 580 insertions(+), 266 deletions(-) create mode 100644 include/qemu/message.h delete mode 100644 stubs/error-printf.c create mode 100644 util/message.c -- 2.52.0

4 69

[PATCH] NEWS: Document features/improvements/bug fixes I've participated in
by Michal Privoznik 14 Jan '26

14 Jan '26

From: Michal Privoznik <mprivozn(a)redhat.com> There are some features/improvements/bug fixes I've either contributed or reviewed/merged. Document them for upcoming release. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index ce55445695..9fff3173ec 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -52,6 +52,14 @@ v12.0.0 (unreleased) Notably, issues that were preventing the use of firmware designed for confidential VMs on aarch64 have been addressed. + * network: Introduce port for DNS forwarder + + In the ``<dns/>`` section of network configuration users can set up + forwarding of DNS requests to custom DNS servers. These are specified using + ``addr`` attribute. But configuring port wasn't possible, until now. New + ``port`` attribute is introduced, which allows overriding the default DNS + port for given address. + * **Bug fixes** * qemu: Fix startup of VMs with more than ~25 external snapshots @@ -66,6 +74,28 @@ v12.0.0 (unreleased) on a shared filesystem on the destination but on the source it's either on a different NFS or unshared completely. + * qemu: Treat memory device source nodemask as strict NUMA policy + + Until now, the NUMA policy for ``<memory/>`` devices was taken either from + the guest NUMA node or ``<numatune/>``. But this may lead to discrepancies, + where the memory device is configured to bind to a set of host NUMA nodes, + but the guest NUMA node is to bind to a disjoint set of host NUMA nodes. To + resolve this, specifying ``<nodemask/>`` for a memory device implies + ``strict`` policy. + + * qemu: Relax validation of some hyperv features + + Since 11.9.0 release, libvirt performs dependency checks for hyperv + features, for instance ``stimer`` requires ``synic``. But as it turned out, + for some ancient machine types (e.g. 'pc-i440fx-3.0' or 'pc-q35-3.0') some + dependencies are not true. Corresponding checks were removed. + + * esx: URI encode inventory objects twice + + Formatting domain XML for domains on an ESX server might fail if + corresponding datacenter or datastore contained special characters (e.g. + '+'). This is now fixed. + v11.10.0 (2025-12-01) ===================== -- 2.52.0

2 1

Re: [PATCH] apparmor: Upgrade ABI version to 4.0, explicitly enable user namespace creation
by Andrea Bolognani 13 Jan '26

13 Jan '26

[adding libvirt devel list] On Sat, Jan 10, 2026 at 04:14:30PM +0100, Stefano Brivio wrote: > In the 3.0 AppArmor ABI version we currently use, user namespace rules > are not supported, and, as long as we load confined profiles, those > implicitly allow creation of user namespaces. > > However, ABI version 4.0 introduces rules for user namespaces, and if > we don't specify any, we can't create user namespaces, see: > > https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction > > This wouldn't affect us in general, given that we're using the 3.0 > ABI, but libvirt's policy uses 4.0 instead, and if our abstractions > are used from there, no matter what ABI policy version we declare, > rules for user namespace creation now match ABI policy version 4.0. AFAICT libvirt's policy doesn't explicitly declares any ABI version, so how does that work? Is the most recent one being used in that case? Assuming that's the case, how far back will that result in ABI 4.0 being the effective one? It looks like Debian only got AppArmor 4+ in March of last year. Do we want to make the ABI version explicit in libvirt's policy? If so, should we stick with 3.0 for maximum compatibility? > As a result, when libvirtd runs as root, and its profile includes > passt's abstraction, cf. commit 66769c2de825 ("apparmor: Workaround > for unconfined libvirtd when triggered by unprivileged user"), passt > can't detach user namespaces and will fail to start, as reported by > Niklas: > > ERROR internal error: Child process (passt --one-off --socket /run/libvirt/qemu/passt/1-haos-net0.socket --pid /run/libvirt/qemu/passt/1-haos-net0-passt.pid --tcp-ports 8123) unexpected exit status 1: Multiple interfaces with IPv6 routes, picked first > UNIX domain socket bound at /run/libvirt/qemu/passt/1-haos-net0.socket > Couldn't create user namespace: Permission denied > > This isn't a problem with libvirtd running as regular user, because > in that case, as a workaround, passt currently runs under its own > profile, not as a libvirtd subprofile (see commit referenced above). > > Given that ABI 4.0 has been around for a while, being introduced in > July 2023, finally take the step to upgrade to it and explicitly > enable user namespace creation. > > No further changes are needed in the existing policies to match new > features introduced in AppArmor 4.0. > > Reported-by: Niklas Edmundsson <nikke(a)accum.se> > Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124801 > Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> > --- > contrib/apparmor/abstractions/passt | 3 ++- > contrib/apparmor/abstractions/pasta | 2 +- > contrib/apparmor/usr.bin.passt | 2 +- > contrib/apparmor/usr.bin.passt-repair | 2 +- > contrib/apparmor/usr.bin.pasta | 2 +- > 5 files changed, 6 insertions(+), 5 deletions(-) > > diff --git a/contrib/apparmor/abstractions/passt b/contrib/apparmor/abstractions/passt > index 25b2ea8..0ffadaf 100644 > --- a/contrib/apparmor/abstractions/passt > +++ b/contrib/apparmor/abstractions/passt > @@ -11,7 +11,7 @@ > # Copyright (c) 2022 Red Hat GmbH > # Author: Stefano Brivio <sbrivio(a)redhat.com> > > - abi <abi/3.0>, > + abi <abi/4.0>, > > include <abstractions/base> > > @@ -24,6 +24,7 @@ > capability setpcap, > capability net_admin, > capability sys_ptrace, > + userns, > > / r, # isolate_prefork(), isolation.c > mount options=(rw, runbindable) -> /, > diff --git a/contrib/apparmor/abstractions/pasta b/contrib/apparmor/abstractions/pasta > index 9f73bee..251d4a2 100644 > --- a/contrib/apparmor/abstractions/pasta > +++ b/contrib/apparmor/abstractions/pasta > @@ -11,7 +11,7 @@ > # Copyright (c) 2022 Red Hat GmbH > # Author: Stefano Brivio <sbrivio(a)redhat.com> > > - abi <abi/3.0>, > + abi <abi/4.0>, > > include <abstractions/passt> > > diff --git a/contrib/apparmor/usr.bin.passt b/contrib/apparmor/usr.bin.passt > index 62a4514..c123a86 100644 > --- a/contrib/apparmor/usr.bin.passt > +++ b/contrib/apparmor/usr.bin.passt > @@ -11,7 +11,7 @@ > # Copyright (c) 2022 Red Hat GmbH > # Author: Stefano Brivio <sbrivio(a)redhat.com> > > -abi <abi/3.0>, > +abi <abi/4.0>, > > include <tunables/global> > > diff --git a/contrib/apparmor/usr.bin.passt-repair b/contrib/apparmor/usr.bin.passt-repair > index 901189d..23ff1ce 100644 > --- a/contrib/apparmor/usr.bin.passt-repair > +++ b/contrib/apparmor/usr.bin.passt-repair > @@ -11,7 +11,7 @@ > # Copyright (c) 2025 Red Hat GmbH > # Author: Stefano Brivio <sbrivio(a)redhat.com> > > -abi <abi/3.0>, > +abi <abi/4.0>, > > #include <tunables/global> > > diff --git a/contrib/apparmor/usr.bin.pasta b/contrib/apparmor/usr.bin.pasta > index 2483968..56b5024 100644 > --- a/contrib/apparmor/usr.bin.pasta > +++ b/contrib/apparmor/usr.bin.pasta > @@ -11,7 +11,7 @@ > # Copyright (c) 2022 Red Hat GmbH > # Author: Stefano Brivio <sbrivio(a)redhat.com> > > -abi <abi/3.0>, > +abi <abi/4.0>, > > include <tunables/global> > > -- > 2.43.0 >

2 3