VMware ESXi does not see a disk after installation

After ESXi is installed, a disk sometimes does not appear when you create a datastore, or ESXi finds an old datastore on it but does not mount it. The cause decides the fix: some fixes keep the data on the disk, others delete it. This guide explains how to find the cause first and then choose the right scenario.

The commands are for ESXi 8.0 and also work on ESXi 7.0. Run them in the ESXi Shell or over SSH as root.

Find the cause

Open the ESXi Host Client in a browser and go to Storage → Devices. Find the disk and check what you see.

• The disk is listed under Storage → Devices but is not available in the New datastore wizard. Before changing anything, check whether it holds an existing datastore, system partitions or other partitions. See scenarios 1 and 2.
• ESXi reports an old VMFS datastore on the disk, but the datastore is not mounted. The disk most likely was used by another ESXi installation or was cloned. Go to scenario 1.
• The disk is not in the list at all. ESXi does not see the device itself. Go to scenario 3.

The same check from the command line. List the disks that ESXi sees:

esxcli storage core device list | grep -E "^[a-z]|Display Name|Size"

List the VMFS volumes that ESXi found but did not mount:

esxcli storage vmfs snapshot list

If the second command shows no volumes, the disk can still hold a normal VMFS datastore that was unmounted manually. ESXi does not mount such a datastore automatically, but it is not a snapshot either. Check the list of file systems:

esxcli storage filesystem list

If the datastore is in the list with Mounted set to false, mount it by its name:

esxcli storage filesystem mount -l DATASTORE_NAME

Or by its UUID:

esxcli storage filesystem mount -u DATASTORE_UUID

If the second command shows a volume, use scenario 1. If neither command shows the datastore, this does not yet mean that the disk only has old partitions: the disk may be the boot disk (see scenario 4) or hold data you need. Check the partitions as described in scenario 2 before you delete anything.

Scenario 1. Mount an existing VMFS datastore and keep the data

Use this scenario when the disk holds a datastore with virtual machines that you need. This happens after ESXi is reinstalled on the same server, when the disk is moved from another host, or when the disk is a copy of another disk.

Every VMFS volume has a signature that is linked to the identifier of the device it was created on. If the device identifier changes, for example after the disk is cloned, moved to another controller or presented with a different LUN ID, ESXi detects the volume as an unresolved snapshot and does not mount it automatically. This protects against mounting two copies of the same datastore. Not every datastore that is not mounted is a snapshot: if the command below shows nothing, the cause is different.

Check the volume:

esxcli storage vmfs snapshot list

Example output:

5f5b217c-2b53d2b8-d1a4-ac1f6be04cea
   Volume Name: datastore1
   VMFS UUID: 5f5b217c-2b53d2b8-d1a4-ac1f6be04cea
   Can mount: true
   Reason for un-mountability:
   Can resignature: true
   Reason for non-resignaturability:
   Unresolved Extent Count: 1

You can keep the existing signature (mount) or write a new one (resignature).

Mount the volume with the existing signature

Use this way when the original datastore is no longer connected to this host, for example after ESXi was reinstalled:

esxcli storage vmfs snapshot mount -l datastore1

Replace datastore1 with the Volume Name from the output. If several volumes have the same name, use the UUID instead: -u 5f5b217c-2b53d2b8-d1a4-ac1f6be04cea. The same applies to resignature. The mount persists after a reboot. To mount the volume only until the next reboot, add -n.

Resignature the volume

Use this way when the original datastore and its copy must work on the same host at the same time:

esxcli storage vmfs snapshot resignature -l datastore1

ESXi writes a new UUID, and the datastore appears with a name such as snap-1a2b3c4d-datastore1. You can rename it in the Host Client.

Check the result

esxcli storage filesystem list

The datastore must be in the list with Mounted set to true. It also appears in Storage → Datastores in the Host Client.

Scenario 2. Clear old partitions and use the disk as new

Use this scenario only when the disk does not hold any data you need. Typical cases: the disk was used by another operating system, by a hardware RAID or by an old ESXi installation that you do not need. ESXi does not offer such a disk for a new datastore while the old partitions are on it.

In the Host Client

Go to Storage → Devices and click the disk. Click Actions and select Clear partition table. Confirm the action.

After that, go to Storage → Datastores, click New datastore and create a VMFS datastore on the disk.

If you only need to remove one partition, select Edit partitions instead, delete the partition and save the changes.

From the command line

Find the device name of the disk:

ls /vmfs/devices/disks/ | grep -v ":"

Make sure this is not the boot disk and that no datastore is located on it. Replace DEVICE with the name from the previous command:

esxcli storage core device list -d DEVICE | grep -E "Display Name|Is Boot Device"
esxcli storage vmfs extent list

Is Boot Device must be false, and the device must not appear in the esxcli storage vmfs extent list output. Also make sure the disk is not used for the crash dump or system logs:

esxcli system coredump partition list
esxcli system syslog config get

The device must not appear in the coredump output, and the syslog directory must not be on a datastore of this disk. If you are not sure what the disk is used for, do not run the destructive command. Then show its partitions:

partedUtil getptbl /vmfs/devices/disks/DEVICE

Write a new empty GPT partition table:

partedUtil mklabel /vmfs/devices/disks/DEVICE gpt

Rescan the adapters so that the Host Client sees the empty disk:

esxcli storage core adapter rescan --all

Then create the datastore in the Host Client as described above.

Scenario 3. The disk is not visible at all

If the disk is not in Storage → Devices, ESXi does not see the device itself. Partitions and datastores do not matter here: the problem is in the hardware, the controller mode or the driver.

Check the storage adapters and their drivers:

esxcli storage core adapter list

Then rescan the adapters:

esxcli storage core adapter rescan --all

Check the device list again:

esxcli storage core device list

If the disk is still missing, check the causes below.

Common causes:

• the disk is behind a RAID controller and is not added to any virtual disk (logical drive) in the controller settings;
• the controller works in a mode that ESXi does not support, for example software RAID of the motherboard;
• there is no ESXi driver for the controller or the NVMe drive. ESXi 7.0 and later no longer support old vmklinux drivers, so hardware that worked with ESXi 6.x may stop working;
• the disk is disabled in the BIOS/UEFI settings, faulty or not connected.

Check the controller and the disk model in the Broadcom Compatibility Guide. For a RAID controller, open its configuration utility during boot and make sure the disk is part of a virtual disk, or switch the controller to HBA (pass-through) mode if it supports it.

Scenario 4. The system disk has little or no space for a datastore

Starting with ESXi 7.0, the installer creates boot partitions and an ESX-OSData partition on the boot disk. By default, these system partitions take up to 138 GB. If the boot disk is 142 GB or smaller, the installer does not create a local datastore on it at all. On a larger disk, the datastore gets only the space that remains. The disk is visible, but there is little or no free space on it.

This is not an error. The exact layout depends on the disk size and the installation options. If you need the space on the system disk, reinstall ESXi with smaller system partitions. When the ESXi installer boot screen appears, press Shift+O to edit the boot options and add the following parameter at the end of the line. This is a boot option of the installer, not a command for the ESXi Shell:

systemMediaSize=min

With min, the system partitions take 33 GB. This value is meant for servers with one disk and a small set of features. Other values are small (69 GB, for servers with at least 512 GB of RAM), default (138 GB) and max (all available space). The option is available starting with ESXi 7.0 Update 1c.

The other way is to keep ESXi on the system disk and create datastores only on other disks.

Conclusion

First check whether ESXi sees the disk and whether it found an old VMFS volume on it. If the disk holds a datastore you need, mount it or resignature it. If the disk holds old data you do not need, clear the partition table and create a new datastore. If the disk is not visible at all, check the controller mode and driver support.