March 2026 - Devel - libvirt List Archives

[PATCH v2] qemu: fix potential hang in qemuMigrationSrcCancelUnattended during reconnect
by Denis V. Lunev 26 Mar '26

26 Mar '26

When libvirtd reconnects to a running QEMU process that had an in-progress migration, qemuProcessReconnect first connects the monitor and only later recovers the migration job. During this window the async job is VIR_ASYNC_JOB_NONE, so any MIGRATION status events from QEMU are silently dropped by qemuProcessHandleMigrationStatus. If the migration was already cancelled or completed by QEMU during this window, no further events will be emitted. When qemuMigrationSrcCancelUnattended later restores the async job and calls qemuMigrationSrcCancel with wait=true, the wait loop calls qemuDomainObjWait (virCondWait with no timeout) and blocks forever waiting for an event that will never arrive. Fix this by re-querying QEMU migration state with qemuMigrationAnyRefreshStatus after restoring the async job but before calling qemuMigrationSrcCancel. If QEMU has already reached a terminal state, the cancel is skipped. Signed-off-by: Denis V. Lunev <den(a)openvz.org> CC: Jiri Denemark <jdenemar(a)redhat.com> CC: Peter Krempa <pkrempa(a)redhat.com> CC: Michal Privoznik <mprivozn(a)redhat.com> CC: Efim Shevrin <efim.shevrin(a)virtuozzo.com> --- v1 -> v2: Instead of querying QEMU with query-migrate inside qemuMigrationSrcCancel, use qemuMigrationAnyRefreshStatus in qemuMigrationSrcCancelUnattended after restoring the async job to re-check migration state before the actual cancel. src/qemu/qemu_migration.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index fec808ccfb..a4bd7efa09 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -7330,6 +7330,7 @@ int qemuMigrationSrcCancelUnattended(virDomainObj *vm, virDomainJobObj *oldJob) { + virDomainJobStatus migStatus = VIR_DOMAIN_JOB_STATUS_NONE; bool storage = false; size_t i; @@ -7348,11 +7349,20 @@ qemuMigrationSrcCancelUnattended(virDomainObj *vm, VIR_JOB_NONE); } - /* We're inside a MODIFY job and the restored MIGRATION_OUT async job is - * used only for processing migration events from QEMU. Thus we don't want - * to start a nested job for talking to QEMU. + /* Query the actual migration state from QEMU. The state passed to + * qemuProcessRecoverMigrationOut may be stale: QEMU could have + * reached a terminal state between that initial query and the async + * job restore above, with the corresponding event silently dropped. */ - qemuMigrationSrcCancel(vm, VIR_ASYNC_JOB_NONE, true); + qemuMigrationAnyRefreshStatus(vm, VIR_ASYNC_JOB_NONE, &migStatus); + + if (migStatus != VIR_DOMAIN_JOB_STATUS_CANCELED) { + /* We're inside a MODIFY job and the restored MIGRATION_OUT async + * job is used only for processing migration events from QEMU. + * Thus we don't want to start a nested job for talking to QEMU. + */ + qemuMigrationSrcCancel(vm, VIR_ASYNC_JOB_NONE, true); + } virDomainObjEndAsyncJob(vm); -- 2.51.0

2 1

[PATCH] util: Fix comment in virBitmapNewData
by Martin Kletzander 26 Mar '26

26 Mar '26

From: Martin Kletzander <mkletzan(a)redhat.com> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Pushed as trivial. src/util/virbitmap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/util/virbitmap.c b/src/util/virbitmap.c index 1a3e75671c25..78545501b791 100644 --- a/src/util/virbitmap.c +++ b/src/util/virbitmap.c @@ -601,8 +601,7 @@ virBitmapNewCopy(virBitmap *src) * Allocate a bitmap from a chunk of data containing bits * information * - * Returns a pointer to the allocated bitmap or NULL if - * memory cannot be allocated. + * Returns a pointer to the allocated bitmap. */ virBitmap * virBitmapNewData(const void *data, -- 2.53.0

1 0

[PATCH] tests/virhostcputest: Remove duplicit g_autofree
by Martin Kletzander 26 Mar '26

26 Mar '26

From: Martin Kletzander <mkletzan(a)redhat.com> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Pushed as trivial. tests/virhostcputest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/virhostcputest.c b/tests/virhostcputest.c index cf310cb4cec4..4e65e5febf93 100644 --- a/tests/virhostcputest.c +++ b/tests/virhostcputest.c @@ -218,7 +218,7 @@ linuxTestNodeCPUStats(const void *data) const struct nodeCPUStatsData *testData = data; int result = -1; g_autofree char *cpustatfile = NULL; - g_autofree g_autofree char *outfile = NULL; + g_autofree char *outfile = NULL; cpustatfile = g_strdup_printf("%s/virhostcpudata/linux-cpustat-%s.stat", abs_srcdir, testData->name); -- 2.53.0

1 0

[PATCH v2 0/4] hyperv: Add snapshot create/delete support
by Jonathon Jongsma 24 Mar '26

24 Mar '26

Add ability to create and delete basic snapshots in thed hyperv driver. Changes in v2: - re-word error message about configuring disks / memory for snapshots - split out the utility function for extracting async method output params Jonathon Jongsma (4): hyperv: Add snapshot related WMI class definitions hyperv: Implement domainSnapshotDelete() hyperv: Add a utility function for getting method output params hyperv: Implement domainSnapshotCreateXML() src/hyperv/hyperv_driver.c | 129 ++++++++++++++++++++++++ src/hyperv/hyperv_wmi.c | 139 ++++++++++++++++++++++++++ src/hyperv/hyperv_wmi.h | 17 ++++ src/hyperv/hyperv_wmi_generator.input | 42 ++++++++ 4 files changed, 327 insertions(+) -- 2.53.0

1 4

[PATCH 0/4] qemu: Fix multiple issues in block information gathering
by Peter Krempa 24 Mar '26

24 Mar '26

virDomainGetBlockInfo didn't log arguments and updates of disk state qemuDomainGetStatsBlockExportDisk didn't export information about <dataStore> in the bulk stats. Peter Krempa (4): virDomainGetBlockInfo: Log 'disk' argument qemuDomainGetStatsBlockExportDisk: Export stats also for 'dataStore' qemu: monitor: Separate stats from capacity properties in qemuBlockStats qemuDomainGetBlockInfo: Add debug statement when updating disk physical size src/libvirt-domain.c | 9 ++++++--- src/qemu/qemu_driver.c | 15 +++++++++++++++ src/qemu/qemu_monitor.h | 1 + 3 files changed, 22 insertions(+), 3 deletions(-) -- 2.53.0

2 5

[PATCH v2 0/2] qemu: Fix monitor access during offline migration
by Peter Krempa 24 Mar '26

24 Mar '26

New version to fix offline migration. This time for real. Previously I thought I've got the right place, but my migration setup wasn't ready so I didn't bother actually testing it. It turns out that the place I've fixed before didn't actually trigger the bug due to a lucky scenario. Changes to v1: - qemuMigrationSrcBeginXML: Don't call 'qemuMigrationSrcBeginPhaseBlockDirtyBitmaps' with offline VM New patch which actually fixes the bug. - qemuMigrationSrcBeginPhase: Don't call 'qemuBlockNodesEnsureActive' with offline VM Updated commit message now states why 'qemuBlockNodesEnsureActive' doesn't actually cause the same failure due to absence of qemuCaps on an offline VM. Peter Krempa (2): qemuMigrationSrcBeginXML: Don't call 'qemuMigrationSrcBeginPhaseBlockDirtyBitmaps' with offline VM qemuMigrationSrcBeginPhase: Don't call 'qemuBlockNodesEnsureActive' with offline VM src/qemu/qemu_migration.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.53.0

2 3

[PATCH] build: Drop numad dependency on numactl
by Jim Fehlig 24 Mar '26

24 Mar '26

From: Jim Fehlig <jfehlig(a)suse.com> The numad and numactl options are orthogonal. numactl support does not need to be enabled to enable numad support. Drop the dependency. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- AFAIK that's the case. And if not, the dependency should be expressed in the numad package. meson.build | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meson.build b/meson.build index 57a87b9a78..1c2d0deb34 100644 --- a/meson.build +++ b/meson.build @@ -2020,10 +2020,10 @@ if not get_option('nss').disabled() endif endif -if not get_option('numad').disabled() and numactl_dep.found() and host_machine.system() == 'linux' +if not get_option('numad').disabled() and host_machine.system() == 'linux' conf.set('WITH_NUMAD', 1) elif get_option('numad').enabled() - error('You must have a Linux host with numactl enabled for numad support.') + error('You must have a Linux host for numad support.') endif # nwfilter should only be compiled for linux, and only if the -- 2.51.0

2 2

[RFC] Reintroducing customisable hotplug timeouts
by Akash Kulhalli 24 Mar '26

24 Mar '26

I'd like to resurface an earlier proposal [1] to make the unplug timeout user-configurable. With production guests running sustained, non-trivial workloads, we find that hot(un)plug operations regularly takes longer than the current default of 5s. However, the inability to easily configure this timeout means that in the worst case a recompilation with appropriate values set is required for each deployment, which is cumbersome to maintain and patch. The previous proposal [1] also initially made the timeout configurable, however that was specifically for the ppc64 architecture. Therefore, imposing this change for an entire architecture made sense, since it was a universal requirement for that platform. With deployment environments as diverse and varied as x86, having a single, inconfigurable value does not make as much sense now. For x86, such a change is not ideal since the desired timeout value depends very heavily on the deployment environment in use - if it is being performed by a human anything more than 10s is an undesirable user experience [2], as pointed out in the original discussion. However, more relaxed timeout values (e.g. 15-20s) can be more acceptable if the operations are background/ not directly user-facing. It is in these cases where the ability to change the timeout more easily becomes more desirable. To prevent misconfiguration, while maintaining the same out-of-box experience for existing users, I'd also like to propose the following- 1. As mentioned in the original proposal [1], the timeout cannot be set to a value lower than the default timeout of 5s; in these cases a warning will be emitted and the timeout will be reset to the default value. 2. Including an upper cap would also be desirable, in my opinion - any API consumer should not wait endlessly for an async operation to finish. 3. This configuration option will only be described in qemu.conf, not imposed - the out-of-box experience will remain unchanged at the current default (5s) for everyone who does not wish to tweak/is unaware of this value. An administrator who knowingly changes these values is therefore not blindsided by any perceived "hangs" resulting from the use of an increased timeout window. Since this would be a clearly documented and explicitly opt-in behaviour, the benefits in the form of easy modification based on evolving operational needs would be quite significant. Given the varying nature of production environments and specific operational needs at scale, it would therefore be beneficial to reconsider the merits of the original proposal. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/TXYV… [2] https://www.nngroup.com/articles/response-times-3-important-limits/

4 11

Re: [PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field
by Philippe Mathieu-Daudé 24 Mar '26

24 Mar '26

On 24/3/26 04:19, Pierrick Bouvier wrote: > On 3/23/26 8:21 AM, Philippe Mathieu-Daudé wrote: >> SchemaInfoEnumMember::values field has been deprecated for >> more than 5 years (see commit 75ecee72625 "qapi: Enable enum >> member introspection to show more than name"), it should be >> safe enough to remove. >> >> Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> >> --- >> docs/about/deprecated.rst | 6 ------ >> docs/about/removed-features.rst | 7 +++++++ >> qapi/introspect.json | 12 +----------- >> scripts/qapi/introspect.py | 3 +-- >> 4 files changed, 9 insertions(+), 19 deletions(-) >> > > By curiosity, is this patch goal is simply to remove a deprecated > feature/code, or does it unlock something beyond it? > No judgment here, that's a genuine question, and both are valid reasons! In a previous thread Daniel said past deprecation period, feature must be removed, otherwise undeprecated and re-introduced. I'm just trying to be consistent with the deprecation process, removing what doesn't seem worth to re-introduce (for the code I'm able to figure out at least). Maybe we should clarify the deprecation process, clarifying that, and mentioning that maintainers sending pull request to commit patches with deprecations are also a commitment to remove code when the proper released is out. > Looks good to me, to the limit of my qapi knowledge :). > Reviewed-by: Pierrick Bouvier <pierrick.bouvier(a)linaro.org> Thanks!

3 2

Re: [PATCH-for-11.0] qapi: Remove deprecated SchemaInfoEnumMember::values field
by Peter Krempa 24 Mar '26

24 Mar '26

On Mon, Mar 23, 2026 at 20:19:45 -0700, Pierrick Bouvier wrote: > On 3/23/26 8:21 AM, Philippe Mathieu-Daudé wrote: > > SchemaInfoEnumMember::values field has been deprecated for > > more than 5 years (see commit 75ecee72625 "qapi: Enable enum > > member introspection to show more than name"), it should be > > safe enough to remove. > > > > Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> > > --- > > docs/about/deprecated.rst | 6 ------ > > docs/about/removed-features.rst | 7 +++++++ > > qapi/introspect.json | 12 +----------- > > scripts/qapi/introspect.py | 3 +-- > > 4 files changed, 9 insertions(+), 19 deletions(-) > > > > By curiosity, is this patch goal is simply to remove a deprecated > feature/code, or does it unlock something beyond it? > No judgment here, that's a genuine question, and both are valid reasons! This patch also shaves off a nice 1.3k lines of duplicate data from the prettified reply from query-qmp-schema. (In libvirt we capture dumps of the schema which we use for internal testing as well as validation that the monitor command handlers and commandline generators (by proxy) don't use deprecated and or non-existent members.) > Looks good to me, to the limit of my qapi knowledge :). > Reviewed-by: Pierrick Bouvier <pierrick.bouvier(a)linaro.org> On behalf of libvirt (and since I didn't look at the code at all; just at the output): ACKed-by: Peter Krempa <pkrempa(a)redhat.com>

2 1