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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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?

--js

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux