- Devel - libvirt List Archives

[PATCH 0/3] docs: Small tweaks to downloads page
by Andrea Bolognani 05 Jun '25

05 Jun '25

*** CLICK HERE TO BLURB *** Andrea Bolognani (3): docs: Unify clone instructions docs: Drop mention of read-only git mirrors docs: Add prompt to clone commands docs/downloads.rst | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) -- 2.49.0

2 7

[PATCH 0/2] docs: Fix docs for VIR_MIGRATE_PARAM_MIGRATE_DISKS_DETECT_ZEROES_ZEROES
by Peter Krempa 05 Jun '25

05 Jun '25

Remove note about needing a pre-cleared image and document need to enable discards to obtain a sparse image. Peter Krempa (2): Revert "docs: Add warning about using a cleared image with VIR_MIGRATE_PARAM_MIGRATE_DISKS_DETECT_ZEROES_ZEROES" docs: Note that zero detection on migration sparsifies image only when discard='unmap' is set docs/manpages/virsh.rst | 7 +++---- include/libvirt/libvirt-domain.h | 12 +++++------- 2 files changed, 8 insertions(+), 11 deletions(-) -- 2.49.0

2 3

[PATCH 0/7] virsh: Fix cleanup in 'event' command and introduce 'await' command
by Peter Krempa 05 Jun '25

05 Jun '25

'virsh await' is a helper/syntax-sugar command which allows you to wait until a domain reaches a certain state. Currently this series implements conditions named 'domain-inactive' and 'guest-agent-available'. Peter Krempa (7): virthread: Register auto cleanup function for virMutex virthread: Add infrastructure for static virCond definitions virsh: cmdEvent: Ensure that event callbacks are unregistered before returning vshCommandRun: Convert to directly return the exit code vsh: Add support for commands with more return values virsh: Introduce 'await' command for waiting until target domain state is reached virsh: await: Introduce 'guest-agent-available' condition docs/manpages/virsh.rst | 30 ++++ src/util/virthread.h | 7 + tools/virsh-domain-event.c | 321 ++++++++++++++++++++++++++++++++++++- tools/virsh.c | 4 +- tools/virt-admin.c | 4 +- tools/vsh.c | 46 ++++-- tools/vsh.h | 3 +- 7 files changed, 398 insertions(+), 17 deletions(-) -- 2.49.0

2 8

[PATCH] libxl_capabilities: Make some functions return void
by Michal Privoznik 05 Jun '25

05 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> Inside of libxlMakeDomainCapabilities() there are some functions called and basically all of them never return anything but zero (indicating success). Yet, they are called in a fashion that suggests otherwise. Turn those functions into void and drop checks for their retvals. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/libxl/libxl_capabilities.c | 43 +++++++++++++--------------------- 1 file changed, 16 insertions(+), 27 deletions(-) diff --git a/src/libxl/libxl_capabilities.c b/src/libxl/libxl_capabilities.c index 6aca4075e7..48f7619cc4 100644 --- a/src/libxl/libxl_capabilities.c +++ b/src/libxl/libxl_capabilities.c @@ -512,7 +512,7 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCaps *caps) return 0; } -static int +static void libxlMakeDomainOSCaps(const char *machine, virDomainCapsOS *os, virFirmware **firmwares, @@ -527,7 +527,7 @@ libxlMakeDomainOSCaps(const char *machine, capsLoader->readonly.report = true; if (STREQ(machine, "xenpv") || STREQ(machine, "xenpvh")) - return 0; + return; capsLoader->supported = VIR_TRISTATE_BOOL_YES; capsLoader->values.values = g_new0(char *, nfirmwares); @@ -542,11 +542,9 @@ libxlMakeDomainOSCaps(const char *machine, VIR_DOMAIN_LOADER_TYPE_PFLASH); VIR_DOMAIN_CAPS_ENUM_SET(capsLoader->readonly, VIR_TRISTATE_BOOL_YES); - - return 0; } -static int +static void libxlMakeDomainDeviceDiskCaps(virDomainCapsDeviceDisk *dev) { dev->supported = VIR_TRISTATE_BOOL_YES; @@ -562,11 +560,9 @@ libxlMakeDomainDeviceDiskCaps(virDomainCapsDeviceDisk *dev) VIR_DOMAIN_DISK_BUS_IDE, VIR_DOMAIN_DISK_BUS_SCSI, VIR_DOMAIN_DISK_BUS_XEN); - - return 0; } -static int +static void libxlMakeDomainDeviceGraphicsCaps(virDomainCapsDeviceGraphics *dev) { dev->supported = VIR_TRISTATE_BOOL_YES; @@ -576,11 +572,9 @@ libxlMakeDomainDeviceGraphicsCaps(virDomainCapsDeviceGraphics *dev) VIR_DOMAIN_GRAPHICS_TYPE_SDL, VIR_DOMAIN_GRAPHICS_TYPE_VNC, VIR_DOMAIN_GRAPHICS_TYPE_SPICE); - - return 0; } -static int +static void libxlMakeDomainDeviceVideoCaps(virDomainCapsDeviceVideo *dev) { dev->supported = VIR_TRISTATE_BOOL_YES; @@ -590,11 +584,9 @@ libxlMakeDomainDeviceVideoCaps(virDomainCapsDeviceVideo *dev) VIR_DOMAIN_VIDEO_TYPE_VGA, VIR_DOMAIN_VIDEO_TYPE_CIRRUS, VIR_DOMAIN_VIDEO_TYPE_XEN); - - return 0; } -static int +static void libxlMakeDomainDeviceHostdevCaps(virDomainCapsDeviceHostdev *dev) { dev->supported = VIR_TRISTATE_BOOL_YES; @@ -625,10 +617,9 @@ libxlMakeDomainDeviceHostdevCaps(virDomainCapsDeviceHostdev *dev) virDomainCapsEnumClear(&dev->pciBackend); VIR_DOMAIN_CAPS_ENUM_SET(dev->pciBackend, VIR_DEVICE_HOSTDEV_PCI_DRIVER_NAME_XEN); - return 0; } -static int +static void libxlMakeDomainDeviceConsoleCaps(virDomainCapsDeviceConsole *console) { console->supported = VIR_TRISTATE_BOOL_YES; @@ -643,8 +634,6 @@ libxlMakeDomainDeviceConsoleCaps(virDomainCapsDeviceConsole *console) VIR_DOMAIN_CHR_TYPE_UDP, VIR_DOMAIN_CHR_TYPE_UNIX, VIR_DOMAIN_CHR_TYPE_VC); - - return 0; } virCaps * @@ -698,15 +687,15 @@ libxlMakeDomainCapabilities(virDomainCaps *domCaps, else domCaps->maxvcpus = PV_MAX_VCPUS; - if (libxlMakeDomainOSCaps(domCaps->machine, os, firmwares, nfirmwares) < 0 || - libxlMakeDomainDeviceDiskCaps(disk) < 0 || - libxlMakeDomainDeviceGraphicsCaps(graphics) < 0 || - libxlMakeDomainDeviceVideoCaps(video) < 0 || - libxlMakeDomainDeviceConsoleCaps(console)) - return -1; - if (STRNEQ(domCaps->machine, "xenpvh") && - libxlMakeDomainDeviceHostdevCaps(hostdev) < 0) - return -1; + libxlMakeDomainOSCaps(domCaps->machine, os, firmwares, nfirmwares); + libxlMakeDomainDeviceDiskCaps(disk); + libxlMakeDomainDeviceGraphicsCaps(graphics); + libxlMakeDomainDeviceVideoCaps(video); + libxlMakeDomainDeviceConsoleCaps(console); + + if (STRNEQ(domCaps->machine, "xenpvh")) { + libxlMakeDomainDeviceHostdevCaps(hostdev); + } domCaps->features[VIR_DOMAIN_CAPS_FEATURE_IOTHREADS] = VIR_TRISTATE_BOOL_NO; domCaps->features[VIR_DOMAIN_CAPS_FEATURE_VMCOREINFO] = VIR_TRISTATE_BOOL_NO; -- 2.49.0

2 1

[PATCH v2 0/4] conf: graphics def and parse refactor
by Kirill Shchetiniuk 04 Jun '25

04 Jun '25

This series refactors the existing parse logic by using the proper utility functions, it also contains some parameters type changes to void unnecessary type convertions. 1. 'VNC' graphics pasing were refactored to use the vitXMLProp* utility functions. 'autoport' and 'websocketGenerated' remain their bool type, as this structure members can be also modified later and not only determined by the initial XML definition. 2. 'RDP' graphics refactored same as VNC graphics, except that 'multiUser' and 'replaceUser' types changed from bool to tristateBool, as parameters are determined only by the initial XML. 3. 'SDL' graphics fullscreen option type changed from bool to tristateBool, to avoid unnecessary type convertions. 4. 'desktop' graphics fullscreen option is removed as it was never used. Kirill Shchetiniuk (4): conf: VNC graphics parse refactor conf: SDL fullscreen option refactor conf: RDP graphics parse refactor conf: desktop graphics remove unused option docs/formatdomain.rst | 5 +- src/conf/domain_conf.c | 125 ++++++++++++++---------------- src/conf/domain_conf.h | 7 +- src/conf/schemas/domaincommon.rng | 5 -- src/qemu/qemu_command.c | 2 +- src/qemu/qemu_process.c | 4 +- src/qemu/qemu_validate.c | 4 +- src/vbox/vbox_common.c | 8 +- 8 files changed, 71 insertions(+), 89 deletions(-) -- 2.49.0

2 6

[PATCH 0/4] conf: graphics def and parse refactor
by Kirill Shchetiniuk 04 Jun '25

04 Jun '25

This series is supposed to refactor the existing parse logic by using the proper utility function and some parameters type change. 1. VNC graphics pasing were refactored to use the vitXMLProp* utility functions. 'autoport' and 'websocketGenerated' remain their bool type, as this structure members can be also modified later and not only determined by the initial XML definition. 2. RDP graphics refactored same as VNC graphics, exept that 'multiUser' and 'replaceUser' types changed from bool to tristate, as parameters determined only by the initial XML. 3. SDL graphics fullscreen option type changed from bool to tristate, to avoid unnecessary type convertions. 4. desktop fullscreen option is removed as it was never used. Kirill Shchetiniuk (4): conf: VNC graphics parse refactor conf: SDL fullscreen option refactor conf: RDP graphics parse refactor conf: desktop graphics remove unused option docs/formatdomain.rst | 5 +- src/conf/domain_conf.c | 125 ++++++++++++++---------------- src/conf/domain_conf.h | 7 +- src/conf/schemas/domaincommon.rng | 5 -- src/qemu/qemu_command.c | 2 +- src/qemu/qemu_process.c | 4 +- src/qemu/qemu_validate.c | 4 +- src/vbox/vbox_common.c | 8 +- 8 files changed, 71 insertions(+), 89 deletions(-) -- 2.49.0

2 6

[PATCH] qemu: command: Don't attempt to set backend MTU for networks which don't use host backend directly
by Peter Krempa 04 Jun '25

04 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> Attempting to set MTU for network types which don't actually use the network device on the host results in a failure. The 'mtu' property is also used e.g. for the 'host_mtu' property of e.g. 'virtio-net-pci' which is applied even in vhost-user mode. Use the existing switch which selects devices without a network device backend on the host side and skip setting the MTU. Tested by running 'passt' in vhost-user mode manually: passt -f --vhost-user -s /tmp/vh.sock and the following XML: <interface type="vhostuser"> <mac address="52:54:00:3d:91:97"/> <source type="unix" path="/tmp/vh.sock" mode="client"/> <model type="virtio"/> <mtu size="9999"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/> </interface> The OS in the guest reports MTU 9999. Closes: https://gitlab.com/libvirt/libvirt/-/issues/717 Closes: https://gitlab.com/libvirt/libvirt/-/issues/192 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_command.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index fec48edfc1..edafe1588c 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -8713,6 +8713,7 @@ qemuBuildInterfaceCommandLine(virQEMUDriver *driver, bool requireNicdev = false; g_autoptr(virJSONValue) hostnetprops = NULL; qemuDomainNetworkPrivate *netpriv = QEMU_DOMAIN_NETWORK_PRIVATE(net); + bool setBackendMTU = true; GSList *n; if (qemuDomainValidateActualNetDef(net, qemuCaps) < 0) @@ -8802,6 +8803,7 @@ qemuBuildInterfaceCommandLine(virQEMUDriver *driver, case VIR_DOMAIN_NET_TYPE_NULL: case VIR_DOMAIN_NET_TYPE_VDS: case VIR_DOMAIN_NET_TYPE_LAST: + setBackendMTU = false; /* These types don't use a network device on the host, but * instead use some other type of connection to the emulated * device in the qemu process. @@ -8842,7 +8844,7 @@ qemuBuildInterfaceCommandLine(virQEMUDriver *driver, } } - if (net->mtu && net->managed_tap != VIR_TRISTATE_BOOL_NO && + if (net->mtu && setBackendMTU && net->managed_tap != VIR_TRISTATE_BOOL_NO && virNetDevSetMTU(net->ifname, net->mtu) < 0) goto cleanup; -- 2.49.0

3 2

[PATCH 0/2] Fix build on non-Linux
by Jiri Denemark 03 Jun '25

03 Jun '25

Jiri Denemark (2): util: Avoid statfs in virFileGetExistingParent util: Move virFileGetExistingParent out of ifdef __linux__ src/util/virfile.c | 56 ++++++++++++++++++++++----------------------- tests/virfilemock.c | 28 +++++++++++++++++++++++ 2 files changed, 56 insertions(+), 28 deletions(-) -- 2.49.0

2 4

[PATCH v2 0/2] qemu: Don't accept VIR_DUMP_LIVE flag in qemuDomainCoreDumpWithFormat()
by Michal Privoznik 03 Jun '25

03 Jun '25

This is a v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/PP7K… Instead of documenting the flag quirks, let's just error out if specified. Michal Prívozník (2): qemu: Don't accept VIR_DUMP_LIVE flag in qemuDomainCoreDumpWithFormat() NEWS: Document removal of support of VIR_DUMP_LIVE flag from QEMU driver NEWS.rst | 7 +++++++ src/qemu/qemu_driver.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) -- 2.49.0

2 4

[PATCH] lib: Document VIR_DUMP_LIVE flag quirk
by Michal Privoznik 03 Jun '25

03 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> The virDomainCoreDump() API has VIR_DUMP_LIVE flag which is documented to leave vCPUs running throughout making of the dump of guest memory. Well, this is not the case for QEMU which pauses vCPUs unconditionally (it calls vm_stop() in dump_init()). Document this quirk. And also mention it in 'virsh dump --live' manapage. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/646 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/manpages/virsh.rst | 3 ++- src/libvirt-domain.c | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 3a00778467..14f22b32c3 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -2927,7 +2927,8 @@ dump Dumps the core of a domain to a file for analysis. If *--live* is specified, the domain continues to run until the core -dump is complete, rather than pausing up front. +dump is complete, rather than pausing up front. Although, the hypervisor might +still decide to pause the guest's vCPUs. If *--crash* is specified, the domain is halted with a crashed status, rather than merely left in a paused state. If *--reset* is specified, the domain is reset after successful dump. diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 93e8f5b853..6d1cd2dba1 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -1445,6 +1445,8 @@ virDomainSaveImageDefineXML(virConnectPtr conn, const char *file, * the guest to run; otherwise, the guest is suspended during the dump. * VIR_DUMP_RESET flag forces reset of the guest after dump. * The above three flags are mutually exclusive. + * However, note that even if VIR_DUMP_LIVE flag is specified, the hypervisor + * might temporarily suspend the guest vCPUs anyway. * * Additionally, if @flags includes VIR_DUMP_BYPASS_CACHE, then libvirt * will attempt to bypass the file system cache while creating the file, -- 2.49.0

3 2

[PATCH 00/11] Support for emulated NVMe disks in VMX and QEMU
by Martin Kletzander 02 Jun '25

02 Jun '25

I took the liberty of adjusting Hongwei's QEMU series and made further adjustments so that the common code can be used for reporting NVMe disks from VMX as well. I added SoBs where I thought applicable, but feel free to correct me and/or agree with me. This series fixes https://issues.redhat.com/browse/RHEL-7390 in the middle, but adds more than just that. Martin Kletzander (11): docs, conf, schemas: Add support for NVMe controller util: Add support for parsing nvmeXnY(pZ) strings conf: Add virDomainDeviceFindNvmeController docs, conf, schemas: Add support for NVMe disks vmx: Add support for NVMe disks qemu_capabilities: Add NVMe controller and disk capabilities qemu_capabilities: Add emulated NVMe disk support to domain capabilities qemu: Add support for NVMe controllers qemu: Add support for emulated NVMe disks NEWS: vmx support for NVMe disks NEWS: qemu support for emulated NVMe disks NEWS.rst | 15 +++ docs/formatdomain.rst | 19 +++- src/bhyve/bhyve_command.c | 1 + src/conf/domain_conf.c | 96 ++++++++++++++++- src/conf/domain_conf.h | 10 ++ src/conf/domain_postparse.c | 2 + src/conf/domain_validate.c | 4 +- src/conf/schemas/domaincommon.rng | 22 +++- src/conf/virconftypes.h | 2 + src/hyperv/hyperv_driver.c | 2 + src/libxl/libxl_driver.c | 2 +- src/qemu/qemu_alias.c | 1 + src/qemu/qemu_capabilities.c | 7 ++ src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 33 +++++- src/qemu/qemu_domain_address.c | 5 + src/qemu/qemu_hotplug.c | 10 +- src/qemu/qemu_postparse.c | 1 + src/qemu/qemu_validate.c | 65 ++++++++++-- src/test/test_driver.c | 2 + src/util/virutil.c | 94 ++++++++++++++-- src/util/virutil.h | 7 +- src/vbox/vbox_common.c | 4 +- src/vmx/vmx.c | 85 ++++++++++++++- src/vz/vz_sdk.c | 6 +- .../qemu_10.0.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 1 + .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 1 + .../qemu_10.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_10.0.0.s390x.xml | 1 + .../qemu_10.0.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 1 + .../qemu_7.2.0-hvf.x86_64+hvf.xml | 1 + .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 1 + .../qemu_7.2.0-tcg.x86_64+hvf.xml | 1 + .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.2.0.ppc.xml | 1 + tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 1 + .../qemu_8.2.0-tcg-virt.loongarch64.xml | 1 + .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 1 + .../qemu_8.2.0-virt.aarch64.xml | 1 + .../qemu_8.2.0-virt.loongarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 1 + tests/domaincapsdata/qemu_8.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 1 + .../qemu_9.1.0-tcg-virt.riscv64.xml | 1 + .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 1 + .../qemu_9.1.0-virt.riscv64.xml | 1 + tests/domaincapsdata/qemu_9.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 1 + .../qemu_9.2.0-hvf.aarch64+hvf.xml | 1 + .../qemu_9.2.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 1 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.2.0.s390x.xml | 1 + .../qemu_9.2.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 1 + .../genericxml2xmlindata/controller-nvme.xml | 21 ++++ .../disk-nvme-invalid-serials.xml | 29 +++++ tests/genericxml2xmlindata/disk-nvme.xml | 32 ++++++ tests/genericxml2xmloutdata/disk-nvme.xml | 38 +++++++ tests/genericxml2xmltest.c | 4 + .../caps_10.0.0_aarch64.xml | 2 + .../caps_10.0.0_ppc64.xml | 2 + .../caps_10.0.0_s390x.xml | 2 + .../caps_10.0.0_x86_64+amdsev.xml | 2 + .../caps_10.0.0_x86_64.xml | 2 + .../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 2 + .../caps_6.2.0_x86_64.xml | 2 + .../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 2 + .../caps_7.0.0_x86_64.xml | 2 + .../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 2 + .../caps_7.1.0_x86_64.xml | 2 + tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 2 + .../caps_7.2.0_x86_64+hvf.xml | 2 + .../caps_7.2.0_x86_64.xml | 2 + .../caps_8.0.0_x86_64.xml | 2 + .../caps_8.1.0_x86_64.xml | 2 + .../caps_8.2.0_aarch64.xml | 2 + .../caps_8.2.0_armv7l.xml | 2 + .../caps_8.2.0_loongarch64.xml | 2 + .../qemucapabilitiesdata/caps_8.2.0_s390x.xml | 2 + .../caps_8.2.0_x86_64.xml | 2 + .../caps_9.0.0_x86_64.xml | 2 + .../caps_9.1.0_riscv64.xml | 2 + .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 2 + .../caps_9.1.0_x86_64.xml | 2 + .../caps_9.2.0_aarch64+hvf.xml | 2 + .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 2 + .../caps_9.2.0_x86_64+amdsev.xml | 2 + .../caps_9.2.0_x86_64.xml | 2 + .../disk-target-nvme.x86_64-latest.args | 39 +++++++ .../disk-target-nvme.x86_64-latest.xml | 53 ++++++++++ tests/qemuxmlconfdata/disk-target-nvme.xml | 32 ++++++ tests/qemuxmlconftest.c | 1 + tests/utiltest.c | 38 ++++--- tests/vmx2xmldata/esx-in-the-wild-15.vmx | 100 ++++++++++++++++++ tests/vmx2xmldata/esx-in-the-wild-15.xml | 45 ++++++++ tests/vmx2xmldata/esx-in-the-wild-16.vmx | 91 ++++++++++++++++ tests/vmx2xmldata/esx-in-the-wild-16.xml | 37 +++++++ tests/vmx2xmltest.c | 2 + 129 files changed, 1128 insertions(+), 49 deletions(-) create mode 100644 tests/genericxml2xmlindata/controller-nvme.xml create mode 100644 tests/genericxml2xmlindata/disk-nvme-invalid-serials.xml create mode 100644 tests/genericxml2xmlindata/disk-nvme.xml create mode 100644 tests/genericxml2xmloutdata/disk-nvme.xml create mode 100644 tests/qemuxmlconfdata/disk-target-nvme.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/disk-target-nvme.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/disk-target-nvme.xml create mode 100644 tests/vmx2xmldata/esx-in-the-wild-15.vmx create mode 100644 tests/vmx2xmldata/esx-in-the-wild-15.xml create mode 100644 tests/vmx2xmldata/esx-in-the-wild-16.vmx create mode 100644 tests/vmx2xmldata/esx-in-the-wild-16.xml -- 2.49.0

2 14

[PATCH] docs: fix indent of hostdev examples
by Daniel P. Berrangé 02 Jun '25

02 Jun '25

From: Daniel P. Berrangé <berrange(a)redhat.com> Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/formatdomain.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 8753ee9c23..ca4e84983f 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -4600,15 +4600,15 @@ or: ... <devices> <hostdev mode='subsystem' type='mdev' model='vfio-pci'> - <source> - <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'/> - </source> + <source> + <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'/> + </source> </hostdev> <hostdev mode='subsystem' type='mdev' model='vfio-ccw'> <source> <address uuid='9063cba3-ecef-47b6-abcf-3fef4fdcad85'/> </source> - <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/> </hostdev> </devices> ... -- 2.49.0

2 1

[PATCH] docs: Change units to 'kiB' from 'kB'/'kilobytes'/'kb'
by Peter Krempa 02 Jun '25

02 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> Use the short unit for kibibytes instead of the confusing or plainly wrong units. Closes: https://gitlab.com/libvirt/libvirt/-/issues/594 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/formatdomain.rst | 4 ++-- docs/formatnetwork.rst | 4 ++-- docs/manpages/virsh.rst | 6 +++--- include/libvirt/libvirt-domain.h | 12 ++++++------ src/libvirt-domain.c | 12 ++++++------ 5 files changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 8753ee9c23..82606ef35f 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -1139,7 +1139,7 @@ influence how virtual memory pages are backed by host pages. element is introduced. It has one compulsory attribute ``size`` which specifies which hugepages should be used (especially useful on systems supporting hugepages of different sizes). The default unit for the ``size`` - attribute is kilobytes (multiplier of 1024). If you want to use different + attribute is kiB (multiplier of 1024). If you want to use different unit, use optional ``unit`` attribute. For systems with NUMA, the optional ``nodeset`` attribute may come handy as it ties given guest's NUMA nodes to certain hugepage sizes. From the example snippet, one gigabyte hugepages are @@ -4298,7 +4298,7 @@ attribute are - ``pcie-to-pci-bridge`` ( :since:`since 4.3.0` ) The root controllers (``pci-root`` and ``pcie-root``) have an optional -``pcihole64`` element specifying how big (in kilobytes, or in the unit specified +``pcihole64`` element specifying how big (in kiB, or in the unit specified by ``pcihole64``'s ``unit`` attribute) the 64-bit PCI hole should be. Some guests (like Windows XP or Windows Server 2003) might crash when QEMU and Seabios are recent enough to support 64-bit PCI holes, unless this is disabled diff --git a/docs/formatnetwork.rst b/docs/formatnetwork.rst index 053fe6ad56..6694a145af 100644 --- a/docs/formatnetwork.rst +++ b/docs/formatnetwork.rst @@ -468,10 +468,10 @@ follows, where accepted values for each attribute is an integer number. ``average`` Specifies the desired average bit rate for the interface being shaped (in - kilobytes/second). + kiB/second). ``peak`` Optional attribute which specifies the maximum rate at which the bridge can - send data (in kilobytes/second). Note the limitation of implementation: this + send data (in kiB/second). Note the limitation of implementation: this attribute in the ``outbound`` element is ignored (as Linux ingress filters don't know it yet). ``burst`` diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 3a00778467..895a905b08 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -2274,7 +2274,7 @@ If no *--inbound* or *--outbound* is specified, this command will query and show the bandwidth settings. Otherwise, it will set the inbound or outbound bandwidth. *average,peak,burst,floor* is the same as in command *attach-interface*. Values for *average*, *peak* and *floor* -are expressed in kilobytes per second, while *burst* is expressed in kilobytes +are expressed in kiB per second, while *burst* is expressed in kiB in a single burst at *peak* speed as described in the Network XML documentation at `https://libvirt.org/formatnetwork.html#quality-of-service <https://libvirt.org/formatnetwork.html#quality-of-service>`__. @@ -5261,8 +5261,8 @@ interface. At least one from the *average*, *floor* pair must be specified. The other two *peak* and *burst* are optional, so "average,peak", "average,,burst", "average,,,floor", "average" and ",,,floor" are also legal. Values for *average*, *floor* and *peak* -are expressed in kilobytes per second, while *burst* is expressed in -kilobytes in a single burst at *peak* speed as described in the +are expressed in kiB per second, while *burst* is expressed in +kiB in a single burst at *peak* speed as described in the Network XML documentation at `https://libvirt.org/formatnetwork.html#quality-of-service <https://libvirt.org/formatnetwork.html#quality-of-service>`__. diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index 9496631bcc..ac5daf7d0c 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -715,9 +715,9 @@ typedef virDomainInterfaceStatsStruct *virDomainInterfaceStatsPtr; * Since: 0.7.5 */ typedef enum { - /* The total amount of data read from swap space (in kB). (Since: 0.7.5) */ + /* The total amount of data read from swap space (in kiB). (Since: 0.7.5) */ VIR_DOMAIN_MEMORY_STAT_SWAP_IN = 0, - /* The total amount of memory written out to swap space (in kB). (Since: 0.7.5) */ + /* The total amount of memory written out to swap space (in kiB). (Since: 0.7.5) */ VIR_DOMAIN_MEMORY_STAT_SWAP_OUT = 1, /* @@ -738,7 +738,7 @@ typedef enum { /* * The amount of memory left completely unused by the system. Memory that * is available but used for reclaimable caches should NOT be reported as - * free. This value is expressed in kB. + * free. This value is expressed in kiB. * * Since: 0.7.5 */ @@ -748,7 +748,7 @@ typedef enum { * The total amount of usable memory as seen by the domain. This value * may be less than the amount of memory assigned to the domain if a * balloon driver is in use or if the guest OS does not initialize all - * assigned pages. This value is expressed in kB. + * assigned pages. This value is expressed in kiB. * * Since: 0.7.5 */ @@ -762,7 +762,7 @@ typedef enum { VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON = 6, /* Resident Set Size of the process running the domain. This value - * is in kB + * is in kiB * * Since: 0.9.10 */ @@ -785,7 +785,7 @@ typedef enum { /* * The amount of memory, that can be quickly reclaimed without - * additional I/O (in kB). Typically these pages are used for caching files + * additional I/O (in kiB). Typically these pages are used for caching files * from disk. * * Since: 4.6.0 diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 93e8f5b853..ca110bdf85 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -6284,27 +6284,27 @@ virDomainGetInterfaceParameters(virDomainPtr domain, * Memory Statistics: * * VIR_DOMAIN_MEMORY_STAT_SWAP_IN: - * The total amount of data read from swap space (in kb). + * The total amount of data read from swap space (in kiB). * VIR_DOMAIN_MEMORY_STAT_SWAP_OUT: - * The total amount of memory written out to swap space (in kb). + * The total amount of memory written out to swap space (in kiB). * VIR_DOMAIN_MEMORY_STAT_MAJOR_FAULT: * The number of page faults that required disk IO to service. * VIR_DOMAIN_MEMORY_STAT_MINOR_FAULT: * The number of page faults serviced without disk IO. * VIR_DOMAIN_MEMORY_STAT_UNUSED: - * The amount of memory which is not being used for any purpose (in kb). + * The amount of memory which is not being used for any purpose (in kiB). * VIR_DOMAIN_MEMORY_STAT_AVAILABLE: - * The total amount of memory available to the domain's OS (in kb). + * The total amount of memory available to the domain's OS (in kiB). * VIR_DOMAIN_MEMORY_STAT_USABLE: * How much the balloon can be inflated without pushing the guest system * to swap, corresponds to 'Available' in /proc/meminfo * VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON: - * Current balloon value (in kb). + * Current balloon value (in kiB). * VIR_DOMAIN_MEMORY_STAT_LAST_UPDATE * Timestamp of the last statistic * VIR_DOMAIN_MEMORY_STAT_DISK_CACHES * Memory that can be reclaimed without additional I/O, typically disk - * caches (in kb). + * caches (in kiB). * VIR_DOMAIN_MEMORY_STAT_HUGETLB_PGALLOC * The number of successful huge page allocations from inside the domain * VIR_DOMAIN_MEMORY_STAT_HUGETLB_PGFAIL -- 2.49.0

2 1

[PATCH] esx: Avoid corner case where esxUtil_ParseDatastorePath could be called with NULL 'datastorePath'
by Peter Krempa 02 Jun '25

02 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> The generated code which parses the data from XML in esxVI_LookupDatastoreContentByDatastoreName can fill the 'folderPath' property with NULL if it were missing from the input XML. While this is not likely when talking to esx it is a possible outcome. Skipp NULL results. All other code paths already ensure that the function is not called with NULL. Closes: https://gitlab.com/libvirt/libvirt/-/issues/776 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/esx/esx_storage_backend_vmfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/esx/esx_storage_backend_vmfs.c b/src/esx/esx_storage_backend_vmfs.c index 145aff0c9c..8e13201fe2 100644 --- a/src/esx/esx_storage_backend_vmfs.c +++ b/src/esx/esx_storage_backend_vmfs.c @@ -616,6 +616,9 @@ esxStoragePoolListVolumes(virStoragePoolPtr pool, char **const names, searchResults = searchResults->_next) { g_autofree char *directoryAndFileName = NULL; + if (!searchResults->folderPath) + continue; + if (esxUtil_ParseDatastorePath(searchResults->folderPath, NULL, NULL, &directoryAndFileName) < 0) { goto cleanup; @@ -759,6 +762,9 @@ esxStorageVolLookupByKey(virConnectPtr conn, const char *key) searchResults = searchResults->_next) { g_autofree char *directoryAndFileName = NULL; + if (searchResults->folderPath) + continue; + if (esxUtil_ParseDatastorePath(searchResults->folderPath, NULL, NULL, &directoryAndFileName) < 0) { goto cleanup; -- 2.49.0

2 1

Release of libvirt-11.4.0
by Jiri Denemark 02 Jun '25

02 Jun '25

The 11.4.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 * qemu: ppc64 POWER11 processor support Support for the recently released IBM POWER11 processor was added. * Packaging changes * All helper programs are now detected from ``$PATH`` during runtime All of the code was now converted to dynamically look up helper programs in ``$PATH`` rather than doing the lookup at build time and then compiling in the result. Programs ``mount``, ``umount``, ``mkfs``, ``modprobe``, ``rmmod``, ``numad``, ``dmidecode``, ``ip``, ``tc``, ``mdevctl``, ``mm-ctl``, ``iscsiadm``, ``ovs-vsctl``, ``pkttyagent``, ``bhyveload``, ``bhyvectl``, ``bhyve``, ``ifconfig``, ``vzlist``, ``vzctl``, ``vzmigrate``, and the tools from the lvm suite (``vgchange``, ``lvcreate``, etc..) are now not needed during build and will still work properly if placed in ``$PATH``. This also ensures that libvirt works correctly on distros that are transitioning ``/sbin`` into ``/bin`` and upgraded installations have a different layout from fresh installations. * Improvements * virsh: Add option ``--no-pkttyagent`` That option suppresses registration of pkttyagent with polkitd. * bhyve: support NVRAM configuration for UEFI firmwares The bhyve driver now supports specifying NVRAM store file, such as:: <os firmware='efi'> <nvram/> </os> * qemu: Improve accuracy of FDC/floppy device support statement in capabilities XML The data is now based on the presence of the controller in qemu rather than just a denylist of machine types where floppies not work. * Bug fixes * qemu: Fix failure when reverting to internal snapshots A regression in ``libvirt-11.2`` and ``libvirt-11.3`` prevents reverting to an internal snapshot. Attempts to revert would produce the following error:: error: operation failed: load of internal snapshot 'foo1' job failed: Device 'libvirt-1-format' is writable but does not support snapshots The only workaround is to avoid the broken versions. * qemu: Fix virtqemud crash when resuming failed post-copy migration A regression introduced in ``libvirt-11.2.0`` caused virtqemud on the destination host to crash when trying to resume failed post-copy migration. * qemu: Treat the ``queues`` configuration of ``virtio-net`` as guest ABI The queue count itself isn't a device frontend property but libvirt uses it to calculate ``vectors`` option of the device which is a guest OS visible property, thus ``queues`` must not change during migration. The ABI stability check now handles this properly. Enjoy. Jirka

1 0

[RFC PATCH 0/5] qemu: Implement support for iommufd and multiple vSMMUs
by Nathan Chen 31 May '25

31 May '25

Hi, This is a follow up to the first RFC patchset [0] for supporting multiple vSMMU instances in a qemu VM. This patchset also introduces support for using iommufd to propagate DMA mappings to kernel for assigned devices. This patchset implements support for specifying multiple <iommu> devices within the VM definition when smmuv3Dev IOMMU model is specified, and is tested with Shameer's latest qemu RFC for HW-accelerated vSMMU devices [1] Moreover, it adds a new 'iommufd' member for virDomainIOMMUDef, in order to represent the iommufd object in qemu command line. This patchset also implements new 'iommufdId' and 'iommufdFd' attributes for hostdev devices to be associated with the iommufd object. For instance, specifying the iommufd object and associated hostdev in a VM definition with multiple IOMMUs, configured to be routed to pcie-expander-bus controllers in a way where VFIO device to SMMUv3 associations are matched with the host (pcie-expander-bus and pcie-root-port controllers are no longer auto-added/auto-routed like in the first revision of this RFC, as the PCIe topology will be configured by management apps): <devices> ... <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='252'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='248'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </controller> ... <controller type='pci' index='21' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='21' port='0x0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> <controller type='pci' index='22' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='22' port='0xa8'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> ... <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <iommufdId>iommufd0</iommufdId> <address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <iommufdId>iommufd0</iommufdId> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> <iommu model='smmuv3Dev'> <iommufd> <id>iommufd0</id> </iommufd> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </iommu> <iommu model='smmuv3Dev'> <iommufd> <id>iommufd0</id> </iommufd> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </iommu> </devices> This would get translated to a qemu command line with the arguments below: -device '{"driver":"pxb-pcie","bus_nr":252,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \ -device '{"driver":"pxb-pcie","bus_nr":248,"id":"pci.2","bus":"pcie.0","addr":"0x2"}' \ -device '{"driver":"pcie-root-port","port":0,"chassis":21,"id":"pci.21","bus":"pci.1","addr":"0x0"}' \ -device '{"driver":"pcie-root-port","port":168,"chassis":22,"id":"pci.22","bus":"pci.2","addr":"0x0"}' \ -object '{"qom-type":"iommufd","id":"iommufd0"}' \ -device '{"driver":"arm-smmuv3-accel","bus":"pci.1"}' \ -device '{"driver":"arm-smmuv3-accel","bus":"pci.2"}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","iommufd":"iommufd0","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","iommufd":"iommufd0","bus":"pci.22","addr":"0x0"}' \ If users would like to leverage qemu's iommufd feature to open the VFIO cdev and /dev/iommu via an external management layer, the fd can be specified like so in the VM definition: <devices> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x06' slot='0x12' function='0x2'/> </source> <iommufdId>iommufd0</iommufdId> <iommufdFd>23</iommufdFd> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </hostdev> <iommu model='intel'> <iommufd> <id>iommufd0</id> <fd>22</fd> </iommufd> </iommu> </devices> This would get translated to a qemu command line with the arguments below: -object '{"qom-type":"iommufd","id":"iommufd0","fd":"22"}' \ -device '{"driver":"vfio-pci","host":"0000:06:12.2","id":"hostdev1","iommufd":"iommufd0","fd":"23","bus":"pci.0","addr":"0x3"}' \ Summary of changes: - Introduced support for specifying multiple <iommu> stanzas in the VM XML definition when using smmuv3Dev model. - Automating PCIe topology to populate VM definition with multiple vSMMUs routed to pcie-expander-bus controllers is excluded, in favor of deferring creation of PXBs and routing of VFIO devices to management apps. - Introduced iommufd support. TODO: - I updated the namespace and cgroup configuration to allow access to iommufd paths at /dev/vfio/devices/vfio* and /dev/iommu. However, qemu needs to be launched with user and group set to 'root' in order for these paths to be accessible. A passthrough device represented by /dev/vfio/18 normally has 'root' user and group permissions, but in the mount namespace it's changed to 'libvirt-qemu' and 'kvm'. I wasn't able to discern where this is happening by looking at src/qemu/qemu_namespace.c and src/qemu/qemu_cgroup.c. Would you have any pointers on how to change the iommufd paths' user and group permissions in the libvirt mount namespace? This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/smmuv3Dev-iommufd-04-15-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/7GDT… [1] https://lore.kernel.org/qemu-devel/20250311141045.66620-1-shameerali.koloth… Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (5): conf: Support multiple smmuv3Dev IOMMU devices conf: Add an iommufd member struct to virDomainIOMMUDef qemu: Implement support for associating iommufd to hostdev qemu: Update Cgroup and namespace for qemu to access iommufd paths qemu: Add test case for specifying iommufd docs/formatdomain.rst | 5 +- src/conf/domain_addr.c | 12 +- src/conf/domain_addr.h | 4 +- src/conf/domain_conf.c | 292 ++++++++++++++++-- src/conf/domain_conf.h | 21 +- src/conf/domain_validate.c | 94 +++++- src/conf/schemas/domaincommon.rng | 37 ++- src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 15 +- src/qemu/qemu_cgroup.c | 47 +++ src/qemu/qemu_cgroup.h | 1 + src/qemu/qemu_command.c | 146 ++++++--- src/qemu/qemu_domain_address.c | 33 +- src/qemu/qemu_driver.c | 8 +- src/qemu/qemu_namespace.c | 36 +++ src/qemu/qemu_postparse.c | 11 +- src/qemu/qemu_validate.c | 22 +- ...fio-iommufd-intel-iommu.x86_64-latest.args | 43 +++ ...vfio-iommufd-intel-iommu.x86_64-latest.xml | 80 +++++ .../hostdev-vfio-iommufd-intel-iommu.xml | 80 +++++ tests/qemuxmlconftest.c | 1 + 22 files changed, 878 insertions(+), 114 deletions(-) create mode 100644 tests/qemuxmlconfdata/hostdev-vfio-iommufd-intel-iommu.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/hostdev-vfio-iommufd-intel-iommu.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/hostdev-vfio-iommufd-intel-iommu.xml -- 2.43.0

3 19

[RFC PATCH 0/2] Fix forward type=hostdev nets for apparmor
by Tim Small 30 May '25

30 May '25

I'm working on a fix for a bug whereby apparmor permissions aren't granted to allow a PCI SR-IOV virtual function to be used in a kvm guest when the VF is defined via a forward type='hostdev' network (as per the 'hostdev' option documented here: https://libvirt.org/formatnetwork.html#connectivity ). Downstream bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993856 I'm not sure if the attached patches are sufficient. When I compare the apparmor permissions file for a guest with a VF shared via forward type='hostdev' vs. the same guest with a VF shared via a PCI hostdev device, the latter has extra apparmor permissions for files like: "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource3_wc" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource0_wc" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource3" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/vendor" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/reset" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/device" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource0" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/config" rw, ... however both guests appear to function in my test environment (Debian 13, 6.12.22-amd64) - i.e. both with and without those entries. So I don't know if those permissions are unneeded, or if they are granted at runtime instead. If those permissions are needed, then I'd appreciate any hints on how to modify virt-aa-helper to discover the PCI address. I appreciate that might not actually be possible because that is dynamically allocated, and so might race - so some other solution might be required. Many Thanks, Tim. Tim Small (2): virt-aa-helper: refactor for readability virt-aa-helper: Allow SR-IOV VF PCI for hostdev networks .../apparmor/usr.lib.libvirt.virt-aa-helper.in | 3 +++ src/security/virt-aa-helper.c | 18 ++++++++++++++---- 2 files changed, 17 insertions(+), 4 deletions(-) -- 2.47.2

2 8

[PATCH v2] NEWS: Mention removal of compile time helper program lookup, virito-net ABI check and FDC capabilities
by Peter Krempa 30 May '25

30 May '25

From: Peter Krempa <pkrempa(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- v2: - moved the entry about $PATH lookup under "packaging changes" - added a note that it fixes libvirt on distros which merged /sbin to /bin but only on new installs NEWS.rst | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index fd577021b3..d1bb19c8db 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -21,6 +21,25 @@ v11.4.0 (unreleased) Support for the recently released IBM POWER11 processor was added. +* **Packaging changes** + + * All helper programs are now detected from ``$PATH`` during runtime + + All of the code was now converted to dynamically look up helper programs + in ``$PATH`` rather than doing the lookup at build time and then compiling + in the result. + + Programs ``mount``, ``umount``, ``mkfs``, ``modprobe``, ``rmmod``, + ``numad``, ``dmidecode``, ``ip``, ``tc``, ``mdevctl``, ``mm-ctl``, + ``iscsiadm``, ``ovs-vsctl``, ``pkttyagent``, ``bhyveload``, ``bhyvectl``, + ``bhyve``, ``ifconfig``, ``vzlist``, ``vzctl``, ``vzmigrate``, and the + tools from the lvm suite (``vgchange``, ``lvcreate``, etc..) are now not + needed during build and will still work properly if placed in ``$PATH``. + + This also ensures that libvirt works correctly on distros that are + transitioning ``/sbin`` into ``/bin`` and upgraded installations have + a different layout from fresh installations. + * **Improvements** * virsh: Add option ``--no-pkttyagent`` @@ -35,6 +54,11 @@ v11.4.0 (unreleased) <nvram/> </os> + * qemu: Improve accuracy of FDC/floppy device support statement in capabilities XML + + The data is now based on the presence of the controller in qemu rather than + just a denylist of machine types where floppies not work. + * **Bug fixes** * qemu: Fix failure when reverting to internal snapshots @@ -52,6 +76,13 @@ v11.4.0 (unreleased) destination host to crash when trying to resume failed post-copy migration. + * qemu: Treat the ``queues`` configuration of ``virtio-net`` as guest ABI + + The queue count itself isn't a device frontend property but libvirt uses + it to calculate ``vectors`` option of the device which is a guest OS visible + property, thus ``queues`` must not change during migration. The ABI stability + check now handles this properly. + v11.3.0 (2025-05-02) ==================== -- 2.49.0

2 1

Plans for 11.4.0 release (freeze on 2025-05-27)
by Jiri Denemark 30 May '25

30 May '25

We are getting close to 11.4.0 release of libvirt. To aim for the release on Monday 02 Jun I suggest entering the freeze on Tuesday 27 May and tagging RC2 on Friday 30 May. I hope this works for everyone. Jirka

1 1

[PATCH] virConnectAuthCallbackDefault: Return failure if 'virGetPassword' returns NULL
by Peter Krempa 29 May '25

29 May '25

From: Peter Krempa <pkrempa(a)redhat.com> virGetPassword can return NULL on linux or BSD if it fails. The caller in virConnectAuthCallbackDefault does dereference it unconditionally. Return failure if virGetPassword returns NULL. Fixes: db72866310d1e520efa8ed2d4589bdb5e76a1c95 Closes: https://gitlab.com/libvirt/libvirt/-/issues/777 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/libvirt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/libvirt.c b/src/libvirt.c index 581fc6deea..375d3fa7ef 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -158,7 +158,9 @@ virConnectAuthCallbackDefault(virConnectCredentialPtr cred, if (fflush(stdout) != 0) return -1; - bufptr = virGetPassword(); + if (!(bufptr = virGetPassword())) + return -1; + if (STREQ(bufptr, "")) VIR_FREE(bufptr); break; -- 2.49.0

2 1

[PATCH] NEWS: Mention removal of compile time helper program lookup, virito-net ABI check and FDC capabilities
by Peter Krempa 29 May '25

29 May '25

From: Peter Krempa <pkrempa(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index fd577021b3..884fcad2d8 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -35,6 +35,24 @@ v11.4.0 (unreleased) <nvram/> </os> + * All helper programs are now detected from ``$PATH`` during runtime + + All of the code was now converted to dynamically look up helper programs + in ``$PATH`` rather than doing the lookup at build time and then compiling + in the result. + + Programs ``mount``, ``umount``, ``mkfs``, ``modprobe``, ``rmmod``, + ``numad``, ``dmidecode``, ``ip``, ``tc``, ``mdevctl``, ``mm-ctl``, + ``iscsiadm``, ``ovs-vsctl``, ``pkttyagent``, ``bhyveload``, ``bhyvectl``, + ``bhyve``, ``ifconfig``, ``vzlist``, ``vzctl``, ``vzmigrate``, and the + tools from the lvm suite (``vgchange``, ``lvcreate``, etc..) are now not + needed during build and will still work properly if placed in ``$PATH``. + + * qemu: Improve accuracy of FDC/floppy device support statement in capabilities XML + + The data is now based on the presence of the controller in qemu rather than + just a denylist of machine types where floppies not work. + * **Bug fixes** * qemu: Fix failure when reverting to internal snapshots @@ -52,6 +70,13 @@ v11.4.0 (unreleased) destination host to crash when trying to resume failed post-copy migration. + * qemu: Treat the ``queues`` configuration of ``virtio-net`` as guest ABI + + The queue count itself isn't a device frontend property but libvirt uses + it to calculate ``vectors`` option of the device which is a guest OS visible + property, thus ``queues`` must not change during migration. The ABI stability + check now handles this properly. + v11.3.0 (2025-05-02) ==================== -- 2.49.0

2 2

[PATCH 0/3] util: Fix virFileIsSharedFSOverride on nonexistent paths
by Jiri Denemark 29 May '25

29 May '25

Jiri Denemark (3): util: Document limitation of virFileCanonicalizePath util: Introduce virFileGetExistingParent helper util: Fix virFileIsSharedFSOverride on nonexistent paths src/util/virfile.c | 76 +++++++++++++++++++++++++++------------------- 1 file changed, 45 insertions(+), 31 deletions(-) -- 2.49.0

2 4

[PATCH 00/15] storage_file_probe: Fix ancient bug in qcow2 header extensions parser and refactor the image probing callbacks
by Peter Krempa 29 May '25

29 May '25

Patch 3 fixes an almost 15 year old bug in the qcow2 header extension parser which breaks when the qcow2 image has more than 1 header extension. For us it caused problems for qcow2 images with data file and backing file which we didn't use before, and the only field we cared about was always put first by qemu. Ironically we did have a test file that had such config but it was missed in the test output. Patches 1, 2 are refinment of debug tools I used to see what's happening. Patch 4 adds bitmaps to some test images. We don't parse them but just to be sure. The rest of the series refactors the metadata parser callbacks with the end goal to not parse the qcow2 header extensions twice. Peter Krempa (15): qcow2GetExtensions: Add debug logs for interesting fields in qcow2 header extension parser virstoragetest: Reformat output to hilight dataFile relationship storage_file_probe: qcow2GetExtensions: Fix qcow2 header extension parsing virstoragetest: Add qcow2 bitmaps to some images storage_file_probe: Add image specific callback taking the whole virStorageSource storage_file_probe: Refactor cowGetBackingStore into cowGetImageSpecific storage_file_probe: Refactor qedGetBackingStore into qedGetImageSpecific storage_file_probe: Refactor vmdk4GetBackingStore into vmdk4GetImageSpecific storage_file_probe: Refactor qcowXGetBackingStore into specific callbacks for qcow and qcow2 storage_file_probe: Move logic from qcow2GetClusterSize to qcow2GetImageSpecific storage_file_probe: Move qcow2GetFeatures(ProcessGroup) functions storage_file_probe: Call qcow2GetFeatures from qcow2GetImageSpecific storage_file_probe: Parse all qcow2 extensions at once storage_file_probe: Move setting of 'compat' attribute to qcow2GetFeatures storage_file_probe: Remove unused image probing callbacks src/storage_file/storage_file_probe.c | 439 ++++++++---------- tests/virstoragetest.c | 20 +- .../virstoragetestdata/images/datafile.qcow2 | Bin 327680 -> 393256 bytes .../images/qcow2_qcow2-qcow2_qcow2-auto.qcow2 | Bin 196616 -> 327720 bytes .../images/qcow2datafile-datafile.qcow2 | Bin 196616 -> 327720 bytes tests/virstoragetestdata/out/directory-dir | 1 + tests/virstoragetestdata/out/directory-none | 1 + tests/virstoragetestdata/out/directory-raw | 1 + .../out/qcow2-auto_qcow2-qcow2_raw-raw | 1 + .../out/qcow2-auto_raw-raw-relative | 1 + tests/virstoragetestdata/out/qcow2-datafile | 15 +- .../out/qcow2-protocol-backing-file | 2 + .../out/qcow2-protocol-backing-nbd | 2 + .../out/qcow2-qcow2_nbd-raw | 2 + .../out/qcow2-qcow2_qcow2-auto | 2 + .../out/qcow2-qcow2_qcow2-qcow2_qcow2-auto | 3 + .../out/qcow2-qcow2_qcow2-qcow2_raw-auto | 3 + .../out/qcow2-qcow2_qcow2-qcow2_raw-raw | 3 + .../out/qcow2-qcow2_raw-raw-relative | 2 + tests/virstoragetestdata/out/qcow2-symlinks | 3 + .../out/qcow2datafile-qcow2_qcow2-datafile | 24 +- tests/virstoragetestdata/out/qed-auto_raw | 1 + tests/virstoragetestdata/out/qed-qed_raw | 2 + tests/virstoragetestdata/out/raw-auto | 1 + tests/virstoragetestdata/out/raw-raw | 1 + 25 files changed, 263 insertions(+), 267 deletions(-) -- 2.49.0

2 20

[PATCH 0/3] bhyve: implement domainInterfaceStats and domainMemoryStats
by Roman Bogorodskiy 29 May '25

29 May '25

Roman Bogorodskiy (3): bhyve: implement domainInterfaceStats virprocess: implement virProcessGetStatInfo() for FreeBSD bhyve: implement domainMemoryStats src/bhyve/bhyve_driver.c | 84 +++++++++++++++++++++++++++++++ src/util/virprocess.c | 104 +++++++++++++++++++++++++++++---------- 2 files changed, 162 insertions(+), 26 deletions(-) -- 2.49.0

1 3

[RFC PATCH v3 0/6] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe 29 May '25

29 May '25

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 v3: Supports two launch VM options: personalization-value and measurement-log. The measurement-log was added to allow us to check if the data loaded into the guest RAM is a good image. The Realm Personalization Value (RPV) was added to allow us to distinguish between realms that have the same initial measurement results. This was added as a new Realm startup option in Linaro QEMU after the v2 patch was posted. That's why we made this change. [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, which QEMU does not yet support. We added a QMP command to retrieve CCA info for test (See "[software version]" below). I need to check qemu_firmware.c to see if my CPU firmware supports CCA. Since it's not implemented yet, I'll wait until a Linux distributor provides me with a JSON file for CCA. 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://github.com/Kazuhiro-Abe-fj/linaro_qemu/tree/cca-latest-qmp which is based on Linaro QEMU (cca/latest) https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/latest?ref_type=heads 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… Signed-off-by: Kazuhiro Abe <fj1078ii(a)aa.jp.fujitsu.com> Akio Kakuno (6): 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 qemucapabilitiestest: Adds Arm CCA support domaincapstest: Adds Arm CCA support qemuxmlconftest: Adds Arm CCA support docs/formatdomain.rst | 43 + 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 | 145 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 29 + src/qemu/qemu_driver.c | 2 + src/qemu/qemu_firmware.c | 1 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 98 + 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_9.1.0-virt.aarch64.xml | 244 + tests/domaincapsdata/qemu_9.1.0.aarch64.xml | 244 + .../caps_9.1.0_aarch64.replies | 36222 ++++++++++++++++ .../caps_9.1.0_aarch64.xml | 530 + .../launch-security-cca.aarch64-latest.args | 30 + .../launch-security-cca.aarch64-latest.xml | 24 + tests/qemuxmlconfdata/launch-security-cca.xml | 16 + tests/qemuxmlconftest.c | 2 + 33 files changed, 37851 insertions(+), 1 deletion(-) create mode 100644 tests/domaincapsdata/qemu_9.1.0-virt.aarch64.xml create mode 100644 tests/domaincapsdata/qemu_9.1.0.aarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml -- 2.43.5

4 14

[libvirt PATCHv2 0/7] qemu: introduce amd-iommu support
by Ján Tomko 28 May '25

28 May '25

Ján Tomko (7): qemu: introduce QEMU_CAPS_AMD_IOMMU qemu: introduce QEMU_CAPS_PCI_ID qemu: add IOMMU model amd docs: formatdomain: document intel-only IOMMU attributes conf: add passthrough and xtsup attributes for IOMMU conf: reject some attributes not applicable to intel IOMMU qemu: format pt and xstup on the command line docs/formatdomain.rst | 22 +++- src/conf/domain_conf.c | 31 +++++ src/conf/domain_conf.h | 3 + src/conf/domain_validate.c | 22 ++++ src/conf/schemas/domaincommon.rng | 11 ++ src/qemu/qemu_capabilities.c | 10 ++ src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 30 +++++ src/qemu/qemu_domain_address.c | 4 + src/qemu/qemu_validate.c | 22 ++++ .../caps_10.0.0_x86_64+amdsev.replies | 102 +++++++++++------ .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.replies | 106 ++++++++++++------ .../caps_10.0.0_x86_64.xml | 2 + .../caps_6.2.0_x86_64.replies | 102 +++++++++++------ .../caps_6.2.0_x86_64.xml | 1 + .../caps_7.0.0_x86_64.replies | 80 +++++++------ .../caps_7.0.0_x86_64.xml | 1 + .../caps_7.1.0_x86_64.replies | 102 +++++++++++------ .../caps_7.1.0_x86_64.xml | 1 + .../caps_7.2.0_x86_64+hvf.replies | 102 +++++++++++------ .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.replies | 102 +++++++++++------ .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.replies | 80 +++++++------ .../caps_8.0.0_x86_64.xml | 1 + .../caps_8.1.0_x86_64.replies | 102 +++++++++++------ .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.replies | 102 +++++++++++------ .../caps_8.2.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.replies | 80 +++++++------ .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_x86_64.replies | 102 +++++++++++------ .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_x86_64+amdsev.replies | 102 +++++++++++------ .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.replies | 102 +++++++++++------ .../caps_9.2.0_x86_64.xml | 1 + .../amd-iommu.x86_64-latest.args | 35 ++++++ .../amd-iommu.x86_64-latest.xml | 1 + tests/qemuxmlconfdata/amd-iommu.xml | 39 +++++++ tests/qemuxmlconftest.c | 2 + 42 files changed, 1161 insertions(+), 454 deletions(-) create mode 100644 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/amd-iommu.xml -- 2.49.0

1 7

[PATCH] qemu: Fix error when migration with shared TPM storage is unsupported
by Jiri Denemark 28 May '25

28 May '25

From: Jiri Denemark <jdenemar(a)redhat.com> The VIR_ERR_NO_SUPPORT error is supposed to be used for unsupported driver APIs. It is incorrectly used when swtpm does not support migration with shared storage resulting in a rather strange error message: this function is not supported by the connection driver: the running swtpm does not support migration with shared storage The correct VIR_ERR_OPERATION_UNSUPPORTED error code provides a much better message: Operation not supported: the running swtpm does not support migration with shared storage Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_migration.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 1f91ad1117..2400750ee4 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1723,7 +1723,7 @@ qemuMigrationSrcIsAllowed(virDomainObj *vm, if (qemuTPMHasSharedStorage(driver, vm->def) && !qemuTPMCanMigrateSharedStorage(vm->def)) { - virReportError(VIR_ERR_NO_SUPPORT, "%s", + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", _("the running swtpm does not support migration with shared storage")); return false; } -- 2.49.0

2 1

[PATCH 1/1] NEWS : update NEWS for POWER11 support
by Narayana Murty N 28 May '25

28 May '25

Update NEWS.rst with the now added POWER11 processor support Signed-off-by: Narayana Murty N <nnmlinux(a)linux.ibm.com> --- NEWS.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 0ba2d20191..fd577021b3 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,6 +17,10 @@ v11.4.0 (unreleased) * **New features** + * qemu: ppc64 POWER11 processor support + + Support for the recently released IBM POWER11 processor was added. + * **Improvements** * virsh: Add option ``--no-pkttyagent`` -- 2.48.1

2 1

[PATCH 0/4] An overdue deprecation, a doc fix, a bit of cleanup
by Markus Armbruster 28 May '25

28 May '25

Markus Armbruster (4): docs/about: Belatedly document tightening of QMP device_add checking qapi/migration: Deprecate migrate argument @detach docs/about/deprecated: Move deprecation notes to tidy up order docs/about/removed-features: Move removal notes to tidy up order docs/about/deprecated.rst | 47 +++++++++------------- docs/about/removed-features.rst | 69 +++++++++++++++++++-------------- qapi/migration.json | 18 ++++----- 3 files changed, 67 insertions(+), 67 deletions(-) -- 2.48.1

6 17

[PATCH] passt: Define backend hostname and fqdn
by Enrique Llorente 27 May '25

27 May '25

This commit introduces a feature enhancement for configuring hostnames in virtual machines (VMs) using DHCP. It adds new options to the "passt" tool to set the hostname and fully qualified domain name (FQDN) for VMs. These map to DHCP option 12 for the hostname and options 81 (IPv4) and 39 (IPv6) for the FQDN. The update enables passt to dynamically assign hostnames to DHCP-aware VMs. To achieve this, the commit adds two fields to the passt domain XML backend. These fields allow passt to configure the hostname and FQDN for the virtual machine, ensuring smooth integration with the DHCP protocol. This improvement is particularly valuable in environments where VMs need dynamic hostname configuration, enhancing flexibility and automation in virtualized network setups. libvirt: Integrate passt --hostname --fqdn options Resolves: https://issues.redhat.com/browse/RHEL-79806 Signed-off-by: Enrique Llorente <ellorent(a)redhat.com> --- docs/formatdomain.rst | 8 +++++--- src/conf/domain_conf.c | 10 +++++++++- src/conf/domain_conf.h | 2 ++ src/conf/schemas/domaincommon.rng | 6 ++++++ src/qemu/qemu_passt.c | 6 ++++++ tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml | 2 +- tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml | 2 +- tests/qemuxmlconfdata/net-user-passt.xml | 2 +- .../net-vhostuser-passt.x86_64-latest.xml | 2 +- tests/qemuxmlconfdata/net-vhostuser-passt.xml | 2 +- 10 files changed, 33 insertions(+), 9 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 8753ee9c23..9c80aa9270 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -5372,10 +5372,12 @@ came from the host's IP. There are a few other options that are configurable only for the passt backend. For example, the ``<backend>`` attribute ``logFile`` can be used to tell the passt process for this interface where to write its -message log, and the ``<source>`` attribute ``dev`` can tell it a +message log, the ``<source>`` attribute ``dev`` can tell it a particular host interface to use when deriving the routes given to the -guest for forwarding traffic upstream. Due to the design decisions of -passt, when using SELinux on the host, it is recommended that the log +guest for forwarding traffic upstream and the ``hostname`` and ``fqdn`` +will conigure the DHCP option 12 hostname and DHCP option 81 and DHCPv6 +option 39 fqdn attribute. Due to the design decisions of passt, when using +SELinux on the host, it is recommended that the log file reside in the runtime directory of the user under which the passt process will run, most probably ``/run/user/$UID`` (where ``$UID`` is the UID of that user), e.g. ``/run/user/1000``. Be aware that libvirt diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index b3b0bd7329..15143f8fa2 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -2909,6 +2909,8 @@ virDomainNetDefFree(virDomainNetDef *def) g_free(def->backend.tap); g_free(def->backend.vhost); g_free(def->backend.logFile); + g_free(def->backend.hostname); + g_free(def->backend.fqdn); virDomainNetTeamingInfoFree(def->teaming); g_free(def->virtPortProfile); g_free(def->script); @@ -9757,6 +9759,8 @@ virDomainNetBackendParseXML(xmlNodePtr node, } def->backend.logFile = virXMLPropString(node, "logFile"); + def->backend.hostname = virXMLPropString(node, "hostname"); + def->backend.fqdn = virXMLPropString(node, "fqdn"); if (tap) def->backend.tap = virFileSanitizePath(tap); @@ -20757,7 +20761,9 @@ virDomainNetBackendIsEqual(virDomainNetBackend *src, if (src->type != dst->type || STRNEQ_NULLABLE(src->tap, dst->tap) || STRNEQ_NULLABLE(src->vhost, dst->vhost) || - STRNEQ_NULLABLE(src->logFile, dst->logFile)) { + STRNEQ_NULLABLE(src->logFile, dst->logFile) || + STRNEQ_NULLABLE(src->hostname, dst->hostname) || + STRNEQ_NULLABLE(src->fqdn, dst->fqdn)) { return false; } return true; @@ -24838,6 +24844,8 @@ virDomainNetBackendFormat(virBuffer *buf, virBufferEscapeString(&attrBuf, " tap='%s'", backend->tap); virBufferEscapeString(&attrBuf, " vhost='%s'", backend->vhost); virBufferEscapeString(&attrBuf, " logFile='%s'", backend->logFile); + virBufferEscapeString(&attrBuf, " hostname='%s'", backend->hostname); + virBufferEscapeString(&attrBuf, " fqdn='%s'", backend->fqdn); virXMLFormatElement(buf, "backend", &attrBuf, NULL); } diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 58b97a2b54..79fd2f1f63 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1067,6 +1067,8 @@ struct _virDomainNetBackend { char *vhost; /* The following are currently only valid/used when backend type='passt' */ char *logFile; /* path to logfile used by passt process */ + char *hostname; /* hostname of the passt process */ + char *fqdn; /* fully qualified domain name of the passt process */ }; struct _virDomainNetPortForwardRange { diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng index 5597d5a66b..f64199ca18 100644 --- a/src/conf/schemas/domaincommon.rng +++ b/src/conf/schemas/domaincommon.rng @@ -3913,6 +3913,12 @@ <ref name="absFilePath"/> </attribute> </optional> + <optional> + <attribute name="hostname"/> + </optional> + <optional> + <attribute name="fqdn"/> + </optional> </element> </optional> <optional> diff --git a/src/qemu/qemu_passt.c b/src/qemu/qemu_passt.c index fcc34de384..9ebb766433 100644 --- a/src/qemu/qemu_passt.c +++ b/src/qemu/qemu_passt.c @@ -229,6 +229,12 @@ qemuPasstStart(virDomainObj *vm, if (net->backend.logFile) virCommandAddArgList(cmd, "--log-file", net->backend.logFile, NULL); + if (net->backend.hostname) + virCommandAddArgList(cmd, "--hostname", net->backend.hostname, NULL); + + if (net->backend.fqdn) + virCommandAddArgList(cmd, "--fqdn", net->backend.hostname, NULL); + /* Add IP address info */ for (i = 0; i < net->guestIP.nips; i++) { const virNetDevIPAddr *ip = net->guestIP.ips[i]; diff --git a/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml b/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml index cfe07cc627..77da297936 100644 --- a/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml +++ b/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml @@ -50,7 +50,7 @@ <range start='443' to='344'/> </portForward> <model type='rtl8139'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> diff --git a/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml b/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml index d7e0ef5f90..917a9edaa0 100644 --- a/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml +++ b/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml @@ -50,7 +50,7 @@ <range start='443' to='344'/> </portForward> <model type='rtl8139'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> diff --git a/tests/qemuxmlconfdata/net-user-passt.xml b/tests/qemuxmlconfdata/net-user-passt.xml index 20c9f50542..80d15de2ed 100644 --- a/tests/qemuxmlconfdata/net-user-passt.xml +++ b/tests/qemuxmlconfdata/net-user-passt.xml @@ -47,7 +47,7 @@ <range start='443' to='344'/> </portForward> <model type='rtl8139'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml b/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml index 529aff11f8..5802754c4b 100644 --- a/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml +++ b/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml @@ -53,7 +53,7 @@ <range start='443' to='344'/> </portForward> <model type='virtio'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <interface type='vhostuser'> diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt.xml b/tests/qemuxmlconfdata/net-vhostuser-passt.xml index 71b845329b..0a37511a0f 100644 --- a/tests/qemuxmlconfdata/net-vhostuser-passt.xml +++ b/tests/qemuxmlconfdata/net-vhostuser-passt.xml @@ -50,7 +50,7 @@ <range start='443' to='344'/> </portForward> <model type='virtio'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <interface type='vhostuser'> -- 2.49.0

1 0

[PATCH] NEWS: Make sure releases are separated by two blank lines
by Jiri Denemark 27 May '25

27 May '25

From: Jiri Denemark <jdenemar(a)redhat.com> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- NEWS.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index a880524ca2..0ba2d20191 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -533,6 +533,7 @@ v10.9.0 (2024-11-01) ``<blockers model='...'>`` element is added for that CPU model listing features required by the CPU model, but not supported on the host. + v10.8.0 (2024-10-01) ==================== @@ -668,6 +669,7 @@ v10.7.0 (2024-09-02) Cloud-Hypervisor driver now supports Ethernet, Network (NAT) and Bridge networking modes. + v10.6.0 (2024-08-05) ==================== -- 2.49.0

2 1

[PATCH 0/2] qemu: Fix crash when resuming failed post-copy migration
by Jiri Denemark 27 May '25

27 May '25

Jiri Denemark (2): qemu: Fix crash when resuming failed post-copy migration NEWS: Fix virtqemud crash when resuming failed post-copy migration NEWS.rst | 7 +++++++ src/qemu/qemu_migration.c | 3 ++- 2 files changed, 9 insertions(+), 1 deletion(-) -- 2.49.0

2 4

Entering freeze for libvirt-11.4.0
by Jiri Denemark 27 May '25

27 May '25

I have just tagged v11.4.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 0

[PATCH 0/9] qemu: Move config validation out of qemu_process.c
by Peter Krempa 27 May '25

27 May '25

Some more cleanups for misplaced validation of config that I've noticed when I was looking for the code validating floppies in my previous series. Peter Krempa (9): qemuDomainValidateStorageSource: Rework protocol validation into a switch statement qemu: Move disk backend validation checks from qemuProcessStartValidateDisks to qemuDomainValidateStorageSource qemu: block: Drop code for 'vxhs' storage protocol qemu.conf: Document options for VxHS block network protocol TLS config as ignored qemu: conf: Drop handling of 'vxhs' config options qemu: Move logic from qemuProcessStartValidateShmem to qemuValidateDomainDeviceDefShmem qemu: Move checks for number of listening sockets of graphics to validation code qemuProcessStartValidateGraphics: Remove redundant checks for RDP protocol features qemuProcessStartValidateGraphics: Move RDP validation logic to qemu_validate.c src/qemu/libvirtd_qemu.aug | 2 + src/qemu/qemu.conf.in | 42 +----------- src/qemu/qemu_block.c | 41 +----------- src/qemu/qemu_conf.c | 17 ----- src/qemu/qemu_conf.h | 4 -- src/qemu/qemu_domain.c | 112 +++++++++++++++---------------- src/qemu/qemu_process.c | 132 ------------------------------------- src/qemu/qemu_validate.c | 45 ++++++++++++- tests/qemuxmlconftest.c | 4 -- tests/testutilsqemu.c | 2 - 10 files changed, 101 insertions(+), 300 deletions(-) -- 2.49.0

2 10

[PATCH v2 0/3] CH: Add support for a configuration file and log level configuration
by Stefan Kober 27 May '25

27 May '25

Similar to the qemu.conf file that allows QEMU specific configurations we add the possibility to specify a ch.conf file for Cloud Hypervisor configuration. The initial single config option is the log level, which sets the verbosity of the Cloud Hypervisor process. This allows for simpler debugging when using Cloud Hypervisor via libvirt. Stefan Kober (3): ch: Add config file support ch: add log level configuration option NEWS: ch: announce log_level config option NEWS.rst | 5 +++++ src/ch/ch.conf | 11 ++++++++++ src/ch/ch_conf.c | 31 ++++++++++++++++++++++++++ src/ch/ch_conf.h | 18 +++++++++++++++ src/ch/ch_driver.c | 6 +++++ src/ch/ch_monitor.c | 6 +++++ src/ch/libvirtd_ch.aug | 40 ++++++++++++++++++++++++++++++++++ src/ch/meson.build | 12 ++++++++++ src/ch/test_libvirtd_ch.aug.in | 5 +++++ 9 files changed, 134 insertions(+) create mode 100644 src/ch/ch.conf create mode 100644 src/ch/libvirtd_ch.aug create mode 100644 src/ch/test_libvirtd_ch.aug.in -- 2.49.0

1 3

[PATCH v3 0/3] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling 26 May '25

26 May '25

Changelog v3 - added qemu caps check to avoid breaking s390 guests trying to default deprecated_features='off' on QEMU versions that do not support reporting these features v2 - changed behavior from disabling features on the host model to instead flagging the guest CPU to disable deprecated features - removed disabling deprecated features on host model in virQEMUCapsInitCPUModelS390 - added flagging deprecated_feats in qemuProcessUpdateGuestCPU - added tests for deprecated_features='on' - split virQEMUCapsUpdateCPUDeprecatedFeatures update and qemuProcessUpdateGuestCPU changes The intention of reporting deprecated features and modifying the guest CPU model was to alleviate the user from the burden of preparing a guest with the necessary amendments to assure migration to newer hardware. While that goal was met by way of the "deprecated_features='on|off'" attribute, it still adds an extra step that the user must be aware to prepare a guest for migration and the errors that stem from an unsuccessful migration (due to feature incompatibility) is not always clear how to resolve. These patches make s390 CPU host models migration ready from the get-go by disabling deprecated features by default. They may still be disabled for other model types via the respective attribute, or reenabled if desired. Collin Walling (3): qemu: caps: add virCPUFeaturePolicy param to virQEMUCapsUpdateCPUDeprecatedFeatures qemu: process: refactor deprecated features code qemu: process: disable deprecated features for s390 models by default src/qemu/qemu_capabilities.c | 6 ++-- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_process.c | 32 ++++++++++++++----- ...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++++++++ ...el-deprecated-features-on.s390x-latest.xml | 25 +++++++++++++++ .../cpu-model-deprecated-features-on.xml | 15 +++++++++ ...default-video-type-s390x.s390x-latest.args | 2 +- ...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +- .../launch-security-s390-pv.s390x-latest.args | 2 +- ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +- .../s390-defaultconsole.s390x-latest.args | 2 +- .../s390-panic.s390x-latest.args | 2 +- tests/qemuxmlconftest.c | 1 + 14 files changed, 110 insertions(+), 19 deletions(-) create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml -- 2.47.1

3 9

[PATCH 0/4] qemu: Reflect support of floppy devices in capabilities XML
by Peter Krempa 26 May '25

26 May '25

Probe if qemu actually supports floppy controllers which can be compiled out with custom configs and reflect that in the capability XML. Peter Krempa (4): qemu: domain: Introduce qemuDomainMachineSupportsFloppy qemu: Move floppy device support validation to validation code qemu: capabilities: Introduce QEMU_CAPS_BUS_FLOPPY qemuDomainMachineSupportsFloppy: Check for QEMU_CAPS_BUS_FLOPPY src/qemu/qemu_capabilities.c | 6 ++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 15 +++++++ src/qemu/qemu_domain.h | 4 ++ src/qemu/qemu_process.c | 8 ---- src/qemu/qemu_validate.c | 7 +++ .../qemu_10.0.0-virt.aarch64.xml | 2 - tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 2 - tests/domaincapsdata/qemu_10.0.0.s390x.xml | 2 - tests/domaincapsdata/qemu_8.1.0.s390x.xml | 2 - .../qemu_8.2.0-tcg-virt.loongarch64.xml | 2 - .../qemu_8.2.0-virt.aarch64.xml | 2 - .../qemu_8.2.0-virt.loongarch64.xml | 2 - tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 2 - tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 2 - tests/domaincapsdata/qemu_8.2.0.s390x.xml | 2 - .../qemu_9.1.0-tcg-virt.riscv64.xml | 2 - .../qemu_9.1.0-virt.riscv64.xml | 2 - tests/domaincapsdata/qemu_9.1.0.s390x.xml | 2 - .../qemu_9.2.0-hvf.aarch64+hvf.xml | 2 - tests/domaincapsdata/qemu_9.2.0.s390x.xml | 2 - .../caps_10.0.0_ppc64.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 1 + .../caps_6.2.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 1 + .../caps_7.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 1 + .../caps_7.1.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 + .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.xml | 1 + .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_9.0.0_sparc.xml | 1 + .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.xml | 1 + .../disk-floppy-pseries.ppc64-latest.err | 2 +- .../disk-floppy-pseries.ppc64-latest.xml | 44 ------------------- tests/qemuxmlconftest.c | 2 +- 44 files changed, 53 insertions(+), 86 deletions(-) delete mode 100644 tests/qemuxmlconfdata/disk-floppy-pseries.ppc64-latest.xml -- 2.49.0

2 8

[RFC PATCH 0/2] schemas: path types refactor
by Kirill Shchetiniuk 26 May '25

26 May '25

This series of patches aims to introduce unification for path attributes in schema definitions. Previously defined types used for schema definitions are now unified into two main types: absolutePath and relativePath. This change addresses previous inconsistencies where types were sometimes used incorrectly (e.g., filePath for directory attributes). Due to prior inconsistencies, some locations now accept relative paths even if they were not explicitly intended to. To avoid such inconsistencies in the future, better names for the path types have been selected. Moreover, I suggest deprecating (with future patches) the use of relative paths in places where they are not explicitly meant to be used. This will make the schemas more consistent and, as a result, encourage users to write more deterministic XML definitions. For now the relativePath is used in such places to remain backward compatibility. Kirill Shchetiniuk (2): schemas: path types unification / refactor schemas: path attributes type refactor src/conf/schemas/basictypes.rng | 18 +--- src/conf/schemas/capability.rng | 4 +- src/conf/schemas/domainbackup.rng | 10 +- src/conf/schemas/domaincaps.rng | 2 +- src/conf/schemas/domaincheckpoint.rng | 2 +- src/conf/schemas/domaincommon.rng | 132 +++++++++++++------------- src/conf/schemas/domainsnapshot.rng | 8 +- src/conf/schemas/network.rng | 4 +- src/conf/schemas/nodedev.rng | 4 +- src/conf/schemas/secret.rng | 2 +- src/conf/schemas/storagecommon.rng | 2 +- src/conf/schemas/storagepool.rng | 10 +- src/conf/schemas/storagevol.rng | 6 +- 13 files changed, 96 insertions(+), 108 deletions(-) -- 2.49.0

1 2

[PATCH 0/2] CH: Add support for a configuration file and log level configuration
by Stefan Kober 26 May '25

26 May '25

Similar to the qemu.conf file that allows QEMU specific configurations we add the possibility to specify a ch.conf file for Cloud Hypervisor configuration. The initial single config option is the log level, which sets the verbosity of the Cloud Hypervisor process. This allows for simpler debugging when using Cloud Hypervisor via libvirt. Stefan Kober (2): ch: Add config file support ch: add log level configuration option src/ch/ch_conf.c | 32 ++++++++++++++++++++++++++++++++ src/ch/ch_conf.h | 18 ++++++++++++++++++ src/ch/ch_driver.c | 6 ++++++ src/ch/ch_monitor.c | 6 ++++++ 4 files changed, 62 insertions(+) -- 2.49.0

2 5

[PATCH v2 0/4] domain_capabilities: add console capabilities
by Roman Bogorodskiy 26 May '25

26 May '25

Main change since v1 is adding console capabilities reporting for the libxl driver. There's also a minor cosmetic change in the qemu part to alphabetically sort VIR_DOMAIN_CHR_TYPE_* arguments for VIR_DOMAIN_CAPS_ENUM_SET(). Apparently, the only other driver reporting domain capabilities is the test driver, so it looks like all drivers are covered by this series. Roman Bogorodskiy (4): domain_capabilities: add console capabilities bhyve: capabilities: report NMDM console qemu: capabilities: report supported console types libxl: capabilities: report supported console types src/bhyve/bhyve_capabilities.c | 5 +++ src/conf/domain_capabilities.c | 12 +++++++ src/conf/domain_capabilities.h | 8 +++++ src/conf/schemas/domaincaps.rng | 10 ++++++ src/libxl/libxl_capabilities.c | 23 ++++++++++++- src/qemu/qemu_capabilities.c | 32 +++++++++++++++++++ src/qemu/qemu_capabilities.h | 3 ++ tests/domaincapsdata/bhyve_basic.x86_64.xml | 5 +++ tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 5 +++ tests/domaincapsdata/bhyve_uefi.x86_64.xml | 5 +++ tests/domaincapsdata/libxl-xenfv.xml | 13 ++++++++ tests/domaincapsdata/libxl-xenpv.xml | 13 ++++++++ .../qemu_10.0.0-q35.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 18 +++++++++++ .../qemu_10.0.0-virt.aarch64.xml | 15 +++++++++ tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 15 +++++++++ tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_10.0.0.s390x.xml | 15 +++++++++ .../qemu_10.0.0.x86_64+amdsev.xml | 18 +++++++++++ tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 15 +++++++++ tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 18 +++++++++++ .../qemu_7.2.0-hvf.x86_64+hvf.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_7.2.0-tcg.x86_64+hvf.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.2.0.ppc.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.1.0.s390x.xml | 15 +++++++++ tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_8.2.0-tcg-virt.loongarch64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 18 +++++++++++ .../qemu_8.2.0-virt.aarch64.xml | 16 ++++++++++ .../qemu_8.2.0-virt.loongarch64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.2.0.s390x.xml | 15 +++++++++ tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.0.0.sparc.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_9.1.0-tcg-virt.riscv64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 18 +++++++++++ .../qemu_9.1.0-virt.riscv64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.1.0.s390x.xml | 15 +++++++++ tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 18 +++++++++++ .../qemu_9.2.0-hvf.aarch64+hvf.xml | 16 ++++++++++ .../qemu_9.2.0-q35.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.2.0.s390x.xml | 15 +++++++++ .../qemu_9.2.0.x86_64+amdsev.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 18 +++++++++++ 74 files changed, 1213 insertions(+), 1 deletion(-) -- 2.49.0

2 5

[PATCH v3 0/2] Fix virtio console port assignment issue
by Aaron M. Brown 22 May '25

22 May '25

Changelog: --- v3: - Added Reviewed-By - Included CI Results Link --- v2: - Split patch into two commits - Added fixes tag --- This libvirt patch does the following: 1. fixes an issue with virtio console device port assignment on vioserial buses 2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity Currently in libvirt, a virtio console device cannot be assigned a port number greater than zero on a vioserial bus. This leads to port collision errors when adding more than 1 virtio console device on a single vioserial bus. After applying this patch, one can add multiple console ports under a single vioserial bus. Here is a link to CI results for this series: https://gitlab.com/aaronbmalik/libvirt/-/pipelines/1831901334 Aaron M. Brown (2): Fix virtio console port assignment on vioserial bus Updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity src/conf/domain_addr.c | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) -- 2.39.5 (Apple Git-154)

1 2

[PATCH 0/7] nss: Couple of fixes and small improvements
by Michal Privoznik 22 May '25

22 May '25

I've noticed most of these after I've turned on debugging for the NSS plugin: diff --git i/tools/nss/libvirt_nss.h w/tools/nss/libvirt_nss.h index 54a0216013..f9c3136985 100644 --- i/tools/nss/libvirt_nss.h +++ w/tools/nss/libvirt_nss.h @@ -35 +35 @@ -#if 0 +#if 1 Michal Prívozník (7): libvirt_nss_macs: Fix type of @len in findMACsFromJSON() nss: Add missing includes for gai_strerror() nss: Declare g_autofree and g_steal_pointer() macros libvirt_nss: Use automatic memory freeing libvirt_nss: Drop needless cleanup labels libvirt_nss: Allocate buffer in ERROR() dynamically libvirt_nss: Allocate buffer in aiforaf() dynamically build-aux/syntax-check.mk | 2 +- tools/nss/libvirt_nss.c | 52 +++++++++++++--------------------- tools/nss/libvirt_nss.h | 33 +++++++++++++++++++-- tools/nss/libvirt_nss_leases.c | 3 ++ tools/nss/libvirt_nss_macs.c | 2 +- 5 files changed, 55 insertions(+), 37 deletions(-) -- 2.49.0

6 16

[PATCH] virsh: Do not print warnings with "error:" prefix
by Jiri Denemark 22 May '25

22 May '25

From: Jiri Denemark <jdenemar(a)redhat.com> Both vshWarn and vshError are just wrappers around vshPrintStderr which properly propagates the message level to the log, but fails to honor it when printing on stderr. https://issues.redhat.com/browse/RHEL-79460 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- tools/vsh.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/vsh.c b/tools/vsh.c index 05845e2c1e..e892cbca22 100644 --- a/tools/vsh.c +++ b/tools/vsh.c @@ -2123,7 +2123,11 @@ vshPrintStderr(vshControl *ctl, * printing to stderr will not interleave correctly with stdout * unless we flush between every transition between streams. */ fflush(stdout); - fprintf(stderr, _("error: %1$s\n"), NULLSTR(str)); + + if (level == VSH_ERR_WARNING) + fprintf(stderr, _("warning: %1$s\n"), NULLSTR(str)); + else + fprintf(stderr, _("error: %1$s\n"), NULLSTR(str)); fflush(stderr); } -- 2.49.0

2 1

[PATCH v5 0/5] Adding POWER11 CPU Support
by Narayana Murty N 22 May '25

22 May '25

This patch series introduces the necessary changes to support the POWER11 CPU and POWER11 host in libvirt. Additionally, it updates the QEMU capabilities with the latest QEMU version v10.0.0 to include power11 in the capabilities tests.During testing of v2 patches found a bug in qemu which sets wrong default cpu for pre-9.0 machines, that was fixed in qemu v10.0.0. Patch Summary: Patch 0001: tests: Pin pseries-2.7 tests to the version 7.0. Patch 0002: Fix: qemuhotplugtest Set the cpu version at source as POWER9. Patch 0003: Add capabilities test support for QEMU 10.0.0 on PPC64. Patch 0004: Add POWER11 CPU model support. Patch 0005: Add POWER11 host model support. The corresponding patches for the Linux kernel and QEMU are already upstream. Relevant links are provided below: Linux kernel patches: 1. Linux P11 support: commit c2ed087ed35c ("powerpc: Add Power11 architected and raw mode") 2. Linux P11 KVM support: commit 96e266e3bcd6 ("KVM: PPC: Book3S HV: Add Power11 capability support for Nested PAPR guests") Qemu patches: 3. Qemu P11 support: commit 273db89bcaf4 ("ppc/pseries: Add Power11 cpu type") 4. Qemu P11 DD02.0 support: commit c0d964076c3e ("target/ppc: Add Power11 DD2.0 processor") 5. Qemu pre-9.0 pseries michines changing default cpu with Qemu commit 1490d0bcdfcb ("ppc/spapr: fix default cpu for pre-9.0 machines."). Note on CPU model naming: From the discussion in the community thread (https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/ICUS…) we will continue using the uppercase only for POWER11 for the CPU model name. This is consistent with the naming convention used for existing POWER models (e.g., POWER9, POWER10) in libvirt's CPU map and avoids compatibility issues with existing tooling and test expectations. Signed-off-by: Narayana Murty N <nnmlinux(a)linux.ibm.com> ---- Changelog: -V4: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/ICUS… *Continue to use POWER11 in uppercase, following feedback. *Test data caps_10.0.0.ppc64.replies generated with QEMU v10.0.0. -V3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/PGSB… *Rebased to top of the tree as I saw some tests were failing with recent commits. -V2:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/JQ5UJFWJG35OFX54RQIDHFUSX3RIYIYP/?sort=thread *Instead of removing pseries-2.7 related tests, they are now pinned to the latest available capabilities version 7.0.0. *patch0003: description explained why the cpu version changed. *change the cpu model name to lower case. *Fixing the hotplugtest by setting the cpu version at source as POWER9 *default CPU change for pseries machines preior to pseries-9.0 tests cases for tcg fixed. * Fixing the compat models check for host CPU names in both lowercase and uppercase. -V1:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/4A3IND2QP5CE654XE755ICRZKLUNYXAE/ *Addressed v2 patch readability issues. Narayana Murty N (5): tests: Pin pseries-2.7 tests to the version 7.0 tests: qemuhotplugtest: Set the cpu version at source for PPC64 tests tests: Add capabilities for QEMU 10.0.0 on ppc64 cpu_map: Add POWER11 CPU model support cpu_ppc64: Add POWER11 host-model support src/cpu/cpu_ppc64.c | 8 +- src/cpu_map/index.xml | 1 + src/cpu_map/meson.build | 1 + src/cpu_map/ppc64_POWER11.xml | 6 + tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 191 + .../caps_10.0.0_ppc64.replies | 39513 ++++++++++++++++ .../caps_10.0.0_ppc64.xml | 1088 + .../ppc64-modern-bulk-domain.xml | 3 +- .../ppc64-modern-individual-domain.xml | 3 +- .../disk-floppy-pseries.ppc64-latest.xml | 2 +- .../memory-hotplug-nvdimm-ppc64.xml | 3 +- .../memory-hotplug-ppc64-nonuma.xml | 3 + .../panic-pseries.ppc64-latest.args | 2 +- .../panic-pseries.ppc64-latest.xml | 2 +- ...ault-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} | 0 ...fault-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} | 0 ...ault-cpu-kvm-pseries-3.1.ppc64-latest.args | 2 +- ...fault-cpu-kvm-pseries-3.1.ppc64-latest.xml | 2 +- ...ault-cpu-kvm-pseries-4.2.ppc64-latest.args | 2 +- ...fault-cpu-kvm-pseries-4.2.ppc64-latest.xml | 2 +- ...ault-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} | 0 ...fault-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} | 0 ...efault-models.ppc64-latest.abi-update.args | 4 +- ...default-models.ppc64-latest.abi-update.xml | 2 +- ...4-pseries-default-models.ppc64-latest.args | 4 +- ...64-pseries-default-models.ppc64-latest.xml | 2 +- .../ppc64-pseries-graphics.ppc64-latest.args | 4 +- .../ppc64-pseries-graphics.ppc64-latest.xml | 2 +- .../ppc64-pseries-headless.ppc64-latest.args | 4 +- .../ppc64-pseries-headless.ppc64-latest.xml | 2 +- ...eries-minimal.ppc64-latest.abi-update.args | 2 +- ...series-minimal.ppc64-latest.abi-update.xml | 2 +- .../ppc64-pseries-minimal.ppc64-latest.args | 2 +- .../ppc64-pseries-minimal.ppc64-latest.xml | 2 +- .../ppc64-tpmproxy-single.ppc64-latest.args | 2 +- .../ppc64-tpmproxy-single.ppc64-latest.xml | 2 +- .../ppc64-tpmproxy-with-tpm.ppc64-latest.args | 2 +- .../ppc64-tpmproxy-with-tpm.ppc64-latest.xml | 2 +- .../pseries-basic.ppc64-latest.args | 2 +- .../pseries-basic.ppc64-latest.xml | 2 +- .../pseries-console-virtio.ppc64-latest.args | 2 +- .../pseries-console-virtio.ppc64-latest.xml | 2 +- ...eries-cpu-compat-power11.ppc64-latest.args | 31 + ...series-cpu-compat-power11.ppc64-latest.err | 1 + ...series-cpu-compat-power11.ppc64-latest.xml | 29 + .../pseries-cpu-compat-power11.xml | 19 + .../pseries-cpu-le.ppc64-latest.args | 2 +- .../pseries-cpu-le.ppc64-latest.xml | 2 +- .../pseries-features.ppc64-latest.args | 2 +- .../pseries-features.ppc64-latest.xml | 2 +- .../pseries-hostdevs-1.ppc64-latest.args | 2 +- .../pseries-hostdevs-1.ppc64-latest.xml | 2 +- .../pseries-hostdevs-2.ppc64-latest.args | 2 +- .../pseries-hostdevs-2.ppc64-latest.xml | 2 +- .../pseries-hostdevs-3.ppc64-latest.args | 2 +- .../pseries-hostdevs-3.ppc64-latest.xml | 2 +- .../pseries-many-buses-1.ppc64-latest.args | 2 +- .../pseries-many-buses-1.ppc64-latest.xml | 2 +- .../pseries-many-buses-2.ppc64-latest.args | 2 +- .../pseries-many-buses-2.ppc64-latest.xml | 2 +- .../pseries-many-devices.ppc64-latest.args | 2 +- .../pseries-many-devices.ppc64-latest.xml | 2 +- .../pseries-nvram.ppc64-latest.args | 2 +- .../pseries-nvram.ppc64-latest.xml | 2 +- .../pseries-panic-missing.ppc64-latest.args | 2 +- .../pseries-panic-missing.ppc64-latest.xml | 2 +- ...pseries-panic-no-address.ppc64-latest.args | 2 +- .../pseries-panic-no-address.ppc64-latest.xml | 2 +- ...ries-phb-default-missing.ppc64-latest.args | 2 +- ...eries-phb-default-missing.ppc64-latest.xml | 2 +- .../pseries-phb-numa-node.ppc64-latest.args | 2 +- .../pseries-phb-numa-node.ppc64-latest.xml | 2 +- .../pseries-phb-simple.ppc64-latest.args | 6 +- .../pseries-phb-simple.ppc64-latest.xml | 2 +- .../pseries-phb-user-alias.ppc64-latest.args | 6 +- .../pseries-phb-user-alias.ppc64-latest.xml | 2 +- .../pseries-serial-native.ppc64-latest.args | 2 +- .../pseries-serial-native.ppc64-latest.xml | 2 +- .../pseries-serial-pci.ppc64-latest.args | 2 +- .../pseries-serial-pci.ppc64-latest.xml | 2 +- .../pseries-serial-usb.ppc64-latest.args | 2 +- .../pseries-serial-usb.ppc64-latest.xml | 2 +- .../pseries-usb-default.ppc64-latest.args | 2 +- .../pseries-usb-default.ppc64-latest.xml | 2 +- .../pseries-usb-kbd.ppc64-latest.args | 2 +- .../pseries-usb-kbd.ppc64-latest.xml | 2 +- .../pseries-usb-multi.ppc64-latest.args | 2 +- .../pseries-usb-multi.ppc64-latest.xml | 2 +- ...series-vio-user-assigned.ppc64-latest.args | 7 +- ...pseries-vio-user-assigned.ppc64-latest.xml | 2 +- .../pseries-vio.ppc64-latest.args | 7 +- .../pseries-vio.ppc64-latest.xml | 2 +- ...fault-pseries.ppc64-latest.abi-update.args | 2 +- ...efault-pseries.ppc64-latest.abi-update.xml | 2 +- ...ntroller-default-pseries.ppc64-latest.args | 2 +- ...ontroller-default-pseries.ppc64-latest.xml | 2 +- ...fault-unavailable-pseries.ppc64-latest.xml | 2 +- tests/qemuxmlconftest.c | 8 +- tests/testutilshostcpus.h | 11 + tests/testutilsqemu.c | 4 + tests/testutilsqemu.h | 1 + 101 files changed, 41005 insertions(+), 101 deletions(-) create mode 100644 src/cpu_map/ppc64_POWER11.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0.ppc64.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.xml rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} (100%) rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} (100%) rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} (100%) rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} (100%) create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.args create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.err create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.xml create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.xml -- 2.48.1

3 8

[PATCH] docs: domain: Explain supported options of 'error_policy'
by Peter Krempa 22 May '25

22 May '25

From: Peter Krempa <pkrempa(a)redhat.com> Explain what the individual settings actually result in. The changes are based on the paraprhase of qemu documentation which in 'qemu-options.hx' states: ``werror=action,rerror=action`` Specify which action to take on write and read errors. Valid actions are: "ignore" (ignore the error and try to continue), "stop" (pause QEMU), "report" (report the error to the guest), "enospc" (pause QEMU only if the host disk is full; report the error to the guest otherwise). The default setting is ``werror=enospc`` and ``rerror=report``. Closes: https://gitlab.com/libvirt/libvirt/-/issues/138 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/formatdomain.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index c7c75ae219..a23a746229 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -3451,8 +3451,12 @@ paravirtualized driver is specified via the ``disk`` element. and sync requests from guest are ignored). :since:`Since 0.6.0` - The optional ``error_policy`` attribute controls how the hypervisor will - behave on a disk read or write error, possible values are "stop", - "report" (:since:`since 0.9.7`), "ignore", and "enospace". + behave on a disk read or write error, possible values are ``stop`` ( + suspend/pause the domain on error), ``report`` (report the error to the + guest OS; :since:`since 0.9.7`), ``ignore`` (ignore the error and try to + continue), and ``enospace`` (suspend/pause the domain only if host storage + is full; report the error to the guest OS otherwise). + The default is left to the discretion of the hypervisor. :since:`Since 0.8.0`. - The optional ``rerror_policy`` attribute controls behavior for read -- 2.49.0

2 1

[PATCH v2 0/3] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling 22 May '25

22 May '25

Changelog v2 - changed behavior from disabling features on the host model to instead flagging the guest CPU to disable deprecated features - removed disabling deprecated features on host model in virQEMUCapsInitCPUModelS390 - added flagging deprecated_feats in qemuProcessUpdateGuestCPU - added tests for deprecated_features='on' - split virQEMUCapsUpdateCPUDeprecatedFeatures update and qemuProcessUpdateGuestCPU changes The intention of reporting deprecated features and modifying the guest CPU model was to alleviate the user from the burden of preparing a guest with the necessary amendments to assure migration to newer hardware. While that goal was met by way of the "deprecated_features='on|off'" attribute, it still adds an extra step that the user must be aware to prepare a guest for migration and the errors that stem from an unsuccessful migration (due to feature incompatibility) is not always clear how to resolve. These patches make s390 CPU host models migration ready from the get-go by disabling deprecated features by default. They may still be disabled for other model types via the respective attribute, or reenabled if desired. Collin Walling (3): qemu: caps: add virCPUFeaturePolicy param to virQEMUCapsUpdateCPUDeprecatedFeatures qemu: process: refactor deprecated features code qemu: process: disable deprecated features for s390 models by default src/qemu/qemu_capabilities.c | 6 ++-- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_process.c | 30 ++++++++++++----- ...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++++++++ ...el-deprecated-features-on.s390x-latest.xml | 25 +++++++++++++++ .../cpu-model-deprecated-features-on.xml | 15 +++++++++ ...default-video-type-s390x.s390x-latest.args | 2 +- ...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +- .../launch-security-s390-pv.s390x-latest.args | 2 +- ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +- .../s390-defaultconsole.s390x-latest.args | 2 +- .../s390-panic.s390x-latest.args | 2 +- tests/qemuxmlconftest.c | 1 + 14 files changed, 108 insertions(+), 19 deletions(-) create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml -- 2.47.1

1 5

RFC: schemas: resolving path type inconsistency in XML schemas
by Kirill Shchetiniuk 21 May '25

21 May '25

Hello everyone, Sometime ago I sent a patch changing the XML schema to add GTK support for libvirt. As the type for one path argument, I used the <text/> type, simply copying the similar approach from another place in the XML schema definition. I was told that it's not the best way to use the <text/> type for paths and that absFilePath, a defined basic type for paths, should be used instead. After this, I decided to fix this in a place where I had seen the same approach, too. After further investigation, I found a lot more places where the <text/> type is used for paths. Moreover, I found out that we have at least 4 type definitions for paths (files and directories). Some of these types accept simply everything, others paths starting with "/" or even Windows-style disk names. <define name="filePath"> <data type="string"> <param name="pattern">.+</param> </data> </define> <define name="dirPath"> <data type="string"> <param name="pattern">.+</param> </data> </define> <define name="absFilePath"> <data type="string"> <param name="pattern">(/|[a-zA-Z]:\\).+</param> </data> </define> <define name="absDirPath"> <data type="string"> <param name="pattern">/.*</param> </data> </define> According to this, I have the following questions: 1. Do we allow users to use relative paths, or MUST all paths be absolute? 2. Do we have to accept Windows-style paths everywhere? 3. Do we need to have different types for directories? For example, in some places, the filePath type is used for directory parameters. And as a last question, do we want to unify the basic types related to paths to maintain the schemas more consistent? Kirill

2 1

[PATCH 0/2] qemu: monitor: Fix handling of 'detach' for 'migrate' and 'dump-guest-memory' QMP commands
by Peter Krempa 21 May '25

21 May '25

QEMU is deprecating 'detach' argument of 'migrate' as it was never actually used. Drop it in libvirt as we always specify it. The monitor handler of 'dump-guest-memory' allows controlling 'detach' but always passes true. Libvirt doesn't want to block the monitor so hardcode 'true' in the monitor code instead. Peter Krempa (2): qemuMonitorDumpToFd: Drop 'detach' argument qemuMonitorJSONMigrate: Drop 'detach' QMP option src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_monitor.c | 5 ++--- src/qemu/qemu_monitor.h | 3 +-- src/qemu/qemu_monitor_json.c | 6 ++---- src/qemu/qemu_monitor_json.h | 3 +-- tests/qemumonitorjsontest.c | 3 +-- 6 files changed, 8 insertions(+), 14 deletions(-) -- 2.49.0

2 3

[PATCH] build-aux: simplify grep detection on FreeBSD
by Roman Bogorodskiy 21 May '25

21 May '25

From: Alexey Dokuchaev <danfe(a)FreeBSD.org> For quite some time now FreeBSD provides its own version of the grep(1) tool, and the GNU grep from the ports collection is available as ggrep(1). So remove the detection code and just request ggrep. Signed-off-by: Alexey Dokuchaev <danfe(a)FreeBSD.org> --- build-aux/meson.build | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/build-aux/meson.build b/build-aux/meson.build index bcd10e89f2..56c91971cf 100644 --- a/build-aux/meson.build +++ b/build-aux/meson.build @@ -13,23 +13,10 @@ if git and tests_enabled[0] if host_machine.system() == 'freebsd' or host_machine.system() == 'darwin' make_prog = find_program('gmake') sed_prog = find_program('gsed') + grep_prog = find_program('ggrep') else make_prog = find_program('make') sed_prog = find_program('sed') - endif - - if host_machine.system() == 'freebsd' - grep_prog = find_program('grep') - grep_cmd = run_command(grep_prog, '--version', check: true) - if grep_cmd.stdout().startswith('grep (BSD grep') - grep_prog = find_program('/usr/local/bin/grep', required: false) - if not grep_prog.found() - error('GNU grep not found') - endif - endif - elif host_machine.system() == 'darwin' - grep_prog = find_program('ggrep') - else grep_prog = find_program('grep') endif -- 2.49.0

2 1

[PATCH 1/2] NEWS: bhyve: document NVRAM support
by Roman Bogorodskiy 21 May '25

21 May '25

Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- NEWS.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index e924c08fbf..102e49373a 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -23,6 +23,14 @@ v11.4.0 (unreleased) That option suppresses registration of pkttyagent with polkitd. + * bhyve: support NVRAM configuration for UEFI firmwares + + The bhyve driver now supports specifying NVRAM store file, such as :: + + <os firmware='efi'> + <nvram/> + </os> + * **Bug fixes** * qemu: Fix failure when reverting to internal snapshots -- 2.49.0

2 3