A storage migration is nearly finished. The virtual machines have moved, the old VMFS datastore looks empty, and the unmount fails with "The resource … is in use" or, from the ESXi command line, "cannot be unmounted. Reason: Busy". The knowledge base fixes for this error include stopping processes, restarting host agents, disabling vSphere HA, enabling vCLS Retreat Mode and rebooting hosts. Several of those affect a whole host or cluster, not just the one datastore.
This article produces a record: each candidate consumer, on each host and each extent, with how strong the evidence for it is and who owns it. It changes nothing, and it does not tell you that the datastore is ready to unmount.
Scope
vSphere 8.0: vCenter Server 8.0 managing ESXi 8.0 hosts, and one VMFS datastore that is still accessible. NFS and vVols datastores, datastores whose device has already been lost (all paths down or permanent device loss), vSAN, and detaching the LUN afterwards are out of scope. How the embedded vCLS of vSphere 8.0 Update 3 uses datastores is not covered by the sources below.
Why the precheck can pass and the unmount still fail
The vSphere Client checks only part of the picture. Broadcom KB 323128 states that "only these checks are performed during the datastore unmount operation": that the host has no virtual machines on the datastore and does not use it for HA heartbeats. Everything else (a template, an ISO, a log directory, an open shell) is found only when the host tries to close the volume.
The vSphere 8.0 documentation adds a warning about heartbeating: "vSphere HA Heartbeating does not prevent you from unmounting the datastore. However, if the datastore is used for heartbeating, unmounting it might cause the host to fail and restart any active virtual machine." A green precheck is therefore not proof that the datastore is free.
How to grade each observation
Give every row in the record one of three grades, with the host, the time and the evidence:
| Grade | Meaning | Example |
|---|---|---|
| Candidate | Something that could hold the datastore, not yet shown to | The datastore is eligible for HA heartbeating; a .vSphere-HA or vCLS folder exists |
| Configured dependency | A setting or inventory object that points at the datastore | A template registered here; Syslog.global.logDir on this datastore |
| Confirmed active handle | A process seen holding a file or the device at a recorded time | fdm holding a heartbeat file in the lsof output |
An empty list in any view is not proof that nothing uses the datastore. It covers only the hosts, extents and moment it was read. Unread hosts and extents stay listed as gaps.
Step 1: record the error and the extents, per host
Record, for each host that mounts the datastore:
| Field | What to record |
|---|---|
| A | Host name and the time of the attempt |
| B | The exact error text from the vSphere Client or from esxcli storage filesystem unmount |
| C | The datastore name, VMFS UUID and every extent's device ID, from esxcli storage vmfs extent list (a datastore can span more than one extent) |
| D | /var/log/vmkernel.log lines from the attempt |
The reason in field B narrows the search. KB 323128 lists these reasons: "One or more virtual machines are still registered on it", VM templates, "Swap to host cache is enabled on it", "Storage I/O Control is either enabled or running in statistics collection mode on it" and "File system is busy".
For field D, KB 311779 shows vmkernel.log naming the file and the process that holds it, in lines of the form "unmounting opened volume … is not allowed" followed by "File syslog.log , fhID: ##, is opened by world: … - vmsyslogd". Lines like these are confirmed active handles for that host at that time.
Step 2: list inventory consumers in vCenter
These are read in the vSphere Client and change nothing.
| Field | Where | What to record |
|---|---|---|
| E | Datastore > VMs, filter Virtual Machines | Every VM listed, with its power state and the datastores holding its disks. This tab also lists VMs whose disks live elsewhere but which reference this datastore, for example through an ISO or a snapshot chain (KB 311779) |
| F | Datastore > VMs, filter VM Templates | Any template here. KB 379435: "If a pointer to a template remains in the vCenter database, the unmount operation will fail." |
| G | For each VM in E whose disks are elsewhere | Whether a connected CD/DVD drive points at an ISO here, or a snapshot chain still references this datastore |
| H | The cluster's vSphere HA heartbeat datastore settings | Whether this datastore is selected for heartbeating, or only eligible. Eligibility alone is a candidate |
| I | Datastore > Configure > General | Storage I/O Control enabled, or statistics collection on |
| J | Datastore inventory | Membership of a datastore cluster, or Storage DRS management |
| K | Datastore browser | .vSphere-HA folders, vCLS folders and replication hbr. files. A folder or file alone is a candidate; it needs a matching handle in Step 4 or a matching inventory object to be more |
Two of these are easy to miss. KB 311779 notes that "Even if ISO file is deleted from the Datastore, the ISO link to the virtual machine is not broken.", so an ISO deleted earlier can still hold the datastore. KB 311779 also describes VMs that were migrated off the datastore while running on snapshots: their snapshot chain still references it.
For field E, a powered-off VM that is still registered with files on this datastore remains a configured dependency. Powering it off can release its process handles, but the vSphere 8.0 prerequisite is "No virtual machines reside on the datastore." Moving a VM to another host without moving its storage does not change where its files are.
For field K, KB 321023 explains why vCLS agent VMs block the unmount: "Because these VMs maintain open file locks to ensure cluster services (DRS/HA), the ESXi Host is prevented from unmounting the volume." KB 311779 lists active vSphere Replication, seen as hbr. files that keep changing, as another consumer.
Step 3: list host consumers on each host
Host settings are per host, so check every host that mounts the datastore. These are display reads.
| Field | Where to read | What counts as a configured dependency |
|---|---|---|
| L | Host > Configure > System > Advanced System Settings, ScratchConfig.CurrentScratchLocation |
The host's scratch location is on this datastore |
| M | Same page, Syslog.global.logDir |
The host's log directory is on this datastore |
| N | Host coredump configuration | Coredump to a file on this datastore (KB 2147177, KB 323128) |
| O | Host swap settings | Swap to host cache or host-local swap storing VM swap files here (KB 2147177) |
KB 2147177 (ESXi 8.x) summarises the host-side consumers in one list: Storage I/O Control, swap file configurations, coredumps to a file, syslog or trace files, vCLS agent VMs, and active file handles, where "Any active I/O, such as an open console session, a running backup, or a mounting ISO file" results in an in-use error.
Step 4: list open files and device users on each host
Only after Steps 2 and 3, and only with the host owner's agreement because these run in the ESXi shell, read what is open right now. All three are display commands. Record the host and time with each output.
Field P, running VMs on this host (KB 390823):
esxcli vm process list
Field Q, processes with a file open on the datastore (KB 311779, KB 390823). Replace <VMFS-UUID> with the UUID from field C:
lsof | grep <VMFS-UUID>
Field R, worlds with the backing device open (KB 323128, KB 390823). Run once for each extent device ID from field C, replacing <device-ID>:
esxcli storage core device world list -d <device-ID>
Read field Q with care. KB 396637 shows the HA agent fdm holding .vSphere-HA/…/host-##-hb, a heartbeat file; that is a confirmed active handle for HA heartbeating on that host, and it upgrades field H. KB 390823 shows a shell whose working directory is inside /vmfs/volumes/<UUID>: "the datastore unmount failed due to root user locked" that directory. In that case the handle is your own SSH session, and leaving that directory is all it takes.
Step 5: hand each consumer to its owner
The right-hand column names who decides, not what they should do. Each decision is a separate change outside this article.
| Consumer recorded | Source | Owner who decides |
|---|---|---|
| Registered VM with files here (E, P), running or powered off | KB 390823, KB 2147177; vSphere 8.0 Unmount Datastores | VM owner: whether and how its storage is relocated. Powering off or a host-only move does not clear it |
| Template (F) | KB 379435 | Template owner |
| ISO on a connected CD/DVD (G) | KB 311779, KB 416522 | VM owner |
| Snapshot chain referencing the datastore (G) | KB 311779 | VM owner, with backup and storage owners: affects disk chains |
HA heartbeating (H confirmed by fdm handle in Q) |
vSphere 8.0 Unmount Datastores; KB 396637 | Cluster owner: affects HA protection |
| Storage I/O Control (I) | vSphere 8.0 Unmount Datastores; KB 2147177 | Storage owner |
| Storage DRS or datastore cluster (J) | vSphere 8.0 Unmount Datastores; KB 323128 | Storage owner |
| vCLS agent VMs (K corroborated, Q) | KB 321023 | Cluster owner: affects DRS and HA services |
| Replication files (K corroborated) | KB 311779 | Replication owner |
| Scratch location (L) | KB 311779, KB 390823 | Host owner |
| Log directory (M) | KB 311779 | Host owner |
| Coredump file (N) | KB 2147177, KB 323128 | Host owner |
| Swap files (O) | KB 2147177 | Host or cluster owner |
| Your own shell in the volume (Q) | KB 390823 | You: leave the directory |
| A process not explained by any row above | KB 390823 | Nobody stops it from this record; hand fields A–R to Broadcom support |
Two costs belong with the record. KB 390823 says "Changing the configured scratch location requires a reboot of the ESXi host for the changes to take effect." KB 311779 says that reconfiguring or removing replication for a VM "will initiate the full sync for the VM."
What this record does not authorise
Naming a consumer does not show that releasing it is safe. The KBs above also describe stopping processes found by lsof, restarting hostd or other agents (KB 390823), disabling HA on the cluster (KB 396637), Retreat Mode for vCLS (KB 311779, KB 321023), consolidating snapshots and unregistering objects. None of them is a step in this article.
They also differ in reach. Unregistering a template or disconnecting one VM's ISO touches one object. Stopping a host process, restarting an agent, disabling HA or entering Retreat Mode affects every workload on the host or in the cluster. Consolidation rewrites a VM's disk chain.
Before any of them, the owner and a qualified reviewer need, for the exact object: its dependencies and current tasks, the protection it provides and what is lost while it is off, whether the data can be recovered if something goes wrong, a procedure matched to the installed version, a way back into the host or cluster that does not depend on the thing being changed, an abort and reversal plan, and how the affected applications will be accepted afterwards. Only a separately authorised change follows that review.
The vSphere 8.0 documentation also asks for quiet during the unmount itself: "Do not perform any configuration operations that might result in I/O to the datastore while the unmounting is in progress."
Worked example (fictional)
The values below are invented to show how the records are read. Datastore ds-old-01 has one extent and is mounted on esx-01 and esx-02. All disks were moved earlier. The unmount fails on both hosts. Records were taken at 10:05 on both hosts.
| Field | esx-01 | esx-02 |
|---|---|---|
| B | file system is busy | file system is busy |
| C | one extent, naa.…01 | same |
| E | app-07 listed, powered on, disks on ds-new-02 | app-07 listed (cluster-wide view) |
| F | 1 template, tpl-win2022 | same |
| G | app-07 CD/DVD connected to [ds-old-01] iso/setup.iso |
none |
| H | ds-old-01 selected for heartbeating | same |
| M | Syslog.global.logDir = [ds-old-01] logs/esx-01 |
not on ds-old-01 |
| P | app-07 running here | app-07 not running here |
| Q | vmsyslogd, fdm, and the app-07 VM process |
fdm |
Graded record:
- Configured dependencies: tpl-win2022 (template owner); app-07's ISO (VM owner); esx-01 log directory (host owner).
- Confirmed active handles at 10:05:
fdmon both hosts, which confirms heartbeating (cluster owner);vmsyslogdon esx-01; app-07's process on esx-01.
app-07 appears in field E even though its disks are elsewhere, because the ISO references this datastore. The record names five consumers across three owners. It does not show that releasing any one of them, or all of them, would let the unmount succeed; that can only be known after the owners' separate changes and a fresh record.
Acceptance checks
- Fields A–D are recorded for every host that mounts the datastore, with every extent from field C listed.
- Every row in Steps 2–4 has a grade, a host, a time and its evidence, or is marked as not read.
- HA heartbeating and folder-only rows are graded as candidates unless a matching handle or selection was recorded.
- Unread hosts, unread extents and unexplained processes are listed as open, not as clear.
- Nothing was changed while reading. Because only reads were made, there is nothing to roll back.
- The record is handed to each named owner. Any change they make needs its own review and validation, and the unmount is not claimed to be ready.
Learning notes
- The client precheck covers registered VMs and HA heartbeating only. Most other consumers appear only when the host tries to close the volume.
- A VM can block a datastore without having a disk on it: an ISO or a snapshot chain is enough.
- A powered-off VM still registered with files here still resides on the datastore.
- A folder is evidence that something used the datastore once; a handle is evidence that something uses it now.
- Every extent and every host needs its own reading.
Related articles
- VMFS file locks: read the lock owner with vmkfstools -D, for the owner of a lock on a particular file (published page, HTTP 200 on 2026-11-03 UTC).
- ESXi logs after a reboot and the active scratch location (proposed: https://netleverage.com/ffb9917-articles/esxi-logs-reboot-active-scratch-location.html; link active only once that article is published).
- Power-on swap file and reservation space (proposed: https://netleverage.com/ffb9917-articles/vsphere-power-on-swap-file-reservation-space.html; link active only once published).
- Inaccessible datastore: all paths down or permanent device loss (proposed: https://netleverage.com/ffb9917-articles/esxi-inaccessible-datastore-apd-pdl-evidence.html; link active only once published).
- vSphere 8.0 Update 3 mixed cluster and embedded vCLS (proposed: https://netleverage.com/ffb9917-articles/vsphere8u3-mixed-cluster-embedded-vcls-drs-gap.html; link active only once published).
Sources
All retrieved 2026-11-03 UTC; dates are the page's own "Last Updated" or knowledge base date.
- Broadcom TechDocs, vSphere 8.0, "Unmount Datastores", last updated 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage/working-with-datastores-in-vsphere-storage-environment/basic-administrative-operations-for-vsphere-datastores/unmount-datastores.html
- Broadcom TechDocs, vSphere 8.0, "Remove VMFS Datastores", last updated 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage/working-with-datastores-in-vsphere-storage-environment/basic-administrative-operations-for-vsphere-datastores/remove-datastores.html
- Broadcom KB 323128, "Detach a LUN device from ESXi hosts" (pre-unmount checklist), 30 October 2026. https://knowledge.broadcom.com/external/article/323128
- Broadcom KB 311779, "Error: 'Device or Resource Busy' or 'Device in use' when attempting to delete/unmount/disconnect a Datastore", 12 September 2026. https://knowledge.broadcom.com/external/article?articleNumber=311779
- Broadcom KB 390823, "Unable to Unmount VMFS Datastore with 'Reason: Busy'", 28 October 2026. https://knowledge.broadcom.com/external/article/390823/unable-to-unmount-vmfs-datastore-with-re.html
- Broadcom KB 2147177, "Unmounting a datastore fails with error 'Cannot unmount volume … because One or more virtual machines are still registered on it'", 12 October 2026. https://knowledge.broadcom.com/external/article?legacyId=2147177
- Broadcom KB 379435, "Error: Unmount datastore failed the resource Datastore is in use.", 15 July 2026. https://knowledge.broadcom.com/external/article/379435/unmount-datastore-failed-the-resource.html
- Broadcom KB 321023, "Unmounting or detaching a VMFS, NFS or vVols Datastore fails due to vCLS VMs", 13 September 2026. https://knowledge.broadcom.com/external/article/321023/unmounting-or-detaching-a-vmfs-nfs-and-v.html
- Broadcom KB 396637, "Unable to Unmount the Datastore, Unmount Option is Grayed Out", 7 November 2025. https://knowledge.broadcom.com/external/article/396637/unable-to-unmount-the-datastore-unmount.html
- Broadcom KB 416522, "Trying to retire storage and an esxi host won't release the drive", 30 October 2025. https://knowledge.broadcom.com/external/article/416522/trying-to-retire-storage-and-an-esxi-hos.html