Re: [Qemu-devel] Image streaming and live block copy (was: [PATCH 00/13] QED image streaming)

[Marcelo Tosatti]

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