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

[Avi Kivity <avi@redhat.com>]

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