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? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list