Re: [Qemu-devel] [RFC]VM live snapshot proposal

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> Il 03/03/2014 14:30, Kevin Wolf ha scritto:
> >> > So why don't we simply reuse the existing migration code?
> >> I think this is different in the same way that block-backup and
> >> block-mirror are different.  Huangpeng's proposal would let you make
> >> a consistent snapshot of disks and RAM.
> >Right. Though the point isn't about consistency (doing the disk snapshot
> >when memory has converged would be consistent as well), but about
> >having the snapshot semantically right at the time when the monitor
> >command is issued instead of only starting it then and being consistent
> >at the point of completion.
> 
> Right---though it's not entirely true that migration only affects
> the point in time where you have consistency.  For example, with
> migration you cannot use the guest agent for freeze/thaw and, even
> if we changed the code to allow that, the pause would be much longer
> than for live snapshots or block-backup.
> 
> >This is indeed like pre/post-copy live migration, and probably both
> >options have their uses. I would suggest starting with the easy one, and
> >adding the post-copy feature on top.
> 
> The feature matrix for migration and snapshot
> 
>                           disk       RAM        internal snapshot
> non-live                  yes (0)    yes (0)    yes
> live, disk only           yes (1)    N/A        yes (2)
> live, pre-copy            yes (3)    yes        no
> live, post-copy           yes (4)    no         no
> live, point-in-time       yes (5)    no         no
> 
>     (0) just stop VM while doing normal pre-copy migration
>     (1) blockdev-snapshot-sync
>     (2) blockdev-snapshot-internal-sync
>     (3) block-stream
>     (4) drive-mirror
>     (5) drive-backup
> 
> By "the easy one" you mean live savevm with snapshot at the end of
> RAM migration, I guess.  But the functionality is already available
> using migration, while point-in-time snapshots actually add new
> functionality.  I'm not sure what's the status of the kernel
> infrastructure for post-copy.  Andrea?

Accumulating the running set of changes that migration is spitting out
gets you some of the way - but to do it you have to have
points in the migration stream which represent a consistent view of
device state, RAM and disk and I think the tricky point is getting
those consistent points; while the CPU is running the set of pages that
migration spits out are certainly newer than old versions of the pages
but I don't think you can just put a marker in and say that the point
represents a single consistent view of RAM.

In many ways this is the opposite of Michael Hines's microcheckpointing approach;
which stops everything and takes the snapshot regularly; I did suggest a
modification to that would be to COW those checkpoints.

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK