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

[Dor Laor <dlaor@redhat.com>]

On 06/27/2011 10:48 AM, Kevin Wolf wrote:
> 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.

What is we'll use iscsi? Will the client have a matching iscsi verb to 
detect whether a certain block is in fact a unallocated and we'll be 
able to use this for our benefit? Of course it will make the non shared 
storage case more complex.



>
> Kevin
>
>