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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
