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

What are the downsides to actually including a predecessor/successor* pointer in QEMU? (1) We'd need to amend the bitmap persistence format

(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.

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? :)

*(Uh-oh, that term is overloaded for QEMU bitmap internals... we can address that later...)