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

Reply via email to