[Qemu-devel] [PATCH] Option to continue after migration

[Qemu-devel] [PATCH] Option to continue after migration

[Nathan Baum]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Hello,

This patch adds a -c "continue" option to the migrate command which
causes the originating VM to remain running after migration, assuming it
was running before.

I've done this primarily so that I can do "migrate -d -c exec:cat>file"
to take a snapshot without needing to have a snapshot-capable drive
attached, or wait until migration is complete and continue the VM
manually.

Signed-off-by: Nathan Baum <nathan@parenthephobia.org.uk>


[-- Attachment #2: continue-after-migration.patch --]
[-- Type: text/x-patch, Size: 1860 bytes --]

diff --git a/migration.c b/migration.c
index 7f93e3f..9536098 100644
--- a/migration.c
+++ b/migration.c
@@ -72,6 +72,7 @@ void do_migrate(Monitor *mon, const QDict *qdict)
     else
         monitor_printf(mon, "unknown migration protocol: %s\n", uri);
 
+    s->stop_at_end = !qdict_get_int(qdict, "continue");
     if (s == NULL)
         monitor_printf(mon, "migration failed\n");
     else {
@@ -287,6 +288,9 @@ void migrate_fd_put_ready(void *opaque)
             state = MIG_STATE_ERROR;
         } else {
             state = MIG_STATE_COMPLETED;
+	    if (!s->mig_state.stop_at_end && old_vm_running) {
+	      vm_start();
+	    }
         }
         migrate_fd_cleanup(s);
         s->state = state;
diff --git a/migration.h b/migration.h
index 53b923d..ea2610b 100644
--- a/migration.h
+++ b/migration.h
@@ -26,6 +26,7 @@ typedef struct MigrationState MigrationState;
 
 struct MigrationState
 {
+    int stop_at_end;
     /* FIXME: add more accessors to print migration info */
     void (*cancel)(MigrationState *s);
     int (*get_status)(MigrationState *s);
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 9f91873..168fe8c 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -466,11 +466,13 @@ STEXI
 Inject an NMI on the given CPU (x86 only).
 ETEXI
 
-    { "migrate", "detach:-d,uri:s", do_migrate,
-      "[-d] uri", "migrate to URI (using -d to not wait for completion)" },
+    { "migrate", "detach:-d,continue:-c,uri:s", do_migrate,
+      "[-d] [-c] uri", "migrate to URI (using -d to migrate in background, and"
+                       " -c to not stop this VM afterward)" },
 STEXI
 @item migrate [-d] @var{uri}
-Migrate to @var{uri} (using -d to not wait for completion).
+Migrate to @var{uri} (using -d to migrate in background, and -c to not stop
+this VM afterward).
 ETEXI
 
     { "migrate_cancel", "", do_migrate_cancel,

Re: [Qemu-devel] [PATCH] Option to continue after migration

[Jamie Lokier]

Nathan Baum wrote:
> Hello,
> 
> This patch adds a -c "continue" option to the migrate command which
> causes the originating VM to remain running after migration, assuming it
> was running before.
> 
> I've done this primarily so that I can do "migrate -d -c exec:cat>file"
> to take a snapshot without needing to have a snapshot-capable drive
> attached, or wait until migration is complete and continue the VM
> manually.

When you later resume from the snapshot, isn't the state of virtual
disks corrupted by the activity after the snapshot was taken?  When
the guest resumes, even though the disks will be corrupted, it won't
_know_ they are corrupted (unlike a reboot), so may proceed to make
things worse.

-- Jamie

Re: [Qemu-devel] [RFC][PATCH] Option to continue after migration

[Nathan Baum]

I see from browsing the list a little more that I should have stuck
[RFC] in my subject lin.

On Fri, 2009-09-18 at 02:52 +0100, Jamie Lokier wrote:
> Nathan Baum wrote:
> > Hello,
> > 
> > This patch adds a -c "continue" option to the migrate command which
> > causes the originating VM to remain running after migration, assuming it
> > was running before.
> > 
> > I've done this primarily so that I can do "migrate -d -c exec:cat>file"
> > to take a snapshot without needing to have a snapshot-capable drive
> > attached, or wait until migration is complete and continue the VM
> > manually.
> 
> When you later resume from the snapshot, isn't the state of virtual
> disks corrupted by the activity after the snapshot was taken?  When
> the guest resumes, even though the disks will be corrupted, it won't
> _know_ they are corrupted (unlike a reboot), so may proceed to make
> things worse.

Yes. This is not specific to my patch, but it does limit its
applicability.

You probably only want to snapshot-and-continue if you have no writable
media -- i.e. you're booting a LiveCD, or you have writable media in
snapshot mode, have stopped and committed immediately before saving the
state this way, and haven't committed since.

In this latter case, my patch wouldn't be useful to you since you
stopped the VM prior to the commit anyway, and my patch only continues
if the VM is still running at the end of the migration. (Maybe it should
force a continue; then you could chuck "stop\ncommit all\nmigrate -d
-c ..." at the monitor.)

I think a far superior alternative approach would be to add "-snapshots
file" option (or similar) to specify a file savevm/loadvm should use for
VM state, and a "-snapshotsdir dir" option which makes QEMU quietly
replace each not-snapshot-capable drive with a qcow2 based on it in that
directory. (Or all the snapshot data could be in the snapshots file;
that looks more complicated to implement.)

> 
> -- Jamie
> 
> 

[Qemu-devel] Re: [RFC][PATCH] Option to continue after migration

[Jan Kiszka]

Nathan Baum wrote:
> I see from browsing the list a little more that I should have stuck
> [RFC] in my subject lin.
> 
> On Fri, 2009-09-18 at 02:52 +0100, Jamie Lokier wrote:
>> Nathan Baum wrote:
>>> Hello,
>>>
>>> This patch adds a -c "continue" option to the migrate command which
>>> causes the originating VM to remain running after migration, assuming it
>>> was running before.
>>>
>>> I've done this primarily so that I can do "migrate -d -c exec:cat>file"
>>> to take a snapshot without needing to have a snapshot-capable drive
>>> attached, or wait until migration is complete and continue the VM
>>> manually.
>> When you later resume from the snapshot, isn't the state of virtual
>> disks corrupted by the activity after the snapshot was taken?  When
>> the guest resumes, even though the disks will be corrupted, it won't
>> _know_ they are corrupted (unlike a reboot), so may proceed to make
>> things worse.
> 
> Yes. This is not specific to my patch, but it does limit its
> applicability.
> 
> You probably only want to snapshot-and-continue if you have no writable
> media -- i.e. you're booting a LiveCD, or you have writable media in
> snapshot mode, have stopped and committed immediately before saving the
> state this way, and haven't committed since.
> 
> In this latter case, my patch wouldn't be useful to you since you
> stopped the VM prior to the commit anyway, and my patch only continues
> if the VM is still running at the end of the migration. (Maybe it should
> force a continue; then you could chuck "stop\ncommit all\nmigrate -d
> -c ..." at the monitor.)
> 
> I think a far superior alternative approach would be to add "-snapshots
> file" option (or similar) to specify a file savevm/loadvm should use for
> VM state, and a "-snapshotsdir dir" option which makes QEMU quietly
> replace each not-snapshot-capable drive with a qcow2 based on it in that
> directory. (Or all the snapshot data could be in the snapshots file;
> that looks more complicated to implement.)

"Migration without shared storage" should once solve this, see Liran's
patches [1]. Your patch will be very helpful in that scenario.

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/52252

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH] Option to continue after migration

[Anthony Liguori]

Nathan Baum wrote:
> Hello,
>
> This patch adds a -c "continue" option to the migrate command which
> causes the originating VM to remain running after migration, assuming it
> was running before.
>
> I've done this primarily so that I can do "migrate -d -c exec:cat>file"
>   

Just do a 'cont' as soon as migration completes.  If you don't use -d, 
you'll have a way to be notified when migration completes.

Regards,

Anthony Liguori