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

[Marcelo Tosatti]

On Wed, Jun 29, 2011 at 11:08:23AM +0100, Stefan Hajnoczi wrote:
> 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 is a present requirement.

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