Identify scope before changing anything
Determine which ESXi hosts, datastores, VMs, paths, and storage devices are affected. If only one host is affected, prioritize its connectivity and multipathing; if many hosts are affected, look for shared fabric, array, or network dependencies.
Trace the path end to end
For block storage, validate HBA, switch fabric, zoning, target ports, LUN masking, device visibility, and multipathing. For NFS, validate VMkernel networking, routing, VLANs, DNS where applicable, export permissions, and storage-side NAS services.
Use latency and path state as clues
Compare device, kernel, and guest symptoms with array and fabric metrics. Path flapping, queueing, congestion, or storage latency can appear to the VM as a general performance problem.
Be cautious with rescans and detach operations
Rescans are common diagnostic actions, but device detach, unmount, resignature, or presentation changes can be disruptive. Confirm dependencies and cluster impact before manipulating production datastores.
Correlate all layers by time
Match ESXi events with switch logs and storage alerts using the same time window. Cross-layer correlation is often the fastest way to distinguish a host issue from a fabric or array issue.
This article is a general troubleshooting framework. Validate commands and procedures against your platform version, vendor documentation, support requirements, and change-control process before making production changes.