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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
