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
>>> to write domain disks to revert them to backed up state. The previous
>>> of RFC is . I'll also describe the API implementation details to shed
>>> 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).
> we have command block-dirty-bitmap-remove in qemu. We don't have transaction
> 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-enable (not in the examples; used when removing
>>> most recent checkpoint)
> they are in
> [PATCH for-2.12 0/4] qmp dirty bitmap API
> (long discussion)
> and, I've already started v2 (preliminary refactoring):
> [PATCH 0/7] Dirty bitmaps fixing and refactoring
> (mostly not reviewed)
> it is in
> [PATCH for-2.13 0/4] NBD export bitmaps
> (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
libvir-list mailing list