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

[Avi Kivity <avi@redhat.com>]

On 02/24/2011 06:39 PM, Marcelo Tosatti wrote:
> >  >
> >  >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).

It's a lot better to have an orthogonal feature set where everything 
works with everything.  These sort of constraints aren't very good, 
especially as they aren't documented.  The code that deals with live 
migration and live copy may be in different places and now we force the 
management tool authors to tangle it up.

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

You just add the locations to a queue and fire them off again when the 
live copy write returns.

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

Don't you need to do this for live-copy?  Ah, you do it asynchronously 
from the dirty log.

You can do the same with the RAID-1 driver by invalidating the 
destination block instead of dual-issuing the write.

> - qemu-img must handle this new format.
>
> So my view ATM is that this is overengineering.

I believe it will actually be smaller since there's no interfacing with 
the dirty log.

> >  It allows generic RAID-1 functionality (for high
> >  availablity).
>
> Isnt HA responsability of the host filesystem?

So is sparseness, snapshots, etc.  Yet we do them in qemu.  In a perfect 
world we'd have just raw files (and use RAID over loop or something for 
live-copy).

-- 
error compiling committee.c: too many arguments to function