vmkernel.log displays frequent H:0xc (Soft Error) SCSI status codes only on one path: vmkernel: cpu48:2098390)NMP: nmp_ThrottleLogForDevice:3893: Cmd 0xa0 (0x45d9ae0b35c0, 0) to dev "naa.xxx" on path "vmhba64:C0:T0:L0" Failed:
vmkernel: cpu48:2098390)NMP: nmp_ThrottleLogForDevice:3898: H:0xc D:0x0 P:0x0 . Act:N ONE. cmdId.initiator=0x45392079b908 CmdSN 0x0localcli storage san fc stats get -a vmhba64
...
Link Failure Count: 2100.
...ESXi
The issue occurs when a specific datastore's Active (Preferred) path is assigned to an HBA experiencing physical link instability (e.g., faulty SFP or fiber cable). In an ALUA environment, the ESXi host attempts to send I/O via the preferred "Active" path. If that HBA (e.g., vmhba64) has hardware failures, the datastore assigned to it will suffer timeouts. Other datastores whose preferred "Active" paths are on a healthy HBA (e.g., vmhba2) will appear normal as they only use the problematic HBA as a standby "Active Unoptimized" path Troubleshooting Storage ALUA Identifying Storage Issues.
Using the command localcli storage nmp path list | egrep "Runtime Name:|Device:|Group State:", the following pattern identifies the imbalance:
Runtime Name: vmhba64:C0:T0:L2 Device: naa.xxx Group State: active <-- Preferred path is on unstable HBA
Runtime Name: vmhba2:C0:T0:L2 Device: naa.xxx Group State: active unoptimized <-- Standby path is on healthy HBANote: In this scenario, Device L2 will experience timeouts because its primary path is on vmhba64, which has physical link errors.
vmkernel.log or hardware management logs (e.g., IMM, iLO) for link resets or high error counts on a specific vmhba.Active path for the affected datastore: localcli storage nmp path list | egrep "Runtime Name:|Device:|Group State:"