[libvirt] [RFC v2] external (pull) backup API

Eric Blake eblake at redhat.com
Wed Apr 18 15:28:24 UTC 2018


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180418/9c473af8/attachment-0001.sig>


More information about the libvir-list mailing list