Feature #5223
Improve snapshots management
| Status: | Pending | Start date: | 07/11/2017 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | Release 5.6 | |||
| Resolution: | Pull request: |
Description
https://dev.opennebula.org/issues/4393#note-17
1. even with ALLOW_ORPHANS="yes" in TM_MAD conf it is not possible to delete any disk snapshot
1.1 Sunstone don't allow deleting "current" snapshot with reason "[one.vm.disksnapshotdelete] Cannot delete the active snapshot"
1.2 Sunstone don't allow deleting "parent" snapshot with reason "[one.vm.disksnapshotdelete] Cannot delete snapshot with children"
1.3 it is not allowed to resize a disk if it has snapshots with reason "[one.vm.diskresize] Cannot resize a disk with snapshots"
(1.4 [new feture?] there is no option to do (atomic)snapshots on all VM disks at once in a single transaction)
All of the above constraints are not issue in StorPool. The snapshots in StorPool are exactly how the snapshot tree is drawn. And the active disk volume is the final leaf to a snapshot then. Each snapshot keeps only the changes against its parent. When a snapshot is deleted its changes are merged to its leaf(s) - either snapshot or the active volume. I'll try to explain with a simple drawing
a VM has one disk named DISK_0, when you do a snapshot it will have
SNAPSHOT_A
\
DISK_0
When you take a second snapshot you'll have
SNAPSHOT_A
\
SNAPSHOT_B
\
DISK_0
When you delete SNAPSHOT_A the shared data is copied to ites leaf.. in this case SNAPSHOT_B
When SNAPSHOT_B is deleted the shared data is copied back to its leaf - DISK_0
The only thing I can think of is that when a disk snapshot is created the actual disk size should be saved as an attribute to the snapshot and when a snapshot is restored - to alter the value in the VM tample with the value saved in the snapshot.
For example if we have a disk with size 10GB, take a snapshot and then resize the disk to 15 GB. When you revert the disk to the snapshot the resulting disk size will be reverted back to 10GB.
I am almost sure same is with CEPH too.
Regarding the VM snapshots.
When managed by libvirt they are locked to the current KVM host and for qcow2 images only. OpenNebula correctly delete the VM snapshots on migrate with KEEP_SNAPSHOTS=no in VMM_MAD. StorPool has no integration with libvirt so the VM snapshot interface is re-purposed to do (1.4 from above) - atomic snapshots on all disks with a single transaction. I achieve this by defining custom local snapshot scripts and setting KEEP_SNAPSHOTS=yes in the VMM_MAD configuration vector for KVM. Again the VM disk resize is in not limited in any way. The only issue is again the disk sizes in the internal VM_TEMPLATE for the cases when there are disk resizes involved after a snapshot is taken. Currently I am stopping oned and altering the database. An API interface to alter only the value would be greatly appreciate :)
There are some more features I am working on:
+ option to limit the number of snapshots per VM (disk and/or "modified" VM snapshots). Configurable per VM or a global attribute in the SYSTEM datastore template.
+ option to export a VM disk from given VM snapshot as a new image - there is a customer with this feature request(to fight ransomware somehow...)
As I am awful in the big explanations you are welcome to ask any questions to clarify :)
Best Regards,
Anton Todorov
History
#1
Updated by Ruben S. Montero almost 4 years ago
1. even with ALLOW_ORPHANS="yes" in TM_MAD conf it is not possible to delete any disk snapshot 1.1 Sunstone don't allow deleting "current" snapshot with reason "[one.vm.disksnapshotdelete] Cannot delete the active snapshot" 1.2 Sunstone don't allow deleting "parent" snapshot with reason "[one.vm.disksnapshotdelete] Cannot delete snapshot with children"
Is this a Sunstone problem?, does it work through the CLI?. If not could you double check the installation, pitfalls:
- The VM is has been created before adding ALLOW_ORPHANS
- oned.conf is not the last one. You need INHERIT_DATASTORE_ATTR = "ALLOW_ORPHANS"
- Datastore was created previous to the oned.conf set. You need manually to trigger an update to include ALLOW_ORPHANS in the datastore template.
1.3 it is not allowed to resize a disk if it has snapshots with reason "[one.vm.diskresize] Cannot resize a disk with snapshots"
This is not currently implemented (we didn't consider that case ;) and could be done for 5.4
(1.4 [new feture?] there is no option to do (atomic)snapshots on all VM disks at once in a single transaction)
This would be the main reason for this issue
#2
Updated by Anton Todorov almost 4 years ago
Hi Ruben,
Thank you for the feedback!
I am working on... lets say upgraded version of OpenNebula :)
And I've missed the third point to add the "ALLOW_ORPHANS=yes" to the datastore. The interface to delete any disk snapshot works. The tree-view is lost but I think it is definitely anoter case for which I'll add a separate feature request.
1.3 it is not allowed to resize a disk if it has snapshots with reason "[one.vm.diskresize] Cannot resize a disk with snapshots" This is not currently implemented (we didn't consider that case ;) and could be done for 5.4
I think this is somehow related to #5224 though. If it is allowed to restore disks with different size I'll need a way to tell OpenNebula what is the current disk capacity.
(1.4 [new feture?] there is no option to do (atomic)snapshots on all VM disks at once in a single transaction) This would be the main reason for this issue
Totally agree :)
Best Regards,
Anton
#3
Updated by Ruben S. Montero almost 4 years ago
And I've missed the third point to add the "ALLOW_ORPHANS=yes" to the datastore. The interface to delete any disk snapshot works. The tree-view is lost but I think it is definitely anoter case for which I'll add a separate feature request.
Hi Anton, that was the requirement for the issue #4885 (I mean, remove the tree view to the snapshots and present a flat list)
#4
Updated by Anton Todorov almost 4 years ago
Hi Anton, that was the requirement for the issue #4885 (I mean, remove the tree view to the snapshots and present a flat list)
Yes, I entirely understand. All visuals are just for user experience. I'll check what our users look for/prefer/ and only then will create feature request if needed.
Personally, I like the tree view because it is (sort of) showing the history and hierarchy of the snapshots. But as already said - it is nothing critical or special at all...
Best Regards,
Anton Todorov
#5
Updated by Stefan Kooman almost 4 years ago
+1 for support for 1.3 (allowed to resize a disk if it has snapshots). I'm really happy we have live disk resize now in 5.4. I'm also happy that we can delete snapshots that are not needed anymore (no more chain depedencies). It would be awesome to be able to resize images with snapshots. Definately a use case for our customers for sure.
1.4: would be nice also, but has less priority IMHO