OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity

live-block-ops.txt: Rename, rewrite, and improve it

Browse Source 
This patch documents (including their QMP invocations) all the four
major kinds of live block operations:

  - `block-stream`
  - `block-commit`
  - `drive-mirror` (& `blockdev-mirror`)
  - `drive-backup` (& `blockdev-backup`)

Things considered while writing this document:

  - Use reStructuredText as markup language (with the goal of generating
    the HTML output using the Sphinx Documentation Generator).  It is
    gentler on the eye, and can be trivially converted to different
    formats.  (Another reason: upstream QEMU is considering to switch to
    Sphinx, which uses reStructuredText as its markup language.)

  - Raw QMP JSON output vs. 'qmp-shell'.  I debated with myself whether
    to only show raw QMP JSON output (as that is the canonical
    representation), or use 'qmp-shell', which takes key-value pairs.  I
    settled on the approach of: for the first occurrence of a command,
    use raw JSON; for subsequent occurrences, use 'qmp-shell', with an
    occasional exception.

  - Usage of `-blockdev` command-line.

  - Usage of 'node-name' vs. file path to refer to disks.  While we have
    `blockdev-{mirror, backup}` as 'node-name'-alternatives for
    `drive-{mirror, backup}`, the `block-commit` command still operates
    on file names for parameters 'base' and 'top'.  So I added a caveat
    at the beginning to that effect.

    Refer this related thread that I started (where I learnt
    `block-stream` was recently reworked to accept 'node-name' for 'top'
    and 'base' parameters):
    https://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg06466.html
    "[RFC] Making 'block-stream', and 'block-commit' accept node-name"

All commands showed in this document were tested while documenting.

Thanks: Eric Blake for the section: "A note on points-in-time vs file
names".  This useful bit was originally articulated by Eric in his
KVMForum 2015 presentation, so I included that specific bit in this
document.

Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170717105205.32639-3-kchamart@redhat.com
Signed-off-by: Jeff Cody <jcody@redhat.com>
This commit is contained in:
Kashyap Chamarthy 2017-07-17 12:52:05 +02:00 committed by Jeff Cody
parent 7746cf8aab
commit 8508eee740
2 changed files with 1088 additions and 72 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1088
docs/interop/live-block-operations.rst Normal file
View File

File diff suppressed because it is too large Load Diff

72
docs/live-block-ops.txt
View File

@ -1,72 +0,0 @@
LIVE BLOCK OPERATIONS
=====================
High level description of live block operations. Note these are not
supported for use with the raw format at the moment.
Note also that this document is incomplete and it currently only
covers the 'stream' operation. Other operations supported by QEMU such
as 'commit', 'mirror' and 'backup' are not described here yet. Please
refer to the qapi/block-core.json file for an overview of those.
Snapshot live merge
===================
Given a snapshot chain, described in this document in the following
format:
[A] <- [B] <- [C] <- [D] <- [E]
Where the rightmost object ([E] in the example) described is the current
image which the guest OS has write access to. To the left of it is its base
image, and so on accordingly until the leftmost image, which has no
base.
The snapshot live merge operation transforms such a chain into a
smaller one with fewer elements, such as this transformation relative
to the first example:
[A] <- [E]
Data is copied in the right direction with destination being the
rightmost image, but any other intermediate image can be specified
instead. In this example data is copied from [C] into [D], so [D] can
be backed by [B]:
[A] <- [B] <- [D] <- [E]
The operation is implemented in QEMU through image streaming facilities.
The basic idea is to execute 'block_stream virtio0' while the guest is
running. Progress can be monitored using 'info block-jobs'. When the
streaming operation completes it raises a QMP event. 'block_stream'
copies data from the backing file(s) into the active image. When finished,
it adjusts the backing file pointer.
The 'base' parameter specifies an image which data need not be
streamed from. This image will be used as the backing file for the
destination image when the operation is finished.
In the first example above, the command would be:
(qemu) block_stream virtio0 file-A.img
In order to specify a destination image different from the active
(rightmost) one we can use its node name instead.
In the second example above, the command would be:
(qemu) block_stream node-D file-B.img
Live block copy
===============
To copy an in use image to another destination in the filesystem, one
should create a live snapshot in the desired destination, then stream
into that image. Example:
(qemu) snapshot_blkdev ide0-hd0 /new-path/disk.img qcow2
(qemu) block_stream ide0-hd0