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

[Stefan Hajnoczi]

On Wed, Jun 29, 2011 at 8:57 AM, Kevin Wolf <address@hidden> wrote:
> Am 28.06.2011 21:41, schrieb Marcelo Tosatti:
>> stream
>> ------
>>
>> 1) base <- remote
>> 2) base <- remote <- local
>> 3) base <- local
>>
>> "local" image is always valid. Requires backing file support.
>
> With the above, this restriction wouldn't apply any more.
>
> Also I don't think we should mix approaches. Either both block copy and
> image streaming use backing files, or none of them do. Mixing means
> duplicating more code, and even worse, that you can't stop a block copy
> in the middle and continue with streaming (which I believe is a really
> valuable feature to have).

Here is how the image streaming feature is used from HMP/QMP:

The guest is running from an image file with a backing file.  The aim
is to pull the data from the backing file and populate the image file
so that the dependency on the backing file can be eliminated.

1. Start a background streaming operation:

(qemu) block_stream -a ide0-hd

2. Check the status of the operation:

(qemu) info block-stream
Streaming device ide0-hd: Completed 512 of 34359738368 bytes

3. The status changes when the operation completes:

(qemu) info block-stream
No active stream

On completion the image file no longer has a backing file dependency.
When streaming completes QEMU updates the image file metadata to
indicate that no backing file is used.

The QMP interface is similar but provides QMP events to signal
streaming completion and failure.  Polling to query the streaming
status is only used when the management application wishes to refresh
progress information.

If guest execution is interrupted by a power failure or QEMU crash,
then the image file is still valid but streaming may be incomplete.
When QEMU is launched again the block_stream command can be issued to
resume streaming.

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 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