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

[John Snow]

On 04/12/2018 10:08 AM, Vladimir Sementsov-Ogievskiy wrote:
> It's not easier, as we'll have to implement either separate of bitmaps
> concept of checkpoints, which will be based on bitmaps, and we'll have
> to negotiate and implement storing these objects to qcow2 and migrate
> them. Or we'll go through proposed by Kevin (If I remember correctly)
> way of adding something like "backing" or "parent" pointer to
> BdrvDirtyBitmap, and anyway store to qcow2, migrate and expose qapi for
> them. The other (more hard way) is move to multi-bit bitmaps (like in
> vmware), where for each granularity-chunk we store a number,
> representing "before which checkpoint was the latest change of this
> chunk", and the same, qapi+qcow2+migration.
> 
> It's all not easier than call several simple qmp commands.

OK, I just wanted to explore the option before we settled on using the
name as metadata.

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