Unable to start VM with disk attached after loss of power

[doxymoron]

I am running ESXi 6.7 U3.  I had to do a hard shutdown yesterday, and after it came back up the VM won't power on if I have the second disk attached.  That disk is connected to a LSI MegaRAID controller that has been having issues (not sure if it's the controller or esxi itself).  This is the error when I try to power on:

• File system specific implementation of OpenFile[file] failed
• 22 (Invalid argument)
• Cannot open the disk '/vmfs/volumes/5a5ea6ed-fd776af1-cc17-0015174b6756/Eros/Eros_Data.vmdk' or one of the snapshot disks it depends on.

There are no snapshots of this VM.  I've looked at multiple posts about recreating the descriptor file, but when I try to do this it says.

Failed to create virtual disk: File too large (1769481).

This is a large 29TB disk.  I've also run vmfkstools -e and receive this:

Failed to open disk link /vmfs/volumes/5a5ea6ed-fd776af1-cc17-0015174b6756/Eros/Eros_Data.vmdk :Invalid argument (1441801)Disk chain is not consistent : Invalid argument (1441801)

I'm really at a loss of what I can do, if anything.  Thanks.

[a_p_]

Please logon to the host's console (or use e.g. putty), and run ls -lisa > filelist.txt in the VM's folder to list all files. Then download filelist.txt from the datastore, and attach it to your next reply (compressed as a .zip archive). This is a first step to find out whether it's a logical issue, or something more severe, in which case you may consider to either open a support case with VMware, or try to contact @continuum who's he expert here on VMTN when it comes to data recovery.

André

[continuum]

Please run the command

hexdump -C /vmfs/volumes/5a5ea6ed-fd776af1-cc17-0015174b6756/Eros/Eros_Data-flat.vmdk | less
Please create a screenshot of the result.

Ulli

[continuum]

Please do NOT read https://kb.vmware.com/s/article/1002511
That can make matters worse !!!!

Ulli

[doxymoron]

Here's the screenshot.

[doxymoron]

Here you go, thanks

[continuum]

This does not look good ... do I assume right that this is a thin provisioned vmdk ?
If this vmdk contains valuable data I suggest that we continue this case doing a Teamviewer-session.
I highly recommend not to write to this datastore before this problem is resolved.
The datastore may run out of resources even if it claims that there is free space available !!!
It may be necessary to extract the vmdk to a different datastore ...

Call me via skype if necessary.

Ulli

[doxymoron]

Actually it is thick:

If you would be able to help that would be great.  I have messaged you on Skype.

[continuum]

Wow - here we see a vmfs-volume in selfdestruct mode.
In to the heartbeat-section the ESXi wrote half of a vmdk-descriptorfile.
No wonder it no longer could handle the 30tb vmdk !
Anyway - I still think I can extract the vmdk - if the volume itself can be fixed is something that I should find out soon.
I keep you updated.

Ulli

[doxymoron]

Hi Ulli, just checking if you are still able to help me with this issue.  Please let me know what I can do, thanks.