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

[Marcelo Tosatti]

On Thu, Feb 24, 2011 at 10:58:10AM +0200, Avi Kivity wrote:
> On 02/23/2011 07:49 PM, Marcelo Tosatti wrote:
> >On Wed, Feb 23, 2011 at 03:01:14PM +0200, 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?
> >>
> >>  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?

> >>  - 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).
> >
> >You don't know if a given block is uptodate or not without the dirty
> >bitmap. So unless you also keep track of dirty log somehow, this is
> >meaningless.
> 
> First, you no longer need the dirty bitmap.  Since all writes go
> through the layered block format driver, you know first-hand what is
> dirty and what isn't.
> 
> >So a commit file as proposed indicates copy state (in 0/1 fashion). The
> >difference in your proposal is that such information is stored inside a
> >special purpose image format?
> >
> 
> It could also store the already synced range.
> 
> The difference is that the file is self contained.  


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

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

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