VMware ESXi cannot see the datastore after restart: LUN recovery case

After a power incident in a Warsaw server room, ESXi may see the LUN but refuse to mount the VMFS datastore. The pressure is immediate: VMs are greyed out, users are waiting, and every rescan or repair attempt may change metadata.

This case-style article focuses on order of operations around VMFS, LUN and SAN/RAID issues: preserve state first, diagnose storage next, and only then attempt logical repair.

Why a datastore disappears after an ESXi restart

The cause may be damaged VMFS metadata, a multipath issue, stale signatures, a RAID controller fault, inconsistent SAN state or corruption of the partition table that points ESXi to the datastore.

The LUN can appear online on the array while vSphere still shows the datastore as unknown, unmounted or missing. Visibility of a LUN is not proof that the VMFS volume is safe to modify.

Symptoms of datastore loss after a restart

• vSphere reports lost access to volume or VMFS UUID warnings.
• Virtual machines are greyed out or cannot start.
• VMDK files appear missing even though the SAN reports the LUN online.
• Rescan does not mount the datastore or shows it as snapshot/unknown.
• Administrators are tempted to remove and recreate the datastore.

Step by step: recovering a VMware datastore

1. Stop random repair attempts and document the current state.
2. Collect ESXi logs, array logs, LUN identifiers and storage path information.
3. Check SAN/RAID health and whether the LUN can be snapshotted safely.
4. Work on a secured image or copy where possible, not on the only production media.
5. Analyse VMFS structures, VMDK files and datastore metadata before logical repair.

For corporate storage incidents, the route is VMware, Hyper-V and SAN data recovery combined with RAID/NAS analysis when the datastore is backed by an array.

Case study: 40 virtual machines after an ESXi restart

In a typical incident, power returns, the host starts, but the datastore does not mount and dozens of virtual machines remain offline. The temptation to rescan, rebuild paths or recreate inventory is high.

The better route is staged and reversible: preserve disk and LUN state, reconstruct the storage layout if needed, identify VMFS metadata damage and verify virtual machines from recovered copies.

What to prepare before contacting the lab

• ESXi version, host model and storage architecture.
• SAN/NAS/controller model, RAID level and number of disks.
• LUN ID, datastore name, VMFS version and last known good state.
• Logs showing lost access, path errors, power loss or controller warnings.
• Priority virtual machines and business systems that must be recovered first.

When not to improvise after a host restart

Do not delete and recreate the datastore, format VMFS, rebuild RAID blindly or move VMDK files before the metadata state is understood. Do not keep rescanning paths if each attempt changes logs and state without bringing the datastore back.

How to close the incident without adding business risk

After data is secured, plan infrastructure repair separately from recovery. The goal is to restore virtual machines from verified copies and avoid returning a damaged storage layer to production.