On Wed, Mar 13, 2019 at 12:01 AM Eric Blake <eblake@xxxxxxxxxx> 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.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
