Re: [Qemu-devel] Image streaming and live block copy

[Anthony Liguori <aliguori@us.ibm.com>]

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