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

[Dor Laor]

On 06/24/2011 12:28 PM, Stefan Hajnoczi wrote:
> On Sun, Jun 19, 2011 at 5:02 PM, Dor Laor<address@hidden>  wrote:
> > On 06/18/2011 12:17 PM, Stefan Hajnoczi wrote:
> > > On Sat, Jun 18, 2011 at 10:15 AM, Stefan Hajnoczi<address@hidden>
> > >   wrote:
> > > > On Fri, Jun 17, 2011 at 1:31 PM, Marcelo Tosatti<address@hidden>
> > > >   wrote:
> > > > > 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?
> > > >
> > > > Think of the use case with a Fedora master image over NFS.  You want a
> > > > local clone of that master image and use the stream command to copy
> > > > the data from the master image into the local clone.
> > > >
> > > > You cannot modify that master image because other VMs are using it too
> > > > and/or you want to be able to clone new VMs from it in the future.
> > >
> > > BTW the workaround is to create two local images:
> > > 1. Local clone with master image as a backing file.  This is the live
> > > block copy source image.
> > > 2. Local image without a backing file.  This is the live block copy
> > > destination image.
> > >
> > > But this is not very elegant.  Writes get mirrored so that crash recovery
> > > works.
> >
> > There is an easier work around for image streaming using live block copy
> > (mirror approach):
> >   - Create the dst VM as an empty new COW image of the src (even over
> >     the non shared storage, use some protocol tag for the src location
> >     like nbd://original_path/src_file_name)
>
> Migration and non-shared storage has come up a few times in this
> discussion.  But both live block copy and image streaming need access
> to source and destination - they do not have explicit non-shared
> storage support.  I think non-shared and using nbd:// is orthogonal to
> the discussion.  Just want to check that you agree and I haven't
> missed something?

You're right, I was mainly trying to be as general as possible.

> >   - Run the usual live block copy of src image (master read only OS
> >     template) to the destination.
> >     - Use a -src-read-only flag that will make the copy skip the src
> >       writing.
> >
> > Voila - no duplicate writes, crash recovery works since we reference the
> > original image and we share the code.
>
> So the running guest is using the destination image since the source
> is read-only?

Yes. The image will run on the destination not because of the source in 
RO state but because that is what we look for.

> This approach makes sense to me.
>
> Stefan