VM suspended on NFS datastore fails to resume with 'file handle not found' after upgrading ESXi hosts

Environment

VMware ESXi 7.0 U3 cluster, NetApp NFSv3 datastore exported to ESXi hosts; several Windows and Linux VMs use the NFS datastore for their virtual disks. Recent vSphere/vCenter upgrade performed cluster‑wide earlier today.

Symptoms

Attempting to resume suspended VMs that have their virtual disk files on the NFS datastore fails with errors referencing 'file handle not found' or 'cannot open virtual disk'. The same VMs resume normally if their disks are Storage vMotioned to a different datastore and then resumed.

Observations

vmkernel.log entries show NFS returning ESTALE or file handle mismatch when ESXi attempts to open *-suspend.vmsn and the VMDK. Other VMs on the same host and datastore can be resumed successfully. Remounting the NFS datastore on the host temporarily clears the issue for a short time. The NFS server (NetApp) reports no missing files and direct mounts from a Linux client can read the suspend files. Problem started after vSphere upgrade and became reproducible on a subset of hosts.

Already attempted

Performed host remount of NFS datastore (esxcli storage nfs remove/add), rebooted host (one host) which temporarily cleared issue for that host, performed Storage vMotion of affected VMs to an iSCSI datastore and then resumed successfully. Did not manually alter NetApp snapshot or export settings.

Question

What are the likely causes of ESXi reporting stale NFS file handles for VM suspend files on NetApp datastore after the upgrade, what reversible diagnostics and mitigations can I run to restore resumable state without corrupting VM disks, and when should I open a support ticket with VMware/NetApp?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

vSphere upgrade changed ESXi NFS client behavior or cache invalidation timing leading to ESTALE on access 90%

NetApp snapshot or volume internal operation changed filehandles/inode mapping while ESXi retained older handles 45%

NFS export options or server behavior changed (e.g., fsid recreation) making previously returned file handles invalid 35%

Summary

ESXi relies on stable NFS file handles. ESTALE/file handle not found errors typically arise when the NFS server changes inode/FS identifiers (for example, after a snapshot or storage reconfiguration) so previously obtained file handles no longer map to the same file. The fact remounting NFS temporarily fixes the problem suggests stale file handle caching on ESXi or differences in how ESXi computes/uses file handles after the vSphere upgrade. Storage vMotion to another datastore succeeds because it creates a fresh VMDK copy with consistent handles. This is a storage/compatibility issue rather than VM‑level corruption, but care is needed.

Suggested Fixes

Diagnostic step 1

Preserve VM file integrity: do NOT attempt to delete or move *-suspend.vmsn or VMDK files directly until logs are reviewed. Create a read‑only backup (NetApp snapshot or copy) of affected VM files if possible before further operations.

Diagnostic step 2

Collect detailed diagnostics: vmkernel logs (vmkwarning/vmkernel) on the host at the time of resume, NFS server export configuration, NetApp event logs for snapshots/volume moves, and a listing of the VMDK and suspend files using both ESXi view and a Linux NFS mount to compare file handles/inode numbers.

Diagnostic step 3

Try remounting the NFS datastore on the affected ESXi hosts to clear cached file handles as a temporary workaround; if that restores resume ability, schedule a coordinated remediation window.