Re: [Qemu-devel] KVM call agenda for June 28

[Dor Laor <dlaor@redhat.com>]

I tried to re-arrange all of the requirements and use cases using this 
wiki page: http://wiki.qemu.org/Features/LiveBlockMigration

It would be the best to agree upon the most interesting use cases (while 
we make sure we cover future ones) and agree to them.
The next step is to set the interface for all the various verbs since 
the implementation seems to be converging.

Cheers,
Dor

On 06/30/2011 09:38 PM, Marcelo Tosatti wrote:
> On Thu, Jun 30, 2011 at 04:52:00PM +0200, Kevin Wolf wrote:
>> Am 30.06.2011 16:36, schrieb Marcelo Tosatti:
>>>> 4. Live block copy API and high-level control - the main code that
>>>> adds the live block copy feature.  Existing patches by Marcelo, can be
>>>> restructured to use common core by Marcelo.
>>>
>>> Can use your proposed block_stream interface, with a "block_switch"
>>> command on top, so:
>>>
>>> 1) management creates copy.img with backing file current.img, allows
>>> access
>>> 2) management issues "block_switch dev copy.img"
>>> 3) management issues "block_stream dev base"
>>
>> Isn't this block_switch command the same as the existing snapshot_blkdev?
>
> Yep.
>
>>> Thought of implementing "block_stream" command by reopening device with
>>>
>>> blkstream:imagename.img
>>>
>>> Then:
>>>
>>> AIO_READ:
>>> - for each cluster in request:
>>>      - if allocated-or-in-final-base, read.
>>>      - check write queue, if present wait on it, if not, add "copy"
>>>        entry to write queue.
>>>      - issue cluster sized read from source.
>>>      - on completion:
>>>          - copy data to original read buffer, complete it.
>>>          - if not cancelled, write cluster to destination.
>>>
>>> AIO_WRITE
>>> for each cluster in request:
>>>      - check write queue, cancel/wait for "copy" entry.
>>>      - add "guest" entry to write queue.
>>>      - issue write to destination.
>>>      - on completion:
>>>          - remove write queue entry.
>>>
>>>
>>> With the 0...END background read, once it completes write final base
>>> file for image.
>>>
>>> So block_stream/block_stream_cancel/block_stream_status commands, the
>>> background read and the rebase -u update can be separate from the block
>>> driver.
>>
>> The way how it works looks good to me, I'm just not entirely sure about
>> the right place to implement it. I think request queueing and copy on
>> read could be useful outside blkstream, too.
>
> They could be lifted later, when there are other users.
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html