Even though QEMU on the source host reports completed migration and thus
we move to the Finish phase, QEMU on the destination host may still be
processing migration data. Thus before we can start guest CPUs on the
destination, we have to wait for a completed migration event.
https://bugzilla.redhat.com/show_bug.cgi?id=1265902
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/qemu/qemu_migration.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index cf3df64..fa81a16 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -5725,6 +5725,27 @@ qemuMigrationFinish(virQEMUDriverPtr driver,
}
}
+ /* We need to wait for QEMU to process all data sent by the source
+ * before starting guest CPUs.
+ */
+ if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_MIGRATION_EVENT)) {
+ int rv;
+ VIR_DEBUG("Waiting for migration to complete");
+ while ((rv = qemuMigrationCompleted(driver, vm,
+ QEMU_ASYNC_JOB_MIGRATION_IN,
+ NULL, 0)) != 1) {
+ if (rv < 0 || virDomainObjWait(vm) < 0) {
+ /* There's not much we can do for v2 protocol since the
+ * original domain on the source host is already gone.
+ */
+ if (v3proto)
+ goto endjob;
+ else
+ break;
+ }
+ }
+ }
+
if (!(flags & VIR_MIGRATE_PAUSED)) {
/* run 'cont' on the destination, which allows migration on qemu
* >= 0.10.6 to work properly. This isn't strictly necessary on
--
2.6.0