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

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?