We are running ESX server 3.0.2 (on a Linux server).
Last night our backups initiated by our Visioncore Ranger product failed due to disk space problems - this left snapshot (delta files) for on of our VM's on the ESX server.
We've tried to clean this up but havn't had any luck.
Some of the things we've tried were:
1) create a new snapshot, then delete all snapshots
2) unregister the vmx, re-register, then create a snapshot then try to delete the snapshots
(see for more on some of what we tried - even though these notes are for an older version)
Basically, we're being told we have no snapshots, but if you move the delta files out of the way then try to restart the VM it will not restart. The "hassnapshot" command shows no snapshot.
Since we are new to ESX we don't want to venture to far from any notes we've found, but unfortunately none of the notes have worked.
We have xxxxx-000001-delta.vmdk through xxxxx-0000009-delta.vmdk (basically 9 delta files). Only "0000009" has a current date/time on it (so obviously it is still being used for some reason).
Also note that checking whether the snapshot chain is consistent (like from this note: ) seems to show that some of the delta files have the same CID and some are their own parents. An example of the grep output is below:
name_3-000001.vmdk:CID=670ce00b
name_3-000001.vmdk:parentCID=670ce00b
name_3-000002.vmdk:CID=670ce00b
name_3-000002.vmdk:parentCID=670ce00b
Though, again noting this is all new to us and we didn't even know what a CID was until 10 minutes ago.
We did not try the step of "vmkfstools -i example-000002.vmdk NewDisk.vmdk" (cloning the vmdk then pointing to the new vmdk) yet since we're not sure we're reading this CID info correctly.
Any suggestions would be appreciated.
