Re: [Qemu-devel] KVM call agenda for June 28

[Stefan Hajnoczi <stefanha@gmail.com>]

On Wed, Jun 29, 2011 at 4:41 PM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> On Wed, Jun 29, 2011 at 11:08:23AM +0100, Stefan Hajnoczi wrote:
>> In the future we could add a 'base' argument to block_stream.  If base
>> is specified then data contained in the base image will not be copied.
>
> This is a present requirement.

It's not one that I have had in the past but it is a reasonable requirement.

One interesting thing about this requirement is that it makes
copy-on-read seem like the wrong primitive for image streaming.  If
there is a base image which should not be streamed then a plain loop
that calls bdrv_is_allocated_chain(bs, base, sector, &pnum) and copies
sectors into bs is more straightforward than passing base to a
copy-on-read operation somehow (through a variable that stashes the
base away somewhere?).

>>  This can be used to merge data from an intermediate image without
>> merging the base image.  When streaming completes the backing file
>> will be set to the base image.  The backing file relationship would
>> typically look like this:
>>
>> 1. Before block_stream -a -b base.img ide0-hd completion:
>>
>> base.img <- sn1 <- ... <- ide0-hd.qed
>>
>> 2. After streaming completes:
>>
>> base.img <- ide0-hd.qed
>>
>> This describes the image streaming use cases that I, Adam, and Anthony
>> propose to support.  In the course of the discussion we've sometimes
>> been distracted with the internals of what a unified live block
>> copy/image streaming implementation should do.  I wanted to post this
>> summary of image streaming to refocus us on the use case and the APIs
>> that users will see.
>>
>> Stefan
>
> OK, with an external COW file for formats that do not support it the
> interface can be similar. Also there is no need to mirror writes,
> no switch operation, always use destination image.

Yep.

Stefan