February 2026 - Devel - libvirt List Archives

[PATCH resend] In virFDStreamRead(), fill buffer from this and next messages
by Erik Huelsmann 23 Feb '26

23 Feb '26

Before this change, buffers returned from virFDStreamRead() would alternate in size (262120 and 24), because it only consumed the bytes remaining from the current background thread message. As the background thread reads 262144 bytes (256kB) of data in each chunk, where the maximum size returned from virFDStreamRead() to be transferred over the remote protocol is only 262120, 24 bytes would be left in the buffer on each iteration. The next iteration leaves 24 bytes, which used to be returned without considering messages waiting in the queue. Signed-off-by: Erik Huelsmann <ehuels(a)gmail.com> --- src/util/virfdstream.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/src/util/virfdstream.c b/src/util/virfdstream.c index 26a1f00..4c974ba 100644 --- a/src/util/virfdstream.c +++ b/src/util/virfdstream.c @@ -905,7 +905,10 @@ static int virFDStreamRead(virStreamPtr st, char *bytes, size_t nbytes) if (fdst->thread) { virFDStreamMsg *msg = NULL; + size_t got = 0; + size_t bsz = 0; + more: while (!(msg = fdst->msg)) { if (fdst->threadQuit || fdst->threadErr) { if (nbytes) { @@ -917,7 +920,7 @@ static int virFDStreamRead(virStreamPtr st, char *bytes, size_t nbytes) virReportSystemError(EBADF, "%s", _("stream is not open")); } else { - ret = 0; + ret = got; } goto cleanup; } else { @@ -931,7 +934,7 @@ static int virFDStreamRead(virStreamPtr st, char *bytes, size_t nbytes) * return 0 immediately. */ if (msg->type == VIR_FDSTREAM_MSG_TYPE_HOLE && msg->stream.hole.len == 0) { - ret = 0; + ret = got; goto cleanup; } @@ -942,21 +945,26 @@ static int virFDStreamRead(virStreamPtr st, char *bytes, size_t nbytes) goto cleanup; } - if (nbytes > msg->stream.data.len - msg->stream.data.offset) - nbytes = msg->stream.data.len - msg->stream.data.offset; + bsz = msg->stream.data.len - msg->stream.data.offset; + if (nbytes < bsz) + bsz = nbytes; - memcpy(bytes, + memcpy(bytes + got, msg->stream.data.buf + msg->stream.data.offset, - nbytes); + bsz); + got += bsz; + nbytes -= bsz; - msg->stream.data.offset += nbytes; + msg->stream.data.offset += bsz; if (msg->stream.data.offset == msg->stream.data.len) { virFDStreamMsgQueuePop(fdst, fdst->fd, "pipe"); virFDStreamMsgFree(msg); } - ret = nbytes; - + ret = got; + if (nbytes > 0) { + goto more; + } } else { retry: ret = read(fdst->fd, bytes, nbytes); -- 2.43.0

4 9

[PATCH v3 00/38] qemu: Implement support for uefi-vars device (varstore element)
by Andrea Bolognani 23 Feb '26

23 Feb '26

This series makes it possible to use Secure Boot with aarch64 VMs. https://issues.redhat.com/browse/RHEL-82645 Note that, while I consider the entire series to be ready for review, there is one patch that is marked as DONOTMERGE: that's because it imports into the tree firmware descriptor that are not yet part of the Fedora edk2 package. Changes from [v2]: * changes to the schema for JSON firmware descriptors have been queued for merge in QEMU, so the corresponding patch is no longer marked as DONOTMERGE; * improve documentation; * rebase on top of master, addressing conflicts that I have caused with some recent changes related to this work. Changes from [v1]: * rewrite based on review feedback: the <nvram> element is no longer used, and a dedicated <varstore> element is introduced instead; * additional test coverage, as well as fixes and improvements related to firmware selection and its documentation, are present as well. [v2] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/WVWT… [v1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/TGLF… Andrea Bolognani (38): qemu_firmware: Only set format for custom loader if path is present conf: Move type=rom default for loader to drivers qemu_firmware: Improve matching when loader.type is absent tests: Rename custom JSON firmware descriptors tests: Update JSON firmware descriptor for BIOS schema: Add varstore element conf: Parse and format varstore element conf: Update validation to consider varstore element qemu_capabilities: Introduce QEMU_CAPS_DEVICE_UEFI_VARS qemu: Validate presence of uefi-vars device tests: Add firmware-manual-efi-varstore-q35 tests: Add firmware-manual-efi-varstore-aarch64 tests: Add firmware-auto-efi-varstore-q35 tests: Add firmware-auto-efi-varstore-aarch64 tests: Add firmware-auto-efi-enrolled-keys-aarch64 qemu_firmware: Parse host-uefi-vars firmware feature qemu_firmware: Split sanity check qemu_firmware: Consider host-uefi-vars feature in sanity check qemu_firmware: Support extended syntax for ROM firmware descriptors qemu_firmware: Report NVRAM template path for ROMs schema: Add varstore element for domcaps conf: Include varstore element in domcaps qemu: Fill in varstore element in domcaps qemu_firmware: Use of NVRAM implies stateful firmware qemu_firmware: Allow matching stateful ROMs qemu_firmware: Fill in varstore information qemu: Introduce varstoreDir qemu_firmware: Generate varstore path when necessary DONOTMERGE: tests: Add firmware descriptors for uefi-vars builds qemu_command: Use uefi-vars device where appropriate qemu: Introduce qemuPrepareNVRAMFileCommon() qemu: Create and delete varstore file security: Mark ROMs as read only when using AppArmor security: Handle varstore file include: Mention varstore where applicable virsh: Update for varstore handling docs: Update for varstore and improve news: Document support for uefi-vars device and firmwares NEWS.rst | 16 ++ docs/formatcaps.rst | 2 +- docs/formatdomain.rst | 47 +++-- docs/formatdomaincaps.rst | 85 +++++--- docs/kbase/secureboot.rst | 46 +++-- docs/manpages/virsh.rst | 44 +++-- include/libvirt/libvirt-domain-snapshot.h | 2 +- include/libvirt/libvirt-domain.h | 4 +- libvirt.spec.in | 1 + src/conf/domain_capabilities.c | 10 + src/conf/domain_capabilities.h | 6 + src/conf/domain_conf.c | 79 +++++++- src/conf/domain_conf.h | 9 + src/conf/domain_postparse.c | 19 -- src/conf/domain_validate.c | 82 +++----- src/conf/schemas/domaincaps.rng | 9 + src/conf/schemas/domaincommon.rng | 64 +++--- src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 2 + src/libxl/libxl_domain.c | 6 + src/qemu/meson.build | 1 + src/qemu/qemu_capabilities.c | 29 ++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 34 ++++ src/qemu/qemu_conf.c | 4 + src/qemu/qemu_conf.h | 1 + src/qemu/qemu_driver.c | 27 ++- src/qemu/qemu_firmware.c | 182 ++++++++++++++++-- src/qemu/qemu_firmware.h | 1 + src/qemu/qemu_process.c | 84 ++++++-- src/qemu/qemu_validate.c | 20 ++ src/security/security_dac.c | 22 ++- src/security/security_selinux.c | 53 +++-- src/security/virt-aa-helper.c | 36 +++- .../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 | 3 + tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 3 + 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 + .../qemu_10.1.0-q35.x86_64+inteltdx.xml | 1 + .../domaincapsdata/qemu_10.1.0-q35.x86_64.xml | 1 + .../qemu_10.1.0-tcg.x86_64+inteltdx.xml | 1 + .../domaincapsdata/qemu_10.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_10.1.0.s390x.xml | 1 + .../qemu_10.1.0.x86_64+inteltdx.xml | 1 + tests/domaincapsdata/qemu_10.1.0.x86_64.xml | 1 + .../qemu_10.2.0-q35.x86_64+mshv.xml | 1 + .../domaincapsdata/qemu_10.2.0-q35.x86_64.xml | 1 + .../qemu_10.2.0-tcg.x86_64+mshv.xml | 1 + .../domaincapsdata/qemu_10.2.0-tcg.x86_64.xml | 1 + .../qemu_10.2.0-virt.aarch64.xml | 3 + tests/domaincapsdata/qemu_10.2.0.aarch64.xml | 3 + .../qemu_10.2.0.x86_64+mshv.xml | 1 + tests/domaincapsdata/qemu_10.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_11.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_11.0.0-tcg.x86_64.xml | 1 + .../qemu_11.0.0-virt.aarch64.xml | 3 + tests/domaincapsdata/qemu_11.0.0.aarch64.xml | 3 + tests/domaincapsdata/qemu_11.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.s390x.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 | 3 + .../qemu_8.2.0-virt.loongarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 3 + 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.sparc.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 | 3 + .../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 + .../caps_10.0.0_aarch64.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.xml | 1 + .../caps_10.1.0_s390x.xml | 1 + .../caps_10.1.0_x86_64+inteltdx.xml | 1 + .../caps_10.1.0_x86_64.xml | 1 + .../caps_10.2.0_aarch64.xml | 1 + .../caps_10.2.0_x86_64+mshv.xml | 1 + .../caps_10.2.0_x86_64.xml | 1 + .../caps_11.0.0_aarch64.xml | 1 + .../caps_11.0.0_x86_64.xml | 1 + .../etc/qemu/firmware/20-bios.json | 1 - .../etc/qemu/firmware/20-libvirt-bios.json | 1 + .../etc/qemu/firmware/59-combined.json | 1 - .../qemu/firmware/59-libvirt-combined.json | 1 + ...{92-masked.json => 92-libvirt-masked.json} | 0 .../{10-bios.json => 10-libvirt-bios.json} | 0 ...0-edk2-ovmf-qemuvars-x64-sb-enrolled.json} | 15 +- .../70-edk2-qemuvars-aarch64-sb-enrolled.json | 28 +++ ...json => 71-edk2-ovmf-qemuvars-x64-sb.json} | 16 +- .../firmware/71-edk2-qemuvars-aarch64-sb.json | 27 +++ ...combined.json => 90-libvirt-combined.json} | 0 .../{91-bios.json => 91-libvirt-bios.json} | 2 +- ...{92-masked.json => 92-libvirt-masked.json} | 0 ...3-invalid.json => 93-libvirt-invalid.json} | 0 tests/qemufirmwaretest.c | 71 ++++--- ...-auto-bios-not-stateless.x86_64-latest.err | 2 +- ...auto-bios-not-stateless.x86_64-latest.xml} | 6 +- ...firmware-auto-bios-nvram.x86_64-latest.err | 2 +- ...are-auto-bios-stateless.x86_64-latest.args | 2 +- ...ware-auto-bios-stateless.x86_64-latest.xml | 2 +- .../firmware-auto-bios.x86_64-latest.args | 2 +- .../firmware-auto-bios.x86_64-latest.xml | 2 +- ...fi-enrolled-keys-aarch64.aarch64-8.2.0.err | 1 + ...enrolled-keys-aarch64.aarch64-latest.args} | 12 +- ...i-enrolled-keys-aarch64.aarch64-latest.xml | 32 +++ ...irmware-auto-efi-enrolled-keys-aarch64.xml | 20 ++ ...-efi-varstore-aarch64.aarch64-latest.args} | 12 +- ...to-efi-varstore-aarch64.aarch64-latest.xml | 32 +++ .../firmware-auto-efi-varstore-aarch64.xml | 18 ++ ...-auto-efi-varstore-q35.x86_64-latest.args} | 5 +- ...e-auto-efi-varstore-q35.x86_64-latest.xml} | 11 +- .../firmware-auto-efi-varstore-q35.xml | 18 ++ ...ual-bios-not-stateless.x86_64-latest.args} | 8 +- ...anual-bios-not-stateless.x86_64-latest.err | 1 - ...nual-bios-not-stateless.x86_64-latest.xml} | 2 +- ...re-manual-bios-stateless.x86_64-latest.xml | 6 +- .../firmware-manual-bios.x86_64-latest.xml | 6 +- ...nual-efi-nvram-stateless.x86_64-latest.err | 2 +- ...nvram-template-stateless.x86_64-latest.err | 2 +- ...ware-manual-efi-rw-nvram.x86_64-latest.err | 2 +- ...ual-efi-varstore-aarch64.aarch64-8.2.0.err | 1 + ...-efi-varstore-aarch64.aarch64-latest.args} | 12 +- ...al-efi-varstore-aarch64.aarch64-latest.xml | 32 +++ .../firmware-manual-efi-varstore-aarch64.xml | 19 ++ ...e-manual-efi-varstore-q35.x86_64-8.2.0.err | 1 + ...anual-efi-varstore-q35.x86_64-latest.args} | 5 +- ...manual-efi-varstore-q35.x86_64-latest.xml} | 11 +- .../firmware-manual-efi-varstore-q35.xml | 19 ++ tests/qemuxmlconftest.c | 16 +- tests/testutilsqemu.c | 2 + tools/virsh-domain.c | 55 ++++-- tools/virsh-snapshot.c | 9 +- 179 files changed, 1314 insertions(+), 380 deletions(-) delete mode 120000 tests/qemufirmwaredata/etc/qemu/firmware/20-bios.json create mode 120000 tests/qemufirmwaredata/etc/qemu/firmware/20-libvirt-bios.json delete mode 120000 tests/qemufirmwaredata/etc/qemu/firmware/59-combined.json create mode 120000 tests/qemufirmwaredata/etc/qemu/firmware/59-libvirt-combined.json rename tests/qemufirmwaredata/etc/qemu/firmware/{92-masked.json => 92-libvirt-masked.json} (100%) rename tests/qemufirmwaredata/home/user/.config/qemu/firmware/{10-bios.json => 10-libvirt-bios.json} (100%) copy tests/qemufirmwaredata/usr/share/qemu/firmware/{90-combined.json => 70-edk2-ovmf-qemuvars-x64-sb-enrolled.json} (55%) create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/70-edk2-qemuvars-aarch64-sb-enrolled.json copy tests/qemufirmwaredata/usr/share/qemu/firmware/{90-combined.json => 71-edk2-ovmf-qemuvars-x64-sb.json} (51%) create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/71-edk2-qemuvars-aarch64-sb.json rename tests/qemufirmwaredata/usr/share/qemu/firmware/{90-combined.json => 90-libvirt-combined.json} (100%) rename tests/qemufirmwaredata/usr/share/qemu/firmware/{91-bios.json => 91-libvirt-bios.json} (90%) rename tests/qemufirmwaredata/usr/share/qemu/firmware/{92-masked.json => 92-libvirt-masked.json} (100%) rename tests/qemufirmwaredata/usr/share/qemu/firmware/{93-invalid.json => 93-libvirt-invalid.json} (100%) copy tests/qemuxmlconfdata/{firmware-auto-bios.x86_64-latest.xml => firmware-auto-bios-not-stateless.x86_64-latest.xml} (84%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-enrolled-keys-aarch64.aarch64-8.2.0.err copy tests/qemuxmlconfdata/{firmware-auto-bios.x86_64-latest.args => firmware-auto-efi-enrolled-keys-aarch64.aarch64-latest.args} (72%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-enrolled-keys-aarch64.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-enrolled-keys-aarch64.xml copy tests/qemuxmlconfdata/{firmware-auto-bios.x86_64-latest.args => firmware-auto-efi-varstore-aarch64.aarch64-latest.args} (72%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-varstore-aarch64.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-varstore-aarch64.xml copy tests/qemuxmlconfdata/{firmware-auto-bios-stateless.x86_64-latest.args => firmware-auto-efi-varstore-q35.x86_64-latest.args} (83%) copy tests/qemuxmlconfdata/{firmware-auto-bios-stateless.x86_64-latest.xml => firmware-auto-efi-varstore-q35.x86_64-latest.xml} (73%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-varstore-q35.xml copy tests/qemuxmlconfdata/{firmware-auto-bios.x86_64-latest.args => firmware-manual-bios-not-stateless.x86_64-latest.args} (84%) delete mode 100644 tests/qemuxmlconfdata/firmware-manual-bios-not-stateless.x86_64-latest.err copy tests/qemuxmlconfdata/{firmware-manual-bios.x86_64-latest.xml => firmware-manual-bios-not-stateless.x86_64-latest.xml} (90%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-varstore-aarch64.aarch64-8.2.0.err copy tests/qemuxmlconfdata/{firmware-auto-bios.x86_64-latest.args => firmware-manual-efi-varstore-aarch64.aarch64-latest.args} (73%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-varstore-aarch64.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-varstore-aarch64.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-varstore-q35.x86_64-8.2.0.err copy tests/qemuxmlconfdata/{firmware-auto-bios.x86_64-latest.args => firmware-manual-efi-varstore-q35.x86_64-latest.args} (85%) copy tests/qemuxmlconfdata/{firmware-auto-bios-stateless.x86_64-latest.xml => firmware-manual-efi-varstore-q35.x86_64-latest.xml} (74%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-varstore-q35.xml -- 2.53.0

4 87

[PATCH] storage: mpath: use device-mapper UUID for volume key
by Lucas Amaral 22 Feb '26

22 Feb '26

The multipath storage backend used the device path (e.g., /dev/mapper/mpathX) as the volume key. Device paths can change across reboots when devices are enumerated in a different order. Use dm_task_get_uuid() to retrieve the device-mapper UUID, which is derived from the underlying hardware identifier and remains stable. Fall back to the device path when a UUID is not available. Signed-off-by: Lucas Amaral <lucaaamaral(a)gmail.com> --- Build-tested and passed full test suite on CentOS Stream 9 (226 OK, 0 failures). Verified dm_task_get_uuid() behavior using a standalone C program that mimics the patched vol->key logic, run against simulated device-mapper devices in a privileged container: $ dmsetup create testmpath0 \ -u "mpath-3600508b4000c4a5d0000300000490000" \ --table "0 1000 zero" $ dmsetup create testmpath1 --table "0 1000 zero" Results: Device: testmpath0 vol->key = mpath-3600508b4000c4a5d0000300000490000 (UUID) Device: testmpath1 (no UUID set) vol->key = /dev/mapper/testmpath1 (path fallback) Device: nonexistent vol->key = /dev/mapper/nonexistent (path fallback) All three cases (UUID present, UUID absent, device missing) behave correctly. Not tested with a running libvirtd and a real mpath pool. --- src/storage/storage_backend_mpath.c | 48 +++++++++++++++++++++++------ 1 file changed, 38 insertions(+), 10 deletions(-) diff --git a/src/storage/storage_backend_mpath.c b/src/storage/storage_backend_mpath.c index 9fc3983c52..a36400502f 100644 --- a/src/storage/storage_backend_mpath.c +++ b/src/storage/storage_backend_mpath.c @@ -40,13 +40,43 @@ VIR_LOG_INIT("storage.storage_backend_mpath"); +static int +virStorageBackendGetDeviceUUID(const char *dev_name, char **uuid) +{ + int ret = -1; + struct dm_task *dmt; + const char *dm_uuid; + + if (!(dmt = dm_task_create(DM_DEVICE_INFO))) + goto out; + + if (!dm_task_set_name(dmt, dev_name)) + goto out; + + if (!dm_task_run(dmt)) + goto out; + + if (!(dm_uuid = dm_task_get_uuid(dmt)) || !*dm_uuid) + goto out; + + *uuid = g_strdup(dm_uuid); + ret = 0; + + out: + if (dmt != NULL) + dm_task_destroy(dmt); + return ret; +} + + static int virStorageBackendMpathNewVol(virStoragePoolObj *pool, const int devnum, - const char *dev) + const char *dev_name) { virStoragePoolDef *def = virStoragePoolObjGetDef(pool); g_autoptr(virStorageVolDef) vol = NULL; + g_autofree char *dev_uuid = NULL; vol = g_new0(virStorageVolDef, 1); @@ -54,15 +84,18 @@ virStorageBackendMpathNewVol(virStoragePoolObj *pool, (vol->name) = g_strdup_printf("dm-%u", devnum); - vol->target.path = g_strdup_printf("/dev/%s", dev); + vol->target.path = g_strdup_printf("/dev/mapper/%s", dev_name); if (virStorageBackendUpdateVolInfo(vol, true, VIR_STORAGE_VOL_OPEN_DEFAULT, 0) < 0) { return -1; } - /* XXX should use logical unit's UUID instead */ - vol->key = g_strdup(vol->target.path); + virStorageBackendGetDeviceUUID(dev_name, &dev_uuid); + if (dev_uuid) + vol->key = g_steal_pointer(&dev_uuid); + else + vol->key = g_strdup(vol->target.path); if (virStoragePoolObjAddVol(pool, vol) < 0) return -1; @@ -151,7 +184,6 @@ virStorageBackendCreateVols(virStoragePoolObj *pool, { uint32_t minor = -1; uint32_t next; - g_autofree char *map_device = NULL; do { int is_mpath = virStorageBackendIsMultipath(names->name); @@ -161,8 +193,6 @@ virStorageBackendCreateVols(virStoragePoolObj *pool, if (is_mpath == 1) { - map_device = g_strdup_printf("mapper/%s", names->name); - if (virStorageBackendGetMinorNumber(names->name, &minor) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to get %1$s minor number"), @@ -170,10 +200,8 @@ virStorageBackendCreateVols(virStoragePoolObj *pool, return -1; } - if (virStorageBackendMpathNewVol(pool, minor, map_device) < 0) + if (virStorageBackendMpathNewVol(pool, minor, names->name) < 0) return -1; - - VIR_FREE(map_device); } /* Given the way libdevmapper returns its data, I don't see -- 2.52.0

1 1

[PATCH] storage: mpath: fix error reporting in virStorageBackendGetMaps
by Lucas Amaral 22 Feb '26

22 Feb '26

virStorageBackendGetMaps() returns 1 on failure instead of the conventional -1, and does not call virReportError() in any of its error paths. On top of that, both callers silently discard the return value: virStorageBackendGetMaps() ignores the result of virStorageBackendCreateVols(), and virStorageBackendMpathRefreshPool() ignores the result of virStorageBackendGetMaps(). Fix all three issues: normalize error returns to -1, add virReportError() calls for each failure path in virStorageBackendGetMaps(), and check return values in both callers so that errors are properly propagated. Signed-off-by: Lucas Amaral <lucaaamaral(a)gmail.com> --- This is similar in spirit to commits e9b931d3e4 ("virpci: Report an error if virPCIGetVirtualFunctionIndex() fails") and 6c2c9e21ac ("virstorageobj: Make virStoragePoolObjAddVol() report an error on failure"), applying the same pattern to the mpath storage backend. Found while auditing storage backends for functions that return error codes without calling virReportError(). src/storage/storage_backend_mpath.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/src/storage/storage_backend_mpath.c b/src/storage/storage_backend_mpath.c index 9fc3983c52..a30153a93b 100644 --- a/src/storage/storage_backend_mpath.c +++ b/src/storage/storage_backend_mpath.c @@ -197,19 +197,25 @@ virStorageBackendGetMaps(virStoragePoolObj *pool) struct dm_names *names = NULL; if (!(dmt = dm_task_create(DM_DEVICE_LIST))) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to create devmapper task")); + retval = -1; goto out; } dm_task_no_open_count(dmt); if (!dm_task_run(dmt)) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to run devmapper task")); + retval = -1; goto out; } if (!(names = dm_task_get_names(dmt))) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to get devmapper device names")); + retval = -1; goto out; } @@ -218,7 +224,10 @@ virStorageBackendGetMaps(virStoragePoolObj *pool) goto out; } - virStorageBackendCreateVols(pool, names); + if (virStorageBackendCreateVols(pool, names) < 0) { + retval = -1; + goto out; + } out: if (dmt != NULL) @@ -248,7 +257,8 @@ virStorageBackendMpathRefreshPool(virStoragePoolObj *pool) virWaitForDevices(); - virStorageBackendGetMaps(pool); + if (virStorageBackendGetMaps(pool) < 0) + return -1; return 0; } -- 2.52.0

1 0

[PATCH 0/3] Add virDomainBlockInfo() support to hyperv driver
by Jonathon Jongsma 20 Feb '26

20 Feb '26

Feature requested by MTV project. See patches for more details Jonathon Jongsma (3): conf: support windows paths in virDomainDiskByName() hyperv: Add resource subtype definitions hyperv: Add basic domainGetBlockInfo() API implementation src/conf/domain_conf.c | 6 +- src/hyperv/hyperv_driver.c | 234 ++++++++++++++++++++++++-- src/hyperv/hyperv_driver.h | 11 ++ src/hyperv/hyperv_wmi.c | 41 +++++ src/hyperv/hyperv_wmi.h | 7 + src/hyperv/hyperv_wmi_generator.input | 109 ++++++++++++ 6 files changed, 392 insertions(+), 16 deletions(-) -- 2.53.0

2 5

[PATCH] virpci: Report an error if virPCIGetVirtualFunctionIndex() fails
by Michal Privoznik 20 Feb '26

20 Feb '26

From: Michal Privoznik <mprivozn(a)redhat.com> Either an error should be returned in all error paths in a function or in none (leaving it up to caller). Well, virPCIGetVirtualFunctionIndex() breaks this pattern. Fix it. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virpci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/util/virpci.c b/src/util/virpci.c index 78c47869ef..ca6f2e8210 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -2870,6 +2870,9 @@ virPCIGetVirtualFunctionIndex(const char *pf_sysfs_device_link, } } + virReportError(VIR_ERR_INTERNAL_ERROR, + _("No virtual function index found for '%1$s'"), + pf_sysfs_device_link); return -1; } -- 2.52.0

3 2

[PATCH v2 0/2] allow migrations with the ext transport
by Sergey Dyasli 19 Feb '26

19 Feb '26

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

3 5

[PATCH 0/2] bhyve: support vcpu pinning
by Roman Bogorodskiy 19 Feb '26

19 Feb '26

Roman Bogorodskiy (2): bhyve: support vcpu pinning bhyve: implement domainGetVcpuPinInfo docs/drvbhyve.rst | 20 +++++ src/bhyve/bhyve_command.c | 15 ++++ src/bhyve/bhyve_driver.c | 74 +++++++++++++++++++ .../x86_64/bhyvexml2argv-vcpupin.args | 15 ++++ .../x86_64/bhyvexml2argv-vcpupin.ldargs | 4 + .../x86_64/bhyvexml2argv-vcpupin.xml | 27 +++++++ tests/bhyvexml2argvtest.c | 1 + 7 files changed, 156 insertions(+) create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-vcpupin.args create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-vcpupin.ldargs create mode 100644 tests/bhyvexml2argvdata/x86_64/bhyvexml2argv-vcpupin.xml -- 2.52.0

2 4

[PATCH] qemu: Report error aborting stopped postcopy migration
by Jiri Denemark 19 Feb '26

19 Feb '26

From: Jiri Denemark <jdenemar(a)redhat.com> When virDomainAbortJob is called with VIR_DOMAIN_ABORT_JOB_POSTCOPY flag and the post-copy migration of the domain is already stopped (either because of a failure or previous call to virDomainAbortJob), the migrate-pause QMP command fails with "migrate-pause is currently only supported during postcopy-active or postcopy-recover state". Such error might be confusing to end users especially when we mark it as an internal error. Let's not call the QMP command at all and report a clear error message instead. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 7f08fd05e9..c5eedeedfa 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -12318,6 +12318,12 @@ qemuDomainAbortJobPostcopy(virDomainObj *vm, return -1; } + if (virDomainObjIsFailedPostcopy(vm, vm->job)) { + virReportError(VIR_ERR_OPERATION_INVALID, "%s", + _("post-copy migration already stopped")); + return -1; + } + VIR_DEBUG("Suspending post-copy migration at client request"); qemuDomainObjAbortAsyncJob(vm); -- 2.53.0

2 1

[PATCH] virstorageobj: Make virStoragePoolObjAddVol() report an error on failure
by Michal Privoznik 19 Feb '26

19 Feb '26

From: Michal Privoznik <mprivozn(a)redhat.com> Adding a storage volume into a pool is done by calling virStoragePoolObjAddVol(). This function may fail if another volume already exists with the same key/name/target. In some cases the storage driver does check for duplicates before calling the function. But in some cases (e.g. when refreshing an RBD pool in virStorageBackendRBDRefreshPool()) it doesn't. The problem here is that the function reports no error upon failure and leaves it as an exercise for caller. Well, no caller does that. Therefore, make the function report an error. The advantage of this approach is - the function can report more accurate error message than any caller ever could. NB¸ this stems from a discussion on the users list [1], and while this does NOT solve the original issue, it fixes one of the symptoms. 1: https://lists.libvirt.org/archives/list/users@lists.libvirt.org/message/BAL… Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- This can be very easily reproduced with test driver. No need for ceph. Just duplicate a volume in a custom test driver XML. Before this patch you'd get: error: failed to connect to the hypervisor error: An error occurred, but the cause is unknown After: error: failed to connect to the hypervisor error: operation failed: volume with target path '/dev/disk/by-path/pci-0000:00:17.0-ata-30' already exist src/conf/virstorageobj.c | 45 +++++++++++++++++++++++++++++++++------- 1 file changed, 37 insertions(+), 8 deletions(-) diff --git a/src/conf/virstorageobj.c b/src/conf/virstorageobj.c index 59fa5da372..ac79ff4c26 100644 --- a/src/conf/virstorageobj.c +++ b/src/conf/virstorageobj.c @@ -621,19 +621,44 @@ virStoragePoolObjAddVol(virStoragePoolObj *obj, virStorageVolObj *volobj = NULL; virStorageVolObjList *volumes = obj->volumes; + if (!voldef->key) { + virReportError(VIR_ERR_OPERATION_FAILED, "%s", + _("volume is missing key")); + return -1; + } + if (!voldef->name) { + virReportError(VIR_ERR_OPERATION_FAILED, "%s", + _("volume is missing name")); + return -1; + } + if (!voldef->target.path) { + virReportError(VIR_ERR_OPERATION_FAILED, "%s", + _("volume is missing target path")); + return -1; + } + virObjectRWLockWrite(volumes); - if (!voldef->key || !voldef->name || !voldef->target.path || - g_hash_table_contains(volumes->objsKey, voldef->key) || - g_hash_table_contains(volumes->objsName, voldef->name) || - g_hash_table_contains(volumes->objsPath, voldef->target.path)) { - virObjectRWUnlock(volumes); - return -1; + if (g_hash_table_contains(volumes->objsKey, voldef->key)) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("volume with key '%1$s' already exist"), + voldef->key); + goto error; + } + if (g_hash_table_contains(volumes->objsName, voldef->name)) { + virReportError(VIR_ERR_STORAGE_VOL_EXIST, + _("'%1$s'"), voldef->name); + goto error; + } + if (g_hash_table_contains(volumes->objsPath, voldef->target.path)) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("volume with target path '%1$s' already exist"), + voldef->target.path); + goto error; } if (!(volobj = virStorageVolObjNew())) { - virObjectRWUnlock(volumes); - return -1; + goto error; } VIR_WITH_OBJECT_LOCK_GUARD(volobj) { @@ -652,6 +677,10 @@ virStoragePoolObjAddVol(virStoragePoolObj *obj, virObjectUnref(volobj); virObjectRWUnlock(volumes); return 0; + + error: + virObjectRWUnlock(volumes); + return -1; } -- 2.52.0

2 1