[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactiona
From: |
John Snow |
Subject: |
Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable |
Date: |
Mon, 3 Apr 2017 16:29:11 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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.
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."
--js
> I realize that 'block-job-cancel' is currently not part of the
> @TransactionAction. Is it worthwhile to do so?
>
> Given the current behavior of QMP 'drive-mirror':
>
> - Upon 'block-job-complete', synchronization will end, and live QEMU
> pivots to the target (i.e. the copy)
>
> - Upon 'block-job-cancel', a point-in-time (at the time of cancel)
> copy gets created, and live QEMU will _not_ pivot.
>
> I realize that it is not possible to perform a "block copy" of multiple
> disks at the same point in time without pausing QEMU. From a brief chat
> with Stefan Hajnoczi on IRC, he does confirm that there's no current API
> for doing it atomically across multiple disks.
>
> Since Stefan asked if a bug exists for adding 'transaction' support to
> 'block-job-cancel', thought I might bring it up here first.
>
>
> [*] https://libvirt.org/git/?p=libvirt.git;a=commit;h=eaba79d --
> blockjob: support pivot operation on cancel
>
Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable, Kevin Wolf, 2017/04/11