If two ESXi hosts reach the same NFS 3 export but vSphere treats it as different datastores, compare the configured server and folder strings. Broadcom explicitly requires identical server and folder names across hosts mounting the same NFS 3 volume. A short server name on one host and a fully qualified name on another can create distinct datastore identities even when both resolve to the same server. A10-D5
This diagnostic uses the vSphere 8.0 storage documentation. It reads existing configuration only. Examples are invented, no commands or migrations were executed, and no storage remount is proposed.
Reachability is only one part of identity
A datastore display name is a convenient inventory label. It is not enough to prove that every host has mounted the same underlying storage consistently. Similarly, successful name resolution does not prove that the strings used by separate NFS 3 mounts match.
The practical consequence is that a migration can fail a shared-storage expectation even though an administrator can browse files from both hosts. Broadcom names vMotion failure as a possible consequence of this NFS 3 discrepancy. The diagnosis therefore belongs at the VMware datastore layer, rather than immediately changing DNS or a physical switch.
Prerequisites are read access to each affected host's existing datastore configuration, its NFS protocol version and storage-owner confirmation of the intended export. Include the actual source and destination hosts from the failed operation; a third healthy host is useful context but cannot substitute for either endpoint.
Build a mount comparison
For each host, record the datastore label, NFS version, configured server value, configured folder/export value and current accessibility. Obtain these from the host's storage configuration or existing inventory evidence. Copy the values exactly before normalising anything for a report.
A synthetic comparison might look like this:
| Field | Host A | Host B |
|---|---|---|
| Protocol | NFS 3 | NFS 3 |
| Server | filer |
filer.example.test |
| Folder | /exports/vms |
/exports/vms |
| Local display label | Shared-VMs |
Shared-VMs |
| Mounted / accessible | Yes / Yes (hypothetical) | Yes / Yes (hypothetical) |
| Evidence time | Record the comparison interval | Record the same interval |
The equal labels and folders do not cancel the unequal server values. If the storage owner confirms these names refer to the same intended export, the table matches Broadcom's documented NFS 3 identity problem. It supports a configuration correction plan; it does not authorise one during the incident.
Keep the folder value equally precise. An alias or alternative export path should not be assumed equivalent merely because its file listing looks similar. Have the storage owner establish the backing relationship before consolidating records.
Add operational state to the comparison for each host: Mounted, Accessible, and the timestamp of that evidence. These values are separate from the server/export strings; a matching identity does not establish current accessibility. Use the existing host mount records supplied by the storage owner. No additional version-cleared ESXCLI listing example is supplied here.
Separate three outcomes
If the affected hosts use NFS 3 and the server or folder values differ, report the exact difference and the affected operation. Preserve the pre-change configuration for the administrator who plans the correction.
If the NFS 3 values match, this particular explanation is not supported. Continue investigating accessibility, permissions and the operation's precise error using the relevant storage and migration guidance. Do not manufacture an identity mismatch from an unrelated difference in display labels.
If both hosts use NFS 4.1, do not apply the NFS 3 naming rule as if it were universal. The version 8.0 guide explicitly excludes NFS 4.1 from that guideline. That exclusion does not prove every NFS 4.1 configuration is valid; it means this article's specific explanation is not established. A10-D5
Mixed protocols are a different problem
NFS 3 and NFS 4.1 datastores can coexist on one host. However, mounting the same datastore through different NFS versions across hosts is unsafe because the locking mechanisms are incompatible. NFS 3 on ESXi uses VMware lock files rather than NLM; NFS 4.1 uses share reservations. A10-D6
Do not interpret the existence of a .lck file as permission to remove it. Nor should changing protocol version be used as a quick way to reconcile two inventory objects. The documentation warns that incompatible clients accessing the same virtual disks can cause incorrect behaviour and data corruption.
Acceptance and reversal limits
The immediate acceptance criterion is a complete, host-specific comparison that either identifies the documented NFS 3 discrepancy or rules that explanation out. Record unknown backing relationships rather than silently treating two exports as identical.
A subsequent correction requires a storage-owner plan covering active consumers, consistent mount definitions, supported access and a validated return path. Proposed post-change acceptance includes the intended datastore identity on all relevant hosts and separately authorised validation of the previously failing operation. No such operation has been run for this article.
Inspection itself needs no rollback. Unmounting a datastore or converting its protocol is a separate storage change, not a harmless renaming exercise.
Learning notes
- Equal datastore labels do not prove equal NFS 3 mount identities.
- Server and folder strings matter even when DNS reaches the same endpoint.
- NFS 3 and NFS 4.1 locking cannot be mixed on the same datastore.