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

[John Snow]

On 04/11/2018 09:56 AM, Eric Blake wrote:
> On 04/03/2018 07:01 AM, Nikolay Shirokovskiy wrote:
>> Hi, all.                                                                                         
>>                                                                                                  
>> This is another RFC on pull backup API. This API provides means to read domain                   
>> disks in a snapshotted state so that client can back them up as well as means                    
>> to write domain disks to revert them to backed up state. The previous version                    
>> of RFC is [1]. I'll also describe the API implementation details to shed light                   
>> on misc qemu dirty bitmap commands usage.                                                        
> 
> Thanks for such a detailed message!  It's got enough that I want to
> spend some time thinking about the implications, but this is an early
> reply to let you know I'm at least working on it now.
> 
> The first thing that caught my eye:
> 
>> Here is a list of bitmap commands used in implementation but not yet in upstream (AFAIK).
>>
>> x-vz-block-dirty-bitmap-remove

We have clear and transactionless remove; this is fine.

>> x-vz-block-dirty-bitmap-merge

Vladimir has a prototype for this I am dragging my feet on because I
wanted to see the anticipated use case, which is provided here. The code
is not complicated.

>> x-vz-block-dirty-bitmap-disable

Same story.

>> x-vz-block-dirty-bitmap-enable (not in the examples; used when removing most recent checkpoint)

Same.

>> x-vz-nbd-server-add-bitmap

<<TANGENT

This one is new to me, but I haven't been looking at the NBD code much.
I have at times in the past suggested a bigger convenience command, like:

x-export-node bitmap=foo node=bar cache-node=baz id=zzyzx [...options...]

which would start an NBD server, tie the bitmap "foo" to it, export the
node "bar", use the node "baz" as a backing-store for writes to "bar"
while the export was active (this is starting a fleecing operation and
that cache needs to be somewhere) ...

and then after we're done,

x-close-export id=zzyzx [...options...]

There's been an open question in my mind if we want to expose all of
this functionality through primitives (like Virtuozzo is proposing) or
if we want to also wrap it up in a convenience command that allows us to
offer more focused testing and declare only a subset of combinations of
these primitives as supported (through what is effectively a new job
command.)


...but don't worry about this suggestion too much. I'll read the full
email and Eric's reply to it in a moment and re-evaluate what I think
about how to expose these features in a moment.

TANGENT

> 
> How close are we to having upstream implementations of any of those
> commands?  If not, what are their specifications?  Libvirt is very
> hesitant to add code that depends on a qemu x-* command, but if we can
> get the actual command into qemu.git without the x-* prefix, it is
> easier to justify libvirt adding the API even if qemu 2.13 is not yet
> released.
> 

Answered in part above, I was hesitant to check in new bitmap commands
like "merge" without the x- prefix to QEMU before I could see the
anticipated workflow and usage for these commands, so I'm going to try
to read this email very carefully to offer any critique.

At one point I offered an alternative workflow that was ... too complex
and at odds with our existing primitives, and I decided to be a little
more hands-off after that.

I'll try to be brief and prudent here.

--js

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