diff options
author | Kashyap Chamarthy <kchamart@redhat.com> | 2017-11-21 12:52:53 +0100 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2017-11-27 14:59:35 +0100 |
commit | c117bb14ff633848cc6b0ff77f081f583dfa8c5e (patch) | |
tree | 20d2ef34114bf27257a63c58ae47b964e3dc5836 /ui/vnc-auth-vencrypt.c | |
parent | 1878eaff9bdeece4546d4f9587e6c75ab0b79b8b (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 'ui/vnc-auth-vencrypt.c')
0 files changed, 0 insertions, 0 deletions