On 04/11/2018 11:14 PM, John Snow wrote: >>> 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. >> > > Oh, I see -- you're using blockdev-backup sync=none to accomplish > fleecing snapshots. It's a little confusing here without the sync=none > information, as usually blockdev-backup provides... backups, not snapshots. Right now, I'm leaning towards a single virDomainBackupStart()/virDomainBackupEnd() pair that work for both push and pull model backups: push model: Start() command points to the place to use as the destination that qemu will push to; it either provides the checkpoint to start from (qemu's "sync":"incremental", using the appropriate bitmap(s) to construct how much data to actually push to the destination), or omits the checkpoint (full backup, qemu's "sync":"full"); optionally creates a new checkpoint at the same time; emits a libvirt event to note when the backup job is complete; then user calls End() to tear down any resources (qemu can no longer write to the destination) pull model: Start() command points to place to use as temporary storage so that guest can continue to write, AND includes the details of the NBD server to set up for third-party access to the backup. The command optionally provides the checkpoint to expose over NBD (which gets translated into the bitmap(s) to expose as block status), or omits it (the third party has to assume that the full image is dirty); either way, the temporary storage uses "sync":"none", and it is up to the third party connecting to NBD how much of the image to read (whether a checkpoint was specified or not, the third-party can read the entire image if desired, or only a fraction of the image if desired; but a checkpoint has to be provided if the third party plans on learning how much of the image to read to capture an incremental backup). There is no event emitted by libvirt; the user calls End() when the third-party client is done using the NBD connection. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
