aboutsummaryrefslogtreecommitdiff
path: root/docs/interop
diff options
context:
space:
mode:
authorKashyap Chamarthy <kchamart@redhat.com>2017-11-21 12:52:53 +0100
committerKevin Wolf <kwolf@redhat.com>2017-11-27 14:59:35 +0100
commitc117bb14ff633848cc6b0ff77f081f583dfa8c5e (patch)
tree20d2ef34114bf27257a63c58ae47b964e3dc5836 /docs/interop
parent1878eaff9bdeece4546d4f9587e6c75ab0b79b8b (diff)
QAPI & interop: Clarify events emitted by 'block-job-cancel'
When you cancel an in-progress 'mirror' job (or "active `block-commit`") with QMP `block-job-cancel`, it emits the event: BLOCK_JOB_CANCELLED. However, when `block-job-cancel` is issued *after* `drive-mirror` has indicated (via the event BLOCK_JOB_READY) that the source and destination have reached synchronization: [...] # Snip `drive-mirror` invocation & outputs { "execute":"block-job-cancel", "arguments":{ "device":"virtio0" } } {"return": {}} It (`block-job-cancel`) will counterintuitively emit the event 'BLOCK_JOB_COMPLETED': { "timestamp":{ "seconds":1510678024, "microseconds":526240 }, "event":"BLOCK_JOB_COMPLETED", "data":{ "device":"virtio0", "len":41126400, "offset":41126400, "speed":0, "type":"mirror" } } But this is expected behaviour, where the _COMPLETED event indicates that synchronization has successfully ended (and the destination now has a point-in-time copy, which is at the time of cancel). So add a small note to this effect in 'block-core.json'. While at it, also update the "Live disk synchronization -- drive-mirror and blockdev-mirror" section in 'live-block-operations.rst'. (Thanks: Max Reitz for reminding me of this caveat on IRC.) Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'docs/interop')
-rw-r--r--docs/interop/live-block-operations.rst50
1 files changed, 32 insertions, 18 deletions
diff --git a/docs/interop/live-block-operations.rst b/docs/interop/live-block-operations.rst
index 5f0179749f..734252bc80 100644
--- a/docs/interop/live-block-operations.rst
+++ b/docs/interop/live-block-operations.rst
@@ -506,26 +506,40 @@ Again, given our familiar disk image chain::
[A] <-- [B] <-- [C] <-- [D]
-The ``drive-mirror`` (and its newer equivalent ``blockdev-mirror``) allows
-you to copy data from the entire chain into a single target image (which
-can be located on a different host).
-
-Once a 'mirror' job has started, there are two possible actions while a
-``drive-mirror`` job is active:
-
-(1) Issuing the command ``block-job-cancel`` after it emits the event
- ``BLOCK_JOB_CANCELLED``: will (after completing synchronization of
- the content from the disk image chain to the target image, [E])
- create a point-in-time (which is at the time of *triggering* the
- cancel command) copy, contained in image [E], of the the entire disk
+The ``drive-mirror`` (and its newer equivalent ``blockdev-mirror``)
+allows you to copy data from the entire chain into a single target image
+(which can be located on a different host), [E].
+
+.. note::
+
+ When you cancel an in-progress 'mirror' job *before* the source and
+ target are synchronized, ``block-job-cancel`` will emit the event
+ ``BLOCK_JOB_CANCELLED``. However, note that if you cancel a
+ 'mirror' job *after* it has indicated (via the event
+ ``BLOCK_JOB_READY``) that the source and target have reached
+ synchronization, then the event emitted by ``block-job-cancel``
+ changes to ``BLOCK_JOB_COMPLETED``.
+
+ Besides the 'mirror' job, the "active ``block-commit``" is the only
+ other block device job that emits the event ``BLOCK_JOB_READY``.
+ The rest of the block device jobs ('stream', "non-active
+ ``block-commit``", and 'backup') end automatically.
+
+So there are two possible actions to take, after a 'mirror' job has
+emitted the event ``BLOCK_JOB_READY``, indicating that the source and
+target have reached synchronization:
+
+(1) Issuing the command ``block-job-cancel`` (after it emits the event
+ ``BLOCK_JOB_COMPLETED``) will create a point-in-time (which is at
+ the time of *triggering* the cancel command) copy of the entire disk
image chain (or only the top-most image, depending on the ``sync``
- mode).
+ mode), contained in the target image [E]. One use case for this is
+ live VM migration with non-shared storage.
-(2) Issuing the command ``block-job-complete`` after it emits the event
- ``BLOCK_JOB_COMPLETED``: will, after completing synchronization of
- the content, adjust the guest device (i.e. live QEMU) to point to
- the target image, and, causing all the new writes from this point on
- to happen there. One use case for this is live storage migration.
+(2) Issuing the command ``block-job-complete`` (after it emits the event
+ ``BLOCK_JOB_COMPLETED``) will adjust the guest device (i.e. live
+ QEMU) to point to the target image, [E], causing all the new writes
+ from this point on to happen there.
About synchronization modes: The synchronization mode determines
*which* part of the disk image chain will be copied to the target.