From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXCWi-0002O5-4y for qemu-devel@nongnu.org; Thu, 16 Jun 2011 09:22:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXCWb-0002sX-Eb for qemu-devel@nongnu.org; Thu, 16 Jun 2011 09:22:27 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:51916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXCWa-0002rq-VE for qemu-devel@nongnu.org; Thu, 16 Jun 2011 09:22:21 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5GCo9X3009964 for ; Thu, 16 Jun 2011 08:50:09 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5GDAbIt099068 for ; Thu, 16 Jun 2011 09:10:37 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5G7ANvT028785 for ; Thu, 16 Jun 2011 01:10:24 -0600 Message-ID: <4DFA00BF.5030605@us.ibm.com> Date: Thu, 16 Jun 2011 08:10:23 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1308075511-4745-1-git-send-email-stefanha@linux.vnet.ibm.com> <4DF9F899.5050301@redhat.com> In-Reply-To: <4DF9F899.5050301@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Image streaming and live block copy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Dor Laor , agl@linux.vnet.ibm.com, Stefan Hajnoczi , jes sorensen , Marcelo Tosatti , qemu-devel@nongnu.org, Avi Kivity On 06/16/2011 07:35 AM, Kevin Wolf wrote: > Am 14.06.2011 20:18, schrieb Stefan Hajnoczi: >> Overview >> -------- >> >> This patch series adds image streaming support for QED image files. Other >> image formats can also be supported in the future. >> >> Image streaming populates the file in the background while the guest is >> running. This makes it possible to start the guest before its image file has >> been fully provisioned. >> >> Example use cases include: >> * Providing small virtual appliances for download that can be launched >> immediately but provision themselves in the background. >> * Reducing guest provisioning time by creating local image files but backing >> them with shared master images which will be streamed. >> >> When image streaming is enabled, the unallocated regions of the image file are >> populated with the data from the backing file. This occurs in the background >> and the guest can perform regular I/O in the meantime. Once the entire backing >> file has been streamed, the image no longer requires a backing file and will >> drop its reference > > Long CC list and Kevin wearing his upstream hat - this might be an > unpleasant email. :-) > > So yesterday I had separate discussions with Stefan about image > streaming and Marcelo, Avi and some other folks about live block copy. > The conclusion was in both cases that, yes, both things are pretty > similar and, yes, the current implementation don't reflect that but > duplicate everything. > > To summarise what both things are about: > > * Image streaming is a normal image file plus copy-on-read plus a > background task that copies data from the source image > * Live block copy is a block-mirror of two normal image files plus a > background task that copies data from the source image Is this correct in practice? Image streaming has the following semantics for A -> B where B is the backing file of A. 1) All writes go to A. 2) If a read can be satisified by A, read from A, else read from B, copy to A, then return Block copy has the following semantics where A is the source and B is the destination. 1) All reads and writes go to A 2) Copy data from B to A in the background 3) When B matches the content of A, switch over to B Other than at a hand wave, they both do copies, I'm not sure I see the overlap in implementations. Regards, Anthony Liguori