[PATCH] Explicitly set VM state to paused after migration completes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In v3 migration, once migration is completed, the VM needs
to be left in a paused state until after Finish3 has been
executed on the target. Only then will the VM be killed
off. When using non-JSON QEMU monitor though, we don't
receive any 'STOP' event from QEMU, so we need to manually
set our state offline & thus release lock manager leases.
It doesn't hurt to run this on the JSON case too, just in
case the event gets lost somehow

* src/qemu/qemu_migration.c: Explicitly set VM state to
  paused when migration completes
---
 src/qemu/qemu_migration.c |   28 +++++++++++++++++++++++++++-
 1 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index f4eda92..aa74d86 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -718,7 +718,7 @@ qemuMigrationSetOffline(struct qemud_driver *driver,
                         virDomainObjPtr vm)
 {
     int ret;
-
+    VIR_DEBUG("driver=%p vm=%p", driver, vm);
     ret = qemuProcessStopCPUs(driver, vm, VIR_DOMAIN_PAUSED_MIGRATION);
     if (ret == 0) {
         virDomainEventPtr event;
@@ -1521,6 +1521,19 @@ static int doNativeMigrate(struct qemud_driver *driver,
     if (qemuMigrationWaitForCompletion(driver, vm) < 0)
         goto cleanup;
 
+    /* When migration completed, QEMU will have paused the
+     * CPUs for us, but unless we're using the JSON monitor
+     * we won't have been notified of this, so might still
+     * think we're running. For v2 protocol this doesn't
+     * matter because we'll kill the VM soon, but for v3
+     * this is important because we stay paused until the
+     * confirm3 step, but need to release the lock state
+     */
+    if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) {
+        if (qemuMigrationSetOffline(driver, vm) < 0)
+            goto cleanup;
+    }
+
     if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen, 0) < 0)
         VIR_WARN("Unable to encode migration cookie");
 
@@ -1816,6 +1829,19 @@ static int doTunnelMigrate(struct qemud_driver *driver,
 
     ret = qemuMigrationWaitForCompletion(driver, vm);
 
+    /* When migration completed, QEMU will have paused the
+     * CPUs for us, but unless we're using the JSON monitor
+     * we won't have been notified of this, so might still
+     * think we're running. For v2 protocol this doesn't
+     * matter because we'll kill the VM soon, but for v3
+     * this is important because we stay paused until the
+     * confirm3 step, but need to release the lock state
+     */
+    if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) {
+        if (qemuMigrationSetOffline(driver, vm) < 0)
+            goto cleanup;
+    }
+
     /* Close now to ensure the IO thread quits & is joinable in next method */
     VIR_FORCE_CLOSE(client_sock);
 
-- 
1.7.4.4

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]