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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
