During a migration from an ESX v3.5 to ESXi v5.0, we ran across a stumbling block. Since the new SAN was implemented using VMFS v5, and ESX v3.5 cannot see that, a new volume was created in the VMFS 3 format, and both hosts were attached to this LUN. We used sVmotion to move the VM from the local storage of the ESX 3.5 box to the SAN for the v5 enviroment.
What I didn't know, is that despite snapshot manager reporting that there weren't any snapshots present; there was! Turns out that a flawed backup software had created four uncommited snapshots. The VM would no longer boot!
During the sVmotion, the ESXi 5 snapshot manager did pick this up and report them; okay so let's use Snapshot Manager to commit the snapshots. After some time, Snapshot manager reports that all snapshots have been taken care of; however the VM still would not boot, and browsing the data store yielded that the snapshot files where still there.
At this point, VMware has a nice feature called "Consolidate Snapshots". After some time all of the snapshot files were now gone, however the VM still would not boot! An error message of a "CID mismatch" showed up. Following this KB article from VMware we were able to fix the issue.
In a nut shell, the vmdk descriptor file has a pointer linking it to it's parent drive, and one had to go in and edit this line.