From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRU1E-0006Pr-BI for qemu-devel@nongnu.org; Tue, 31 May 2011 14:50:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRU1C-0005Ri-Nw for qemu-devel@nongnu.org; Tue, 31 May 2011 14:50:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRU1C-0005Ra-7S for qemu-devel@nongnu.org; Tue, 31 May 2011 14:50:18 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4VHZHHB022808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 31 May 2011 13:35:32 -0400 Date: Tue, 31 May 2011 13:38:58 -0300 From: Marcelo Tosatti Message-ID: <20110531163858.GB9656@amt.cnet> References: <20110523213115.164535428@amt.cnet> <20110523213411.003695437@amt.cnet> <4DE209C1.4080807@redhat.com> <20110531160636.GA9656@amt.cnet> <4DE51401.6040602@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE51401.6040602@redhat.com> Subject: Re: [Qemu-devel] [patch 6/7] QEMU live block copy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: kwolf@redhat.com, Jes.Sorensen@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org 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...