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

[Stefan Hajnoczi]

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?

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

This approach makes sense to me.

Stefan