Hello,
we are not able to delete a certain snapshot of a VM. A Veeam back job fails because it cannot delete this snapshot.
(vSphere 5.5)
Someone has a idea why it cannot delete snapshot ? I know that we added a virtual disk (thin format) to mentioned VM.
Since that time the backup job fails. Veeam Support says problem is a vmware level.
Any help would be greatly appreciated.
Kind regards,
Roland
memaad schrieb:
Hello Roland,
First question , how big is this snapshot in size.
To resolve this issue two option.
1. Connect vCenter server, take one more snapshot and then do "delete all". If this does not work, step 2
2. Power off the virtual machine, do cloning of this disk which has snapshot using "vmkfstools -i" command
VMware KB: Cloning individual virtual machine disks via the ESX/ESXi host terminal
To understand why the snapshot consolidation fails , you need review hostd.log
Regards
Mohammed Emaad
Hi Mohammed Emaad,
snapshot size should be 5 TB but I am no quite sure.
(see screenshot)
Kind regards,
Roland
Hi Roland,
I took closer look of your screen captures and I noticed that datastore does not have any snapshots in it. Snapshot files would be files below and those are missing.
FileServer-VM-1-000001.vmdk (descriptor file)
FileServer-VM-1-000001-delta.vmdk (delta data file)
FileServer-VM-1_1-000001.vmdk (descriptor file for HD 2#)
FileServer-VM-1_1-000001-delta.vmdk (delta data file for HD 2#)
I suspect that snapshot descriptor file (FileServer-VM-1.vmsd) might be corrupted, could you post the content of it here? Also could you post contents of vmx file? Example snapshot descriptor file is below:
.encoding = "UTF-8"
snapshot.lastUID = "2"
snapshot.current = "2"
snapshot.needConsolidate = "TRUE"
snapshot0.uid = "2"
snapshot0.filename = "TestVM-Snapshot2.vmsn"
snapshot0.displayName = "TestSnap"
snapshot0.description = ""
snapshot0.createTimeHigh = "325022"
snapshot0.createTimeLow = "929252648"
snapshot0.numDisks = "2"
snapshot0.disk0.fileName = "TestVM.vmdk"
snapshot0.disk0.node = "scsi0:0"
snapshot0.disk1.fileName = "TestVM_1.vmdk"
snapshot0.disk1.node = "scsi0:1"
snapshot.numSnapshots = "1"
If you dare you could delete (backup first!) the descriptor file and either restart the ESXi host or remove from inventory & import it again. It seems that ESXi host caches the snapshot data so "cache refresh" is necessary 
.
I hope this helps and please let me know if you still have problems!
Hannu
> Shall I delete mentioned stale snapshot using vSphere Web Client ?
No - if Veeam could not delete it - ESXi very likely cant do it either.
A safe approach would look like this:
1. Stop any running Veeam Jobs - if possible shut down Veeam completely.
2. Stop the VM and remove it from inventory
3. verify that there really is no snapshot ! - open the vmx-file (easiest way to do that is to connect via winscp and then just doubleclick the vmx-file)
- find the 2 lines
scsi0:0.filename = "Fileserver-VM-1.vmdk"
scsi0:1.filename =" Fileserver-VM-1_1.vmdk"
We need to make sure that there is no reference like for example
scsi0:0.filename = "/vmfs/volumes/other-datastore/directory/Fileserver-VM-1-000099.vmdk"
The fact that there are no *-00000*.vmdk files does not mean that there are no snapshots and assuming so can be very dangerous.
Only when there is no reference to a name-00000*.vmdk in the vmx AND when during last run the status of the Fileserver was NOT outdated - only then you can safely assume that there really is no snapshot.
4. Once you verified that there is no snapshot delete the vmsd-file -+ which is responsible for the false display in Snapshotmanager.
5. Then search the vmx-file for the entry
ctk.enabled = "true"
Set the value to "false"
There are 2 more lines specifying ctk-status for both your vmdks - set them to "false"
6. Delete all *.ctk.vmdks from that directory.
- Delete any *.vmsn files- in case they exist
- Delete any *.vmss files- in case they exist
- Delete any *.vmem files - in case they exist
7. Look in /dev/deltadisks if there are any delta-files that belong to the Fileserver-VM - there should be none!
8. Safe the vmx-file - and reopen it to make sure your edits really were saved.
9. Start Datastorebrowser and register the vmx-file again.
10. Start the VM once - let it boot and power it off again. That will make sure the change-block-tracking database used by Veeam gets new , clean data.
11. Power on the VM and restart Veeam - to be on the safe side I would recommend to let Veeam create a full backup on next run. Assume that last Veeam-runs created bad backups !
Thats why we reset the ctk.vmdks and create a full backup next.
12. When next Veeam Job is done - check that you have new ctk.vmdks in the directory and that there are no errors in the Veeam-logs
13. Next time you have a few minutes - look inside the Fileserver as Admin and check if there any errors regarding VSS in the Windows-system logs.
Also check if VSS is fully functional - and if vmware.tools are running.
Too many steps ? - some of them not necessary in a given case ? - yes - right.
I found that following all the steps gives you all info you need to prevent yourself from deleting files that just look as if they are unused or stale.
No mistakes = less work tomorrow.
By the way - dont trust Snapshotmanager when using Veeam and learn how to clean a VM-directory. That will reduce the amount of friday-night-snapshot-consolidation-adventures to almost zero 
... if vmkfstools -i fails for unknown or obscure reasons - then it often helps to present the vmdks to vmkfstools as if they were unused.
To do that unregister the VM after a clean shutdown, move all non-vmdk files to a temp-directory and set virtual hardware to latest version in the vmdk-descriptor.
Now run the vmkfstools -i command.
After that - move the non-vmdk files back into place and revert any changes you made to the vmdk-descriptorfile.