ESXi VMs fail to boot after SAN firmware upgrade: 'device with uuid ... not found' and VMX references stale datastore paths

Environment

vSphere ESXi 7.0 hosts (3-node cluster) backed by SAN LUNs presented via iSCSI; storage array firmware upgraded overnight; several VMs stored on upgraded datastores; HA enabled; one host shows disconnected state briefly during upgrade.

Symptoms

After storage firmware upgrade and ESXi reconnect, some VMs fail to power on with errors in vCenter 'File not found' and host logs show 'Failed to open disk: device with uuid ... not found' or 'VMX failed to find backing file'. Affected VMs' .vmx still reference VMDK paths on original datastore names.

Observations

vSphere hostd logs show repeated SAN rescan messages and LUN ID mapping changes; esxcli storage core device list shows devices with new naa identifiers for same LUNs; datastore names are unchanged in UI but underlying UUIDs differ for some datastores; some VMDK files are present when browsing datastore via Datastore Browser, but path prefixes in VM configuration point to stale VVol or renamed datastore mount points; hosts that did not disconnect during upgrade are unaffected.

Already attempted

Attempted vmfs datastore resignature/rescan; restarted management agents on hosts; attempted to register VM using datastore browser and manually editing .vmx to correct path (did not attempt destructive edits on production VMs); consulted storage array change logs which show migration of some volumes to new back-end nodes leading to new identifiers.

Question

Why do VMs report missing disk UUIDs after SAN firmware upgrade, and what are safe recovery steps to restore VM boot without risking data loss? When should I escalate to VMware or SAN vendor support?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1d ago• Trouble ID

Most likely 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%

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.

Suggested Fixes

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.

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).

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.