Re: [libvirt] [PATCH v4 00/20] Incremental Backup API additions
On Mon, Feb 18, 2019 at 15:50:52 -0600, Eric Blake wrote:
On 2/18/19 10:34 AM, Peter Krempa wrote:
[...]
> In the ideal world of snapshots when deletion/revertion was
implemented
> we'd never expose the virDomainBlockCommit and virDomainBlockPull APIs
> including the multi-use backdoor virDomainBlockRebase() which should
> have never existed and users would do equivalent operations using the
> snapshot APIs.
>
> virDomainBlockCopy is useful on it's own though but badly combines with
> snapshots. This will need some fixing.
Indeed, and that's true regardless of whether the backup API goes in
(although the backup API probably compounds the issue on the number of
corner cases we have to think about; the conservative approach is that
at least in the beginning, you won't be able to run a BlockCopy and a
BackupBegin job at the same time).
We currently do this kind of interlocking between blockjobs and
snapshots as well, so that will not be a problem. We don't even allow
two blockjobs on non-conflicting parts of the backing chain while qemu
allows that now.
Allowing that will require some API design considerations/compromises as
our job tracking and manipulation APIs and events identify the job by
the disk.
Given that a guest can detach a disk frontend without qemu interaction
we will somehow need to be able to display jobs which don't have a disk
assigned any more though which will have the same implications
basically.
> With the new checkpoint APIs the situation is even more
"fun" as
> modification of the backing chain involves in some cases changes to the
> bitmaps. Ideally these would do "the right thing (TM)" during snapshot
> deletion/reversion. Given that at this time we don't support snapshot
> deletion/reversion for external snapshots we can use the excuse that
> snapshot management is not implemented so that checkpoints don't need
> to be modified.
Somewhat correct - but we DO have to think about how we plan for the API
to grow in the future when we eventually DO fix snapshot
deletion/reversion. Hence my question - would we rather have the
creation of a checkpoint at the same time as the creation of an external
snapshot (which we DO know we will want) to occur via the existing API
(by extending the snapshot XML to include the checkpoint XML as a
sub-element), or via a new API (by passing the checkpoint XML as a
second parameter)? Once we've answered that question, it then
determines what signature we want for virDomainBackupBegin() (either two
separate XML parameters, one for the backup job and one for the
checkpoint creation, as presented in v4 of the series, OR as one single
XML call where the checkpoint XML is a sub-element of the backup XML).
This is an interesting point. Given that the snapshot creates new files
(speaking of external snapshots obviously) you get an implicit
"checkpoint" at that moment as basically all blocks changed since that
moment are recorded in the overlay file. For any other snapshot you get
the same if you apply the overlay file on top of it.
Now the question is whether we need to be able to track that checkpoint
explicitly or whether it needs an explicit bitmap, but I'm not that
familiar with qemu implementation.
If we don't require any explicit bitmap or marking in qemu to be able to
track a checkpoint from a snapshot point we can e.g. allow the backup
API to take an external checkpoint as a reference for the backup
itself.
Creating both a snapshot and a checkpoint is certainly possible but I
fear that making the snapshot more complex than it is will be an
unexpected can of worms.
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)