qemu-devel
[Top][All Lists]
Advanced

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

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


From: Nathan Baum
Subject: Re: [Qemu-devel] [RFC][PATCH] Option to continue after migration
Date: Fri, 18 Sep 2009 08:42:26 +0100

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
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]