Generated Oct 3, 2026, 12:35:03 AM
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.
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.
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.
If remounting is not acceptable or if problem recurs across multiple hosts, Storage vMotion the affected VMs to a different datastore (as you already validated) and then resume — this is a safe reversible mitigation but can be IO‑heavy.
Escalate to VMware and NetApp support with collected logs and NetApp storage snapshots: this is appropriate when remounts are required frequently, when many VMs are affected, or when you observe NetApp snapshots/replication events coinciding with ESTALE errors. Include vmkernel logs, NFS export options, and NetApp SVM and volume change history.