Can you provide some background on when this issue occurred? (e.g. following a failed back-up)

I see there that you have a snapshot delta.vmdk but no descriptor in that directory, I also note that this doesn't appear to be referenced in the vmware.log of the VM.

The first thing to do is to verify the disk-chain order (e.g. what is in use here and what is not), verify that the chain has consistent values (e.g. CIDs PIDs) and finally check that all the disks can be opened (and if not, identify which and what is locking them).

Check what the .vmx is pointing to (e.g. base-disk or snapshot):

# cd /vmfs/volumes/5a0edc98-5d83df4e-1c3d-a0369fe81e02/SAFEGUARD/

# cat SAFEGUARD.vmx | grep vmdk

Query the chain - this should tell you which disk cannot be opened:

# vmkfstools -q -v10 NameOfDiskOrSnapshotFromAboveCommand.vmdk | less

If any of the disks in the chain are locked then determine what is locking it (e.g. snapshot/base-disk still mounted to a back-up proxy VM):

DISKLIB-LINK : "/vmfs/volumes/5a0edc98-5d83df4e-1c3d-a0369fe81e02/SAFEGUARD/SAFEGUARD.vmdk" : failed to open (The file specified is not a virtual disk).

DISKLIB-CHAIN : "/vmfs/volumes/5a0edc98-5d83df4e-1c3d-a0369fe81e02/SAFEGUARD/SAFEGUARD.vmdk" : failed to open (The file specified is not a virtual disk).

DISKLIB-LIB : Failed to open 'SAFEGUARD.vmdk' with flags 0x17 The file specified is not a virtual disk (15).

(END)

vmkfstools SAFEGUARD.vmdk -e

Failed to open disk link /vmfs/volumes/5a0edc98-5d83df4e-1c3d-a0369fe81e02/SAFEGUARD/SAFEGUARD.vmdk :The file specified is not a virtual disk (15)Disk chain is not consistent : The file specified is not a virtual disk (15)

vmkfstools SAFEGUARD.vmdk --chainConsistent

Failed to open disk link /vmfs/volumes/5a0edc98-5d83df4e-1c3d-a0369fe81e02/SAFEGUARD/SAFEGUARD.vmdk :The file specified is not a virtual disk (15)Disk chain is not consistent : The file specified is not a virtual disk (15)

Is it possible that someone renamed SAFEGUARD-000001.vmdk to SAFEGUARD.vmdk ?Did you try to fix the problem yourself by assigning SAFEGUARD.vmdk instead of SAFEGUARD-000001.vmdk ?Anyway - please provide the data I asked for

Ulliedit: to download SAFEGUARD.vmdk you can not use Datastorebrowser - use WinSCP or any other SSH/FTP-client.

Good - there is a syntax error in the vmdk-descriptor so very likely there is no serious damage.There are two ways to continue from here:Option A: just fix the SAFEGUARD.vmdkOption B: fix the SAFEGUARD.vmdk and create a new SAFEGUARD-000001.vmdk

I would suggest that you try option B first.Do you have any older vmware.logs ? - that would help me to find out which option to use ...Anyway - I will attach two zip files for each option in a couple of minutes

According to your log files I cant decide which configuration was used in the last successful start of the VM.According to the timestamps in your filelist the last config probably used SAFEGUARD-000001.vmdkI assume that after 22th of MAY someone manually edited the vmxfile , deleted SAFEGUARD-000001.vmdk and edited a syntax-error into SAFEGUARD.vmdk.This is the only explanation for the data I see here.Suggestion:use WinSCP and upload SAFEGUARD.vmdk and SAFEGUARD-000001.vmdkUse the buildin editor of WinSCP and edit the file SAFEGUARD.vmx

change the line

scsi0:0.fileName = "SAFEGUARD.vmdk"

to

scsi0:0.fileName = "SAFEGUARD-000001.vmdk"Then start the VM.If anything goes wrong during the startup or if the VM appears to be in an outdated state power it off again.In this case switchscsi0:0.fileName = "SAFEGUARD-000001.vmdk"

back to

scsi0:0.fileName = "SAFEGUARD.vmdk"

and start the VM again.Probably both variants will work but only one of them is uptodate.Please report results as soon as possible - I will be here in case you run into problems.

I would strongly advise cloning the base disk before considering bypassing the snapshot - especially since the goal here is to revive data from the last 24hrs and the fact that that snapshot contains data. If you simply bypass the snapshot and the data is old then there is no way to add back the snapshot data (unless you have a clone to work from).

That is indeed progress - but it also means that the basedisk may be truncated.The next steps are more delicate - so I would rather do it myself.If it possible lets continue via Teamviewer.Please download http://download.teamviewer.com/download/version_10x/TeamViewerQS.exeand call me via skype "sanbarrow"UlliIGNORE THIS POST - SEE NEXT ONE