ESXi存储故障排查实战：LSI 9211-8i HBA卡周期性Reset循环的完整解决方案

发布于 3 小时前  9 次阅读

ESXi存储故障排查实战：LSI 9211-8i HBA卡周期性Reset循环的完整解决方案

问题背景

我的ESXi 6.7主机上挂了三块SSD（2块WD Green + 1块Kingston SA400S3），全部连接在同一个HBA卡vmhba4上。这张卡是LSI 9240-8i cross-flash到9211-8i IT模式的，运行固件P15。

最近在持续写入负载下，系统出现了严重的延迟和SCSI命令失败，具体表现为：

  • vmkfstools创建eager-zero VMDK时卡在D状态（不可中断睡眠）
  • kill -9完全无效
  • vmkernel.log里疯狂刷mpt2sas0: _base_fault_reset_work: hard reset: success
  • 三块盘在同一5毫秒窗口内同时失去VMFS reservation

关键发现：找到了正确的复现方法

测试工具选型的坑

一开始我用dd试图复现故障：

dd if=/dev/zero of=/vmfs/volumes/SSD_450G/test.dat bs=1M count=10000 oflag=direct,conv=fsync

结果：完全无法复现。dd在ESXi BusyBox Shell里写入几秒钟就"完成"了，esxtop完全看不到DAVG波动。后来意识到，ESXi Shell层的I/O路径可能与vmkernel实际存储调度是分离的，dd的数据并未真正持续冲击物理盘。

正确的工具：vmkfstools

真正能复现故障的命令是：

time vmkfstools -c 20G -d eagerzeroedthick /vmfs/volumes/<datastore>/perf_test.vmdk

这个命令直接对接VMFS/vmkernel存储栈，会强制写入每个块，是复现这类存储故障的标准方法。

测试完清理：

vmkfstools -U /vmfs/volumes/<datastore>/perf_test.vmdk

故障复现的完整证据链

第一次复现（WD Green T1盘）

执行vmkfstools -c 20G写入T1期间，esxtop实时捕获到：

T1: QUED=21, %USD=65, DAVG=222.37ms, GAVG=341.79ms, QAVG=71842.66ms

QAVG接近72秒！ 同时T2盘也出现41.95ms的异常延迟（背景抖动），而Kingston T0此时完全空闲。

vmkernel.log同期出现：

mpt2sas_scsih_issue_tm: timeout
attempting task abort!
HBX: Reading HB ... failed: Reservation Lost
Long VMFS rsv time

I/O延迟从5.96ms飙升到3.09秒，随后逐步回落到610ms→120ms→24ms→12ms。

第二次复现（Kingston SSD，关键验证）

有人质疑"只测WD Green就判定是HBA问题"——这个质疑是对的。于是我补测了Kingston（不同厂商、不同主控）。

结果：

  • Kingston同样出现losing reservation
  • 日志出现mpt2sas0: _base_fault_reset_work: hard reset: success（比Power-on Reset更严重）
  • Kingston和T2在同一秒内同时losing reservation

这证明了故障是vmhba4控制器整体触发，与盘的品牌无关。

第三轮：周期性故障循环（决定性证据）

连续观测到3轮几乎完全相同的故障循环，周期约22-23秒：

hard reset → (9s) → task abort attempt → (0.6s) → diag reset sent → (0.9s) → 
diag reset SUCCESS → (9s) → 下一轮hard reset

最严重的一次：三盘心跳同时超时

SSD_450G的VMFS reservation被held 7012毫秒（7秒），随后三个datastore的心跳在同一5毫秒窗口内（07:45:53.546~.551）全部超时。

这是最强的一条证据：vmhba4故障发作时会波及其下挂载的全部设备，与盘的品牌/型号/主控无关。

根因分析：固件/驱动版本不匹配

当前配置

  • 固件：P15 (15.00.00.00)
  • 驱动：mpt2sas 19.00.00.00.2vmw
  • 芯片：LSI2008 (PCI ID 1000:0072)

问题所在

社区经验明确指出：LSI的mpt2sas驱动和固件必须配对使用，版本号应该对齐。我的配置是驱动比固件新4个大版本，这是典型的版本不匹配。

社区验证的稳定版本

根据ServeTheHome论坛和GitHub社区的反馈：

  • P16（FreeBSD/CentOS 6）或P19（Solaris/较新Linux） 是被广泛推荐的稳定版本
  • P20固件在多个平台被确认有严重bug（特别是SSD的CRC错误和读取速度崩溃），应该避开
  • P15固件应该配P15驱动，P19固件应该配P19驱动

参考资料：

解决方案：升级到P19固件+P19驱动

为什么选P19而不是P20

  • P20在2014-2015年被多个社区确认有严重bug
  • P19是被Solaris、Linux社区广泛推荐的最后一个稳定版本
  • 即使Broadcom后来重发了P20.00.02.00和P20.00.04.00，社区仍然倾向于P19

关键挑战：Cross-flash卡的特殊处理

我的卡是9240-8i刷成9211-8i IT模式，不是原厂9211-8i，这带来了额外的风险：

  1. SAS地址已经被改过（从9240原厂改成了9211的地址空间）
  2. 刷写失败或断电会导致卡变砖
  3. 必须用特殊工具绕过厂商校验（Mfg Page 2校验）

刷写步骤（7个阶段）

阶段0：准备USB启动盘

  1. 格式化USB盘为FAT32
  2. 创建EFI启动目录结构： 
    USB:/
├── EFI/
│   └── BOOT/
│       └── BOOTX64.EFI  (UEFI Shell v1启动文件)
├── 2118it_p7.bin       (P7过渡固件)
├── 2118it.bin          (P19最终固件)
├── mptsas2.rom         (SAS BIOS，可选)
├── sas2hax.efi         (专用刷写工具，cross-flash卡必用)
├── sas2flash_p19.efi   (P19官方工具)
└── sas2flash.efi       (P20官方工具，用于验证)

所有固件和工具可以从GitHub社区仓库获取：
https://github.com/lrq3000/lsi_sas_hba_crossflash_guide

阶段1：备份SAS地址（最关键）

进入UEFI Shell后：

fs0:
sas2flash.efi -listall
sas2flash.efi -c 0 -list

手动抄写SAS Address到纸上或手机拍照（例如：500605b123456789）。这个地址丢失后无法通过任何软件方法恢复。

阶段2：刷P19固件（直接升级）

注意：P15→P19可以直接升级，不需要P7过渡步骤。 P7过渡仅适用于P7以下的古老固件。

sas2hax.efi -o -f 2118it.bin

如果报错"Mfg Page 2 Mismatch"是正常的，sas2hax.efi会自动绕过。只要最后显示"Firmware Flash Successful"就是成功。

断电重启（关键！必须硬重启才能加载新固件）：

  1. 输入reset或直接按主机电源键关机
  2. 等待10秒
  3. 再次开机并进入UEFI Shell

阶段3：验证P19固件已生效

fs0:
sas2flash.efi -listall

确认输出中显示：Firmware Version: 19.00.00.00

阶段4：检查SAS地址（通常不需要恢复）

sas2flash_p19.efi -o -f 2118it.bin

如果报错，尝试用sas2hax.efi -o -f 2118it.bin（用绕过版本）。

断电重启（等待10秒）。

sas2flash_p19.efi -o -f 2118it.bin

如果报错，尝试用sas2hax.efi -o -f 2118it.bin（用绕过版本）。

断电重启（等待10秒）。

阶段5：检查并恢复SAS地址（如果需要）

先检查地址是否还在：

fs0:
sas2flash_p19.efi -listall

查看输出中的SAS Address字段：

  • 如果显示你在阶段1备份的地址 → 跳过此步骤，地址完好
  • 如果显示000000000000或其他错误值 → 需要恢复

仅当地址丢失时才执行恢复：

sas2flash_p19.efi -o -sasadd 500605b123456789
# 替换成你在阶段1备份的真实地址

验证：

sas2flash_p19.efi -c 0 -list
# 确认SAS Address显示为你备份的那个地址

说明： -o -f 固件升级通常不会擦除SAS地址，但作为防御性操作仍建议检查。

阶段6：刷BIOS ROM（可选）

如果需要从HBA启动系统：

sas2flash_p19.efi -o -b mptsas2.rom

如果不需要HBA BIOS（推荐，减少启动时间）：

sas2flash_p19.efi -o -e 5

⚠️ 关键警告：绝对不要使用 -e 7！

  • -e 5 = 仅擦除BIOS/Option ROM（安全）
  • -e 6 = 擦除所有数据但保留制造区（会丢固件，需重刷）
  • -e 7 = 擦除整个Flash包括SAS地址（彻底变砖）

阶段7：最终验证

fs0:
sas2flash.efi -listall

检查：

  • Firmware Version: 19.00.00.00
  • SAS Address: 你备份的那个地址

安装ESXi驱动

刷完固件回到ESXi后，驱动也必须更新到19.00版本。

驱动获取途径

  1. VMware官方（需要免费账号）

  2. HPE vibsdepot镜像站（公开可访问）

  3. Lenovo OEM驱动

安装步骤

# SSH登录ESXi主机

# 上传VIB到/tmp（用WinSCP或scp）

# 进入维护模式
esxcli system maintenanceMode set --enable true

# 安装新驱动
esxcli software vib install -v /tmp/scsi-mpt2sas-19.00.*.vib --no-sig-check

# 重启后验证驱动版本
vmkload_mod -s vmhba4 | grep Version
# 应该显示 19.00.xx.xx

验收测试

测试1：单盘eager-zero

vmkfstools -c 20G -d eagerzeroedthick /vmfs/volumes/SSD_450G/p19_test1.vmdk

同时在另一个SSH窗口监控：

tail -f /var/log/vmkernel.log | grep -iE "reset|abort"

测试2：三盘并发

vmkfstools -c 15G -d eagerzeroedthick /vmfs/volumes/SSD_450G/p19_test_a.vmdk &
vmkfstools -c 15G -d eagerzeroedthick /vmfs/volumes/SSD_930G_1/p19_test_b.vmdk &
vmkfstools -c 15G -d eagerzeroedthick /vmfs/volumes/SSD_930G_2/p19_test_c.vmdk &
wait

成功标准

  • ✅ 所有vmkfstools正常完成，不卡在D状态
  • ✅ vmkernel.log里没有"mpt2sas0: _base_fault_reset_work"
  • ✅ esxtop显示DAVG峰值<50ms，无72秒级别QAVG

关键注意事项

  1. 每次刷写后必须硬重启（断电10秒再开机），软重启不会加载新固件
  2. SAS地址丢失后无法通过任何软件方法恢复，只能重新生成一个（可能导致VMFS识别问题）
  3. 绝对不要在刷写过程中断电或强制重启
  4. 不要跳过P7直接刷P19，可能导致NVDATA损坏
  5. Cross-flash卡禁止刷回9240固件，只能在9211 IT/IR模式之间切换

失败回退方案

如果刷坏了（卡无法识别）

  1. 不要慌张反复刷，先断电10分钟让卡完全放电
  2. 重新进入UEFI Shell，尝试sas2flash.efi -listall
  3. 如果能看到卡但显示错误固件版本 → 用sas2hax.efi -o -f 2118it_p7.bin重刷P7
  4. 如果完全看不到卡 → 需要用Linux下的lsirec工具低级恢复

如果P19后仍然出现reset循环

  1. 确认驱动已经更新到19.00
  2. 如果还不行，问题可能不在固件 → 考虑物理层面（线缆/供电/PCIe槽位/卡本体硬件故障）
  3. 可以尝试回退到P16（社区另一个稳定版本）

经验教训

1. 用对测试工具

在ESXi环境下复现存储故障，不能用dd，要用vmkfstools：

vmkfstools -c 20G -d eagerzeroedthick /vmfs/volumes/<datastore>/test.vmdk

2. 多厂商验证

不要只测一个品牌的盘就下结论。我测了WD Green和Kingston两个不同厂商的SSD，才确认问题在HBA而不是盘本身。

3. 固件/驱动版本必须配对

LSI HBA的固件和驱动版本号应该对齐。驱动比固件新4个大版本是明确的配置错误。

4. Cross-flash卡的特殊风险

9240-8i刷成9211-8i的卡，刷固件时：

  • 必须用sas2hax.efi绕过厂商校验
  • 必须备份并恢复SAS地址
  • 必须先刷P7再刷P19，不能跳过

5. 社区资源很重要

Broadcom/LSI官网对旧版本固件的支持很差，GitHub社区仓库和ServeTheHome论坛提供了宝贵的固件包和经验。

参考资料

总结

这次故障排查从怀疑盘的问题，到确认是HBA控制器的固件/驱动版本不匹配，经历了：

  1. 找到正确的复现方法（vmkfstools而不是dd）
  2. 多厂商验证排除盘本身的问题
  3. 捕获周期性reset循环的完整时序
  4. 通过社区资源找到固件/驱动版本匹配的要求
  5. 针对cross-flash卡制定安全的升级方案
  6. 成功升级到P19固件+P19驱动
  7. 通过压力测试验证故障已解决

整个过程中，最关键的是正确的测试方法和社区经验的参考。如果你也遇到LSI HBA卡在ESXi下的周期性reset问题，希望这篇文章能帮到你。

或许明日太阳西下倦鸟已归时