May 2026 - Devel - libvirt List Archives

Reboot events
by Marek Marczykowski-Górecki 10 Jun '26

10 Jun '26

Hi, What should be the events fired when VM requests reboot? Currently the libxl driver fires VIR_DOMAIN_EVENT_STOPPED, and if on_reboot is set to restart, it fires VIR_DOMAIN_EVENT_STARTED next to it (in fact, _STARTED gets fired before _STOPPED here, but it's another issue). What I'd like to do, is to set on_reboot to destroy, but still receive information whether VM requested just shutdown or reboot, so my application (qubesd daemon) can act on it. I see VIR_DOMAIN_EVENT_ID_REBOOT, but it's not used in libxl. What's the intended semantic of it? Should it be fired next to the lifecycle event (VIR_DOMAIN_EVENT_STOPPED/VIR_DOMAIN_EVENT_STARTED)? Or instead? Is it okay to fire it even if on_reboot=destroy? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

2 3

[PATCH] lxc: truncate LOOP_GET_STATUS64.lo_file_name for long loop backing paths
by Radoslaw Smigielski 10 Jun '26

10 Jun '26

LXC domains with long file-backed filesystem path fail to start when the backing image path is longer than LO_NAME_SIZE (64 bytes, 63 characters plus NUL). When long file path is passed, virFileLoopDeviceAssociate() -> virStrcpy() fails and user gets missleading error and domain fails to start. Example: <filesystem type='file' accessmode='passthrough'> <driver type='loop' format='raw'/> <source file='/root/demoaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.raw'/> <target dir='/'/> </filesystem> To match losetup behavior we copy the path with virStrcpy() and allow truncation of lo_file_name only if needed, while still calling open() on the unchanged path. Finally log VIR_WARN when the path is expected to be truncated. But still report VIR_ERR_INTERNAL_ERROR for all other virStrcpy() failures. Fixes: https://gitlab.com/libvirt/libvirt/-/work_items/63 Signed-off-by: Radoslaw Smigielski <rsmigiel(a)redhat.com> --- src/util/virfile.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/src/util/virfile.c b/src/util/virfile.c index a0c6cb804862..ae33deb8d223 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -995,11 +995,18 @@ int virFileLoopDeviceAssociate(const char *file, lo.lo_flags = LO_FLAGS_AUTOCLEAR; - /* Set backing file name for LOOP_GET_STATUS64 queries */ + /* lo_file_name is loop device name, max length is LO_NAME_SIZE bytes. + * Truncate loop device name if file path is longer than LO_NAME_SIZE, + * and still use the full path to open backing file. */ if (virStrcpy((char *) lo.lo_file_name, file, LO_NAME_SIZE) < 0) { - virReportSystemError(errno, - _("Unable to set backing file %1$s"), file); - goto cleanup; + if (strlen(file) >= LO_NAME_SIZE) { + VIR_WARN("Loop backing device name %s truncated to %d bytes.", + file, LO_NAME_SIZE); + } else { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Unable to set loop lo_file_name for %1$s"), file); + goto cleanup; + } } if ((fsfd = open(file, O_RDWR)) < 0) { -- 2.54.0

3 7

[PATCH] virt-aa-helper: Prevent spurious denials for AoE disks
by PUSHKARAJ PATIL 10 Jun '26

10 Jun '26

virt-aa-helper calls virStorageSourceGetMetadata before adding a disk path to a domain's apparmor profile. This probes the device and may trigger an AppArmor denial when the disk is an AoE device under /dev/etherd/. The return value of virStorageSourceGetMetadata is not checked, so the denial has no functional impact but results in noisy dmesg logs. Explicitly deny read access to /dev/etherd/e*.* in the virt-aa-helper profile to avoid these spurious denials. Co-Authored-By: Peter Krempa <pkrempa(a)redhat.com> Signed-off-by: PUSHKARAJ PATIL <pushkaraj.patil(a)in.ibm.com> --- src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in | 1 + 1 file changed, 1 insertion(+) diff --git a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in index e209a8bff7..1f1b80b9f9 100644 --- a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in +++ b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in @@ -38,6 +38,7 @@ profile virt-aa-helper @libexecdir@/virt-aa-helper { deny /dev/dm-* r, deny /dev/drbd[0-9]* r, deny /dev/dasd* r, + deny /dev/etherd/e*.* r, deny /dev/nvme* r, deny /dev/zd[0-9]* r, deny /dev/mapper/ r, -- 2.50.1 (Apple Git-155)

3 2

[PATCH 1/1] qemu: Inherit SCSI controller model from existing peers
by Denis V. Lunev 09 Jun '26

09 Jun '26

virDomainDefMaybeAddHostdevSCSIcontroller() already inherits the model of an existing SCSI controller when auto-adding peers driven by a hostdev whose drive address overflows the highest declared idx. virDomainDefAddDiskControllersForType(), called for the disk-driven analogue, does not -- it passes model=-1 unconditionally. The unspecified peers then arrive at qemuDomainDefaultSCSIControllerModel() and pick up whichever model the capability cascade settles on (typically lsilogic). A user-declared virtio-scsi controller at idx 0 ends up alongside auto-added lsilogic peers at idx 1+. Plug the same inheritance into qemuDomainDefaultSCSIControllerModel() itself so it covers both the disk-driven path and any other caller that arrives with an unresolved model. The function already prefers architectural defaults (PSeries, ARM virt, RISC-V virt, LoongArch, s390, built-in ESP) over capabilities; peer inheritance slots in just before the capability cascade. A virtio-scsi domain keeps the new peers as virtio-scsi; an lsisas1068 domain stays lsisas1068; a fresh domain with no SCSI controllers still gets the cap-driven default. controller-scsi-auto, the only existing test that flows through this helper, is unaffected (it has no peers to inherit from). controller-scsi-inherit-model covers the new behavior. Signed-off-by: Denis V. Lunev <den(a)openvz.org> --- src/qemu/qemu_domain.c | 15 +++++++ ...ller-scsi-inherit-model.x86_64-latest.args | 38 ++++++++++++++++ ...oller-scsi-inherit-model.x86_64-latest.xml | 45 +++++++++++++++++++ .../controller-scsi-inherit-model.xml | 20 +++++++++ tests/qemuxmlconftest.c | 1 + 5 files changed, 119 insertions(+) create mode 100644 tests/qemuxmlconfdata/controller-scsi-inherit-model.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/controller-scsi-inherit-model.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/controller-scsi-inherit-model.xml diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 84c8645259..21f2641521 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4289,6 +4289,8 @@ virDomainControllerModelSCSI qemuDomainDefaultSCSIControllerModel(const virDomainDef *def, virQEMUCaps *qemuCaps) { + size_t i; + /* For machine types with built-in SCSI controllers, the choice * of model is obvious */ if (qemuDomainHasBuiltinESP(def)) @@ -4305,6 +4307,19 @@ qemuDomainDefaultSCSIControllerModel(const virDomainDef *def, if (qemuDomainIsPSeries(def)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI; + /* Inherit the model from any peer SCSI controller already + * resolved on this domain. */ + for (i = 0; i < def->ncontrollers; i++) { + const virDomainControllerDef *peer = def->controllers[i]; + + if (peer->type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI) + continue; + if (peer->model == VIR_DOMAIN_CONTROLLER_MODEL_SCSI_DEFAULT || + peer->model == VIR_DOMAIN_CONTROLLER_MODEL_SCSI_AUTO) + continue; + return peer->model; + } + /* If there is no preference, base the choice on device * availability. In this case, lsilogic is favored over * virtio-scsi for backwards compatibility reasons */ diff --git a/tests/qemuxmlconfdata/controller-scsi-inherit-model.x86_64-latest.args b/tests/qemuxmlconfdata/controller-scsi-inherit-model.x86_64-latest.args new file mode 100644 index 0000000000..2bcd9ed92f --- /dev/null +++ b/tests/qemuxmlconfdata/controller-scsi-inherit-model.x86_64-latest.args @@ -0,0 +1,38 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/var/lib/libvirt/qemu/domain--1-guest \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-guest/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-guest/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-guest/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=guest,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-guest/master-key.aes"}' \ +-machine pc,usb=off,dump-guest-core=off,memory-backend=pc.ram,acpi=off \ +-accel tcg \ +-cpu qemu64 \ +-m size=219136k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":224395264}' \ +-overcommit mem-lock=off \ +-smp 8,sockets=8,cores=1,threads=1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=@mon-fd@,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device '{"driver":"virtio-scsi-pci","id":"scsi0","bus":"pci.0","addr":"0x2"}' \ +-device '{"driver":"virtio-scsi-pci","id":"scsi1","bus":"pci.0","addr":"0x3"}' \ +-device '{"driver":"virtio-scsi-pci","id":"scsi2","bus":"pci.0","addr":"0x4"}' \ +-device '{"driver":"virtio-scsi-pci","id":"scsi3","bus":"pci.0","addr":"0x5"}' \ +-blockdev '{"driver":"file","filename":"/tmp/data.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage"}' \ +-device '{"driver":"scsi-hd","bus":"scsi3.0","channel":0,"scsi-id":0,"lun":3,"device_id":"drive-scsi3-0-0-3","drive":"libvirt-1-format","id":"scsi3-0-0-3","bootindex":1}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxmlconfdata/controller-scsi-inherit-model.x86_64-latest.xml b/tests/qemuxmlconfdata/controller-scsi-inherit-model.x86_64-latest.xml new file mode 100644 index 0000000000..b971c89a1b --- /dev/null +++ b/tests/qemuxmlconfdata/controller-scsi-inherit-model.x86_64-latest.xml @@ -0,0 +1,45 @@ +<domain type='qemu'> + <name>guest</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>8</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <cpu mode='custom' match='exact' check='none'> + <model fallback='forbid'>qemu64</model> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/tmp/data.qcow2'/> + <target dev='sdy' bus='scsi'/> + <address type='drive' controller='3' bus='0' target='0' unit='3'/> + </disk> + <controller type='scsi' index='0' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </controller> + <controller type='scsi' index='1' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </controller> + <controller type='scsi' index='2' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </controller> + <controller type='scsi' index='3' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <controller type='usb' index='0' model='none'/> + <controller type='pci' index='0' model='pci-root'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <audio id='1' type='none'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxmlconfdata/controller-scsi-inherit-model.xml b/tests/qemuxmlconfdata/controller-scsi-inherit-model.xml new file mode 100644 index 0000000000..45e96b7ea1 --- /dev/null +++ b/tests/qemuxmlconfdata/controller-scsi-inherit-model.xml @@ -0,0 +1,20 @@ +<domain type='qemu'> + <name>guest</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <vcpu placement='static'>8</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + </os> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='scsi' index='0' model='virtio-scsi'/> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/tmp/data.qcow2'/> + <target dev='sdy' bus='scsi'/> + </disk> + <controller type='usb' index='0' model='none'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c index 8e0f4bcb4f..7a441c1fa2 100644 --- a/tests/qemuxmlconftest.c +++ b/tests/qemuxmlconftest.c @@ -1690,6 +1690,7 @@ mymain(void) DO_TEST_CAPS_LATEST_PARSE_ERROR("disk-scsi-product-length"); DO_TEST_CAPS_LATEST("controller-virtio-scsi"); DO_TEST_CAPS_LATEST("controller-scsi-auto"); + DO_TEST_CAPS_LATEST("controller-scsi-inherit-model"); DO_TEST_FULL("controller-scsi-default-unavailable", ".x86_64-latest", ARG_CAPS_ARCH, "x86_64", ARG_CAPS_VER, "latest", -- 2.51.0

3 2

[PATCH v3 0/2] allow migrations with the ext transport
by Mark Cave-Ayland 09 Jun '26

09 Jun '26

[MCA: I've now adopted these patches from Sergey] Hello, I have a use case for live-migration where the socket of the destination libvirtd is proxied by an mTLS WebSocket proxy. Since there is no WebSocket support in Libvirt, I've decided to use the existing ext transport and point it to a proxy binary on the source host of live-migration. While doing that, I've discovered a couple of roadblocks: 1. There is no way of passing cmdline arguments to the ext program 2. Live-migrations using ext transport fail localhost checks This short series addresses those limitations. v2 -> v3: - fix passing of extArgs v1 -> v2: - new way of passing argv Sergey Dyasli (2): remote: allow passing argv to the ext transport remote: allow migrations with the ext transport src/libvirt-domain.c | 8 +++++--- src/remote/remote_driver.c | 30 ++++++++++++++++++++++++++---- src/util/viruri.c | 32 ++++++++++++++++++++++++++++++++ src/util/viruri.h | 2 ++ 4 files changed, 65 insertions(+), 7 deletions(-) -- 2.43.0

2 5

[PATCH RFC 0/6] Add qemu-vnc support
by marcandre.lureau＠redhat.com 04 Jun '26

04 Jun '26

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, This series allows to run the QEMU VNC server in a standalone process. The qemu-vnc binary is aimed to be released with QEMU 11.1. It is still being reviewed (https://patchew.org/QEMU/20260410-qemu-vnc-v2-0-231416f76dc3@redhat.com/) The standalone VNC activates automatically when a domain has both <graphics type='dbus'/> (bus mode) and <graphics type='vnc'/>, and the qemu-vnc binary is available. Comments welcome! Marc-André Lureau (6): qemu: add standalone VNC state directory qemu: add qemu-vnc configuration qemu: add qemu-vnc helper unit qemu: integrate standalone VNC in domain lifecycle qemu: wire up standalone VNC in driver APIs qemu: add tests for standalone VNC graphics po/POTFILES | 1 + src/qemu/libvirtd_qemu.aug | 1 + src/qemu/meson.build | 1 + src/qemu/qemu.conf.in | 8 + src/qemu/qemu_command.c | 2 + src/qemu/qemu_conf.c | 8 + src/qemu/qemu_conf.h | 2 + src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 2 + src/qemu/qemu_driver.c | 68 ++- src/qemu/qemu_extdevice.c | 13 +- src/qemu/qemu_hotplug.c | 12 + src/qemu/qemu_process.c | 40 +- src/qemu/qemu_vnc.c | 407 ++++++++++++++++++ src/qemu/qemu_vnc.h | 41 ++ src/qemu/test_libvirtd_qemu.aug.in | 1 + ...hics-vnc-standalone-p2p.x86_64-latest.args | 34 ++ ...phics-vnc-standalone-p2p.x86_64-latest.xml | 40 ++ .../graphics-vnc-standalone-p2p.xml | 39 ++ ...s-vnc-standalone-socket.x86_64-latest.args | 33 ++ ...cs-vnc-standalone-socket.x86_64-latest.xml | 40 ++ .../graphics-vnc-standalone-socket.xml | 40 ++ ...graphics-vnc-standalone.x86_64-latest.args | 33 ++ .../graphics-vnc-standalone.x86_64-latest.xml | 40 ++ .../graphics-vnc-standalone.xml | 40 ++ tests/qemuxmlconftest.c | 4 + tests/testutilsqemu.c | 9 + 27 files changed, 950 insertions(+), 10 deletions(-) create mode 100644 src/qemu/qemu_vnc.c create mode 100644 src/qemu/qemu_vnc.h create mode 100644 tests/qemuxmlconfdata/graphics-vnc-standalone-p2p.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/graphics-vnc-standalone-p2p.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/graphics-vnc-standalone-p2p.xml create mode 100644 tests/qemuxmlconfdata/graphics-vnc-standalone-socket.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/graphics-vnc-standalone-socket.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/graphics-vnc-standalone-socket.xml create mode 100644 tests/qemuxmlconfdata/graphics-vnc-standalone.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/graphics-vnc-standalone.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/graphics-vnc-standalone.xml -- 2.53.0

3 10

[PATCH v2 00/16] qemu: Fix CPU feature reporting on AMD CPUs
by Jiri Denemark 02 Jun '26

02 Jun '26

See the last patch for detailed description and individual patches for specific changes in v2. Important changes in version 2: - tests - the functionality uses a new flag for virConnectGetDomainCapabilities Jiri Denemark (16): cpu_conf: Introduce virCPUDefSortFeatures qemu_capabilities: Split virQEMUCapsFillDomainCPUCaps qemu: Move domain caps flags handling to virQEMUCapsFillDomainCPUHostModel qemu_capabilities: Always sort features in host-model CPU qemu_capabilities: Use g_autoptr in virQEMUCapsInitHostCPUModel qemu_capabilities: Split conditions in virQEMUCapsInitHostCPUModel qemu_capabilities: Cache expanded CPU domaincapstest: Test EXPAND_CPU_FEATURES flag util: Publish and mock virHostCPUGetMSRFromKVM cpu_x86: Introduce virCPUx86DataAddMSR cpu: Introduce virCPUUpdateFeatures Fix documentation of VIR_CONNECT_GET_DOMAIN_CAPABILITIES_EXPAND_CPU_FEATURES Introduce VIR_CONNECT_GET_DOMAIN_CAPABILITIES_SUPPORTED_CPU_FEATURES flag virsh: Add --supported-cpu-features option for domcapabilities domaincapstest: Test SUPPORTED_CPU_FEATURES flag qemu_capabilities: Fix domain capabilities on AMD CPUs docs/manpages/virsh.rst | 12 +- include/libvirt/libvirt-domain.h | 3 + src/conf/cpu_conf.c | 20 + src/conf/cpu_conf.h | 3 + src/cpu/cpu.c | 48 +- src/cpu/cpu.h | 12 + src/cpu/cpu_x86.c | 54 +- src/cpu/cpu_x86.h | 4 + src/libvirt-domain.c | 14 +- src/libvirt_private.syms | 4 + src/qemu/qemu_capabilities.c | 214 +- src/qemu/qemu_capabilities.h | 6 +- src/qemu/qemu_conf.c | 6 +- src/qemu/qemu_conf.h | 3 +- src/qemu/qemu_driver.c | 18 +- src/util/virhostcpu.c | 16 +- src/util/virhostcpu.h | 3 + ...qemu_10.0.0-q35.x86_64+amdsev-expanded.xml | 1123 ++++++++ ...emu_10.0.0-q35.x86_64+amdsev-supported.xml | 1015 +++++++ .../qemu_10.0.0-q35.x86_64+amdsev.xml | 48 +- .../qemu_10.0.0-q35.x86_64-expanded.xml | 1979 ++++++++++++++ .../qemu_10.0.0-q35.x86_64-supported.xml | 1903 ++++++++++++++ .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 50 +- .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 60 +- .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 60 +- tests/domaincapsdata/qemu_10.0.0.s390x.xml | 94 +- .../qemu_10.0.0.x86_64+amdsev.xml | 48 +- tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 50 +- ...mu_10.1.0-q35.x86_64+inteltdx-expanded.xml | 1250 +++++++++ ...u_10.1.0-q35.x86_64+inteltdx-supported.xml | 1064 ++++++++ .../qemu_10.1.0-q35.x86_64+inteltdx.xml | 56 +- .../qemu_10.1.0-q35.x86_64-expanded.xml | 2328 +++++++++++++++++ .../qemu_10.1.0-q35.x86_64-supported.xml | 2259 ++++++++++++++++ .../domaincapsdata/qemu_10.1.0-q35.x86_64.xml | 40 +- .../qemu_10.1.0-tcg.x86_64+inteltdx.xml | 66 +- .../domaincapsdata/qemu_10.1.0-tcg.x86_64.xml | 66 +- tests/domaincapsdata/qemu_10.1.0.s390x.xml | 106 +- .../qemu_10.1.0.x86_64+inteltdx.xml | 56 +- tests/domaincapsdata/qemu_10.1.0.x86_64.xml | 40 +- .../qemu_10.2.0-q35.x86_64+mshv-expanded.xml | 237 ++ .../qemu_10.2.0-q35.x86_64+mshv-supported.xml | 237 ++ .../qemu_10.2.0-q35.x86_64-expanded.xml | 1483 +++++++++++ .../qemu_10.2.0-q35.x86_64-supported.xml | 1365 ++++++++++ .../domaincapsdata/qemu_10.2.0-q35.x86_64.xml | 24 +- .../qemu_10.2.0-tcg.x86_64+mshv.xml | 66 +- .../domaincapsdata/qemu_10.2.0-tcg.x86_64.xml | 66 +- tests/domaincapsdata/qemu_10.2.0.x86_64.xml | 24 +- .../qemu_11.0.0-q35.x86_64+sgx-expanded.xml | 1865 +++++++++++++ .../qemu_11.0.0-q35.x86_64+sgx-supported.xml | 1747 +++++++++++++ .../qemu_11.0.0-q35.x86_64+sgx.xml | 24 +- .../qemu_11.0.0-q35.x86_64-expanded.xml | 1856 +++++++++++++ .../qemu_11.0.0-q35.x86_64-supported.xml | 1738 ++++++++++++ .../domaincapsdata/qemu_11.0.0-q35.x86_64.xml | 24 +- .../qemu_11.0.0-tcg.x86_64+sgx.xml | 66 +- .../domaincapsdata/qemu_11.0.0-tcg.x86_64.xml | 66 +- tests/domaincapsdata/qemu_11.0.0.s390x.xml | 106 +- .../domaincapsdata/qemu_11.0.0.x86_64+sgx.xml | 24 +- tests/domaincapsdata/qemu_11.0.0.x86_64.xml | 24 +- .../qemu_7.2.0-hvf.x86_64+hvf.xml | 36 +- .../qemu_7.2.0-q35.x86_64-expanded.xml | 1257 +++++++++ .../qemu_7.2.0-q35.x86_64-supported.xml | 1181 +++++++++ .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 36 +- .../qemu_7.2.0-tcg.x86_64+hvf.xml | 46 +- .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 46 +- tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 36 +- .../qemu_8.0.0-q35.x86_64-expanded.xml | 1366 ++++++++++ .../qemu_8.0.0-q35.x86_64-supported.xml | 1290 +++++++++ .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 36 +- .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 54 +- tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 36 +- .../qemu_8.1.0-q35.x86_64-expanded.xml | 1624 ++++++++++++ .../qemu_8.1.0-q35.x86_64-supported.xml | 1548 +++++++++++ .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 38 +- .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 60 +- tests/domaincapsdata/qemu_8.1.0.s390x.xml | 62 +- tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 38 +- .../qemu_8.2.0-q35.x86_64-expanded.xml | 1626 ++++++++++++ .../qemu_8.2.0-q35.x86_64-supported.xml | 1550 +++++++++++ .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 40 +- .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 58 +- tests/domaincapsdata/qemu_8.2.0.s390x.xml | 62 +- tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 40 +- .../qemu_9.0.0-q35.x86_64-expanded.xml | 1627 ++++++++++++ .../qemu_9.0.0-q35.x86_64-supported.xml | 1551 +++++++++++ .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 40 +- .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 62 +- tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 40 +- .../qemu_9.1.0-q35.x86_64-expanded.xml | 1763 +++++++++++++ .../qemu_9.1.0-q35.x86_64-supported.xml | 1687 ++++++++++++ .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 48 +- .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 60 +- tests/domaincapsdata/qemu_9.1.0.s390x.xml | 94 +- tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 48 +- .../qemu_9.2.0-q35.x86_64+amdsev-expanded.xml | 1003 +++++++ ...qemu_9.2.0-q35.x86_64+amdsev-supported.xml | 895 +++++++ .../qemu_9.2.0-q35.x86_64+amdsev.xml | 48 +- .../qemu_9.2.0-q35.x86_64-expanded.xml | 1821 +++++++++++++ .../qemu_9.2.0-q35.x86_64-supported.xml | 1745 ++++++++++++ .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 50 +- .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 60 +- .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 60 +- tests/domaincapsdata/qemu_9.2.0.s390x.xml | 94 +- .../qemu_9.2.0.x86_64+amdsev.xml | 48 +- tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 50 +- tests/domaincapstest.c | 56 +- tests/qemucpumock.c | 22 + tools/virsh-host.c | 7 + 107 files changed, 48819 insertions(+), 1569 deletions(-) create mode 100644 tests/domaincapsdata/qemu_10.0.0-q35.x86_64+amdsev-expanded.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0-q35.x86_64+amdsev-supported.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0-q35.x86_64+inteltdx-expanded.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0-q35.x86_64+inteltdx-supported.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0-q35.x86_64+mshv-expanded.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0-q35.x86_64+mshv-supported.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_11.0.0-q35.x86_64+sgx-expanded.xml create mode 100644 tests/domaincapsdata/qemu_11.0.0-q35.x86_64+sgx-supported.xml create mode 100644 tests/domaincapsdata/qemu_11.0.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_11.0.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_7.2.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_7.2.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_8.0.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_8.0.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_8.1.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_8.1.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_8.2.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_8.2.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_9.0.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_9.0.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_9.1.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_9.1.0-q35.x86_64-supported.xml create mode 100644 tests/domaincapsdata/qemu_9.2.0-q35.x86_64+amdsev-expanded.xml create mode 100644 tests/domaincapsdata/qemu_9.2.0-q35.x86_64+amdsev-supported.xml create mode 100644 tests/domaincapsdata/qemu_9.2.0-q35.x86_64-expanded.xml create mode 100644 tests/domaincapsdata/qemu_9.2.0-q35.x86_64-supported.xml -- 2.54.0

2 32

[RFC patch 00/17] qemu: Unlock VM object while accessing storage (in certain cases)
by Peter Krempa 29 May '26

29 May '26

If a thread is blocked while holding the VM lock, other operations become impossible. This is due to the fact that both listing domains of a daemon requires locking the objects (for accessing the name/uuid/id, but also for filtering). Similarly even if a user has a virDomainPtr instace already looked up invoking an API results into trying to fetch a locked VM object instance which will simply block. This patchset is a path for being able to identify stuff which colud block and similarly to how monitor is accessed unlocking @vm while doing such operation. To show how it's used, we use it when probing disk size data. The patchset obviously needed to refactor stuff first for this to happen. Peter Krempa (17): storage_source: Don't modify @src in 'virStorageSourceUpdatePhysicalSize' virStorageSourceGetSize: Return also 'allocation' value if needed virStorageFileProbeFormatFromBuf: Allow NULL 'path' argument virStorageFileProbeGetMetadata: Allow NULL 'meta->path' virStorageSourceGetMetadataFromBuf: Refactor cleanup virStorageSourceUpdateCapacity: Factor out size probing to 'virStorageSourceProbeCapacityFromBuf' qemu: domain: Introduce 'qemuDomainStorageSourceProbeSize' qemuDomainGetBlockInfo: Rewrite to 'qemuDomainStorageSourceProbeSize' qemuDomainGetStatsOneBlock: Rewrite to 'qemuDomainStorageSourceProbeSize' qemuMigrationDstPrepareStorage: Rewrite to 'qemuDomainStorageSourceProbeSize' qemuDomainBlockResize: Rewrite to 'qemuDomainStorageSourceProbeSize' qemu: domain: Remove 'qemuDomainStorageUpdatePhysical' qemuDomainGetStatsOneBlockFallback: Rewrite using 'qemuDomainStorageSourceProbeSize' qemuDomainGetBlockInfo: Rewrite using 'qemuDomainStorageSourceProbeSize' qemu: domain: Fix coding style of domain object locking helpers qemu: domain: Introduce APIs for unlocking domain object during potentially long running operations qemuDomainStorageSourceProbeSize: Yield domain object while accessing storage src/libvirt_private.syms | 3 +- src/qemu/qemu_domain.c | 140 ++++++++++++++++++++++--- src/qemu/qemu_domain.h | 19 +++- src/qemu/qemu_driver.c | 143 +++++++------------------- src/qemu/qemu_migration.c | 5 +- src/storage_file/storage_file_probe.c | 20 +++- src/storage_file/storage_source.c | 98 +++++++++++++----- src/storage_file/storage_source.h | 16 ++- 8 files changed, 279 insertions(+), 165 deletions(-) -- 2.54.0

1 17

KVM Forum 2026: Call For Presentations
by Peter Maydell 29 May '26

29 May '26

#################### KVM Forum 2026 November 12-13, 2026 Vancouver, Canada #################### On behalf of the program committee for the KVM Forum, I am pleased to announce the KVM Forum 2026 Call for Presentations. CALL FOR PRESENTATIONS ====================== We encourage you to submit presentations via Pretalx at https://kvm-forum.qemu.org/2026/cfp/ All presentation slots will be 25 minutes + 5 minutes for questions. Suggested topics: - Scalability and Optimization - Hardening and security - Confidential computing KVM and the Linux Kernel - New Features and Architecture Ports - Device Passthrough: VFIO, mdev, vDPA - Network Virtualization - Virtio and vhost Virtual Machine Monitors and Management - VMM Implementation: APIs, Live Migration, Performance Tuning, etc. - Multi-process VMMs: vhost-user, vfio-user, QEMU Storage Daemon - QEMU without KVM: Hypervisor.framework, Hyper-V, etc. - Managing KVM: Libvirt, KubeVirt, Kata Containers Emulation - New Devices, Boards and Architectures - CPU Emulation and Binary Translation Developer-focused content - Tooling improvements - Enabling Rust - Testing frameworks and strategies Speakers are expected to attend in person. IMPORTANT DATES =============== The deadline for submitting presentations is: 2026-08-01 00:00 (Canada/Pacific) Accepted speakers will be notified on August 21, 2026. ATTENDING KVM FORUM =================== The cost of admission to KVM Forum 2026 is $75. You can get your ticket at https://kvm-forum.qemu.org/2026/register/ Admission is free for accepted speakers. The conference will be held at Coast Coal Harbour Hotel Vancouver by APA in Vancouver, Canada. More details about the location, and about the reduced price rooms available for attendees at the conference hotel, can be found at: https://kvm-forum.qemu.org/location/ If you need a visa invitation letter in order to attend, please reach out to the organizers at kvm-forum-pc(a)redhat.com. We are committed to fostering an open and welcoming environment at our conference. Participants are expected to abide by our code of conduct and media policy: https://kvm-forum.qemu.org/coc/ https://kvm-forum.qemu.org/media-policy/ CONTACTS ======== Reach out to us should you have any questions. The program committee may be contacted as a group via email: kvm-forum-pc(a)redhat.com. -- Peter Maydell

1 0

[PATCH] examples: Improved shell output of showDomains
by Daniel Hora 29 May '26

29 May '26

From: Daniel Hora <dhora(a)redhat.com> Improved formatting of the shell output of the function showDomains based on length of the longest domain. Signed-off-by: Daniel Hora <dhora(a)redhat.com> --- examples/c/misc/hellolibvirt.c | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/examples/c/misc/hellolibvirt.c b/examples/c/misc/hellolibvirt.c index 39cefe934c..77098d7be3 100644 --- a/examples/c/misc/hellolibvirt.c +++ b/examples/c/misc/hellolibvirt.c @@ -4,6 +4,7 @@ #include <stdio.h> #include <stdlib.h> +#include <string.h> #include <libvirt/libvirt.h> #include <libvirt/virterror.h> @@ -44,11 +45,34 @@ showHypervisorInfo(virConnectPtr conn) return 0; } +static int +longestDomain(virDomainPtr *nameList, int numNames) +{ + int longestDomainLength; + size_t i; + + longestDomainLength = 0; + + for (i = 0; i < numNames; i++) { + const char *currentDomain = virDomainGetName(nameList[i]); + + if (currentDomain != NULL) { + int currentDomainLength = strlen(currentDomain); + + if (currentDomainLength > longestDomainLength) { + longestDomainLength = currentDomainLength; + } + } + } + + return longestDomainLength; + +} static int showDomains(virConnectPtr conn) { - int numNames, numInactiveDomains, numActiveDomains; + int numNames, numInactiveDomains, numActiveDomains, longestDomainLength; ssize_t i; int flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE | VIR_CONNECT_LIST_DOMAINS_INACTIVE; @@ -88,9 +112,12 @@ showDomains(virConnectPtr conn) return 1; } + longestDomainLength = longestDomain(nameList, numNames); + for (i = 0; i < numNames; i++) { int active = virDomainIsActive(nameList[i]); - printf(" %8s (%s)\n", + printf(" %-*s (%s)\n", + longestDomainLength, virDomainGetName(nameList[i]), (active == 1 ? "active" : "non-active")); /* must free the returned named per the API documentation */ -- 2.54.0

2 1