On 3/12/19 6:45 PM, Nir Soffer wrote: > > 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. Correct - from libvirt's point of view, when a disk is hotplugged, the next backup needs to perform a full backup rather than an incremental backup on that disk, because that disk was not present in the machine on the last checkpoint and therefore does not have bitmap coverage from the last checkpoint to the present moment. But you don't necessarily have to delete bitmaps from the qcow2 file to get this effect. The fact that libvirt stored a full <domain> at the time of the checkpoint is enough for libvirt to tell that you are requesting a backup of a disk that did not exist at the starting checkpoint, and therefore that disk needs a full rather than incremental backup. > > I think what we keep is enough to tell libvirt which bitmaps are needed for > a backup. The current design for virDomainBackup() is that you state which checkpoint to start from, and then libvirt computes all bitmaps from that checkpoint to the present in order to perform the incremental backup, or complains that there is no sequence of bitmaps that covers that length in time so you have to do a full backup instead. You do not tell libvirt 'perform a backup of the clusters represented in bitmaps B, C, and D', but 'perform a backup of the clusters modified since time T2'. Libvirt then crawls the chain of checkpoint objects to find T2 and verify which bitmaps between T2 and the present (if that be bitmaps B, C, and D) that it needs to use to perform that differential 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. And that configuration per checkpoint IS the <domain> subelement. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 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
