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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]

On 04/03/2017 03:29 PM, John Snow wrote:
> 
> 
> 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.
> 
> I think at other points we have discussed the concept of having a
> configurable completion mode that jobs could have (and allowing this
> setting to be adjusted at runtime) that changes which completion mode
> they'll pursue.

Indeed, having a runtime-adjustable completion mode would allow what
libvirt wants: libvirt doesn't know what mode the user wants until they
request virDomainBlockJobAbort() (the name is scary, but it merely means
that they are stopping what is otherwise an unending job), and pass a
flag that says whether they want pivot or end-point-in-time copy
semantics.  If they request pivot semantics, libvirt invokes
block-job-complete to do its default completion mode, if they request
copy semantics, libvirt then switches the completion mode and still
calls block-job-complete (which _is_ valid in a transaction).

> 
> This would make a cancel unambiguously a cancellation. It would make a
> non-pivot completion to a mirror action an unambiguous success, too.
> 
> Minor nit, perhaps, but I want to be sure before we cement the semantics
> of how mirror can be "successful."

Minor or not, it is a useful viewpoint. Either way, as long as the new
way of getting a transactional non-pivot successful completion is
something that libvirt can learn via introspection, it should solve what
we are hoping for here.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]