1
Diagnostic step 1
Do not power on or modify affected VMs until you have a verified backup or snapshot state (if possible). Collect a full set of logs from ESXi hosts (hostd, vobd, vmkernel) and SAN array event logs for the firmware window.
FULL AI ANALYSIS
ESXi VMs fail to boot after SAN firmware upgrade: 'device with uuid ... not found' and VMX references stale datastore paths
Generated Oct 14, 2026, 9:39:02 AM
Analysis summary
Storage firmware upgrade likely changed LUN serial/naa or performed a back-end migration causing device identifiers presented to ESXi to change. ESXi maps datastores and VMDK backings by identifiers; when those change, VMX files reference paths that no longer map correctly. Recovery involves ensuring ESXi sees the same LUNs and datastores with original identifiers or updating VM config to point to correct files after verifying data integrity. Because these steps touch storage mappings and VM config files, proceed cautiously and escalate to SAN or VMware support if device re-identification is ambiguous or if automatic remapping fails.
Possible causes
Storage array migration/firmware process changed LUN identifiers (naa/serial) causing ESXi to present new device identifiers and breaking datastore-to-LUN mapping the VMs expect.
80%Transient host disconnection during upgrade caused inconsistent VMFS metadata caches across cluster nodes; some hosts have stale mapping and require datastore rescan/refresh to reattach correctly.
55%Datastore rename or VVol policy rebind by storage management during the firmware upgrade changed path prefixes used by VMX files, leaving VMDK files intact but inaccessible by original path.
40%ESXi bug in storage rescan handling under that specific firmware version left partial VMFS corruption requiring manual repair or SAN-side fix.
25%Suggested fixes
2
Diagnostic step 2
On each host, run esxcli storage core adapter rescan and esxcli storage filesystem list to confirm datastores are visible and mounted on all hosts. Use vSphere Datastore Browser to verify the presence and integrity of VMDK files (do not edit VMX yet).
3
Diagnostic step 3
Compare device naa/serial values shown by SAN (array management) with esxcli storage core device list to confirm whether identifiers changed. If identifiers changed but LUN content is intact, coordinate with SAN vendor to remap or re-publish LUNs using original identifiers or provide a supported migration plan.
4
Diagnostic step 4
If datastore mapping appears inconsistent across hosts, perform a controlled maintenance: put host in maintenance mode (if HA allows), rescan, and attempt to unregister/register the datastore from the host rather than deleting it. Avoid resignaturing datastores unless you are certain the LUN contains a unique VMFS signature and no other host uses it.
5
Diagnostic step 5
If you cannot safely restore mappings or if datastore metadata shows corruption, escalate to VMware support and your SAN vendor with collected logs and storage mappings — this is appropriate for firmware-induced identifier changes or suspected VMFS corruption. Do not attempt destructive repairs without vendor guidance.