From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRTiz-0001YG-O4 for qemu-devel@nongnu.org; Tue, 31 May 2011 14:31:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRTiy-0001Vw-2j for qemu-devel@nongnu.org; Tue, 31 May 2011 14:31:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRTix-0001Va-IN for qemu-devel@nongnu.org; Tue, 31 May 2011 14:31:27 -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 p4VGF444023685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 31 May 2011 12:15:05 -0400 Message-ID: <4DE51401.6040602@redhat.com> Date: Tue, 31 May 2011 19:14:57 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20110523213115.164535428@amt.cnet> <20110523213411.003695437@amt.cnet> <4DE209C1.4080807@redhat.com> <20110531160636.GA9656@amt.cnet> In-Reply-To: <20110531160636.GA9656@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [patch 6/7] QEMU live block copy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: kwolf@redhat.com, Jes.Sorensen@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org 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? > - 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? > > It would also remove the conflict with migration. > > There is no fundamental problem with migration, its simply unsupported > now. Why? > > But that's an implementation detail and can be changed later. > -- error compiling committee.c: too many arguments to function