Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration

[Marcelo Tosatti <mtosatti@redhat.com>]

On Mon, May 09, 2011 at 10:23:03AM -0500, Anthony Liguori wrote:
> On 05/09/2011 08:40 AM, Dor Laor wrote:
> >No patch here (sorry) but collection of thoughts about these features
> >and their potential building blocks. Please review (also on
> >http://wiki.qemu.org/Features/LiveBlockMigration)
> >
> >Future qemu is expected to support these features (some already
> >implemented):
> >
> >* Live block copy
> >
> >Ability to copy 1+ virtual disk from the source backing file/block
> >device to a new target that is accessible by the host. The copy
> >supposed to be executed while the VM runs in a transparent way.
> >
> >Status: code exists (by Marcelo) today in qemu but needs refactoring
> >due to a race condition at the end of the copy operation. We agreed
> >that a re-implementation of the copy operation should take place
> >that makes sure the image is completely mirrored until management
> >decides what copy to keep.
> 
> Live block copy is growing on me.  It can actually be used (with an
> intermediate network storage) to do live block migration.
> 
> >
> >* Live snapshots and live snapshot merge
> >
> >Live snapshot is already incorporated (by Jes) in qemu (still need
> >qemu-agent work to freeze the guest FS).
> 
> Live snapshot is unfortunately not really "live".  It runs a lot of
> operations synchronously which will cause the guest to incur
> downtime.
> 
> We really need to refactor it to truly be live.
> 
> 
> >* Copy on read (image streaming)
> >Ability to start guest execution while the parent image reside
> >remotely and each block access is replicated to a local copy (image
> >format snapshot)
> >
> >It should be nice to have a general mechanism that will be used for
> >all image formats. What about the protocol to access these blocks
> >over the net? We can reuse existing ones (nbd/iscsi).
> 
> I think the image format is really the best place to have this
> logic. Of course, if we have live snapshot merge, we could use a
> temporary QED/QCOW2 file and then merge afterwards.
> 
> >* Using external dirty block bitmap
> >
> >FVD has an option to use external dirty block bitmap file in
> >addition to the regular mapping/data files.
> >
> >We can consider using it for live block migration and live merge too.
> >It can also allow additional usages of 3rd party tools to calculate
> >diffs between the snapshots.
> >There is a big down side thought since it will make management
> >complicated and there is the risky of the image and its bitmap file
> >get out of sync. It's much better choice to have qemu-img tool to be
> >the single interface to the dirty block bitmap data.
> 
> Does the dirty block bitmap need to exist outside of QEMU?
> 
> IOW, if it goes away after a guest shuts down, is that problematic?
> 
> I think it potentially greatly simplifies the problem which makes it
> appealing from my perspective.

One limitation of block copy is the need to rewrite data that differs
from the base image on every "merge". But this is a limitation of qcow2
external snapshots represented as files, not block copy itself (with
external qcow2 snapshots, even a "live block merge" would require
potentially copying large amounts of data).

Only with snapshots internal to an image data copying can be avoided
(and depending on the scenario, this can be a nasty limitation).

> 
> Regards,
> 
> Anthony Liguori