From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S10LI-00027h-B4 for qemu-devel@nongnu.org; Fri, 24 Feb 2012 13:58:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S10LE-0005m8-7F for qemu-devel@nongnu.org; Fri, 24 Feb 2012 13:58:08 -0500 Received: from plane.gmane.org ([80.91.229.3]:56608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S10LE-0005lx-0f for qemu-devel@nongnu.org; Fri, 24 Feb 2012 13:58:04 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S10LC-0002zQ-0N for qemu-devel@nongnu.org; Fri, 24 Feb 2012 19:58:02 +0100 Received: from 93-34-182-16.ip50.fastwebnet.it ([93.34.182.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Feb 2012 19:58:01 +0100 Received: from pbonzini by 93-34-182-16.ip50.fastwebnet.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Feb 2012 19:58:01 +0100 From: Paolo Bonzini Date: Fri, 24 Feb 2012 19:57:52 +0100 Message-ID: References: <1329930815-7995-1-git-send-email-fsimonce@redhat.com> <1330102144-14491-2-git-send-email-fsimonce@redhat.com> <4F47CCF2.1090007@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit In-Reply-To: <4F47CCF2.1090007@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/2 v2] Add the blockdev-reopen and blockdev-migrate commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 02/24/2012 06:46 PM, Eric Blake wrote: > I think you need to be more explicit that @new-image-file MUST have > identical contents as the current image file, for this to be useful, and > that qemu does not validate whether the new image met those conditions. > Possible ways to achieve this: Not necessarily, you could always do this on a paused machine. >> > +# @destination: the destination of the block migration. > Where do you list what format the destination is? Shouldn't this have > an optional format, defaulting to qcow2? Does qemu create the > destination file, or must it already be existing? I think no default, raw makes as much or more sense in the non-incremental case. Anyway either autodetect, or no default. >> > +# >> > +# @new-image-file: #optional an existing image file that will replace >> > +# the current one in the device. > Where do you list what format the new-image-file is? Shouldn't this > have an optional format, defaulting to qcow2? Does qemu create the > new-image-file, or can one already be existing? qemu does not create the file now, but in the future we may add a flag to create a snapshot. I think no default is better here too, or autodetect. > I know that this patch is only implementing the case where incremental > is true and new-image-file is provided; but I'm not quite sure what > semantics are intended if incremental is false. Is that still a case > where this sets up mirroring (writes go to two images) but additionally > the contents from the current image are (asynchronously) streamed into > the destination? Yes. The image should already be there also in this case, and new-image-file will usually be omitted. Paolo