服务器“小紫”就是紫屏，业内俗称PSOD（Purple Screen of Death），它主要出现在VMware ESXi虚拟化平台上，代表内核级致命错误唱完这首歌，这台宿主机上的所有虚拟机都会跟着遭殃，它和Windows蓝屏是表亲，但脾气更倔，经常出现在凌晨三点。
为什么会叫“小紫”呢？因为全世界的ESXi服务器在崩溃时都偏爱紫色背景，白字滚动，像是一封来自内核的告别信，每一位运维老手看到这抹紫色，心里都会咯噔一下，这期内容，咱们就替服务器“小紫”翻翻旧账，看看它到底会因为哪些事儿蹦出来吓人,以及遇到之后怎么把它请走。
服务器紫屏是什么原因：小紫不是无缘无故来的
服务器不会无缘无故“生气”，它的紫屏本质上是一次强制性的内核暂停，目的是在硬件彻底毁掉数据之前主动止损，行业共识认为,绝大多数紫屏都指向以下几个扎心的真相。
硬件层面的“隐疾”是最大嫌疑人
- 内存故障： 这是最常见的诱因，服务器内存颗粒虚焊、接触不良，或者某根内存条在高温下“中暑”，都会让CPU读到错乱的数据，早年间不少PC服务器标配的Reg ECC内存在长时间高负载下，照样会报“Uncorrected Memory Error”然后紫给你看。
- CPU过热或微码触发异常： 机房空调罢工，或者散热风扇被灰尘糊死，CPU温度飙升到警戒线后，ESXi的监控进程会发起最终裁决，虽然紫屏报错里不一定写“温度”两个字，但你去翻硬件日志，十有八九躺着一条“Thermal Trip”记录。
- HBA卡或RAID卡固件BUG： 硬盘背板上的扩展卡和ESXi的内置驱动不对付，在特定I/O压力下会触发“Device Error”或“NMI”错误，这个情况很隐蔽，因为硬盘本身没坏,换了阵列卡反而好了。
驱动和微码版本“打架”
这里重点说ESXi系统本身，由于ESXi的驱动模型是封闭的，它只认自己的官方VIB包，如果你用第三方工具强行塞进去一个兼容性列表（HCL）之外的新网卡驱动，或者服务器固件升级到一半被中断,下一次重启时小紫出现的概率会相当大。
vmkernel日志分区被写爆了
这是个容易被忽视的温床，VMware ESXi系统盘默认有一个log分区，如果配置了过多的syslog策略，或者因为告警风暴疯狂刷日志，这个分区一旦撑满，整个主机就可能陷入一种“想跑但跑不动”的状态，最终触发紫色恐慌，虽然这个原因占比不算特别高，但排查成本最低,值得先看。
ESXi紫屏怎么排查：先给服务器做个“尸检”
面对紫屏，瞎按重启键是最亏的操作，因为紫屏上的堆栈信息是唯一的破案线索，一旦断电重启,现场就没了。
第一步：抄下紫屏底部的关键代码
紫屏下方通常有一行像这样格式的文字：#1 PCPU: 0x0或PSOD： 0xXXXXXXXX，你可能看不懂，但别管，用手机拍清楚，如果不方便拍照，那就抄下来，后续去VMware KB库搜索时，这个代码就是你的“门牌号”。
第二步：把“遗书”从日志里捞出来
如果主机还能通过IPMI或iLO远程访问（哪怕屏幕已经紫了，基板管理控制器通常还活着）,抓紧时间进去导出两份文件：
- 存放在存储分区内的
vmkernel.log和vcpu-0.log。 - 通过ESXi Shell执行
vsish -e get /hardware/memory/等命令获取硬件视图信息（如果系统还没完全锁死的话）。
这张日志就是小紫醒来前的最后半小时日记，里边会记录是哪个设备先报了错,又是哪个驱动做了最后的垂死挣扎。
第三步：对照VMware的HCL（兼容性列表）
硬件兼容性列表是揪出“内鬼”的照妖镜。 你可以登录VMware官网的Compatibility Guide，把你服务器的型号、BIOS版本、整列卡驱动版本输进去，看看有没有踩坑记录，不少“无头尸案”的原因就是主板BIOS微码太新或太旧，和ESXi的内核不对齐,导致虚拟化指令集在崩溃边缘反复试探。
服务器紫屏怎么解决：三步稳住阵脚
排查完原因，接下来就是实操环节，这里给几个成熟老运维总结出的路子，按顺序来,别跳。
- 物理层的“绝地求生”：如果紫屏上明确写着内存相关的物理地址，别犹豫，直接关机断电，拔掉非关键内存条，把CPU的散热硅脂重新涂一遍，顺便清掉机箱里的积灰，然后最小化配置开机（只保留一根内存、一块系统盘、一块网卡），如果能顺利起来，再把部件一个一个加回去,故障点就锁定了。
- 对ESXi系统层执行“检修”：如果在最小化配置下依然紫屏，说明系统内核或引导文件本身出了问题，用相同的ESXi版本镜像启动，进入“Shift+O”高级引导界面，尝试添加
noAutoRelaod等参数跳过自动加载，或者直接重装ESXi，然后使用vim-cmd恢复虚拟机注册信息，多数情况下，重装系统层能救回宿主机，但我们依然要通过dcui或esxcli system version核对自己的镜像版本,避免重复踩坑。 - 升级固件而不是降级：很多运维的习惯是遇到问题先降级驱动，其实在2026年的今天，新硬件的微码往往已经修复了旧版CPU空闲时的供电bug，正确的做法是先刷新BIOS和网卡固件到官网推荐版本，再从VMware官网下载对应的“Offline Bundle”补丁包，通过
esxcli software profile update -d /tmp/xxx.zip命令离线升级，记住一个原则：能用官方补丁解决的问题，不要抓第三方半路出家的驱动。
现场没有日志怎么复盘
实在没抓到日志，也别慌，多台服务器同时紫屏，先看是不是机房供电有瞬时波动；单台反复紫屏，且集中在每天后半夜，去看看是不是有定时备份任务卡死导致磁盘I/O爆满，这种情况下，调整任务执行窗口往往就能把小紫“哄睡着”。
关于服务器紫屏频率的争议：别总让ESXi背锅
很多新手一看到ESXi紫屏就骂VMware辣鸡，但业内专家指出，超过一半的紫屏事件，起因在物理层被你忽略的监控项里：比如IPMI里长期没有打开的“内存纠正错误计数”，或者硬盘背板的SGPIO线松了，导致硬盘虽然没掉线,但SAS链路一直处于半睡半醒的降速状态。
另外有一种小众但典型的情况值得单独拎出来说数据中心供电线路中的零线（N线）电压漂移，这会导致服务器电源模块在高压端产生毛刺，硬件上看一切正常，但CPU在特定运算频率下会错位，这种紫屏的重现性极差，经常带着“WATCHDOG”字样出现，遇到这类灵异事件，建议给服务器机柜加装一个带滤波功能的PDU（电源分配单元）。
服务器“紫蓝”一家人：紫屏和蓝屏的区别
为了让更多刚接手服务器运维的朋友不搞混,这里做一个速查表：
| 对比项 | 服务器紫屏（PSOD） | 普通电脑蓝屏（BSOD） |
|---|---|---|
| 常见场景 | 多出现在VMware ESXi物理机 | Windows桌面或Windows Server |
| 致命程度 | 宿主机会挂，影响其上的N台虚拟机 | 只影响本机，服务中断范围可控 |
| 报错含义 | 内核态灾难，CPU暂停 | 系统调用异常，驱动或内存错误 |
| 恢复方式 | 重启宿主机并自动拉起虚拟机 | 重启电脑，修复驱动 |
它们俩本质都是内核的“窒息”，但小紫在数据中心里的分量，比蓝屏重得多毕竟每台ESXi上面都蹲着十几个业务老爷,你懂的。
写在最后： 无论小紫来得多么突然，硬件日志里的每一个神秘数字都算数，ESXi的每一个报错都不会白给，它只是提醒你：别总顾着盯监控大屏，偶尔也该弯腰摸摸机柜里的灰,和躲在角落的那根内存条说声抱歉。
关于服务器紫屏的常见问答
问：服务器紫屏后重启机器会自动起来吗？需要手动干预吗？
答：如果VMware的HA（高可用）功能配置得当，紫屏后ESXi主机会自动重启，并且HA会把虚拟机迁移到集群内其他健康主机上，但要注意，如果紫屏发生在存储栈上，重启后可能因为文件锁文件还没释放，导致虚拟机无法注册,依然需要登录vCenter手动抢占锁。
问：ESXi紫屏一定会导致数据丢失吗？
答：不一定，紫屏发生时，虚拟机文件（VMDK）是静止存在虚拟机磁盘文件里的，像一套写了一半的文件卡在那里，但绝大多数情况下数据本身是完整的，只要磁盘阵列没坏，重启后通过磁盘扫描或快照恢复，数据基本能找回来，怕的是那种因为内存条坏道导致的页面错误，可能改写文件系统元数据,这种情况需要做全量文件系统校验。
问：紫屏和主机直接断电重启，哪个更伤服务器？
答：紫屏本身对物理硬件的冲击远小于直接断电，紫屏只是CPU停止了所有职业活动，类似于“突然发愣”，而断电是强行切断数据流通路，对磁盘读写的伤害更大，但从业务连贯性来看，断电只是当前服务不可用，紫屏则可能连同虚拟机的网络配置一起“锁死”,恢复时需要更长时间的人工介入。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/794611.html
