ESXi Datastore or VM Missing? Check This First

Two situations come up often with ESXi: a datastore that no longer appears, or shows as inaccessible, and a virtual machine that has disappeared from inventory even though nothing was intentionally deleted. In both cases the underlying VMFS volume and its files are frequently intact, and the fastest way to make things worse is to start recreating things before checking what is actually there.

Each VM's files sit in its own folder on a datastore: the configuration (.vmx), the virtual disks (.vmdk, each really a small descriptor plus one or more large flat or sparse files), a swap file, snapshot files if any exist, and a small log. None of these move on their own. If a VM is missing from inventory, its folder is usually still present on the datastore even though the vSphere client no longer lists it.

With SSH enabled on the host, `esxcli storage filesystem list` shows every mounted VMFS volume and whether it is currently accessible. `ls /vmfs/volumes/` lists them by name and UUID, and the folder for a specific VM can be found under the datastore's own directory. If a datastore shows in this list but not in the vSphere client, the storage is present and the problem is more likely with the client, the host's inventory, or how the datastore is presented, not with the data itself.

If a datastore does not show at all, `esxcli storage core device list` and `esxcli storage core path list` show whether the underlying LUN or disk is visible to the host. A LUN that has dropped out at this level points to the storage array, the SAN fabric, or the cabling, rather than to VMFS.

A VM can disappear from inventory after a host reboot, an accidental removal from inventory (different from 'delete from disk'), or a vCenter database issue, while its files remain untouched on the datastore. Browsing the datastore in the vSphere client, or checking the folder by SSH, usually confirms this quickly. If the .vmx file is present, re-registering the VM from that file normally restores it to inventory without touching its disks.

A VMFS volume can fail to mount after a host reboot because of a resignature conflict from replicated or snapshotted storage, a change to the underlying LUN, or damage to the volume's own metadata. Forcing a mount, resignaturing, or reformatting at this point can overwrite the information needed to reconstruct the original layout. If the datastore does not mount cleanly on the first attempt, that is the point to stop and image the underlying storage rather than try a second or third repair option.

Do not recreate a VM from scratch and attach an existing VMDK to it as a first step, since a mismatched configuration can make later recovery more confusing rather than less. Do not run a datastore repair, reformat, or 'add storage' onto a LUN you are not certain is empty. Do not delete or move files while searching a datastore folder for a missing VM, and do not assume a VM is gone because it is absent from inventory alone.

A broken snapshot chain can also make a VM appear to have lost data, when in fact a delta file is missing or a chain is out of order. Snapshot consolidation on a chain that is already broken can make matters worse, so check the VM's folder for the full set of snapshot files before running consolidation on a VM that has been showing errors.

Ask a specialist when a datastore will not mount after the first attempt, when the underlying LUN or disks show errors, when a VM's files cannot be found on any datastore, or when a repair has already been tried and made things worse. Work is normally done on images of the underlying storage, so the original LUN or disks are touched as little as possible. Results depend on what happened to the storage and cannot be promised in advance.