From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXDzC-0001sH-0c for qemu-devel@nongnu.org; Thu, 16 Jun 2011 10:56:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXDz5-0000wx-Fq for qemu-devel@nongnu.org; Thu, 16 Jun 2011 10:55:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXDz5-0000wl-0M for qemu-devel@nongnu.org; Thu, 16 Jun 2011 10:55:51 -0400 Date: Thu, 16 Jun 2011 11:38:48 -0300 From: Marcelo Tosatti Message-ID: <20110616143848.GA12173@amt.cnet> References: <1308075511-4745-1-git-send-email-stefanha@linux.vnet.ibm.com> <4DF9F899.5050301@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DF9F899.5050301@redhat.com> Subject: Re: [Qemu-devel] Image streaming and live block copy (was: [PATCH 00/13] QED image streaming) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Anthony Liguori , Stefan Hajnoczi , jes sorensen , Dor Laor , qemu-devel@nongnu.org, Avi Kivity , Adam Litke On Thu, Jun 16, 2011 at 02:35:37PM +0200, 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 > > The right solution is probably to implement COR and the background task > in generic block layer code (no reason to restrict it to QED) and use it > for both image streaming and live block copy. (This is a bit more > complicated than it may sound here because guest writes must always take > precedence over a copy - but doing complicated things is an even better > reason to do it in a common place instead of duplicating) > > People seem to agree on this, and the reason that I've heard why we > should merge the existing code instead is downstream time pressure. That > may be a valid reason for downstreams to add such code, but is taking > such code really the best option for upstream (and therefore long-term > for downstreams)? > > If we take these patches as they are, I doubt that we'll ever get a > rewrite to implement the code as it should have been done in the first > place. That (a newer, unified mechanism) is just a matter of allocating resources to the implementation. At least in block copy's case the interface can be reused, so it can be seen as an incremental approach (read: advocating in favour of merging live block copy patchset). > So I'm tempted to reject the current versions of both the image > streaming and live block copy series and leave it to downstreams to use > these as temporary solutions if the time pressure is too high. I know > that maintaining things downstream is painful, but that's the whole > point: I want to see the real implementation one day, and I'm afraid > this might be the only way to get it. > > Kevin