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