On Wed, Jun 29, 2011 at 4:41 PM, Marcelo Tosatti <mtosa...@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
