VMware Datastore Is Missing and Production VMs Cannot Start
The ESXi host is running, but a required datastore is absent, inaccessible, or will not mount—and the production virtual machines on it cannot start. The failure may be below VMware in a local RAID, SAN, NAS, LUN, controller, or storage path, or within the partition and VMFS structures that identify the datastore.
Do not create a replacement datastore, format the offered device, force resignature, run VMFS repair, or repeatedly rescan and reboot while the backing-device identity is uncertain. Preserve the host and storage evidence first.
Tell an ADR technician what the system reports and what has already been attempted. The failed system does not have to be brought online first.
What this condition means
A detached test datastore or a temporary path outage is not automatically a data-recovery crisis. It becomes one when the only current datastore copy remains unavailable, required production VMs cannot start, and normal storage-path correction has not restored the same verified device.
ESXi may have lost the backing device, detected a snapshot LUN, rejected damaged VMFS metadata, or received a changed logical volume from the controller or storage system. VMFS work cannot compensate for an unstable RAID member, incomplete SAN presentation, or a volume assembled from the wrong member state.
What to record
- ESXi and vCenter versions and the exact datastore, device, and VM startup messages
- Datastore name, VMFS version, UUID, last known capacity, and priority VM names
- Backing local RAID, SAN, NAS, HBA, controller, LUN, and multipath details
- Affected hosts and whether the same device, capacity, and identifier are visible to each one
- Power, firmware, controller, path, rebuild, snapshot-LUN, mount, resignature, restore, or repair actions already attempted
- Which VMs and business services must be recovered first
What not to do
- Create or format a datastore on the affected or offered device
- Force resignature without proving which logical volume is being presented
- Run VMFS repair against unstable or incorrectly assembled backing storage
- Rescan and reboot repeatedly while the device identity or capacity changes
- Register, power on, consolidate, or write to the only available VM copies by trial and error
- Restore or write recovered files back onto the affected datastore
How ADR evaluates it
ADR maps the path from physical members through RAID or shared storage to the LUN, partition, VMFS datastore, virtual disks, and priority VMs. Each layer is validated before work moves upward.
The ESXi host does not have to mount the datastore before recovery can begin. Stable logical cases can be evaluated while the source remains under the client’s control. If the backing storage is unstable or the logical volume is uncertain, protected imaging and reconstruction come before VMFS or VMDK work.
ADR can begin at the lowest uncertain layer, preserve the backing storage, and determine whether ESXi is seeing the correct logical device. VMFS, virtual disks, and the VMs the business needs first are evaluated only after that foundation is established.
What happens next
A datastore that will not mount may still contain recoverable virtual machines. The result depends on the backing-storage state, VMFS metadata, prior writes or repair attempts, and whether the correct device can be reconstructed and presented.