From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcFja-0003DE-5b for qemu-devel@nongnu.org; Thu, 30 Jun 2011 07:48:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcFjY-0003YB-GL for qemu-devel@nongnu.org; Thu, 30 Jun 2011 07:48:37 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:34246) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcFjY-0003Y1-20 for qemu-devel@nongnu.org; Thu, 30 Jun 2011 07:48:36 -0400 Received: by gwb19 with SMTP id 19so972201gwb.4 for ; Thu, 30 Jun 2011 04:48:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110629154134.GA6631@amt.cnet> References: <20110628194106.GA17443@amt.cnet> <4E0ADAE0.6040204@redhat.com> <20110629154134.GA6631@amt.cnet> Date: Thu, 30 Jun 2011 12:48:35 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call agenda for June 28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Kevin Wolf , Chris Wright , KVM devel mailing list , quintela@redhat.com, Dor Laor , qemu-devel@nongnu.org, Avi Kivity On Wed, Jun 29, 2011 at 4:41 PM, Marcelo Tosatti wrot= e: > On Wed, Jun 29, 2011 at 11:08:23AM +0100, Stefan Hajnoczi wrote: >> In the future we could add a 'base' argument to block_stream. =A0If base >> is specified then data contained in the base image will not be copied. > > This is a present requirement. It's not one that I have had in the past but it is a reasonable requirement= . One interesting thing about this requirement is that it makes copy-on-read seem like the wrong primitive for image streaming. If there is a base image which should not be streamed then a plain loop that calls bdrv_is_allocated_chain(bs, base, sector, &pnum) and copies sectors into bs is more straightforward than passing base to a copy-on-read operation somehow (through a variable that stashes the base away somewhere?). >> =A0This can be used to merge data from an intermediate image without >> merging the base image. =A0When streaming completes the backing file >> will be set to the base image. =A0The backing file relationship would >> typically look like this: >> >> 1. Before block_stream -a -b base.img ide0-hd completion: >> >> base.img <- sn1 <- ... <- ide0-hd.qed >> >> 2. After streaming completes: >> >> base.img <- ide0-hd.qed >> >> This describes the image streaming use cases that I, Adam, and Anthony >> propose to support. =A0In the course of the discussion we've sometimes >> been distracted with the internals of what a unified live block >> copy/image streaming implementation should do. =A0I wanted to post this >> summary of image streaming to refocus us on the use case and the APIs >> that users will see. >> >> Stefan > > OK, with an external COW file for formats that do not support it the > interface can be similar. Also there is no need to mirror writes, > no switch operation, always use destination image. Yep. Stefan