Symptoms:
VM's become inaccessible in vSphere Client
A working VMFS datastore suddenly appears to have a different name in the vSphere Client
You may experience a PSOD similar to the following:
Verify the current partition table on the affected LUN:
partedUtil getptbl /vmfs/devices/disks/<device ID>
...where <device ID> is the t10.xxx, naa.xxx, or eui.xxx device ID
You should see output similar to the following:
Device: /vmfs/devices/disks/naa.abcdef0123456789abcdef0123456789Partition table:gptXXXX 255 63 YYYYYYYYY1 2048 ZZZZZZZZZ AA31E02A400F11DB9590000C2911D1B8 vmfs 0
Usable sectors:34 ZZZZZZZZZ
If not, then the partition table no longer contains a valid VMFS partition and has been deleted, overwritten, or corrupted.
Depending on the situation, you may be able to restore access to the VM's by replacing the incorrect/missing partition table with a valid VMFS partition table similar to the above (see: Using partedUtil command line disk partitioning utility on ESXi) . Please contact Broadcom Technical Support for assistance.
Otherwise, recovery from backups or data recovery service engagement will be required (see: Data recovery services for data not recoverable by VMware Technical Support).
A common scenario is when a customer has re-installed ESXi on an existing host, leaving the fabric or network cabling connected to the host, so that the host still has visibility to LUN's other than the boot LUN.
A typical ESXi boot LUN partition table will look similar to the following:
Device: /vmfs/devices/disks/naa.abcdef0123456789abcdef0123456789Partition table:gpt58361 255 63 9375719681 64 204863 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128 < --- This is the boot partition5 208896 8595455 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 06 8597504 16984063 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 07 16986112 268435455 4EB2EA3978554790A79EFAE495E21F8D vmfsl 08 268437504 937571934 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
Usable sectors:34 937571934