Am 21.11.2017 um 12:52 hat Kashyap Chamarthy geschrieben:
> 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 <kcham...@redhat.com>
> Reviewed-by: Eric Blake <ebl...@redhat.com>
> +(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 storage migration.
As commented on v4, I dropped the last sentence here for now. Please
suggest an unambiguous wording if you'd prefer to keep it.
Thanks, applied to the block branch.
Kevin
