On Mon, Apr 03, 2017 at 03:38:36PM -0500, Eric Blake wrote: > On 04/03/2017 03:29 PM, John Snow wrote: > > On 03/24/2017 08:34 AM, Kashyap Chamarthy wrote:
[...] > >> "[...] 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). Thanks for the nice articulation of the problem at hand, and yes -- configurable / "runtime-adjustable completion mode" would be useful for long-running block operations. > > 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, Can you elaborate a little more on the above, for my own edification -- how might it be possible for "libvirt can learn via introspection"? Is it via some method using the QMP 'query-commands' / 'query-command-line-options'? > it should solve what we are hoping for here. -- /kashyap
