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

[Avi Kivity <avi@redhat.com>]

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

-- 
error compiling committee.c: too many arguments to function