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.
> 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 think it's an important one. It moves the code from the generic layer
to a driver. It allows generic RAID-1 functionality (for high availablity).
--
error compiling committee.c: too many arguments to function
