Hi,
Okay, I know, the title is misleading. This actually wasn't all that funny 
I ran in to an episode with snapshots hanging after a VDP failure. It's all sorted, just thought I'd share my experience...
I actually didn't notice anything wrong at first, was it not for my daily snapshot script reporting active snapshots on all my management servers.
This was when it hit me that I (admitted stupidly) had rebooted my VC server in the middle of a backup job. Luckily it was only my management servers that were affected (since backup usually runs late at night).
After I went and deleted the snapshots, the warning about "consolidation needed" would come up - which I couldn't get rid of.
At first, obviously, I tried rebooting the VDP appliance to get rid of any stalled jobs. I ended up shutting down the VM affected and then cloned it to another datastore.
From here the clone would boot just fine, with no warning about snapshot consolidation needed.
Next I removed the original VM from the backup job, then deleted it from the original datastore. I then noticed that VMware didn't delete the VMDK from the datastore and also wouldn't let me delete it, either from datastore browser or via SSH.
I then located the host that had a lock on the files by using 'lsof' via SSH.
(Old vm name is 'mgmt-lnx01', cloned name is 'mgmt-lnx01-new'.)
--
~ # lsof | grep lnx01
698324 vmx FILE 143 /vmfs/volumes/52fde910-64bd0394-bf5d-18a90557f0a2/mgmt-lnx01/mgmt-lnx01-flat.vmdk
698324 vmx FILE 158 /vmfs/devices/deltadisks/7ca9c406-mgmt-lnx01.vmdk-delta.REDO_0Jf8Hy
698324 vmx FILE 159 ./mgmt-lnx01.vmdk-delta.REDO_0Jf8Hy
--
In order to fix this, I thought I'd reboot the ESX holding the lock. Migrating VM's away in order to go to maintenance mode resulted in a sudden death of the VDP appliance involved in the jobs earlier on.
The log for the vmotion operation, which failed, got me below results, which tells me the VM still have ties to the old VMDK of the now deleted original VM.
A quick look at the VDP VM settings confirmed this - the disk was added as a local drive.
--
An operation required the virtual machine to quiesce and the virtual machine was unable to continue running.
Cannot open either the disk '/vmfs/volumes/52fde910-64bd0394-bf5d-18a90557f0a2/mgmt-lnx01/mgmt-lnx01.vmdk' or the redo log './mgmt-lnx01.vmdk.REDO_0Jf8Hy'.
The system cannot find the file specified
VMware ESX cannot find the virtual disk "/vmfs/volumes/52fde910-64bd0394-bf5d-18a90557f0a2/mgmt-lnx01/mgmt-lnx01.vmdk". Verify the path is valid and try again.
The VM failed to resume on the destination during early power on.
Module DiskEarly power on failed.
Cannot open either the disk '/vmfs/volumes/52fde910-64bd0394-bf5d-18a90557f0a2/mgmt-lnx01/mgmt-lnx01.vmdk' or the redo log './mgmt-lnx01.vmdk.REDO_0Jf8Hy'.
The system cannot find the file specified
VMware ESX cannot find the virtual disk "/vmfs/volumes/52fde910-64bd0394-bf5d-18a90557f0a2/mgmt-lnx01/mgmt-lnx01.vmdk". Verify the path is valid and try again.
--
The host didn't mind entering maintenance mode now with this one powered off vm left. Before rebooting (last resort) I went to check again with 'lsof'. This time the list was clear and I could now delete the orphaned VMDK along with the folder for the original VM.
Problem solved, so far. Now what about the VDP appliance...?
I still had two other VM's left with same symptoms. 'lsof' would report a lock on the host currently hosting the powered off VDP.
I went to check again and sure enough, the VDP VM also had the VMDK's of my two other VM's added.
I then deleted the link to the old VMDK from the list (remove from virtual machine) and booted the VDP back on.
Everything seemed okay, though I didn't sit around for 30 minutes watching a VDP appliance boot...
Next step was removing the VMDK from the other two VM's. I took a shot and did this with the VDP still booted, which didn't seem to anoy it.
This actually turned out to be the fix all along. Now I could consolidate snapshots on the remaining two VM's no problem...
This last step is optional, but i'd like to preserve naming as before, so I storage vmotion'ed the VM back to the original datastore after renaming, so that the VMDK files would be renamed back, then added the new VM to the VDP job.
Hope this will serve helpful to others in a similar situation.