On 04/13/2018 03:02 PM, John Snow wrote:
What are the downsides to actually including a predecessor/successor* pointer in QEMU?
(1) We'd need to amend the bitmap persistence format
Which I think is doable, since we have a size field.
(2) We'd need to amend some of the bitmap management commands (3) We'd need to make sure it migrates correctly: (A) Shared storage should be fine; just flush to disk and pivot (B) Live storage needs to learn a new field to migrate.
Certainly it's not ...trivial, but not terribly difficult either. I wonder if it's the right thing to do in lieu of the naming hacks in libvirt.
There wasn't really a chorus of applause for the idea of having checkpoints more officially implemented in QEMU, but... abusing the name metadata still makes me feel like we're doing something wrong -- especially if a third party utility that doesn't understand the concept of your naming scheme comes along and modifies a bitmap.
Speaking of that, we really need at least read-only commands for qemu-img to show details about what bitmaps are present in a qcow2 file, at least for debugging all of this.
It feels tenuous and likely to break, so I'd like to formalize it more. We can move this discussion over to the QEMU lists if you think it's worth talking about.
Or I'll just roll with it. I'll see what Eric thinks, I guess? :)
Indeed, discussing an enhancement of qcow2 metadata to track bitmap relationships is probably appropriate on the qemu list.
*(Uh-oh, that term is overloaded for QEMU bitmap internals... we can address that later...)
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org