On 11.04.2018 17:16, Vladimir Sementsov-Ogievskiy wrote: > 11.04.2018 16:56, Eric Blake wrote: >> On 04/03/2018 07:01 AM, Nikolay Shirokovskiy wrote: >>> Hi, all. >>> This is another RFC on pull backup API. This API provides means to read domain >>> disks in a snapshotted state so that client can back them up as well as means >>> to write domain disks to revert them to backed up state. The previous version >>> of RFC is [1]. I'll also describe the API implementation details to shed light >>> on misc qemu dirty bitmap commands usage. >> Thanks for such a detailed message! It's got enough that I want to >> spend some time thinking about the implications, but this is an early >> reply to let you know I'm at least working on it now. >> >> The first thing that caught my eye: >> >>> Here is a list of bitmap commands used in implementation but not yet in upstream (AFAIK). >>> >>> x-vz-block-dirty-bitmap-remove > > we have command block-dirty-bitmap-remove in qemu. We don't have transaction support, > but it is hard to implement it, because we need to protect from operations on same bitmap in same > transaction, so, we decided to not do it, Nikolay? Yeah, that's right. Having bitmap remove operation outside of transaction will not impact implementation of tracking bitmaps order and consistency in libvirt substantially. > >>> x-vz-block-dirty-bitmap-merge >>> x-vz-block-dirty-bitmap-disable >>> x-vz-block-dirty-bitmap-enable (not in the examples; used when removing most recent checkpoint) > they are in > [PATCH for-2.12 0/4] qmp dirty bitmap API > https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg02281.html > (long discussion) > > and, I've already started v2 (preliminary refactoring): > [PATCH 0/7] Dirty bitmaps fixing and refactoring > https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg06568.html > (mostly not reviewed) > >>> x-vz-nbd-server-add-bitmap > > it is in > [PATCH for-2.13 0/4] NBD export bitmaps > http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg05701.html > (reviewed, I need to respin) > > >> How close are we to having upstream implementations of any of those >> commands? If not, what are their specifications? Libvirt is very >> hesitant to add code that depends on a qemu x-* command, but if we can >> get the actual command into qemu.git without the x-* prefix, it is >> easier to justify libvirt adding the API even if qemu 2.13 is not yet >> released. > > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
