On Thu, Feb 24, 2011 at 05:28:20PM +0200, Avi Kivity wrote:
On 02/24/2011 05:14 PM, Marcelo Tosatti wrote:
>> 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
There is a similar situation with atomicity here. Mgmt app requests a
switch and dies immediately, before receiving the command reply. Qemu
crashes. Which image is the uptodate one, source or live-copy?
live-copy (or it's new name, RAID-1). Once you've created it it is
equivalent to source. Once it switches to state=synced you can
switch back to either source or destination (I guess by telling qemu
to detach the one you don't want first, so it falls back to
state=degraded).
You could hot-unplug the image and hot-plug it later (continuing the
copy with qemu-img),
Then there's no need for live copy. qemu-img does that already.
It will start from the beginning.
or live migrate it.
You can live migrate (but not live migrate with live block migration)
with live copy in progress, its just that its not supported yet.
A RAID-1 driver will work with block live migration too.
Nobody cares about that one (block copy and block live migration in
progress). In fact, i doubt anybody cares about parallel block migration
and block copy either (mgmt can easily cope with that limitation, stop
live copy if migration is needed).
In fact I think a qemu RAID-1 driver
removes the restriction that you can't live-migrate and live-copy
simultaneously.
As mentioned its just an implementation detail.
I meant the restriction of live-migrate and live-copy in parallel.
I think it's an important one. It moves the code from the generic
layer to a driver.
Well it is a nice idea, but devil is in the details:
- Guest writes must invalidate in progress live copy reads
and live copy writes, so you have to maintain a queue for live
copy AIO.
- Live copy writes must be aware of in progress guest AIO writes, so
you have to maintain a queue for guest AIO.
- Guest writes must be mirrored to source and destination.
- qemu-img must handle this new format.
So my view ATM is that this is overengineering.