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