先说结论一台海光HygonCPU的服务器装VMware ESXi 7.0的时候安装阶段一切正常第一次重启进系统却直接紫屏。这种“装得上、启动崩”的问题在非官方硬件列表HCL里的机器上非常典型。这篇记录从紫屏信息定位、根因分析到修复步骤完整复现一遍我当时的处理过程给同样在x86信创硬件上碰vSphere的朋友一条可复用的排查路径。先说明一下海光CPU本质上是x86架构所以VMware产品能安装但不代表它在这个CPU平台上被官方验证过。紫屏Purple Screen of DeathPSOD就是ESXi的VMkernel崩溃界面功能和Windows的蓝屏差不多一旦出现整个Hypervisor停摆上面所有虚拟机全部断电。所以遇到紫屏重点不是“能不能重启”而是搞清楚VMkernel到底死在了哪里以及为什么死在这个CPU上。1. 紫屏现场看懂PSOD上的关键信息1.1 紫屏信息怎么读ESXi的紫屏界面看起来很吓人满屏十六进制、寄存器dump、一堆CPU堆栈但其实真正有用的信息就集中在最上面几行。PSOD顶部通常是一个类似这样的报错段WARNING: Purple screen exception: 0x0N Exception 14 in world ... vmkernel module backtrace: ... BlueScreen: 0x4106ac...这里需要抓住的几个信息是异常类型Exception 14是Page FaultException 6是Invalid OpcodeException 18是Machine Check。不同异常类型指向的方向完全不同。触发位置所在模块比如vmklinux、vmw_ahci、pvscsi等如果是VMkernel模块崩溃一般会显示模块名和偏移地址这能直接指向是不是驱动问题。世界ID和CPU编号可以看到是哪个vCPU在什么world里崩溃的。栈顶地址配合VMware的符号服务器可以解析出具体函数名不过这一步普通人用不到。我当时抓到的紫屏报错信息里反复出现MCE相关内容并且CPU 0和CPU 1的寄存器dump都有异常状态。这就让我把排查重心放在了CPU微码和硬件feature检测上而不是先去翻驱动。1.2 第一时间该做的三件事遇到紫屏我强烈建议在机器复位前先做三件事这三件事每次都能大幅缩短定位时间第一件事是拍照。用手机把整个屏幕拍清晰尤其拍下顶部报错段和中间Backtrace段。重启之后日志不会默认落盘如果没配置转储服务器内存里那点线索会全部丢掉。第二件事是检查启动介质。如果ESXi装在U盘或SD卡上紫屏后重启经常出现根文件系统只读或少量文件损坏这会造成后续问题排查时误判。建议准备一个备用启动盘。第三件事是随机应变做交叉对比。如果机器支持在BIOS里临时禁用掉一半CPU核心或者换成单路连续做几次启动测试看紫屏是否跟CPU核心数相关。这个动作能很快区分是CPU微架构层面的兼容问题还是软件层面的调度问题。记住紫屏不是“死给你看”而是“想告诉你它死前看到了什么”。信息抓取越及时后面定位越省力。2. 根因判断海光CPU和ESXi之间到底哪里不对付2.1 不在HCL里的硬件问题只能自己扛VMware对硬件有一套严格的兼容性认证体系官方支持的CPU、主板、存储控制器、网卡都会列在兼容性指南里只有被列入HCL的硬件组合才算是“官方支持”。海光CPU目前并不在VMware兼容性列表里这意味着vSphere可以在它上面运行但一旦出问题VMware官方支持大概率会以“非兼容配置”为由拒绝介入。所以在这个平台上做虚拟化所有排查都要靠社区案例和自己的技术能力支撑心态上需要先接受这一点。这不是说不能用于生产而是要有预案、有快速回退手段并且对紫屏类问题有一套自己的定位方法。2.2 CPU微码与虚拟化特性检测不匹配海光处理器在指令集层面上兼容x86但它在微架构细节上与AMD的EPYC并不完全相同。ESXi启动阶段有一个CPU特性枚举和微码加载的过程VMkernel会向CPU索取CPUID信息比对功能位再决定启用哪些内核机制。如果某些feature位返回的值和VMware预期不一致VMkernel可能走进一个没有准备好的分支触发非法指令异常或机器检查异常最终表现为紫屏。我当时遇到的机器检查MCE类崩溃最常见的原因之一就是ESXi尝试加载自己的CPU微码补丁但对应的CPU型号在VMware的微码表里不存在匹配项。加载失败之后CPU进入了一种不确定状态任何一个敏感指令都可能触发异常。2.3 主板固件和ACPI表也是重要变量CPU微码只是其中一个变数主板固件BIOS/UEFI对ESXi的兼容性影响同样巨大。AMI和Insyde的固件在一些国产主板上会根据销售区域或者定制需求修改ACPI表、调整PCIe枚举顺序这会让ESXi在探测设备时产生偏差。紫屏如果集中在PCI device扫描阶段大概率就是ACPI或PCIe配置空间的问题。所以修这个问题的整体思路就是先看微码再看电源管理再看虚拟化扩展最后才考虑驱动和存储控制器。顺序不能反否则容易被表象带到沟里去。3. 修复实操从BIOS到ESXi引导选项到版本升级3.1 升级BIOS与关闭节能状态第一刀先给主板BIOS升级到最新版。海光平台的固件更新迭代很快新固件通常会把CPU微码表、ACPI表、PCIe枚举问题一并修掉。当时我手里这颗CPU的服务器出厂固件是2022年中的版本升级到2023年末的版本后紫屏频率明显下降。紧接着在BIOS里关闭几个电源管理项Power Management - C6 State - Disabled CPU Enhanced Halt (C1E) - Disabled SVM Mode - Enabled关闭C6和C1E的目的是减少CPU在深度睡眠状态与唤醒状态之间的切换。ESXi本身对C-state管理有自己的逻辑但在非认可平台上C6深度睡眠的进入/退出偶尔会踩到微码实现的边缘情况造成MCE。当时我关闭这两个选项之后紫屏从“每次必现”变成“偶尔才现”这让我确认方向是对的。SVMSecure Virtual Machine即AMD的虚拟化扩展必须保持开启否则ESXi虚拟机连创建都跑不动。如果为了测试开了又关、关了又开记得在同一配置下至少做三轮重启验证。3.2 关掉Microcode更新选项绕开紫屏触发点这一步是整个修复过程中最关键的一步也是我踩了几天坑才找到的突破口。ESXi在启动早期会调用cpu_microcode模块给CPU刷一遍微码。问题在于海光CPU的微码patch数据并未完整出现在VMware的微码库中ESXi刷写失败后并不会停下来但CPU内部状态已经受影响后续执行任何复杂指令都可能触发MCE。现象就是安装没问题第一次启动没多久就紫屏。针对这个情况我在BIOS里找到了一项“CPU Microcode Load”或“Microcode Patch Enable”的选项把它改为Disabled。这样ESXi启动时就不会试图继续打补丁CPU直接使用出厂固件里烧录的微码运行反而稳定了。注意关闭主板的微码自动加载可能会让CPU错过部分安全更新只适合在排查定位阶段使用。如果后续确认关掉它才能稳定运行建议先咨询整机厂商有没有包含已验证微码的新版固件不能为了一时稳定放弃安全修复。这台机器关闭Microcode Load之后连续重启紫屏没有再出现。当时我把系统稳定运行24小时作为判断节点过了这个时间基本可以认同该方案有效。3.3 用引导参数排除IOMMU的干扰还有一个值得一提的参数。海光平台的高速IO设备经常挂在IOMMU后面而ESXi对IOMMU的默认处理是基于AMD IOMMU驱动的。如果这个驱动在检测设备时没有识别到预期的BDFBus Device Function结构会直接panic。这种情况下的紫屏通常出现在PCIe设备初始化阶段和MCE的表现并不一样。定位方法是在ESXi引导控制台停留时按下ShiftO7.0/8.0版本都是这个快捷键会显示一条引导选项命令可以在里面临时追加参数noIOMMU这个参数表示禁用IOMMU驱动绕过DMA重映射。它只对本次启动有效重启后不保留。如果加了noIOMMU之后紫屏不再出现就能锁定问题在PCIe设备与IOMMU的配合上。后续可以再逐一插拔PCIe设备来确定具体是哪张卡触发的。我测试过一次在插着某国产HBA卡时加了noIOMMU确实能稳定启动但拔掉卡后原样启动也没问题。这说明是设备侧对DMA重映射支持不完善导致与ESXi本身关系不大。生产环境遇到这种情况优先考虑更换兼容性更好的卡而不是长期关闭IOMMU。3.4 直接换新版本ESXi如果前面的微码和BIOS手段都不彻底最后一招是换ESXi版本。海光CPU基于的微架构在ESXi 8.0里得到了更多识别和适配新版本的内核在CPU feature检测上比7.0更宽容也补充了更多AMD平台的微码表。当时为了验证8.0是否更稳我在测试分区安装了一台ESXi 8.0 U1跑同样的负载和重启压力紫屏完全没发生。最终生产环境也是直接切到了ESXi 8.0彻底告别了紫屏。版本升级需要注意一个细节不能跨版本直跳先从7.0 U3升到7.0 U3 latest再从7.0跨到8.0步骤尽量不要省。ESXi升级本身的失败处理可以参考VMware官方Upgrade Path文档。4. 验证稳定性与后续监测手段4.1 长时间压力测试怎么做修完之后不能直接认为自己“修好了”必须做一轮持续验证。我在64GB内存的测试机上开了8台Linux虚拟机每台各分配2个vCPU和2GB内存再逐台执行下面这样的压力任务stress-ng --cpu 4 --vm 2 --vm-bytes 768M --timeout 3600s同时让ESXi主机的CPU负载长期保持在80%左右持续跑满24小时。这能充分抬高CPU的P-state切换频率、内存控制器负载和SVM嵌套页表压力是比较严谨的功能性回归。压力测试期间如果再次出现紫屏需要立刻检查系统在崩溃前有没有通过事件日志留下记录。如果又出现了MCE相关信息就要回头确认BIOS关闭Microcode Load选项是否在CMOS复位后失效。4.2 日志与传感器监测验证期我会同时监听两个层面的日志ESXi自身的日志和IPMI传感器日志。ESXi日志查看比较常用的是esxcli命令esxcli system syslog log get options tail -f /var/log/vmkernel.logvmkernel.log里如果出现mce、mca、machine check等关键字说明问题还在只是触发的频率变低了。传感器层面则可以通过ipmitool读取ipmitool sel elist ipmitool sensor list | grep -E CPU|Temp|Power当时我在监控日志里看到一个规律紫屏前几分钟CPU的Tctl温度会快速飙到85度以上接着MCE产生。这就不仅是微码兼容问题还叠加了散热瓶颈。更换散热硅脂并改善机箱风道后温度稳定在65度以下紫屏再也没复现。5. 常见问题排查速查与经验总结5.1 紫屏特征对照表紫屏特征可能原因处理方向Exception 18 MCECPU微码加载失败或MCE异常关闭BIOS微码加载、升级整机固件Exception 14 模块名带vmw_ahciSATA/RAID控制器驱动异常调整磁盘控制器模式改用直通或多路径初始化PCI设备阶段紫屏IOMMU或PCIe枚举异常引导参数加noIOMMU测试确认后换卡随机紫屏且发生在负载高峰电源管理或散热问题关闭C6/C1E检查散热和供电频繁发生在虚拟机启动时SVM/Nested虚拟化特性不匹配BIOS重建SVM设置升级ESXi版本这个表格并不是标准答案库而是给你一个筛选方向。真正定位时还是要结合紫屏第一行报错和现场截图来判断。5.2 我的几个实操心得第一个心得海光平台折腾VMware不要把时间花在“调无数个内核参数”上。参数只是临时的探针不是根本解法。我排查过程中试过maxVMs、mem.ScrubPeriod、tpsShrinkUtil这类千奇百怪的参数真正生效的核心还是固件版本、微码策略和ESXi版本这三件事。第二个心得BIOS里的“CPU Microcode Load”选项在不同主板上的名称差别很大有的叫“Microcode Patch”有的叫“CPU uCode Update”有的隐藏在“Advanced - CPU Configuration”里。如果怎么都找不到可以先升级BIOS再重新找新版固件的选项描述一般更直白。实在找不到就直接把ESXi引导选项加一行跳过CPU微码处理的参数不过这个参数在不同版本里写法不同不能在这里瞎给以你当前版本的官方引导选项文档为准。第三个心得如果公司有大量同型号海光服务器要部署vSphere先花两天时间做“单机完整验证”全部通过后再批量装。我在批量部署前验证了几轮把可复现的配置整理成一份checklist后续新开机器照着做基本都是半小时内完成装机再也没有遇到紫屏困扰。另外再提一句不是所有虚拟化负载都非得用VMware。如果团队的虚拟化重度依赖vCenter的高级功能那确实应该坚持把ESXi跑稳如果只是要把一堆服务容器化起来Hyper-V或者KVM会省心很多不必在HCL之外的硬件上硬磕。选择没有对错看业务需要什么。最后紫屏问题并不可怕它只是ESXi在用一种比较生硬的方式提示你这里有不匹配的地方请确认一下。拿着PSOD信息按“日志定位 - 固件更新 - 模块锁定 - 参数验证”的顺序来大多数问题都能找到出路。别在第一次崩溃后就重装系统那样大概率只会得到一台重复崩溃的主机。