qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	Dor Laor <dlaor@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>, Adam Litke <agl@us.ibm.com>
Subject: Re: [Qemu-devel] live block copy/stream/snapshot discussion
Date: Mon, 11 Jul 2011 13:32:26 -0300	[thread overview]
Message-ID: <20110711163226.GA10924@amt.cnet> (raw)
In-Reply-To: <CAJSP0QX0ksga-bPPy53SPcPaApT5uXfH-8ORtT0JkPRaskBkhg@mail.gmail.com>

On Mon, Jul 11, 2011 at 03:47:15PM +0100, Stefan Hajnoczi wrote:
> Kevin, Marcelo,
> I'd like to reach agreement on the QMP/HMP APIs for live block copy
> and image streaming.  Libvirt has acked the image streaming APIs that
> Adam proposed and I think they are a good fit for the feature.  I have
> described that API below for your review (it's exactly what the QED
> Image Streaming patches provide).
> 
> Marcelo: Are you happy with this API for live block copy?  Also please
> take a look at the switch command that I am proposing.
> 
> Image streaming API
> ===================
> 
> For leaf images with copy-on-read semantics, the stream commands allow the user
> to populate local blocks by manually streaming them from the backing image.
> Once all blocks have been streamed, the dependency on the original backing
> image can be removed.  Therefore, stream commands can be used to implement
> post-copy live block migration and rapid deployment.
> 
> The block_stream command can be used to stream a single cluster, to
> start streaming the entire device, and to cancel an active stream.  It
> is easiest to allow the block_stream command to manage streaming for the
> entire device but a managent tool could use single cluster mode to
> throttle the I/O rate.
> 
> The command synopses are as follows:
> 
> block_stream
> ------------
> 
> Copy data from a backing file into a block device.
> 
> If the optional 'all' argument is true, this operation is performed in the
> background until the entire backing file has been copied.  The status of
> ongoing block_stream operations can be checked with query-block-stream.
> 
> Arguments:
> 
> - all:    copy entire device (json-bool, optional)
> - stop:   stop copying to device (json-bool, optional)
> - device: device name (json-string)

It must be possible to specify backing file that will be
active after streaming finishes (data from that file will not 
be streamed into active file, of course).

> Return:
> 
> - device: device name (json-string)
> - len:    size of the device, in bytes (json-int)
> - offset: ending offset of the completed I/O, in bytes (json-int)
> 
> Examples:
> 
> -> { "execute": "block_stream", "arguments": { "device": "virtio0" } }
> <- { "return":  { "device": "virtio0", "len": 10737418240, "offset": 512 } }
> 
> -> { "execute": "block_stream", "arguments": { "all": true, "device":
> "virtio0" } }
> <- { "return": {} }
> 
> -> { "execute": "block_stream", "arguments": { "stop": true, "device":
> "virtio0" } }
> <- { "return": {} }
> 
> query-block-stream
> ------------------
> 
> Show progress of ongoing block_stream operations.
> 
> Return a json-array of all operations.  If no operation is active then an empty
> array will be returned.  Each operation is a json-object with the following
> data:
> 
> - device: device name (json-string)
> - len:    size of the device, in bytes (json-int)
> - offset: ending offset of the completed I/O, in bytes (json-int)
> 
> Example:
> 
> -> { "execute": "query-block-stream" }
> <- { "return":[
>        { "device": "virtio0", "len": 10737418240, "offset": 709632}
>     ]
>   }
> 
> 
> Block device switching API
> ==========================
> 
> Extend the 'change' command to support changing the image file without
> media change notification.
> 
> Perhaps we should take the opportunity to add a "format" argument for
> image files?
> 
> change
> ------
> 
> Change a removable medium or VNC configuration.
> 
> Arguments:
> 
> - "device": device name (json-string)
> - "target": filename or item (json-string)
> - "arg": additional argument (json-string, optional)
> - "notify": whether to notify guest, defaults to true (json-bool, optional)
> 
> Examples:
> 
> 1. Change a removable medium
> 
> -> { "execute": "change",
>              "arguments": { "device": "ide1-cd0",
>                             "target": "/srv/images/Fedora-12-x86_64-DVD.iso" } }
> <- { "return": {} }
> 
> 2. Change a disk without media change notification
> 
> -> { "execute": "change",
>              "arguments": { "device": "virtio-blk0",
>                             "target": "/srv/images/vm_1.img",
>                             "notify": false } }
> 
> 3. Change VNC password
> 
> -> { "execute": "change",
>              "arguments": { "device": "vnc", "target": "password",
>                             "arg": "foobar1" } }
> <- { "return": {} }
> 
> How live block copy works
> =========================
> 
> Live block copy does the following:
> 
> 1. Create the destination file: qemu-img create -f $cow_fmt -o
> backing_file=$base destination.$cow_fmt
> 2. Switch to the destination file: change -n virtio-blk0 /srv/images/vm_1.img

The snapshot command (snapshot_blkdev) can be used for these two steps.

> 3. Stream the base into the image file: block_stream -a virtio-blk0
> 
> Stefan

  reply	other threads:[~2011-07-11 18:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-05 14:17 [Qemu-devel] live block copy/stream/snapshot discussion Dor Laor
2011-07-11 12:54 ` Stefan Hajnoczi
2011-07-11 14:47   ` Stefan Hajnoczi
2011-07-11 16:32     ` Marcelo Tosatti [this message]
2011-07-12  8:06       ` Kevin Wolf
2011-07-12 15:45         ` Stefan Hajnoczi
2011-07-12 16:10           ` Kevin Wolf
2011-07-13  9:51             ` Stefan Hajnoczi
2011-07-14  9:39               ` Stefan Hajnoczi
2011-07-14  9:55                 ` Kevin Wolf
2011-07-14 10:00                   ` Stefan Hajnoczi
2011-07-14 10:07                     ` Kevin Wolf
2011-07-12 17:47           ` Adam Litke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110711163226.GA10924@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=agl@us.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=dlaor@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).