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.
Attachment:
signature.asc
Description: PGP signature
