Upgrade from on 6.6.0.1 to 6.8.0.1 => error: Operation not supported: disk image 'sda' for internal snapshot 'snap1' is not the same as disk image currently used by VM

Community Support Upgrade
1

After a succesful opennebula migration from 6.6.0.1 to 6.8.0.1, one vm is not able to delete snapshots created before the upgrade.

I had to shutdown the vm and had remove all qemu-img (kvm) snapshots manually by performing:
qemu-img snapshot -d

It’s seems this issue affects only (K)VM, which run on a Hypervisor (KVM) with RHEL 9.3
KVM’s running on a Hypversior (KVM) with RHEL 8.10 seem not to be affected !?
ERROR message:

Sun Feb 9 19:57:52 2025 [Z0][VMM][E]: SNAPSHOTDELETE: ERROR: snapshot_delete: Command “virsh --connect qemu:///system snapshot-delete xx-xxx-xxx-xxx snap1” failed: error: Failed to delete snapshot snap1 error: Operation not supported: disk image ‘sda’ for internal snapshot ‘snap1’ is not the same as disk image currently used by VM Could not delete snapshot snap-657 for domain xx-xxx-xxx-xxx.

Only the vm snapshots done AFTER the upgrade (on 6.8.1.1) can be removed after creating.

2

just tested another vm (kvm) to remove older snapshots (created BEFORE the upgrade) =>

Sun Feb 9 21:16:31 2025 [Z0][VMM][E]: SNAPSHOTDELETE: ERROR: snapshot_delete: Command “virsh --connect qemu:///system snapshot-delete xxx-xxx snap-557” failed: error: Failed to delete snapshot snap-557 error: Operation not supported: disk image ‘sda’ for internal snapshot ‘snap-557’ is not the same as disk image currently used by VM Could not delete snapshot snap-557 for domain xxx-xxx-xxx.
Sun Feb 9 21:16:31 2025 [Z0][VM][I]: New LCM state is RUNNING

It seems, there is a fundamental structure change in XML, where old snapshots cannot be removed anymore by OpenNebula.

3

Before upgrading, is always a good idea to take a look at the compatibility section. In this case there is a breaking change with snapshot names.

4

Thanks Daniel

i think you mentioned this one:

KVM and Shared/Qcow2 Transfer Manager Drivers

In order to implement the disk-snapshot delete operation (via virsh blockcommit/blockpush and qemu-img rebase) some internal changes has been made, namely:

  • KVM deployment files are re-written on the fly to resolve the disk.<disk_id> symbolic links. This solves an issue that prevents a correct backingStore to be constructed by libvirt for the VMs.
  • When a snapshot is deleted (<vm_folder>/disk.<disk_id>.snap/<snap_id>) some times it is necessary to adjust actual file names supporting a given snapshot. In this case a file ended by .current is created. All related operations have been updated to react to the presence of this file.

This changes are not exposed by any OpenNebula interface and are not an issue for any existing VM while upgrading your cloud.

For me this explains not fully the behave i had, but yes - i could be related to some changes on the symbolic disk-links.