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?
Regards,
Povilas
[1]: https://libvirt.org/formatsnapshot.html
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
