On Wed, Jun 29, 2011 at 8:57 AM, Kevin Wolf <kw...@redhat.com> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
