[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-block] Making QMP 'block-job-cancel' transactionable
From: |
Kashyap Chamarthy |
Subject: |
[Qemu-block] Making QMP 'block-job-cancel' transactionable |
Date: |
Fri, 24 Mar 2017 13:34:58 +0100 |
User-agent: |
Mutt/1.6.0.1 (2016-04-01) |
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. [...]"
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
--
/kashyap
- [Qemu-block] Making QMP 'block-job-cancel' transactionable,
Kashyap Chamarthy <=