The ESXi Datastore Is Missing. Don't Create a New VMFS.

Written and maintained by the Desert Data Recovery lab team. · Updated October 7, 2026

We already wrote about a hardware RAID card's Foreign configuration and Force Online, about the Rebuild button, and about a RAID 5 that has lost a second drive. This page is the ESXi screen after the virtual disk or the LUN is in front of the host again — a controller or HBA swap, a firmware update, a rebuilt host, a LUN number or device identity that no longer matches — and the VMFS datastore did not mount. New Datastore is not how you check whether the virtual machines are still there.

What "missing" is

A datastore in the vSphere client is a VMFS volume this host has mounted. When the entry disappears, the host is not mounting that volume. That is a host status. It does not say whether the VMDKs are still on the media.

The device row under it is one of these, and they are not the same failure:

• The LUN is listed, and the datastore column says Not consumed — or it is blank. The host can see a block device. It has not mounted a VMFS on it. Broadcom's snapshot-LUN article and their inconsistent-LUN-presentation article both use Not consumed for a device that is visible and not mounted. Empty is not what that word means.
• The Snapshot Volume column has a value. The vSphere storage guide says ESXi detected a VMFS datastore copy on that device. The New Datastore wizard then offers mount options. The volume was found. It was not mounted, because the host will not automatically mount a copy.
• The device is not the virtual disk that held the datastore. A new RAID controller that has not imported its configuration, a virtual disk someone initialized, or the member disks presented one by one, show up as disks. They can be the right platters and the wrong address space. Creating a datastore on them writes those disks.
• The LUN is not there at all. The controller marked the virtual disk offline, or the array never presented it. There is no VMFS for the wizard to find. The job is the array, on the rebuild page, before anyone creates a replacement virtual disk for ESXi to format.

Reinstalling ESXi onto its own boot device does not, by itself, format the other LUNs. The installer writes the disk you select as the target. Selecting the data virtual disk, or the RAID set that held the datastore, is an install onto that disk. A new host can also boot cleanly and then refuse to mount a volume it now calls unresolved. The refusal is the snapshot case below. Creating a datastore so the folder comes back is the format.

Why the host stopped mounting it

Each VMFS datastore has a signature, the UUID, stored in the filesystem superblock. The current vSphere storage guide says a replica or an array snapshot is a byte-for-byte copy, so the copy carries the same UUID. The host will not mount two volumes with that UUID as if they were unrelated. The same guide says a LUN ID change can produce a copy of the original datastore even when nobody took a snapshot. The device is the volume you had. The identity the host just inquired does not match the identity stored with the VMFS.

Broadcom's article on LUNs detected as snapshots names the situations where that check fails: replacing SAN hardware, firmware upgrades, SAN replication, a disaster-recovery test, and some HBA firmware upgrades. It also fails when the LUN number mapped to the host is not the LUN number that was mapped when the datastore was created. The LUN number is part of the device path, and it is part of the VMFS metadata. The log line they quote is detected to be a snapshot, followed by a queried disk ID and an on-disk disk ID. In one of their examples the LUN was created as LUN 17 and is now presented as LUN 36. In the other, the hardware ID hash changed, which they say usually happens when the data was replicated or moved to an array with a different identity. A firmware update or a new HBA does not hide every datastore. When the identity in that log line changed, this is the check that hid it.

A RAID controller swap is a step past a LUN number. The new card has to present the same virtual disk. If the BIOS says foreign configuration, the array metadata is on the disks and not loaded on the card. If it says no virtual disk, or the virtual disk is a new one, ESXi is not looking at the VMFS. Clearing that foreign config, or initializing a virtual drive so a datastore can be created, is the write that removes the map. That screen is the controller page. This page is what ESXi offers once the card is showing a disk again.

Failed member disks are the other reason the datastore is gone. The virtual disk is offline, degraded, or missing because the set underneath it is incomplete. A datastore wizard does not rebuild a member. A rebuild, a consistency check, or a new virtual disk on the survivors writes the set. If two members of a RAID 5 are already down, the limit is the two-drives page. ESXi formatting the LUN the controller still presents does not bring the missing member's sectors back.

The three choices, and what each one writes

When the Snapshot Volume column has a value, New Datastore — Add Storage on older hosts — asks which mount option to use. Broadcom's article for that screen, written for ESXi 7 and later, prints the three sentences the wizard shows:

• Keep existing signature. "Data on the disk will be retained. The datastore will be mounted using the same signature." The datastore is mounted with the original name.
• Assign a new signature. "Data on the disk will be retained. A new signature will be assigned to the datastore and references to existing signature from VM configuration files will be updated." The wizard then says the datastore will be mounted using the original name.
• Format the disk. "The current disk layout will be destroyed and all data will be lost permanently."

Keep existing signature does not change the UUID. The vSphere storage guide calls this mounting without changing the signature. You can do it when the original volume is not already mounted — their example is a disaster-recovery copy at a site where the primary is gone. The current esxcli page for this mount says ESXi allows both read and write on the LUN copy, the LUN has to be writable, and the mount persists across reboots. The mount is refused if a datastore with the same UUID is already mounted. Broadcom's snapshot article calls the same operation a force mount, including esxcli storage vmfs snapshot mount, and -n on that command for a mount that does not persist across a reboot. -n is still a mount. Their troubleshooting note says keeping the signature leaves later problems, including expanding the datastore and having a new host mount it automatically, and they describe the force mount as a temporary way to get access. Temporary, in that article, means you are supposed to come back and resignature or move the VMs. It does not mean the mount was read-only. Powering a virtual machine on, or letting the host use the volume, is I/O on the LUN. On disks that already failed, that I/O is the thing the wizard did not repair.

Assign a new signature is resignature. The storage guide says the host writes a new UUID and mounts the copy as a datastore distinct from the original. Resignature is irreversible. After it, the device is no longer treated as a replica. A spanned datastore can be resignatured only if every extent is online. The guide says the process is fault tolerant and can be resumed if it is interrupted. That is a statement about the metadata write continuing. It is not a reason to resignature a LUN that is dropping commands. The guide also says that if the hosts can see both copies of a LUN, resignature is the option that avoids a UUID collision. That sentence is about a real replica presented next to the original. A volume flagged as a snapshot because the controller or the LUN number changed, with no second copy anywhere, is still the only copy. Resignature on it is the same UUID write.

What the name and the VM files do is where Broadcom's current pages split, and this post will not pick a winner for you. The wizard text quoted above says the datastore is mounted using the original name, and that references in VM configuration files are updated. The esxcli resignature page says the host assigns a new UUID and a new label, and that the default label is snap-, a number, and the original label. It then says you may still have to update references in the .vmx, .vmdk, .vmsd, and .vmsn files and register the virtual machines with vCenter. Broadcom's snapshot-LUN article uses the label form snap- plus an id plus the old label, says the name gains snap- by default, and says not to resignature a datastore that has running VMs, because the path changes. Their order is: shut the VMs down, unregister them, unmount the datastore on every host, resignature, then add the VMs back. A VM that only has some of its disks on that volume can need the VMDK removed from the configuration and added again from the new path. The same KB article that quotes the wizard's "original name" line also says the result is typically a snap- name. Read both before anyone treats "data will be retained" as "nothing on the volume changes." The retained part is the file data, as against Format. The write is a new UUID in the superblock, the label change those pages describe, and whatever happens to the VM configuration files. It does not come back. It does not rebuild a failed disk.

Format the disk creates a new VMFS. The wizard's own line is that the current layout is destroyed and the data is lost permanently. That is a partition and a filesystem written on the device. vmkfstools creating a VMFS on that device is the same write from the shell. Neither one reads the old virtual machines out first.

The device that looks empty

The three options show up when ESXi has already found a VMFS signature and called it a copy. The other screen is worse, because it does not look like a decision. The device is on the list, Snapshot Volume is blank, and the wizard is ready to create a datastore with a name and VMFS as the type.

Broadcom's article on SAN snapshots that appear in Add Storage without "add with resignaturing" or "use existing signature" says this directly: do not proceed with adding a datastore that has data you need to preserve when those mount options are absent. Proceeding reformats the VMFS and loses the data. They attribute that screen to the LUN being presented incorrectly. ESXi does not assign the LUN number. It reads the number the array returns at discovery. A LUN whose number does not match across the hosts can land in this dialog instead of the signature dialog. Their fix, for a healthy array, is to correct the presentation on the array and rescan — and if the LUN is then detected as a snapshot, you are back on the signature page, not on Format.

A local controller produces the same empty device without a SAN. The card is showing the member disks instead of the virtual disk. Or someone cleared the foreign configuration and created a new virtual disk. Or an initialize already wrote the virtual disk that used to hold the VMFS. The wizard is telling the truth about the device it can see right now: it does not find a VMFS signature to offer you. The old stripes, if they are still on the members, are not this dialog's problem. Creating VMFS writes the device the controller is presenting. It does not reconstruct the virtual disk the previous controller had.

Not consumed belongs in this paragraph so it does not get read as blank media. On the inconsistent-presentation article, the LUN is visible, the datastore column says Not consumed, and the log says the device was detected as a snapshot because the LUN number does not match the rest of the cluster. That article's instruction is to correct the LUN number on the array and rescan, and not to force-mount, because a force mount does not fix the presentation. A snapshot flag and a blank "looks empty" wizard are different screens. Both of them are still the original volume until someone creates a datastore on it.

What you can look at, and what not to click

If the chassis is quiet and the host is already up, two things VMware documents are looks. They are not the repair, and they are not a loop to run until the datastore appears.

esxcli storage vmfs snapshot list lists unresolved snapshot and replica volumes. The sample in Broadcom's snapshot article prints the volume name, the VMFS UUID, whether it can mount, whether it can resignature, the reason if it cannot, and an unresolved extent count. Photograph that. The following commands in the same article — esxcli storage vmfs snapshot resignature, esxcli storage vmfs snapshot mount, and esxcfg-volume -M or -r — are the UUID write and the force mount. Do not run them because the list succeeded.

A storage rescan is how the host reads device identity again. The UI control is Rescan Storage on the adapter. The command Broadcom gives for a rescan after a LUN-ID correction is esxcli storage core adapter rescan --all. A rescan can make a snapshot line appear in the log. It does not create a filesystem, and it does not resignature. If the datastore is still missing when the rescan finishes, the wizard is not the next step that "completes" the rescan.

On the storage devices page, photograph the device id, the capacity, the datastore column, and the Snapshot Volume column before a refresh clears the view. If /var/run/log/vmkernel.log already has detected to be a snapshot, photograph the queried disk ID and the on-disk disk ID. Those two lines are how you tell a LUN-number change from a hardware-identity change. They are not a mount.

On the RAID controller, photograph the virtual disk and any foreign-configuration line before you leave the BIOS. Clear Foreign Configuration deletes the card's metadata for that array. Initialize, Fast Init, and Reinitialize write the virtual disk. A new virtual disk on those members is a new device, and it is the device New Datastore will offer to put a filesystem on. Import is a separate decision, and only when you already know the foreign view is this array and what the card will do with cache. That warning is written out on the battery and foreign-config page. Do not clear foreign, and do not initialize the virtual drive, to give ESXi a disk it is willing to format.

This screen is not the other pages

The RAID card page is Force Online, preserved cache, and Foreign on a PERC, Smart Array, MegaRAID, or the same class of controller. Clear Foreign there deletes the array metadata. This page is the ESXi wizard that shows up once a disk is visible to the host, including a disk that is only visible because that metadata was cleared and a new virtual disk was created. If the screen in front of you is the controller BIOS, use that post. If the screen is New Datastore, you are here. Importing a foreign config does not create a VMFS, and creating a VMFS does not import the array.

Rebuild versus recovery is the controller writing a replacement member from the disks it believes are healthy. A missing ESXi datastore with a failed member underneath is that decision first. The datastore wizard does not become safe because the rebuild finished, and a rebuild does not become safe because the datastore is missing. RAID 5 with two drives down is a parity set that has already lost the one disk it could lose. Formatting the LUN will not put the second member back. RAID 0 is a stripe with no second copy. One dead member and the virtual disk does not contain the files. A new VMFS on the survivor is a write on the only stripe piece you still have.

Unraid unmountable and TrueNAS will not import is Format, New Config, and a pool that will not import. The word Format is the same class of mistake. The filesystem and the buttons are not VMFS. Do not follow this page into an Unraid format, and do not follow that page into New Datastore on an ESXi LUN. Initialize Disk is the Windows partition-table dialog. A VMFS LUN attached to a Windows machine "to look" can land there, and confirming it writes a new table at the start of the LUN. That is a Windows write on a VMFS volume. It is not a way to avoid the ESXi wizard.

What to do right now

Stop the wizard. If a disk is clicking, or a rebuild or an initialize already started, power the machine down. If the host is quiet and the datastore is simply unmounted, cancel New Datastore and leave the volume unmounted. Do not present the same LUN to a second host to try the wizard there.

1. Stop. Cancel New Datastore. Do not choose Keep existing signature, Assign a new signature, or Format the disk. Do not run esxcli storage vmfs snapshot mount, esxcli storage vmfs snapshot resignature, or esxcfg-volume -r. Do not create a VMFS with vmkfstools, and do not delete or rewrite the partition table. Do not Clear Foreign Configuration, initialize a virtual disk, or start a rebuild. If a disk is clicking, grinding, or dropping out, power it down. See what a clicking drive means. If the LUN is on a SAN shelf that is not this server, stopping means leave it unmounted. Pulling drives out of a live array shelf is not the look.
2. Photograph the host before a rescan or a reboot changes the view. Storage devices: device id, capacity, Not consumed or blank, Snapshot Volume. The esxcli storage vmfs snapshot list output if you already have it: name, UUID, can mount, can resignature, extent count. Any detected to be a snapshot line, with both disk IDs. The New Datastore screen, including which of the three options is selected, then cancel it. Screenshots help. They are not a diagnosis.
3. Photograph the controller if the disks are behind a RAID card. Virtual disk online, offline, or missing. Foreign configuration, and the exact menu that is open. Failed or rebuilding members. Do not accept Clear, Import, Initialize, or Rebuild to get a cleaner picture.
4. Label every disk by serial before anything is unplugged. Bay or port, and the serial on the label. A pile of unlabeled members is how the wrong one gets a new virtual disk later. If the storage is a SAN LUN and you cannot see the member disks, write down the array, the LUN, and the NAA or device id from the screenshot instead of guessing which shelf to open.
5. Keep every member. The disk the controller called failed. A hot spare that had already joined. Any disk an initialize or a rebuild had started writing. The boot device is a separate disk. Do not send a VM you exported after a format and call it the datastore.
6. Write down what you remember: controller or HBA swap, firmware update, host reinstall, LUN remap, array snapshot, or a replication cutover. Whether anyone already chose a mount option, created a datastore, resignatured, force-mounted, cleared foreign, initialized, or rebuilt. VMFS version if you know it. Whether the virtual machines were encrypted, and where that key is. Encryption without the key is still encryption. And whether a backup exists on media that is not this LUN. "The array snapshot is the backup" means it is not, once that snapshot is the LUN you are about to format.

Pack loose disks the way you would any failed drive — how to ship a failed drive safely. If you cannot pull the set cleanly, the chassis can come in as a chassis. Do not open a drive on a table to see which member the controller called failed.

How a lab handles it

We do not finish New Datastore on your host to see if a folder appears. We do not keep the signature, resignature, or format the original LUN. We do not run vmkfstools against it, and we do not mount it on an ESXi host of ours so a VM can power on. We do not clear a foreign configuration, initialize a virtual disk, or rebuild on the controller that lost the datastore.

When the datastore lives on disks in the server, each member is imaged write-blocked first. That includes a disk the controller already calls failed, as far as that disk will read, and a disk an initialize or a rebuild had already started writing. The controller stays out of the path. Imaging uses the lab tools already named on this site, including the ACE Lab PC-3000 and DeepSpar Disk Imager. Those tools image the disks. They are not a New Datastore wizard. Work happens on the copies: which virtual disk the members still describe, and whether a VMFS superblock and the VMDKs are still in that address space.

When the only problem is a healthy LUN that ESXi flagged because a LUN number or a device identity changed, the bytes are still on that LUN and the way they get destroyed is the wizard. Resignaturing the original so the host will mount it is the irreversible UUID write, done on the only copy. We will not do that to see the folder. A SAN shelf that has failed members is the same member-disk job as any other array, once those disks are the ones in front of us. We do not tell you to pull drives out of a production shelf from this page.

What imaging cannot do: put back a VMFS that Format, or a finished vmkfstools create, already replaced with a new filesystem; a virtual disk a full initialize already wiped; or a member a rebuild already overwrote. A resignature that finished has already written the new UUID. We will tell you if the old signature and the VMDKs are not on the copy. We will not promise the wizard's "lost permanently" is sitting intact under a format that completed.

The public case log has no ESXi datastore, no VMFS resignature, and no New Datastore job. We will not invent one.

The closest published server is a different write-up, and the outcome belongs to those drives. 21607: twelve HPE 1.8 TB SAS drives on one SmartArray, a five-drive RAID 5 and a seven-drive RAID 6. The RAID 5 problem was the controller dropping offline. The RAID 6 had lost three members. The server hosted the client's virtual machines. Nothing was rebuilt on the original controller. Three members needed head swaps, every drive was imaged, and the arrays were reconstructed from the images. The verification they recorded was a GPT header at the start of the reconstructed volume. The case does not say the filesystem was VMFS, and it does not say anyone had opened New Datastore. It is a hardware controller that took the virtual disks away, handled by imaging the members. It is not a rate, and it is not a prediction about a LUN someone is about to format. We don't advertise a success rate.

If the screen is the controller BIOS and the battery or a foreign config is the story, start with don't force the array online. If a rebuild is the button, start with rebuild versus recovery. For the work itself, see RAID data recovery.