]> xenbits.xensource.com Git - people/liuw/libxenctrl-split/libvirt.git/commitdiff
qemu: Wait until destination QEMU consumes all migration data
authorJiri Denemark <jdenemar@redhat.com>
Fri, 2 Oct 2015 10:08:26 +0000 (12:08 +0200)
committerJiri Denemark <jdenemar@redhat.com>
Tue, 6 Oct 2015 14:15:21 +0000 (16:15 +0200)
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@redhat.com>
src/qemu/qemu_migration.c

index cf3df64b9b3a3d328e96cccd51563a6ee718f2fb..fa81a168e617e36ef843602c3b834db24f0c110b 100644 (file)
@@ -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