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