[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dor Laor
Subject: Re: [Qemu-devel] KVM call agenda for June 28
Date: Tue, 05 Jul 2011 11:01:57 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 ThunderBrowse/3.3.5

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.


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


Thought of implementing "block_stream" command by reopening device with



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

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

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 address@hidden
More majordomo info at  http://vger.kernel.org/majordomo-info.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]