[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactiona
From: |
Kashyap Chamarthy |
Subject: |
Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable |
Date: |
Tue, 4 Apr 2017 15:28:15 +0200 |
User-agent: |
Mutt/1.6.0.1 (2016-04-01) |
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
Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Kevin Wolf, 2017/04/11
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Eric Blake, 2017/04/11
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Kevin Wolf, 2017/04/11
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Fam Zheng, 2017/04/12
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Kevin Wolf, 2017/04/12
- Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Fam Zheng, 2017/04/12