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