When creating qemu-(kvm) disk-snapshots and removing them an obsolete link (ln -s) will not be removed

[Githopp192]

Description
When creating qemu-(kvm) disk-snapshots and removing them an obsolete link (ln -s) will not be removed.

To Reproduce (all steps done through sunstone gui)

• create disk-snapshot 1 on a image via sunstone (kvm-vm).
• create disk-snapshot 2 on this image
• snapshot 2 is the active one
• revert to snapshot 1 (this is now the active one)
• delete snapshot 2
• flattern snapshot 1 (this will start a "qemu-img convert -O qcow2 /var/lib/one//datastores/x/yyy.snap/1 /var/lib/one//datastores/x/yyy.tmp" operation)
• now disk disk.0 is linked to a non existing location:

lrwxrwxrwx 1 oneadmin oneadmin 68 Jun 21 17:08 disk.0 -> /var/lib/one//datastores/xxx/yyy.snap/2

ls: cannot access '/var/lib/one//datastores/xxx/yyy.snap/2': No such file or directory

-rw-rw-r-- 1 oneadmin oneadmin 2.0K Jun 21 17:51 deployment.5
drwxrwxr-x 1 oneadmin oneadmin 108 Jun 21 17:51 .
-rw-rw-r-- 1 oneadmin oneadmin 1.1K Jun 21 17:51 ds.xml
-rw-rw-r-- 1 oneadmin oneadmin 5.8K Jun 21 17:51 vm.xml
-rw-r--r-- 1 oneadmin oneadmin 364K Jun 21 17:51 disk.1
lrwxrwxrwx 1 oneadmin oneadmin 68 Jun 21 17:51 disk.2 -> /var/lib/one//datastores/xxx/yyy.snap/0
lrwxrwxrwx 1 oneadmin oneadmin 68 Jun 21 17:08 disk.0 -> /var/lib/one//datastores/xxx/yyy.snap/2
-rw-rw-r-- 1 oneadmin oneadmin 2.0K Jun 21 16:38 deployment.0

deployment.5 does reflect this situation:

Expected behavior
OpenNebula / sunstone should:

1. link (ln -s) disk.0 to /var/lib/one//datastores/xxx/yyy.snap/0
2. not link disk.2 -> /var/lib/one//datastores/xxx/yyy.snap/0
3. not let dangling link on disk without removing them

Details

• Affected Component: sunstone, image location
• Hypervisor: KVM
• Version: 6.4.0.1

Additional context

Progress Status

• Code committed
• Testing - QA
• Documentation (Release notes - resolved issues, compatibility, known issues)

[Githopp192]

What i did to resolve:

1. make sure vm is down ! (may be you should/can stop opennebula)
2. remove all soft-links (disk.0 & disk2) from affected vm
3. relink disk.0 to /var/lib/one//datastores/xxx/yyy.snap/0
4. chown - h : correct permissions to oneadmin:oneadmin (if you did it with root)
5. adjust appropriate <DISK_ID> (change from 2 to 0) : onedb update-body vm --id
6. start vm now should start with disk.0 = DISK_ID 0

[rsmontero]

Are you doing this flatten "outside" OpenNebula right? We are implementing #6265 to short backing chains (i.e. delete snapshots) for live and poff VMs. I'm closing this one as invalid

[Githopp192]

No - all operations did happen INSIDE OpenNebula (=> SUNSTONE) !

As i described - invalid links will remain on the storage layer - i did describe the steps i did to make the cleanup as workaround.

Normally OpenNebula / sunstone should do that - or better: set the corresponding links (ln -s) in a proper way.

[rsmontero]

How did you perform the flatten operation?

[Githopp192]

Insite sunstone gui (detached vm disk, storage/Images/Snapshots)

There you have several options in general: Flatten, Revert, Delete

If you wish i could create a document (PDF), which will reflect this situation

[rsmontero]

No problem, now I think understand the procedure. However, if you detach the image and then flatten it. It should not be any disk.0 in the VM folder, or did you reattach it? After reattaching the links should be recreated

[Githopp192]

i did re-create this case scenario with another vm. check-out the attached PDF.

OpenNebula_case#6247.pdf

[rsmontero]

THANKS a lot for the details. But as you said in the PDF disk.0 is a dead link not actually used by the VM. Agree this should be removed with the detach but it is not causing any trouble right? i.e. this is a cosmetic fix, as disk.0 has no meaning for OpenNebula at that point.

Also as mentioned earlier #6265 should allow you to do this without the detach / attach (and hence using the disk.0 reference)

[Githopp192]

Very welcome & yes, it's more a cosmetic one, which - as far i saw - did not cause operation issues.
Thx to link me to #6256