[PATCH v2 0/2] qemu: Fix monitor access during offline migration
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
From: Peter Krempa <pkrempa@redhat.com> Commit a4f610ff3fe190058f1 made the call to 'qemuMigrationSrcBeginPhaseBlockDirtyBitmaps' inside 'qemuMigrationSrcBeginXML' unconditional. This unfortunately means that it was called also with 'VIR_MIGRATE_OFFLINE'. Attempting to enter the monitor in such case results in an error: error: operation failed: domain is no longer running Restrict the call only to non-offline migration. Fixes: a4f610ff3fe190058f18baea18b095d0bc69441b Resolves: https://redhat.atlassian.net/browse/RHEL-156800 Closes: https://gitlab.com/libvirt/libvirt/-/work_items/865 Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- src/qemu/qemu_migration.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index fec808ccfb..cd4ddde897 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2692,7 +2692,8 @@ qemuMigrationSrcBeginXML(virDomainObj *vm, if (!(mig = qemuMigrationCookieNew(vm->def, priv->origname))) return NULL; - if (qemuMigrationSrcBeginPhaseBlockDirtyBitmaps(mig, vm) < 0) + if (!(flags & VIR_MIGRATE_OFFLINE) && + qemuMigrationSrcBeginPhaseBlockDirtyBitmaps(mig, vm) < 0) return NULL; if (qemuMigrationCookieFormat(mig, driver, vm, -- 2.53.0
From: Peter Krempa <pkrempa@redhat.com> Commits 7b5566ce67b18a and f879d5f40385358 ( v11.8.0-92-gf879d5f403 ) moved around code for re-activating block backends after migration. While previously it was done when migration failed now we do it when we need qemu to do some block operations. 'qemuBlockNodesEnsureActive' is thus called also when 'VIR_MIGRATE_OFFLINE' is used. This doesn't cause failure similar to previous patch only due to a conincidence as 'qemuCaps' wasn't initialized yet and thus we assume that QEMU doesn't support 'blockdev-set-active' and skip all monitor code. Make the code more robust and explicit by calling 'qemuBlockNodesEnsureActive' only on active VMs during migration. Fixes: 7b5566ce67b18a2bebe68fdb07e046f25185f8d3 Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- src/qemu/qemu_migration.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index cd4ddde897..c0fa4623a4 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2871,7 +2871,8 @@ qemuMigrationSrcBeginPhase(virQEMUDriver *driver, vm->newDef && !qemuDomainVcpuHotplugIsInOrder(vm->newDef))) cookieFlags |= QEMU_MIGRATION_COOKIE_CPU_HOTPLUG; - if (qemuBlockNodesEnsureActive(vm, vm->job->asyncJob) < 0) + if (virDomainObjIsActive(vm) && + qemuBlockNodesEnsureActive(vm, vm->job->asyncJob) < 0) return NULL; return qemuMigrationSrcBeginXML(vm, xmlin, -- 2.53.0
participants (1)
-
Peter Krempa