[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 for-2.11] QAPI & interop: Clarify events emit
From: |
Kashyap Chamarthy |
Subject: |
Re: [Qemu-devel] [PATCH v4 for-2.11] QAPI & interop: Clarify events emitted by 'block-job-cancel' |
Date: |
Tue, 21 Nov 2017 10:58:48 +0100 |
User-agent: |
Mutt/1.6.0.1 (2016-04-01) |
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