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

[Anthony Liguori]

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.

Regards,

Anthony Liguori