Am 26.06.2011 14:50, schrieb Dor Laor: > On 06/24/2011 12:28 PM, Stefan Hajnoczi wrote: >> On Sun, Jun 19, 2011 at 5:02 PM, Dor Laor<dl...@redhat.com> wrote: >>> On 06/18/2011 12:17 PM, Stefan Hajnoczi wrote: >>>> >>>> On Sat, Jun 18, 2011 at 10:15 AM, Stefan Hajnoczi<stefa...@gmail.com> >>>> wrote: >>>>> >>>>> On Fri, Jun 17, 2011 at 1:31 PM, Marcelo Tosatti<mtosa...@redhat.com> >>>>> 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.
I think there is one important point to consider for using NBD: You always see a single image on the NBD client, which could in fact have a backing file chain on the source. So bdrv_is_allocated() doesn't work over NBD, which becomes interesting when you want to share a backing file with the new copy. Kevin
