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 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.
This API does not use existent disks snapshots. Instead it introduces snapshots
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 thus
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 image
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.
[snip!]
Do you think it's possible to characterize this API proposal as two
mechanisms:
(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
these checkpoints?
i.e.
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?