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

[Marcelo Tosatti]

On Tue, May 31, 2011 at 07:14:57PM +0300, Avi Kivity wrote:
> On 05/31/2011 07:06 PM, Marcelo Tosatti wrote:
> >On Sun, May 29, 2011 at 11:54:25AM +0300, Avi Kivity wrote:
> >>  On 05/24/2011 12:31 AM, Marcelo Tosatti wrote:
> >>  >Support live image copy + switch. That is, copy an image backing
> >>  >a guest hard disk to a destination image (destination image must
> >>  >be created separately), and switch to this copy.
> >>  >
> >>  >Command syntax:
> >>  >
> >>  >block_copy device filename [-i] -- live block copy device to image
> >>  >               -i for incremental copy (base image shared between src 
> >> and destination)
> >>  >
> >>  >Please refer to qmp-commands diff for more details.
> >>
> >>  IMO it would have been nicer to use the mirror driver for all
> >>  copying; there would be no STAGE_DIRTY; simply a background process
> >>  that copies over all blocks, taking care not to conflict with
> >>  ongoing writes.
> >
> >Don't see the advantage of doing that.
> 
> No dirty logging
> No conflict with migration
> Simpler conceptually (IMO)
> 
> >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).

> >- Complexity to handle copy write conflict (there is no need to handle
> >   that with current solution).
> 
> If new write from source A overlaps an in-flight write from source
> B, hold it in a list off the B request, and re-issue it on B
> completion.
> 
> >- 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.

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

But yeah, it should be implemented sometime...