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

[Kevin Wolf]

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.

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