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

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/23/2011 07:01 AM, 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?

I like to use the phrase "stateful config file".  To me, it's just a 
database for QEMU to persist data about the VM.  It's the only way for 
QEMU to make certain transactions atomic in the face of QEMU crashing.

The user visible config file is a totally different concept.  A 
management tool launches QEMU and tells it where to keep it's state 
database.  The management application may prepopulate the state database 
or it may just use an empty file.

QEMU uses the state database to store information that is created 
dynamically.  For instance, devices added through device_add.  A device 
added via -device wouldn't necessary get added to the state database.

Practically speaking, it let's you invoke QEMU with a fixed command 
line, while still using the monitor to make changes that would otherwise 
require the command line being updated.

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

This is a more elegant solution to the problem than the commit problem 
but it's also a one-off.  I think we have a generic problem here and we 
ought to try to solve it generically (within reason).

Regards,

Anthony Liguori