Re: [Qemu-devel] Image streaming and live block copy

[Marcelo Tosatti <mtosatti@redhat.com>]

On Thu, Jun 16, 2011 at 04:30:18PM +0100, Stefan Hajnoczi wrote:
> On Thu, Jun 16, 2011 at 11:52:43AM -0300, Marcelo Tosatti wrote:
> This approach does not use the backing file feature?
> 
> > blkstream block driver:
> > 
> > - Maintain in memory whether given block is allocated in local image,
> > if not, read from remote, write to local. Set block as local.
> > Local and remote simply two block drivers from image streaming driver
> > POV.
> > - Once all blocks are local, notify mgmt so it can switch to local
> > copy.
> > - Writes are mirrored to source and destination, minding guest writes
> > over copy writes.
> 
> We open the remote file read-only for image streaming and do not want to
> mirror writes.

Why not? Is there any disadvantage of mirroring writes?

> If QEMU crashes or there is a power failure we need to restart the
> streaming process carefully - local blocks must not be overwritten.
> Perhaps this is the tricky part.

Under the proposed scheme, if QEMU crashes you'd restart streaming from
zero. In that case, the remote image is consistent due to mirrored
writes.

That is one disadvantage of keeping the local/remote status of blocks
in memory: in case of a crash you'd have to restart from zero. But this
should be an uncommon case (and there is not much of an option for
generic-format image streaming without keeping metadata).

Do you see a problem with that?

> > Over this scheme, you'd have:
> > 
> > 1) Block copy. 
> > Reopen image to be copied with
> > blkstream:/path/to/current-image:/path/to/destination-image,
> > background read sectors 0...N.
> > 
> > 2) Image stream:
> > blkstream:remote-image:/path/to/local-image,
> > background read sectors 0...N.
> 
> Stefan