Re: [Qemu-devel] [patch 6/7] QEMU live block copy

[Avi Kivity <avi@redhat.com>]

On 05/31/2011 07:38 PM, Marcelo Tosatti wrote:
> >
> >  >Disadvantages:
> >  >
> >  >- Guest write performance is affected during copying (guest writes
> >  >    compete with stream of writes from copy).
> >
> >  Competes anyway with your background task?
>
> No because guest writes are to the source and copy writes are to
> destination (which are potentially different disks or set of disks).

Your copy task reads from the source disk and writes to the destination 
disk.  A guest write doesn't touch the destination disk, but schedules a 
later write due to dirty tracking.  In all, the total number of writes 
should be similar.  Background copy is a more efficient since multiple 
writes to the same location are coalesced, but that's not very common 
(except perhaps for transaction logs).

> >
> >  >- Unability to have the mirror functionality in a separate driver.
> >
> >  Why?
>
> Because you need to handle the interaction between guest writes and
> copy writes someplace which can be aware of both.
>
> For example, in-flight copy writes must be invalidated in the guest
> write path.

guest -> device -> mirror driver -> [ source disk, destination disk ]

> >  >>   It would also remove the conflict with migration.
> >  >
> >  >There is no fundamental problem with migration, its simply unsupported
> >  >now.
> >
> >  Why?
>
> Don't see the need for that, management can simply wait for livecopy to
> finish or cancel livecopy and restart on destination after migration.

They can do it, but I imagine it's pretty hard for them.

> But yeah, it should be implemented sometime...
>


We should make an effort not to introduce interdependencies which make 
management's life harder.

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