VM power-on may appear to hang (e.g., stall at ~88% progress in vCenter) immediately before the host reboots.
PCI Vendor ID 1077).vmkernel.log located at ESXi /var/run/log/ shows the device failing to recover after a PCIe reset, e.g.:WARNING: PCI: 743: Dev <SBDF> is unresponsive after resetPCIPassthru: 5852: <SBDF> :Reset for device failed with FailurePCI: 1404: Skipping device reset on <SBDF> because PCIe link to the device is downThese Marvell/QLogic FC adapters do not support Function Level Reset (FLR). By default, ESXi falls back to resetting such devices via a secondary bus (bridge) reset when the device is claimed for passthrough. On some platforms, this bridge reset is not handled cleanly by the device/platform, leaving the PCIe device unresponsive and, in this case, causing a host PSOD/reboot during passthrough device initialisation.
These adapters do support the D3D0 power-state reset method (D0 → D3hot → D0), which works reliably as an alternative to bridge reset.
Broadcom Engineering is aware of the issue and is working on a fix in an upcoming release
Configure ESXi to use the D3D0 reset method instead of the default bridge reset for the affected device IDs, via /etc/vmware/passthru.map.
esxcli hardware pci listvendorID and deviceID for all the Marvel/QLogic FC HBAs./etc/vmware/passthru.map and add entries for the affected devices1077 2281 d3d0 false1077 2261 d3d0 false
Vendor ID 1077 = Marvell/QLogic; device IDs listed are the confirmed affected 16/32/64Gb FC HBA models. If a different device ID is seen for the same adapter family based on esxcli command output from step 1, add it in the same <vendor> <device> d3d0 false format.)Persistence note: /etc/vmware/passthru.map is a sticky-bit configuration file — changes persist across reboots, but only if the host is shut down cleanly, or backup.sh 0 has run before the next reboot (it runs periodically on its own).
Verification:
esxcli hardware pci list