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

[Kevin Wolf <kwolf@redhat.com>]

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<dlaor@redhat.com>  wrote:
>>> On 06/18/2011 12:17 PM, Stefan Hajnoczi wrote:
>>>>
>>>> On Sat, Jun 18, 2011 at 10:15 AM, Stefan Hajnoczi<stefanha@gmail.com>
>>>>   wrote:
>>>>>
>>>>> On Fri, Jun 17, 2011 at 1:31 PM, Marcelo Tosatti<mtosatti@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