Vmware: Removing a Stale Inaccessible VMFS Datastore from VMware vCenter

Overview

This runbook documents a real-world vSphere Vmware: pattern: a VMFS datastore has already been removed from the storage presentation layer, but the datastore object remains visible in vCenter. The datastore is inaccessible and unmounted, normal PowerCLI removal fails, and vCenter may report unexpected virtual machines during maintenance-mode checks.

The key to resolving the issue safely is to separate the stale datastore from similarly named healthy datastores, prove that no live VM or template depends on it, verify the ESXi storage state, and then rescan the affected hosts.

Example Environment — Anonymized

Names, hostnames, VM names and identifiers from the production environment have been intentionally changed. The Vmware: logic and command patterns remain applicable to vSphere environments with the same symptoms.

Symptoms

• The datastore remains visible in vCenter even though its backing storage has been decommissioned.
• The datastore shows Accessible: False.
• vCenter still lists multiple hosts under the datastore's Hosts tab.
• Those host associations show Mounted: False and Accessible: False.
• ESXi does not show the datastore in its VMFS extent or filesystem lists.
• Remove-Datastore without -VMHost reports that VMHost is mandatory.
• Host-specific removal can fail with Unable to query live VMFS state of volume: No such file or directory.
• Maintenance-mode checks may report virtual machines even when the datastore's VMs tab appears empty.

Step 1 — Confirm the Exact Datastore

Start by identifying the exact datastore object. Do not rely on a common naming prefix when several datastores share the same prefix.

$ds = Get-Datastore -Name "PROD_VM_TEMPLATES_OLD"
$ds | Select-Object Name,Id,Type,CapacityGB

Record the datastore ID and UUID before making changes. Treat similarly named datastores as separate resources.

Step 2 — Check Host Associations

$ds.ExtensionData.Host | ForEach-Object {
    $h = Get-View $_.Key -Property Name

    [PSCustomObject]@{
        Host        = $h.Name
        Mounted     = $_.MountInfo.Mounted
        Accessible  = $_.MountInfo.Accessible
        Path        = $_.MountInfo.Path
    }
} | Format-Table -AutoSize

A stale datastore can remain associated with hosts in vCenter even when the host is no longer mounting the VMFS volume. The important distinction is between an inventory association and an active storage mount.

Step 3 — Check VM and Template Dependencies

Before removing anything, search for references to the exact datastore name or exact UUID. Do not search only for a shared prefix such as PROD_VM, because that can match VMs stored on completely different datastores.

$target = "PROD_VM_TEMPLATES_OLD"
$uuid   = "00000000-0000-0000-0000-000000000000"

$vms = Get-View -ViewType VirtualMachine `
    -Property Name,Config.Files,Config.Hardware.Device

foreach ($vm in $vms) {
    if ($vm.Config.Files) {
        $refs = @(
            $vm.Config.Files.VmPathName
            $vm.Config.Files.SnapshotDirectory
            $vm.Config.Files.SuspendDirectory
            $vm.Config.Files.Firmware
        )

        foreach ($ref in $refs) {
            if ($ref -and ($ref -match [regex]::Escape($target) -or
                           $ref -match [regex]::Escape($uuid))) {
                [PSCustomObject]@{
                    VM        = $vm.Name
                    Reference = "VM Configuration"
                    Path      = $ref
                }
            }
        }
    }

    foreach ($device in $vm.Config.Hardware.Device) {
        if ($device.Backing -and $device.Backing.FileName) {
            $ref = $device.Backing.FileName

            if ($ref -match [regex]::Escape($target) -or
                $ref -match [regex]::Escape($uuid)) {
                [PSCustomObject]@{
                    VM        = $vm.Name
                    Reference = $device.GetType().Name
                    Path      = $ref
                }
            }
        }
    }
}

An empty result is a strong indication that current VM configuration and device backing files do not reference the stale datastore. Templates should be checked separately when vCenter reports template dependencies.

Step 4 — Check the ESXi Storage Layer

Run the following on each affected ESXi host. These checks are read-only.

esxcli storage vmfs extent list | grep -i "DATASTORE_UUID"

esxcli storage filesystem list | grep -i "PROD_VM_TEMPLATES_OLD"

vim-cmd hostsvc/datastore/lists | grep -i -A10 -B2 "PROD_VM_TEMPLATES_OLD"

In the documented case, the first two commands returned no match, while vim-cmd hostsvc/datastore/lists still showed a VMFS datastore object with zero capacity/free space and accessible=false. That combination indicates a stale host-side inventory object rather than a live mounted VMFS filesystem.

Step 5 — Understand Remove-Datastore Errors

Two different failures can occur and they mean different things.

Remove-Datastore -Datastore $ds -Confirm:$false

Value cannot be found for the mandatory parameter VMHost

This indicates that PowerCLI requires a host context for the datastore associations that still exist.

Remove-Datastore -Datastore $ds -VMHost $esxHost -Confirm:$false

Unable to query live VMFS state of volume:
No such file or directory

This is different: ESXi cannot query the live VMFS volume because the underlying volume is no longer present. Repeating the same removal operation against other hosts is not a substitute for diagnosing the stale state.

Step 6 — Do Not Confuse Similar Datastores

A common trap is searching for a partial datastore name. For example, if an environment contains:

• PROD_VMFS_01
• PROD_VMFS_02
• PROD_VMFS_03
• PROD_VMFS_04
• PROD_VMFS_05
• PROD_VM_TEMPLATES_OLD

a broad search for PROD_VM can identify VMs from multiple healthy datastores. Always narrow the test to the exact target datastore name or UUID before removing inventory objects.

Step 7 — Check and Clear Maintenance Mode State

$ds.ExtensionData.Summary | Select-Object Name,Url,Accessible,MaintenanceMode,Type

If the datastore is stuck in an inMaintenance state, a non-destructive state refresh can be attempted:

$ds.ExtensionData.RefreshDatastore()
$ds.ExtensionData.RefreshDatastoreStorageInfo()

Set-Datastore -Datastore $ds -MaintenanceMode $false -Confirm:$false

Exiting maintenance mode does not itself remove the stale datastore. It simply removes one possible state complication before the final cleanup.

Step 9 — Verify the Datastore Has Disappeared

Get-Datastore -Name "PROD_VM_TEMPLATES_OLD" `
    -ErrorAction SilentlyContinue

If no object is returned, the stale datastore entry has been cleared from the vCenter inventory view. Also verify that the healthy datastores and their VMs remain unchanged.

What Not to Do

• Do not remove healthy datastores merely because they share a naming prefix with the stale datastore.
• Do not remove VMs from inventory based only on a broad name match.
• Do not run storage deletion commands blindly. First prove which device backs the target datastore.
• Do not use partedUtil against an unknown device. If the VMFS extent is already absent, there may be no valid target device.
• Do not manually edit the vCenter database or ESXi inventory files as an ad-hoc fix.
• Do not use datastore destruction APIs simply because a Destroy method is visible. API availability does not mean the operation is valid for the datastore's current state.

Troubleshooting Decision Tree

Datastore remains in vCenter
        |
        v
Is it Accessible?
   |              |
  Yes             No
   |              |
Normal cleanup    Check host associations
                  |
                  v
          Mounted on any host?
             |           |
            Yes          No
             |           |
      Investigate live   Check VMFS extent/filesystem
      storage first      |
                         v
                 VMFS extent present?
                    |            |
                   Yes           No
                    |            |
             Investigate LUN     Stale inventory object
             presentation       |
                                v
                       Search exact VM/template refs
                                |
                                v
                         No dependencies?
                                |
                                v
                       Refresh / exit stale
                       maintenance state
                                |
                                v
                        Rescan affected hosts
                                |
                                v
                      Verify datastore is gone

Lessons Learned

• Exact identifiers matter. Shared datastore prefixes can create misleading VM search results.
• Mounted and accessible are separate concepts. A datastore can remain associated with a host while being neither mounted nor accessible.
• vCenter inventory can outlive storage presentation. A datastore object can persist after its backing VMFS volume has disappeared.
• Use layered diagnostics. Check vCenter, VM inventory, host associations, and the ESXi storage layer before taking corrective action.
• Prefer read-only validation before remediation. This prevents an orphaned datastore problem from becoming an outage on a healthy datastore.

Frequently Asked Questions