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@xxxxxxxxxx> --- 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list