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

[Kevin Wolf <kwolf@redhat.com>]

Am 16.06.2011 16:52, schrieb Marcelo Tosatti:
> On Thu, Jun 16, 2011 at 03:08:30PM +0200, Kevin Wolf wrote:
>> Am 16.06.2011 14:49, schrieb Avi Kivity:
>>> On 06/16/2011 03:35 PM, Kevin Wolf wrote:
>>>> * Image streaming is a normal image file plus copy-on-read plus a
>>>> background task that copies data from the source image
>>>
>>> Or a block-mirror started in degraded mode.
>>
>> At least not in the same configuration as with live block copy: You
>> don't want to write to the source, you only want to read from it when
>> the destination doesn't have the data yet.
>>
>>>> * Live block copy is a block-mirror of two normal image files plus a
>>>> background task that copies data from the source image
>>>
>>> = block-mirror started in degraded mode
>>
>>>> The right solution is probably to implement COR and the background task
>>>> in generic block layer code (no reason to restrict it to QED) and use it
>>>> for both image streaming and live block copy. (This is a bit more
>>>> complicated than it may sound here because guest writes must always take
>>>> precedence over a copy - but doing complicated things is an even better
>>>> reason to do it in a common place instead of duplicating)
>>>
>>> Or in a block-mirror block format driver - generic code need not be 
>>> involved.
>>
>> Might be an option. In this case generic code is only involved with the
>> stacking of BlockDriverStates, which is already implemented (but
>> requires -blockdev for a sane way to configure things).
>>
>> Kevin
> 
> What are the disadvantages of such an approach for image streaming,
> versus the current QED approach?
> 
> 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.

Why maintain it in memory? We already have mechanisms to track this in
COW image formats, so that you can even continue after a crash.

We can still add a raw-cow driver that maintains the COW data in memory
for allowing raw copies, if this is needed.

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

Image streaming shouldn't write to the source. But adding a flag for
this isn't a major problem.

> Over this scheme, you'd have:
> 
> 1) Block copy. 
> Reopen image to be copied with
> blkstream:/path/to/current-image:/path/to/destination-image,
> background read sectors 0...N.
> 
> 2) Image stream:
> blkstream:remote-image:/path/to/local-image,
> background read sectors 0...N.
> 
> Where remote-image is remote accessible image such as NBD.

I think that should work.

By the way, we'll get problems with the colon syntax. Without -blockdev
we'll have to invent a new syntax, maybe with brackets:

blkstream:[nbd:localhost]:out.qcow2

Kevin