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

[Anthony Liguori <anthony@codemonkey.ws>]

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

Yeah, it feels like we're introducing QEMU level RAID.  At what point 
are we going to add RAID5 support and not just RAID1.  And it certainly 
begs the question of whether this use-case can be satisfied by just 
using Linux's RAID stack leaving one drive degraded and enabling the 
other drive when the time comes to fail over.

Regards,

Anthony Liguori