[libvirt] External disk snapshot paths and the revert operation

[Povilas Kanapickas]

On 21/10/2018 21:31, Povilas Kanapickas wrote:
> Hey,
> 
> It seems that there's an issue of how external disk snapshots currently
> work. The snapshot definition xml[1] that is supplied to the API has a
> list of disks each of which specify where the new overlay disks should
> be placed.
> 
> This leads to ambiguities when we want to revert the domain to a
> snapshot with children. Consider the following situation:
> 
> 0. Initial state:
> Domain definition: disk at disk-base.qcow2
> 
> 1. We create a snapshot snap1 placing the overlay at disk-snap1.qcow2
> 
> Domain definition: disk at disk-snap1.qcow2
> Disks:
>   - disk-base.qcow2 (read-only)
>   - disk-snap1.qcow2 (overlay, base: disk-base.qcow2)
> 
> Snapshots:
>   - snap1 (snapshot domain disk list: disk-base.qcow2,
>            snapshot disk list: disk-snap1.qcow2)
> 
> 2. We create another snapshot snap2 placing the overlay at disk-snap2.qcow2
> 
> VM definition: disk at disk-snap2.qcow2
> Disks:
>   - disk-base.qcow2 (read-only)
>   - disk-snap1.qcow2 (overlay, base: disk-base.qcow2, read-only)
>   - disk-snap2.qcow2 (overlay, base: disk-snap1.qcow2)
> 
> Snapshots:
>   - snap1 (snapshot domain disk list: disk-base.qcow2,
>            snapshot disk list: disk-snap1.qcow2)
>   - snap2 (snapshot domain disk list: disk-snap1.qcow2,
>            snapshot disk list: disk-snap2.qcow2)
> 
> Now what happens if we want to revert to snap1? We can't use any of the
> paths that snap1 itself references: both disk-base.qcow2 and
> disk-snap1.qcow2 are read-only as part of the backing chain for disks
> used by snap2. Possible options are these:
> 
>  - we can reuse disk-snap2.qcow2 which we no longer need as it contains
> overlay on top of snap2. This is non-optimal because now the path of the
> disk after revert depends on the disk path before it.
> 
>  - we can think of some name with the expectation that the user will
> change it later anyway.
> 
> I think that both of the above are non-optimal because we don't actually
> revert to the exact state we took the snapshot of. The user is
> effectively no longer in control of the disk path after the revert.
> 
> One of possible solutions would be add additional flag during the
> snapshot creation that would change the current behavior. Instead of
> creating a new disk for the overlay we could move the base disk to the
> specified path and create the overlay in its place. The advantages of
> this behavior would be the following:
> 
>  - the path to the current disk used in the domain would not change when
> taking snapshots. This way we could avoid the problem listed above and
> easily revert to any snapshot.
> 
>  - the confusion in naming of the overlay disks would be reduced.
> Currently the path specified when creating snapshot refers to the
> overlay image. Most of the time user does not know what will be changed
> in the domain until the next snapshot. So any path he chooses will
> likely not reflect what will end up in the overlay at the time of the
> next snapshot. If it was possible to specify the path where the current
> disk should be put instead, then the user could just name it after the
> snapshot and it would correctly represent the contents of that disk.
> 
> The major disadvantage of the approach is that it would introduce extra
> complexity in the presently simple interface and also the underlying
> code. I've completely disregarded the case of taking snapshots while the
> domain is running, so there might be hidden complications there as well.
> 
> Personally, I don't mind the current situation too much, but if libvirt
> developers think it's a thing worth fixing I would be willing to work on it.
> 
> Any opinions?
> 

Friendly ping :-)

Regards,
Povilas