On Wed, Mar 13, 2019 at 12:01 AM Eric Blake <eblake@redhat.com> wrote:
On 3/12/19 4:52 PM, Eric Blake wrote:
vm_checkpoints table
- checkpoint_id: UUID - parent: UUID - vm_id: UUID - creation_date: TIMESTAMP
vm_checkpoint_disk_map table - disk_id: UUID - checkpoint_id: UUID
And no state of the <domain> at the time the checkpoint was created?
I meant to add:
once we start playing with checkpoints vs. external snapshots vs. hotplug in anger, then knowing WHICH disks existed at the time of a given checkpoint may prove invaluable to even figure out WHICH disks need to participate in a given backup operation. The initial implementation uses XML (so that adding features can hopefully reuse the same API, rather than needing yet more one-off API additions), even if it is currently limited to not playing nicely with snapshots.
When you plug a disk, you cannot use any of the bitmaps on the disk because you don't have any guarantee that the user did not attach the disk to another machine that modified the data in some way without updating the bitmaps. So we are going to delete a disk from checkpoints once you unplug it, and start from scratch when you plug a disk. I think what we keep is enough to tell libvirt which bitmaps are needed for a backup. We probably need to keep the vm configuration per checkpoint or at least ensure consistency, so once you started a backup the configuration cannot change until the backup ends.