[libvirt] [PATCH v4 0/8] bulk snapshot list/redefine (incremental backup saga)

[Nir Soffer]

On Wed, Mar 13, 2019 at 12:01 AM Eric Blake <eblake at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190313/b4389437/attachment-0001.htm>