4. ESXi主机紫屏与核心转储分析
紫屏（Purple Screen of Death，PSOD）是ESXi主机最严重的一类故障表现：VMkernel在检测到无法继续安全运行的致命错误时，主动停止调度并显示紫色诊断屏。与虚拟机蓝屏不同，PSOD意味着整台主机的虚拟化层已经不可信，其上所有虚拟机都会随之中断。诊断PSOD的核心思路不是“看屏幕”，而是把屏幕上的异常信息、vmkernel日志和核心转储三者串成一条证据链，最终定位到具体模块、具体调用栈和具体触发条件。
一、PSOD原因分类：先判断属于哪一类致命错误
PSOD的紫色屏幕顶部通常给出简短原因，例如 #PF Exception 14 in world xxxx:module、#GP Exception 13、NMI、Panic、Assert、Coscheduling 等。按根因性质，可归纳为以下几类：
- 硬件类：内存ECC不可纠正错误、CPU机器检查异常（MCA/MCE）、PCIe AER致命错误、主板/电源异常。典型特征是异常地址随机、涉及多个不同模块、伴随NMI。
- 驱动/固件类：网卡、HBA、RAID、GPU等驱动缺陷或固件不兼容。典型特征是崩溃点稳定落在同一驱动模块，且与特定I/O操作相关。
- VMkernel软件缺陷类：内核断言失败、锁竞争、内存管理异常。典型特征是调用栈稳定复现，升级补丁后消失。
- 资源耗尽类：world（世界/线程）数量耗尽、堆内存耗尽、文件描述符耗尽。典型特征是崩溃前日志出现大量资源告警。
- 配置/人为类：不兼容的VIB、错误的引导参数、第三方模块冲突。
分类的意义在于决定后续动作：硬件类优先更换部件并做内存/CPU诊断；驱动类优先升级驱动与固件；软件类优先打补丁；资源类优先调整配置与容量。
二、vmkernel日志解读：从屏幕到日志的对应关系
PSOD屏幕信息有限，完整证据在 /var/log/vmkernel.log 与 /var/crash/ 目录。崩溃瞬间，VMkernel会把关键信息刷入日志，常见字段包括：
2024-06-11T03:14:22.318Z cpu7:2097154)Panic: 14: Assert failed in module vmw_ahci
2024-06-11T03:14:22.319Z cpu7:2097154)Backtrace:
2024-06-11T03:14:22.319Z cpu7:2097154) [0x41801234] vmw_ahci+0x1234
2024-06-11T03:14:22.319Z cpu7:2097154) [0x41805678] vmkernel+0x5678
2024-06-11T03:14:22.320Z cpu7:2097154)Code: 0f 0b ...
2024-06-11T03:14:22.320Z cpu7:2097154)cr0=0x80010033 cr2=0x0 cr3=0x...
解读要点：world号（如2097154）用于在日志中追踪同一执行流；Backtrace给出调用栈，最上面的模块通常是崩溃点；cr2是页错误地址，若为0或异常值往往指向空指针或非法访问；Code是出错指令字节。把屏幕上的 Exception 14 与日志中的 #PF 对应起来，就能确认是页错误而非断言。
三、核心转储配置：让崩溃现场可被保存
默认情况下，ESXi的转储空间有限，PSOD后可能只保留部分信息。要完整分析，必须提前配置核心转储。常用方式有三种：
- 诊断分区转储：使用本地磁盘上的
vmkdump分区，容量通常较小，适合快速抓取。 - 网络转储（NetDump）：通过
esxcli system coredump network set指定转储服务器IP、端口和网卡，把转储文件发送到远端。 - 文件转储：将转储写入共享存储或本地大容量卷。
配置示例（网络转储）：
esxcli system coredump network set -i vmk0 -s 192.168.10.50 -p 6500
esxcli system coredump network set -e true
esxcli system coredump network get
配置后应验证：esxcli system coredump partition get 查看当前转储分区，esxcli system coredump file get 查看文件转储状态。转储文件通常为 *.dump 或 vmcore，可用 vmkdump 工具或 VMware 的 vmcore 分析工具解析。
四、崩溃根因定位：从转储到结论
拿到转储后，定位根因的流程是：先看转储头部的 Panic 原因和 Backtrace，再结合 vmkernel.log 中崩溃前30秒的日志，最后对照硬件事件（如iDRAC日志中的内存/PCIe错误）。若调用栈稳定指向同一驱动，优先怀疑驱动；若地址随机且伴随MCA，优先怀疑硬件；若断言来自VMkernel核心模块，则考虑补丁或配置。
实际排障中，建议把上述证据链固化为一张检查表：记录PSOD时间、屏幕原因、world号、Backtrace首行模块、cr2值、转储是否成功、硬件日志是否有MCA/ECC。多次崩溃时对比这些字段，若模块和地址高度一致，基本可锁定为驱动或软件缺陷；若每次不同且伴随硬件错误，则应优先处理硬件。
最后，PSOD分析不是孤立动作。定位到驱动或固件问题后，应同步检查同批次主机的驱动版本、固件版本和VIB清单，避免同类故障在其他主机上重复发生；定位到硬件问题后，应结合厂商诊断工具确认部件健康状态，再决定更换或降级运行。只有把“屏幕—日志—转储—分类—处置—验证”串成闭环，紫屏故障才真正从“不可解释的宕机”变成“可定位、可修复、可预防”的工程问题。