February 2026 - Devel - libvirt List Archives

[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

[PATCH 0/6] qemu: Avoid use of regular file FDs with qemu's 'fd:' migration backend
by Peter Krempa 18 Feb '26

18 Feb '26

When reverting a save image in the most naive case libvirt would still try to use a regular file FD with the 'fd:' migration backend in qemu which will no longer work as of qemu-11.0. This patchet addresses it by using the filewrapper for all cases to pass pipes to 'fd' instead. In addition this patchset also adds a check that if 'sparse' save image format is used which requires the 'file' backend in qemu that a regular file FD is indeed passed to qemu. Peter Krempa (6): qemuSaveImageOpen: Remove wrong ATTRIBUTE_NONNULL qemuMonitorMigrateToFdSet: Drop 'flags' argument virfile: Introduce 'virFileFDIsRegular' qemuSaveImageCreateFd: Handle case when 'virQEMUFileOpenAs' doesn't return a file fd for 'sparse' format qemu: driver: Merge 'qemuDomainRestoreInternal' and 'qemuDomainObjRestore' qemu: saveimage: Use 'virFileWrapperFd' when loading non-sparse saveimage src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 254 +++++++++++++++++++------------------- src/qemu/qemu_migration.c | 2 +- src/qemu/qemu_monitor.c | 6 +- src/qemu/qemu_monitor.h | 1 - src/qemu/qemu_saveimage.c | 48 +++++-- src/qemu/qemu_saveimage.h | 6 +- src/qemu/qemu_snapshot.c | 12 +- src/util/virfile.c | 8 ++ src/util/virfile.h | 1 + 10 files changed, 191 insertions(+), 148 deletions(-) -- 2.53.0

2 7

[RFC PATCH 0/3] qemu: Support vCMDQ
by Nathan Chen 18 Feb '26

18 Feb '26

Hi, This is a follow up to the previous RFC patchset [0] for supporting Tegra241 vCMDQ, separated out from the series for accelerated SMMUv3. This patchset is tested with Shameer's v2 qemu series [1] for vCMDQ support. The accelerated SMMUv3 series for qemu and Libvirt [2] are pre-requisites for vCMDQ support, as accelerated SMMUv3 must be enabled alongside vCMDQ. A new 'cmdqv' <iommu> driver attribute is introduced to toggle enabling vCMDQ support. An additional 'identifier' <iommu> driver attribute is introduced to specify an enumeration-independent SMMUv3 device identifier. This identifier is used so that both Tegra DSDT and SMMUv3 IORT use the same identifier. For instance, specifying hostdevs associated with multiple accelerated SMMUs + CMDQV enabled, configured to be routed to pcie-expander-bus controllers in a way where VFIO device to SMMUv3 associations are matched with the host: <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> <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> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> <iommu model='smmuv3'> <driver pciBus='1' accel='on' ats='on' ril='on' ssidSize='20' oas='44' cmdqv='on' identifier='0'/> </iommu> <iommu model='smmuv3'> <driver pciBus='2' accel='on' ats='on' ril='on' ssidSize='20' oas='44' cmdqv='on' identifier='1'/> </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"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.1","id":"iommu0","accel":true,"ats":true,"tegra241-cmdqv":true,"identifier":0,"ril":true,"pasid":true,"oas":44}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.2","id":"iommu1","accel":true,"ats":true,"tegra241-cmdqv":true,"identifier":1,"ril":true,"pasid":true,"oas":44}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","bus":"pci.22","addr":"0x0"}' \ This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/cmdqv-02-26/ Thanks, Nathan Changes: - Support 'identifier' attribute for SMMUv3 [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/VRS… [1] https://lore.kernel.org/qemu-devel/20260206144823.80655-1-skolothumtho@nvid… [2] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5GG7… Nathan Chen (3): qemu: Support NVIDIA Tegra241 CMDQV for SMMUv3 qemu: Support enumeration-independent SMMUv3 identifier tests: qemuxmlconfdata: provide cmdqv sample XML and CLI args docs/formatdomain.rst | 13 ++++ src/conf/domain_conf.c | 32 ++++++++++ src/conf/domain_conf.h | 2 + src/conf/domain_validate.c | 8 ++- src/conf/schemas/domaincommon.rng | 10 ++++ src/qemu/qemu_command.c | 2 + ...u-smmuv3-pci-bus-cmdqv.aarch64-latest.args | 40 +++++++++++++ ...mu-smmuv3-pci-bus-cmdqv.aarch64-latest.xml | 59 +++++++++++++++++++ .../iommu-smmuv3-pci-bus-cmdqv.xml | 49 +++++++++++++++ tests/qemuxmlconftest.c | 1 + 10 files changed, 215 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-cmdqv.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-cmdqv.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-cmdqv.xml -- 2.43.0

2 6