Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable

[Kevin Wolf <kwolf@redhat.com>]

Am 03.04.2017 um 22:29 hat John Snow geschrieben:
> On 03/24/2017 08:34 AM, Kashyap Chamarthy wrote:
> > While debugging some other issue, I happened to stumble across an old
> > libvirt commit[*] that adds support for pivot (whether QEMU should
> > switch to a target copy or not) operation as a result of issuing QMP
> > 'block-job-cancel' to a 'drive-mirror' (in libvirt parlance, "block
> > copy").
> > 
> > In the libvirt commit message[*] Eric Blake writes:
> > 
> >     "[...] There may be potential improvements to the snapshot code to
> >     exploit block copy over multiple disks all at one point in time.
> >     And, if 'block-job-cancel' were made part of 'transaction', you
> >     could copy multiple disks at the same point in time without pausing
> >     the domain. [...]"
> > 
> 
> Oh, you want a transactional cancel to basically capitalize on the
> second completion mode of the mirror job.
> 
> I have never really cared for the way this job works, because I don't
> think "canceling" a ready job is semantically valid (it's not canceled!
> We completed successfully, just using a different completion mode) --
> but if I am in the minority here I would cede that a transactional
> cancel would be a worthwhile thing to have.

Note that job completion/cancellation aren't synchronous QMP commands.
The job works something like this, where '...' means that the VM can run
and submit new writes etc.:

1. Start job: mirror_start
...
2. Bulk has completed: BLOCK_JOB_READY event
...
3. Request completion/cancellation: block-job-completet/cancel
...
4. Actual completion/cancellation: BLOCK_JOB_COMPLETED

The last one is the actual job completion that we want to be atomic for
a group of nodes. Just making step 3 atomic (which is what including
block-job-complete/cancel in transaction would mean) doesn't really buy
us anything because the data will still change between step 3 and 4.

Now step 4 is reached for each job individually, and unless you stop the
VM (or at least the processing of I/O requests), I don't see how you
could reach it at the same time for all jobs.

Kevin