Stumbled across this usefull article on problems with VMware snapshots
Specifically the items below, please note I have changed the wording a content on some items from the original post now.
Locating VMs that have snapshots
Trying to find out which VMs have snapshots can be challenging. There is no centralized way to do this built into the VMware Infrastructure Client or VirtualCenter, so you should periodically check your ESX servers for old snapshots that need to be deleted. There are a few methods you can use to accomplish this.
Method 1 – use the Find command on the Service Console
- Login to service console.
- Change to your /vmfs/volumes/ directory.
- Type find -iname “*-delta.vmdk” -mtime +7 -ls to find snapshot files that have not been modified in 7 days or simply find -iname “*-delta.vmdk” to find all snapshot files.
Dealing with snapshots that do not delete properly
Occasionally, a snapshot will not delete properly leaving an active snapshot for a VM. This can happen when using VMware Consolidated Backup or when deleting snapshots through Snapshot Manager. In most cases, the snapshot will not appear in the Snapshot Manager for you to delete. The only indication that a snapshot may still exist is the presence of delta files in the VM’s directory.
If you do have a snapshot running that is not in Snapshot Manager, you can attempt to delete it one of two ways. First, create a new snapshot using the VI Client and delete all snapshots from the snapshot manager after the new one has been created. Alternatively, login to the ESX Service Console, switch to the VM’s home directory and create a new snapshot by typing vmware-cmd createsnapshot (The syntax is as follows “vmware-cmd createsnapshot name description quiesce memory” view an example here . Wait for the snapshot to be created and type vmware-cmd removesnapshots. When it completes, check to see if the delta files have been deleted. If they have, then it was successfully completed.
If the delta files weren’t deleted, check the vmx file for the VM and locate the lines starting with scsi. If the VM is configured with only one virtual disk, it is usually scsi0:0 (if .present is false, it is a non-existent drive that you can ignore). The .fileName should be using the original disk file that was created with the VM and is usually the same name as your VM. If this is the case, then your VM is not using the snapshot files. If it has a -00000# in the filename, it is currently using a snapshot file. The following makes this a little clearer: VM with no snapshots: scsi0:0.present = “true” scsi0:0.fileName = “myvmname.vmdk” VM with snapshots: scsi0:0.present = “true” scsi0:0.fileName = “myvmname-000001.vmdk”
If this is the case and the above operation failed, another option you have is to either clone the VM or clone the VM’s disk file. To clone the VM I would recommend the VM is powered down and cloned through the VI client to another VM, although this could technically be done whilst the VM is powered up if you are using ESX 3.5 Update 2 or newer.
Another method is to shutdown the VM, login to the Service Console, switch to the VM’s directory and clone the VM’s disk file by using vmkfstools and specifying the snapshot file as the source disk, i.e. “vmkfstools –i myvmname-000001.vmdk myvmnamenew.vmdk” Once it completes go into the settings for the VM, remove (don’t delete) the hard disk, add a new hard disk and browse to the newly created disk file. Power on the VM and verify everything is working before you delete the old disk and delta files.
Please note if you are struggling with a particular issue with snapshot and you have a current VMware support contract, VMware support are very good at assisting with these problems and I would suggest you log a call with them rather than trying anything you are unsure of.
I like your site and really appreciate all the great info. There are several issues with your “Dealing with Snapshots that do not delete properly”
ie. “vmware-cmd createsnapshot” is missing the path to the .vmx file name. Also, there are other option other than cloning the vm/disk to commit/remove the snapshots. This statement “If this is the case and the above operation failed, your only other option is to either clone the VM or clone the VM’s disk file” is just not accurate at all.
Thanks for the feedback im glad you like my blog, these were actually excertps from another users blog but you were quite right on the points you picked up. I have now made a few changes above. If you have any other advice on dealing with snapshots I would love to add it to my blog as it is a common problem for users.