On 03/24/2017 07: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. [...]" > > I realize that 'block-job-cancel' is currently not part of the > @TransactionAction. Is it worthwhile to do so?
Yes, it is still worthwhile to make that improvement, although it is now 2.10 material. > > 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 > -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
