一次VMware ESXi主机紫屏宕机的排查与恢复实录

Tue, 20 Sep 2022 10:45:00 +0000

问题背景

某日凌晨 3:07，监控系统收到大量告警：生产环境中的一台 VMware ESXi 主机（HP ProLiant DL380 Gen10）突然下线，该主机上运行着 12 台虚拟机，包含 ERP 系统、OA 系统、文件服务器等关键业务系统。

早上 8:30 运维人员到岗后发现问题，此时所有虚拟机均已强制关机，现场查看物理服务器，显示屏上出现了 VMware 的紫屏（PSOD，Purple Screen of Death），服务器处于 hung 状态，需要硬重启才能恢复。

紫屏截图如下（关键信息记录）：

VMware ESXi 7.0.3 (VMkernel Release Build 20842708)
HP ProLiant DL380 Gen10
PCPU 12 locked up. Failed to ack TLB invalidate.
0x0000000000000000:[0x4180b22e54b3]...

故障现象

ESXi 主机出现紫屏，物理界面显示 PSOD
12 台虚拟机全部强制关机（非正常关闭）
监控系统在 3:07 开始收到该主机上所有 VM 的 ping 超时告警
vCenter 显示该主机为"未响应"状态

排查过程

第一步：硬重启并收集 PSOD 日志

在确认无法软恢复后，对物理服务器进行硬重启（ILO 远程管理界面操作）。

重启后，立即从 ESXi 主机提取紫屏 dump 文件。VMware ESXi 在 PSOD 时会自动将内存转储到本地磁盘。

SSH 连接到恢复后的 ESXi 主机：

# 查看 VMkernel 日志目录
ls /var/core/
# 输出：
# vmkernel-zdump.0
# vmkernel-zdump.1（如有多次）

# 查看最新的 vmkernel 日志
cat /var/log/vmkernel.log | tail -200

关键日志片段：

2022-09-20T03:07:12.145Z cpu12:2098226)ALERT: PCPU 12 locked up. Failed to ack TLB invalidate.
2022-09-20T03:07:12.145Z cpu12:2098226)Machine check: Bank 5, status 0xBE20000000800400
2022-09-20T03:07:12.145Z cpu12:2098226)Machine check: addr 0x0000000000000000
2022-09-20T03:07:12.146Z cpu12:2098226)NMI IPI: nmiHandler:Dump stack ...

出现了 Machine check 错误，Bank 5 对应内存控制器（Memory Controller），状态码 0xBE20000000800400 是典型的内存 ECC 错误（Uncorrected Error）。

第二步：分析机器检查错误（MCA）

Machine Check Architecture（MCA）是 x86 CPU 的硬件错误上报机制。Bank 5 在 Intel Xeon 平台通常对应内存通道或内存控制器。

状态码解析（0xBE20000000800400）：

Bit 63（VAL）= 1：有效的机器检查错误
Bit 61（UC）= 1：未修正的错误（Uncorrected Error），不可纠正
Bit 57（EN）= 1：已启用错误报告
错误类型：Memory Error

这说明是 内存硬件故障，且是不可纠正的 ECC 错误，直接触发了 CPU 的机器检查中断，进而导致 VMkernel 进入紫屏。

第三步：查看 HP ILO 日志

通过 HP ILO（服务器硬件管理接口）查看服务器事件日志：

1
2

Uncorrectable Memory Error on Slot 0, Bank 0 / Rank 0
DIMM Location: PROC 1 DIMM 3A

明确指出了 PROC 1 DIMM 3A 这根内存条出现了不可纠正的内存错误。

第四步：物理确认故障内存

关机后，打开服务器，按照 ILO 日志标注的位置找到 PROC 1 DIMM 3A 插槽，将这根内存条拔出，仔细检查：

外观：金手指有轻微氧化痕迹
运行时长：该服务器已运行约 4 年

将这根故障内存取出，其余内存条保持原位，重新上电。

第五步：内存 Memtest 验证

在正式上线前，使用 HPE Memory Diagnostics（通过 ILO 的 SPP 工具）对剩余内存条进行检测，结果全部通过。

重新启动 ESXi，主机正常进入系统，无报错。

解决方案

立即处理：

拔除故障内存条（PROC 1 DIMM 3A）
重启 ESXi 主机（此时总内存从 256GB 降至 240GB）
逐步启动各虚拟机，优先恢复 ERP、OA 等关键业务
向厂商提交内存条保修申请（服务器在保修期内）

虚拟机启动顺序：

1
2
3

# 通过 vCenter 或 esxcli 启动关键 VM
vim-cmd vmsvc/getallvms   # 列出所有 VM 及其 VMID
vim-cmd vmsvc/power.on <VMID>

恢复顺序：

ERP 数据库服务器（最高优先级）
ERP 应用服务器
OA 系统
文件服务器
其他非关键系统

全部 VM 在 9:20 前恢复运行，业务中断约 6 小时（3:07 - 9:20）。

根因分析

根本原因：服务器内存条（PROC 1 DIMM 3A）发生硬件故障，产生了不可纠正的 ECC 错误（Uncorrected ECC Error）。

ECC 内存通常能自动纠正单 bit 错误（CE，Correctable Error），但当出现双 bit 或更多 bit 错误时，无法纠正，只能上报给 CPU，CPU 触发 Machine Check Exception（MCE），VMkernel 捕获后生成 PSOD，保护虚拟机数据完整性。

该内存条已运行约 4 年，正处于硬件老化周期，发生故障属于正常硬件生命周期现象。

预防措施

1. 配置 ECC 内存可纠正错误（CE）告警

不等到 UCE 触发宕机，在 CE 频繁出现时就主动更换内存：

在 vCenter 中配置主机硬件健康告警，当 ECC CE 告警达到阈值时通知运维。

2. 接入服务器硬件监控

将 HP ILO / Dell iDRAC 等 BMC 接口接入监控系统（如 Prometheus + ipmi_exporter），实时采集内存、CPU、硬盘健康状态。

3. 制定虚拟机启动优先级 SOP

提前定义好各 VM 的重要程度和启动顺序，避免故障时手忙脚乱。

4. 定期巡检服务器硬件

每季度查看一次 ILO/iDRAC 的事件日志，对已有 CE 记录的内存条提前备件替换，不等到 UCE 再处理。

总结

服务器运维中，硬件故障是无法完全避免的，但可以通过完善的监控和告警机制，将影响降到最低。这次事故之所以造成 6 小时的业务中断，一方面是故障发生在凌晨，另一方面是在日常运维中没有关注到 ILO 里已经存在的 CE 告警（事后查看 ILO 日志，发现事故前两周就已经有 CE 告警，只是没有引起重视）。

要点： ECC 的可纠正错误（CE）是 UCE 和宕机的前兆，一旦出现 CE 告警就应计划更换内存，不要等到 UCE 发生时再被动处理。

ESXi on Zero Day Notes