Re: [libvirt] [Qemu-devel] QEMU bitmap backup usability FAQ

On 8/21/19 10:21 AM, Vladimir Sementsov-Ogievskiy wrote: > [CC Nikolay] > > 21.08.2019 1:25, John Snow wrote: >> Hi, downstream here at Red Hat I've been fielding some questions about >> the usability and feature readiness of Bitmaps (and related features) in >> QEMU. >> >> Here are some questions I answered internally that I am copying to the >> list for two reasons: >> >> (1) To make sure my answers are actually correct, and >> (2) To share this pseudo-reference with the community at large. >> >> This is long, and mostly for reference. There's a summary at the bottom >> with some todo items and observations about the usability of the feature >> as it exists in QEMU. >> >> Before too long, I intend to send a more summarized "roadmap" mail which >> details all of the current and remaining work to be done in and around >> the bitmaps feature in QEMU. >> >> >> Questions: >> >>> "What format(s) is/are required for this functionality?" >> >> From the QEMU API, any format can be used to create and author >> incremental backups. The only known format limitations are: >> >> 1. Persistent bitmaps cannot be created on any format except qcow2, >> although there are hooks to add support to other formats at a later date >> if desired. >> >> DANGER CAVEAT #1: Adding bitmaps to QEMU by default creates transient >> bitmaps instead of persistent ones. >> >> Possible TODO: Allow users to 'upgrade' transient bitmaps to persistent >> ones in case they made a mistake. > > I doubt, as in my opinion real users of Qemu are not people but libvirt, which > should never make such mistake. > Right, that's largely been the consensus here; but there is some concern that libvirt might not be the only user of QEMU, so I felt it was worth documenting some of the crucial moments where it was "easy" to get it wrong. I think like it or not, the API that QEMU presents has to be considered on its own without libvirt because it's not a given that libvirt will forever and always be the only user of QEMU. I do think that any problems of this kind that can be solved in libvirt are not immediate, crucial action items. libvirt WILL be the major user of these features.