Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy

[Marcelo Tosatti <mtosatti@redhat.com>]

On Wed, Feb 23, 2011 at 03:01:14PM +0200, Avi Kivity wrote:
> On 02/23/2011 01:14 AM, Anthony Liguori wrote:
> >
> >-drive already ties into the qemuopts infrastructure and we have
> >readconfig and writeconfig.  I don't think we're missing any major
> >pieces to do this in a more proper fashion.
> 
> The problem with qemu config files is that it splits the
> authoritative source of where images are stored into two.  Is it in
> the management tool's database or is it in qemu's config file?
> 
> For the problem at hand, one solution is to make qemu stop after the
> copy, and then management can issue an additional command to
> rearrange the disk and resume the guest.  A drawback here is that if
> management dies, the guest is stopped until it restarts.  We also
> make management latency guest visible, even if it doesn't die at an
> inconvenient place.
> 
> An alternative approach is to have the copy be performed by a new
> layered block format driver:
> 
> - create a new image, type = live-copy, containing three pieces of
> information
>    - source image
>    - destination image
>    - copy state (initially nothing is copied)
> - tell qemu switch to the new image
> - qemu starts copying, updates copy state as needed
> - copy finishes, event is emitted; reads and writes still serviced
> - management receives event, switches qemu to destination image
> - management removes live-copy image
> 
> If management dies while this is happening, it can simply query the
> state of the copy.  
> Similarly, if qemu dies, the copy state is persistent (could be 0/1 or
> real range of blocks).

You don't know if a given block is uptodate or not without the dirty
bitmap. So unless you also keep track of dirty log somehow, this is
meaningless.

So a commit file as proposed indicates copy state (in 0/1 fashion). The
difference in your proposal is that such information is stored inside a
special purpose image format?