Troubleshooting VMware ESXi Boot from SAN Failures and Path Errors
When an ESXi host boots from a LUN on a shared storage array, the hypervisor depends on a chain of physical and logical components firing in sequence before any VM starts. Any break in that chain surfaces as a PSOD, missing bootbank, or unresponsive console. Engineers running estates at Macquarie Park in Sydney or Melbourne's Docklands see these failures often, since boot from SAN is the default deployment mode for Cisco UCS and HPE BladeSystem hardware.
The troubleshooting playbook differs from a conventional disk failure. There is no local diagnostic partition to fall back on, no graphical installer waiting in the wings. The issue lives at the intersection of the storage fabric, the HBA, the multipathing stack, and the ESXi bootloader itself, so each layer must be tested before any reboot.
Local context shapes the picture. Many Australian operators route storage traffic to replication targets over the Southern Cross cable to Singapore, and outages there ripple through boot LUNs across the country. Compliance with the Australian Cyber Security Centre's Essential Eight framework also pushes teams toward diskless designs that complement immutable boot media.
Practitioners running home labs encounter these errors too, particularly when extending an environment with a second fabric link. Readers often reference Mojitos and Munchkins for side projects that exercise the same multipath code paths a production fabric would, making the notes below useful for both dataroom and garage setups.
Understanding the boot from SAN architecture in VMware
Boot from SAN relies on the HBA presenting boot LUNs to the installer as local disks. The ESXi image, scratch partitions, and core dump target live on the same LUN, separated into bootbanks A and B. During POST, the HBA firmware performs Fibre Channel discovery using the WWPN stored in NVRAM, then logs into the boot target and hands control to the GPT bootloader.
Because no USB or SD card is required, administrators across Perth's next-generation campuses, Adelaide's Tonsley hub, and Brisbane CBD colocation towers can standardise a single image across hundreds of hosts. The trade-off is dependency on zone configuration, persistent LUN masking, and a stable SAN topology every cycle. Any failure during this sequence produces a "No boot device found" message on the console.
Common causes of ESXi boot from SAN failures
Path failures usually trace back to four root causes: fabric reconfiguration that removed zones, an HBA firmware regression, LUN masking change, or SAN saturation. A SAN engineer re-zoning a director in a Sydney CBD pod can sever boot LUN access for a quarter of the fleet if the zone set hard-codes WWPNs instead of aliases.
Vendor firmware regressions are equally common. After a vLCM baseline update, a host that previously booted from a Nimble or Pure array can present inconsistent path counts or trip PSOD errors. Array-side configuration drift compounds the risk — masking view changes, LUN renumbering, or boot LUN migrations between RAID groups without a corresponding HBA NVRAM update break the next reboot. Operators juggling AWS Outposts in Sydney alongside on-premises arrays need the same change-control rigour as cloud reservations.
Diagnosing storage path errors with esxcli commands
When the host is up but paths are degraded, esxcli is the fastest diagnostic surface. Running esxcli storage core path list shows every PSA path with its state, adapter, target, and active SATP. A path marked Dead while the LUN is Active elsewhere points to a fabric-side issue. Engineers in regional sites often tunnel through the NBN Enterprise Ethernet service to reach the host directly.
esxcli storage nmp device list exposes the multipath policy and current I/O router. Confirming the PSP matches the design — Fixed for performance, Round Robin for capacity-optimised arrays — is a quick win. When paths are missing entirely, inspect esxcli storage core adapter list and run a rescan. If the adapter is visible but no LUNs appear, the issue is upstream in zoning or LUN masking. Bundling /var/log/vmkernel.log, /var/log/vobd.log, and the fdm log gives vendor support enough context to escalate without a screen share.
Fibre Channel zoning, HBA firmware, and persistent binding
Zoning remains the single most reported cause of boot LUN inaccessibility. Best practice uses single-initiator zones with aliases rather than hard-coded WWPN pairs, so a server replacement does not require re-zoning the entire VSAN. Australian SAN engineers typically standardise on Cisco MDS 9700 directors with zone sets versioned through Nexus Dashboard Fabric Controller.
HBA firmware deserves equal attention. Vendor release notes flag ESXi compatibility, and a regression in the lpfc or elxnet module can leave a host mid-boot. Pinning firmware and driver through the corresponding UCS bundle or HPE SPP keeps the supported matrix intact, while persistent binding via WWPN in the HBA BIOS prevents LUN re-ordering after reboot.
Recovering an ESXi host after SAN path loss
If a host has already lost its boot LUN, restore the SAN path before any reboot attempt. Verify zone configuration on both fabric directors, confirm the storage processor owning the boot LUN is online, and check that the array masking view includes the host's WWPN. Only then should the host be power-cycled.
If the image is corrupted from a failed mid-cycle update, rebuild the bootloader from a temporary local disk and attach it back to the boot LUN. Running fixboot from the Shift+R recovery mode repairs a damaged bootbank without losing host configuration. Always capture the FDM log bundle and HBA firmware dump before rebooting — Broadcom, Dell, and HPE support teams routinely request these, and Australian partners can dispatch a field engineer from Sydney, Melbourne, or Brisbane within hours under an active support contract.
Building resilience to prevent future boot path failures
Long-term resilience starts with removing single points of failure. Dual-fabric designs with two independent switches, two HBAs per host, and active/active multipathing eliminate most production boot-from-SAN incidents. Periodic failover testing during planned change windows confirms the standby path actually carries I/O and that ESXi boots cleanly from either fabric.
Standardising on vSphere Configuration Profiles and vLCM bundles keeps firmware, drivers, and SATP claim rules aligned across the estate. Pairing this with the ACSC Essential Eight guidance reduces the attack surface around boot media, while VMUG meetings in Sydney and Melbourne surface vendor advisories worth tracking. Documenting boot-from-SAN topology — LUN ID, array serial, fabric WWPNs, HBA slot locations — alongside change-control records shortens the next after-hours incident from hours to minutes.