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.
When that partition table gets corrupted or deleted, ESXi sees the raw disk as a blank, unpartitioned device. However, the actual VMFS filesystem metadata (heartbeats, file descriptors, block pointers) lives inside the partition, untouched.
This post is a deep dive into recovering a lost or corrupted VMFS partition table. I’ll cover theory, common causes, diagnostic tools, and step-by-step recovery procedures. A VMFS datastore lives inside a primary partition (type 0xFB for VMFS3 or 0xFC for VMFS5/6) on a disk or LUN. The partition table (usually GPT, sometimes MBR on older systems) sits at the very beginning of the disk (LBA 0) and contains a small entry pointing to the start sector and length of that VMFS partition. vmfs partition table recovery
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 :
esxcfg-info -s | grep -i vmfs Better yet, use the hidden voma tool (VMFS Offline Metadata Analyzer) in read-only mode: partedUtil get /vmfs/devices/disks/naa
sudo apt-get install vmfs-tools Then scan:
No recovery method replaces a verified backup. Use this knowledge to survive the crisis, then immediately double-check your 3-2-1 backup strategy. When that partition table gets corrupted or deleted,
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.
