Re: [Qemu-devel] [PATCH v4 for-2.11] QAPI & interop: Clarify events emitted by 'block-job-cancel'

[Kashyap Chamarthy <kchamart@redhat.com>]

On Fri, Nov 17, 2017 at 07:54:44PM +0100, Kashyap Chamarthy wrote:

[...]

> +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].
>  
> -(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.  One use case for this is live
> +    storage migration.

Dave Gilbert pointed out on IRC that last sentence ("One use case for
this is live storage migration") should apply to point (1) above.  He's
right, I'll send a v5 with that (and the commit message tweak I noted
earlier) fix.

[...]


-- 
/kashyap