partedUtil get /vmfs/devices/disks/naa.6001234567890 If you see Unknown or an empty table, the partition table is missing. Use vmkfstools to scan for VMFS superblocks without relying on the partition table:
Check partition table:
partedUtil get /vmfs/devices/disks/naa.6001234567890 If it shows a table but complains about checksum, you may repair the primary from the backup (see recovery section). Method A: Restore partition table from a known backup (Best case) If you have a backup of your ESXi host configuration (e.g., from vicfg-cfgbackup ), you might have saved the partition layouts. Or if you have another identical datastore, compare. vmfs partition table recovery
Good luck, and may your sector scans be clean. Have your own VMFS partition table horror story or recovery trick? Share it in the comments.
dd if=/vmfs/devices/disks/naa.6001234567890 bs=512 count=1 skip=END_SECTOR_NUMBER | hexdump -C | grep "EFI PART" But skip math is error-prone. Instead, use partedUtil : partedUtil get /vmfs/devices/disks/naa
voma -m vmfs -f /vmfs/devices/disks/naa.6001234567890 This tool is a lifesaver. It will scan the entire device for VMFS structures and report the found start LBA, block size, and file system version. If your disk uses GPT (most modern VMFS5/6), the primary GPT header at LBA 1 might be corrupt, but a backup GPT header resides at the last sector of the disk.
We've all felt that cold sweat moment. You log into vCenter or ESXi, look at your storage devices, and see a datastore marked as or simply "Invalid partition table." Your VMs are inaccessible. Your heart rate spikes. Or if you have another identical datastore, compare
ls -l /vmfs/devices/disks/ Look for the device that should be your datastore (e.g., naa.6001234567890 ). Note if there are no :1 , :2 , etc. partitions listed—only the base device.