On August 21, 2019 11:19 pm, John Snow wrote: > > > 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. Chiming in with a bit of vacation-induced delay - libvirt is definitely not the only user of QEMU's QMP interface - we at Proxmox use QEMU directly in our Proxmox VE product (usually a rather recent version, currently 4.0 with some cherry-picks and custom patches) and have been doing so for quite a while (the earliest reference in git that I can find is for QEMU 0.11.1, but there was SVN before that..). IIRC, we currently only use the bitmap features for our own custom backup jobs (shipped in our patched QEMU packages[1]), and are planning to integrate differential mirroring on top of storage-level/ZFS snapshots once that has stabilized upstream. That being said, the same basic guidelines apply to us that apply to libvirt - our users are (normally) also not talking QMP manually, our stack does it for them. Misuse of QMP interfaces is thus a bug in our software, and not a mistake made by its user. We do expose HMP over our API, but that is more for convenience of power users than any real use case that I am aware of. 1: patches #20-24 from https://git.proxmox.com/?p=pve-qemu.git;a=tree;f=debian/patches/pve;h=46bd31d60fe2c03571d9d29c7ee80f208206d37e;hb=refs/heads/master -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
