[libvirt] [RFC v2] external (pull) backup API

[Nikolay Shirokovskiy]

On 19.04.2018 20:28, John Snow wrote:
> 
> 
> On 04/16/2018 06:20 AM, Vladimir Sementsov-Ogievskiy wrote:
>>
>> So my point is: if we are going to implement something complicated,
>> let's implement entirely what we want, not a semi-solution. Otherwise,
>> implement a minimal and simple thing, to just make it all work (my
>> current solution).
> 
> So basically:
> 
> (1) Using bitmap names: It's a hack, but it works; and
> (2) Adding parentage information to QEMU bitmaps is also a hack, but a
> more permanent commitment to the hack.
> 
> And further, both (1) and (2) leave the same problem that if a third
> party utility deletes the bitmap, they are checkpoint-unaware and will
> ruin the metadata.
> 
> (Though QEMU could be taught to disallow the deleting of bitmaps with
> parents/children, unless you specify --force or --mergeleft or
> --mergeright or some such. That's not an option with the
> name-as-metadata strategy.)
> 
> Why is option 3 unworkable, exactly?:
> 
> (3) Checkpoints exist as structures only with libvirt. They are saved
> and remembered in the XML entirely.
> 
> Or put another way:
> 
> Can you explain to me why it's important for libvirt to be able to
> reconstruct checkpoint information from a qcow2 file?
> 

In short it take extra effort for metadata to be consistent when 
libvirtd crashes occurs. See for more detailed explanation 
in [1] starting from words "Yes it is possible".

[1] https://www.redhat.com/archives/libvir-list/2018-April/msg01001.html

Nikolay