On Thu, Jun 30, 2011 at 01:54:09PM +0100, Stefan Hajnoczi wrote:
> On Wed, Jun 29, 2011 at 4:41 PM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote:
> > On Wed, Jun 29, 2011 at 11:08:23AM +0100, Stefan Hajnoczi wrote:
> >> This can be used to merge data from an intermediate image without
> >> merging the base image. When streaming completes the backing file
> >> will be set to the base image. The backing file relationship would
> >> typically look like this:
> >>
> >> 1. Before block_stream -a -b base.img ide0-hd completion:
> >>
> >> base.img <- sn1 <- ... <- ide0-hd.qed
> >>
> >> 2. After streaming completes:
> >>
> >> base.img <- ide0-hd.qed
> >>
> >> This describes the image streaming use cases that I, Adam, and Anthony
> >> propose to support. In the course of the discussion we've sometimes
> >> been distracted with the internals of what a unified live block
> >> copy/image streaming implementation should do. I wanted to post this
> >> summary of image streaming to refocus us on the use case and the APIs
> >> that users will see.
> >>
> >> Stefan
> >
> > OK, with an external COW file for formats that do not support it the
> > interface can be similar. Also there is no need to mirror writes,
> > no switch operation, always use destination image.
>
> Marcelo, does this mean you are happy with how management deals with
> power failure/crash during streaming?
Yep.
> Are we settled on the approach where the destination file always has
> the source file as its backing file?
Yep.
> Here are the components that I can identify:
>
> 1. blkmirror - used by live block copy to keep source and destination
> in sync. Already implemented as a block driver by Marcelo.
No need for it anymore, now you switch to the destination before
the operation starts. And always use destination from there on.
> 2. External COW overlay - can be used to add backing file (COW)
> support on top of any image, including raw. Currently unimplemented,
> needs to be a block driver. Kevin, do you want to write this?
>
> 3. Unified background copy - image format-independent mechanism for
> copy contents of a backing file chain into the image file (with
> exception of backing files chained below base). Needs to play nice
> with blkmirror. Stefan can write this.
Note the background copy itself is to simply read from 0...END. The bulk
is in the block driver.
> 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"
> 5. Image streaming API and high-level control - the main code that
> adds the image streaming feature. Existing patches by Stefan, Adam,
> Anthony, can be restructured to use common core by Stefan.
>
> I previously posted a proposed API for the unified background copy
> mechanism. I'm thinking that background copy is not the best name
> since it is limited to copying the backing file into the image file.
>
> /**
> * Start a background copy operation
> *
> * Unallocated clusters in the image will be populated with data
> * from its backing file. This operation runs in the background and a
> * completion function is invoked when it is finished.
> */
> BackgroundCopy *background_copy_start(
> BlockDriverState *bs,
>
> /**
> * Note: Kevin suggests we migrate this into BlockDriverState
> * in order to enable copy-on-read.
> *
> * Base image that both source and destination have as a
> * backing file ancestor. Data will not be copied from base
> * since both source and destination will have access to base
> * image. This may be NULL to copy all data.
> */
> BlockDriverState *base,
>
> BlockDriverCompletionFunc *cb, void *opaque);
>
> /**
> * Cancel a background copy operation
> *
> * This function marks the background copy operation for cancellation and the
> * completion function is invoked once the operation has been cancelled.
> */
> void background_copy_cancel(BackgroundCopy *bgc,
> BlockDriverCompletionFunc *cb, void *opaque);
>
> /**
> * Get progress of a running background copy operation
> */
> void background_copy_get_status(BackgroundCopy *bgc,
> BackgroundCopyStatus *status);
>
> Stefan
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.
--
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
