Re: RFC: revert to external snapshot API

On Mon, Sep 13, 2021 at 17:52:49 +0300, Nikolay Shirokovskiy wrote: [...] Well, if the management deletes them (at least 'base.qcow2'), it's a problem because it can no longer be reverted to 'snap1'. As you've correctly pointed out 'snap1.qcow2' is unreachable and thus should have been deleted. Sure but programatically checking all the possibilities (e.g. in this scenario: s s n n a a p p 1 2 vda.qcow2 │ vda.snap1 │ vda.snap2 o ────────────► │ ──────────────────────► │ ────────── p r vdb.qcow2 │ vdb.snap2 r i ──────────────────────────────────────► │ ────────── e g vdc.qcow2 vdc.snap1 vdc.other │ vdc.snap2 s i ────────────► │ ─────────X ──────────► │ ────────── e n vdd.qcow2 │ vdc.snap1 vdc.snap1 │ vdd.snap2 n ────────────► │ ─────────X ──────────► │ ────────── t will become a bit of a nightmare. E.g. checking that 'vdc' was replaced by a different image if the names don't match might be feasible, but if a user just rewrites the image it's actually impossible for us to detect. This will require a bit more of thinking how to deal with certain situations and we might even need to be able to introduce a flag for reverting from an unsafe scenario such as: s n a p 1 vda.qcow2 │ vda.snap1 ────────────► │ ────────────────────── vdc.qcow2 vdc.snap1 vdc.other ────────────► │ ─────────X ────────── Even here we need to be careful, because reverting back to snap1 will possibly leak 'vdc.other'. To manage user expectations properly we might want to add a flag which will e.g. disallow reversion if files which arent recorded in 'snap1' are going to be left behind but we must never delete 'vdc.other' to prevent data loss. No, you are right. I forgot that we actually do, which is good. This will provide the possibility to do a lot of checks to prevent breaking user setup. This point is no longer applicable. We do record the snapshot XML too so this allows us to do checking whether the current configuration of the VM is consistent with the state when the snapshot was created. Basically the hardest part of this is to ensure that we don't remove or corrupt any image with user data which still might be needed. For simple VM definitions this is very simple but since we give the users quite a lot of freedom what to do (including replacing disks, taking partial snapshots, etc.) we then need to be prepared for a comparatively large number of scenarios we'll need to deal with. Unfortunately we're risking data loss here, so we need to approach it very carefully especially for scenarios where individual users use e.g. virsh to do management where they might not have tested whether everything works on throwaway VMs. [...] Yeah, both need to be implemented at the same time. We definitely plan to work on it, but I can't give you any time estimates yet. More importantly, since you are interested into this as well, it would be great if you could elaborate on how you want to use this if it's ready especially any special scenarios. For us the basic goal is to achieve feature parity between internal and external snapshots so that they can be used interchangably and eventually prefering external snapshots as the way forward.