On 04/03/2018 08:01 AM, Nikolay Shirokovskiy wrote:
> Hi, all.
> This is another RFC on pull backup API. This API provides means to read
> 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 . I'll also describe the API implementation details to shed
> on misc qemu dirty bitmap commands usage.
> This API does not use existent disks snapshots. Instead it introduces
> provided by qemu's blockdev-backup command. The reason is we need snapshotted
> disk state only temporarily for duration of backup operation and newly
> introduced snapshots can be easily discarded at the end of operation without
> block commit operation. Technically difference is next. On usual snapshot we
> create new image backed by original and all new data goes to the new image
> original image stays in a snapshotted state. In temporary snapshots we create
> new image backed by original and all new data still goes to the original
> but before new data is written old data to be overwritten is popped out to
> the new
> image thus we get snapshotted state thru new image.
> Disks snapshots as well as disks itself are avaiable to read/write thru qemu
> NBD server.
Do you think it's possible to characterize this API proposal as two
(1) A mechanism for creating and manipulating "checkpoints" -- which are
book-ended by bitmap objects in QEMU -- implemented by the creation,
deletion, 'disabling' and 'merging' of bitmaps, and
(2) A mechanism for the consumption of said checkpoints via NBD / the
"fleecing" mechanisms that allow a live export of a static view of the
disk at that time (block snapshots + NBD exports)
If this is the case, do you think it is possible to consider (1) and (2)
somewhat orthogonal items -- in so far as it might be possible to add
support to libvirt directly to add push-model support for writing out
once you have created a temporary snapshot and merged the various
component bitmaps into it, instead of creating an ephemeral block
snapshot and exporting it via NBD, we request a `blockdev-backup` with a
libvirt-specified target instead?
You don't have to add support for this right away, but I would really
enjoy if any API we check in here has the capacity to support both
push-and-pull paradigms without getting too ugly.
Does that sound like it can easily fit in with your designs so far?
libvir-list mailing list