共计 6154 个字符，预计需要花费 16 分钟才能阅读完成。
这篇文章给大家介绍 ESXI 主机紫屏分析方法是什么，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
一：概述
相信 VMware 的工程师对紫屏不会陌生，紫屏死机（PSoDs，Purple Screen of Death）是发生在 ESXI 上的一种故障，类似于微软 Windows 操作系统的蓝屏。紫屏情况通常是由于硬件和软件故障导致的，比如软件 bug、CPU、内存泄露等原因。当发生紫屏故障时整个 ESXI 主机会突然崩溃，当紫屏故障发生后管理员能做的只有记录紫屏信息以及重启主机，也就是说 ESXI 主机上面的虚拟机将会受到影响；如果有 HA 机制的话则会迁移到其他可用的 ESXI 主机。
当发现 ESXI 主机出现紫屏现状时第一时间应该将紫屏的信息记录下来，简单的办法就是将当前的屏幕信息截图或者拍照下来，因为里面包括很多重要的信息；在里面可以显示和了解到 ESXI 版本和 build 号、异常类型、寄存器转储（register dump）、崩溃时每个 CPU 正在跑什么、回溯追踪（back-trace）、服务器运行时间、错误日志、内存硬件信息等。当将 ESXI 主机重启后，还可以通过 ESXI 主机的 /root 或者 //var/core/ 获取 vmkernel-zdump 文件，当发生紫屏后会有一个以 vmkernel-zdump 开头（命名）的文件，可以将该文件提交给 VMware 的技术支持帮助进行故障分析；同时也可以额借助通过 vmkdump 工具提取 VMkernel 日志信息、寻找与 PSoDs 有关的线索，从而判断 PSoDs 发生的原因。关于提取和识别 vmkernel-zdump 查阅官方 KB：https://kb.vmware.com/s/article/1006796?lang=zh_CN
二：理解紫屏信息
通过紫屏后屏幕信息都可以获取到很多关键信息，管理员可以快速的借助这些信息进行故障定位和排查。错误会显示在紫色诊断屏幕中。紫色诊断屏幕大致如下所示：
通过以上内容可以查看到几个关键信息
· 产品和内部版本：
VMware ESX Server [Releasebuild-3620759
紫色诊断屏幕中的此部分表示出错的产品和内部版本。在本示例中，产品是 ESXI，版本号是 3620759，也就是 ESXI 6.0 U2
· 错误消息：
PCPU 1 locked up.Failed to ack TLB invalidate
紫色诊断屏幕的此部分表示报告的错误消息。只能报告有限数量的错误消息。本文稍后会讨论这些错误消息。
· CPU 寄存器：
frame=0x3a37d98 ip=0x625e94 cr2=0x0 cr3=0x40c66000 cr4=0x16c
es=0xffffffff ds=0xffffffff fs=0xffffffff gs=0xffffffff
eax=0xffffffff ebx=0xffffffff ecx=0xffffffff edx=0xffffffff
ebp=0x3a37ef4 esi=0xffffffff edi=0xffffffff err=-1 eflags=0xffffffff
出错时，这些值存储在物理 CPU 寄存器中。这些寄存器中的信息千差万别，具体取决于出现的 VMkernel 错误
· 物理 CPU：
*0:1037/helper1-4 1:1107/vmm0:Fagi 2:1121/vmware-vm 3:1122/mks:Franc
紫色诊断屏幕的此部分表示 VMkernel 出错期间运行指令的物理 CPU。在本示例中，0 旁边的 * 表示发生故障时物理 CPU 0 正在运行操作。新版本 ESX 不再使用 *，而是使用前缀字母 CPU。例如，如果新版本 VMware ESX 同样出现上述错误，则同一行会显示为：
CPU0:1037/helper1-4 cpu1:1107/vmm0:Fagi cpu2:1121/vmware-vm cpu3:1122/mks:Franc。
紫色诊断屏幕的此部分还描述了出错时 CPU 上运行的环境（进程）。在上述示例中，用户环境正在运行 helper1-4。
注意：进程名称可能已截断。
· 堆栈跟踪：
0x3a37ef4:[0x625e94]Panic+0x17 stack: 0x833ab4, 0x3a37f10, 0x3a37f48
0x3a37f04:[0x625e94]Panic+0x17 stack: 0x833ab4, 0x1, 0x14a03a0
0x3a37f48:[0x64bfa4]TLBDoInvalidate+0x38f stack: 0x3a37f54, 0x40, 0x2
0x3a37f70:[0x66da4d]XMapForceFlush+0x64 stack: 0x0, 0x4d3a, 0x0
0x3a37fac:[0x652b8b]helpFunc+0x2d2 stack: 0x1, 0x14a4580, 0x0
0x3a37ffc:[0x750902]CpuSched_StartWorld+0x109 stack: 0x0, 0x0, 0x0
0x3a38000:[0x0]blk_dev+0xfd76461f stack: 0x0, 0x0, 0x0
堆栈表示出错时 VMkernel 正在执行的操作。在本示例中，VMkernel 正在尝试清除内存页表 (TLB)。此信息是一个重要工具，有助于通过评估出错时内核所执行的操作来诊断紫色屏幕错误。
· 正常运行时间：
VMK uptime: 7:05:43:45.014 TSC: 1751259712918392
此部分表示自上次启动以来服务器运行的时间。在本示例中，ESXI 主机已运行了 7 天 5 小时 43 分 45.014 秒。TSC 值是服务器启动之后经过的 CPU 时钟频率循环次数。
· 核心转储：
Starting coredump to disk Starting coredump to disk Dumping using slot 1 of 1…using slot 1 of 1… log
紫色诊断屏幕的此部分表示正复制到 vmkcore 分区的 VMkernel 内存内容。
三：通过错误信息定位故障
上面介绍了如何查看和理解紫屏的屏幕信息，其中比较关键的就是关于错误信息的字段，接下来我们可以通过紫色屏幕生成的 VMkernel 错误消息可用于确定问题原因。不过，产生的错误消息数是有限的。以下是已知的 VMkernel 错误消息列表。
l 类型：控制台警告
错误示例：COS Error: Oops
描述：ESX 主机出现故障并在出现服务控制台警告时显示紫色屏幕。与大多数紫色屏幕错误不同的是，该错误并非由 VMkernel 触发。相反，它由服务控制台触发，并发生在 Linux 级别。这些紫色屏幕错误包含来自 Linux 内核的其他信息。有关控制台警告的详细信息，请参见 Understanding an Oops purple diagnostic screen (1006802)。
l 类型：检测信号丢失
错误示例：Lost Heartbeat
描述：ESX VMkernel 和服务控制台 Linux 内核同时在 ESX 上运行。服务控制台 Linux 内核会运行一个称为 vmnixhbd 的进程，只要 VMkernel 能够分配和释放内存页，该进程便会向 VMkernel 发送检测信号。如果在 30 分钟超时时间之前未收到检测信号，VMkernel 会触发 COS 严重错误以及表明检测信号丢失的紫色诊断屏幕。有关检测信号丢失的详细信息，请参见 Understanding a Lost Heartbeat purple diagnostic screen (1009525)。
l 类型：断言
错误示例：ASSERT bora/vmkernel/main/pframe_int.h:527
描述：断言错误属于软件错误，因为它们都与程序所基于的假设条件有关。此类型的紫色屏幕错误主要是由软件错误导致的。有关断言错误消息的详细信息，请参见 Understanding ASSERT and NOT_IMPLEMENTED purple diagnostic screens (1019956)。
l 类型：未执行
错误示例：
NOT_IMPLEMENTED /build/mts/release/bora-84374/bora/vmkernel/main/util.c:83
描述：代码遇到超出设计处理范围的情形时会出现未执行错误消息。有关详细信息，请参见 Understanding ASSERT and NOT_IMPLEMENTED purple diagnostic screens (1019956)。
l 类型：转数已超出 / 可能出现死锁
错误示例：Spin count exceeded (iplLock) – possible deadlock
描述：线程尝试在代码关键部分执行时，VMware ESX 主机可能在紫色诊断屏幕上报告转数已超出且可能出现死锁。由于线程正尝试进入关键部分，因此，它需要执行自旋锁操作，以便先轮询互斥锁，然后再执行代码。线程在执行自旋锁操作期间会继续轮询互斥锁，但是，互斥锁轮询次数存在一定限制。有关转数已超出错误的详细信息，请参见 Understanding a Spin count exceeded purple diagnostic screen (1020105)。
l 类型：无法确认 TLB 是否失效
错误示例：PCPU 1 locked up.Failed to ack TLB invalidate.
描述：物理 CPU 在尝试清除内存页表时出现故障。有关详细信息，请参见 Understanding a Failed to ack TLB invalidate purple diagnostic screen (1020214)。
紫色诊断屏幕还会以异常的形式出现。异常处理程序是一种计算机硬件机制，旨在处理正常执行流（除零、页面错误等）发生变动的某些情形。该处理程序并无跟踪机制，因此您需要通过日志记录确定处理程序是否出现问题（或通过单步调试）。以下是常见异常列表：
l 类型：异常 13（一般保护错误）
错误示例：#GP Exception(13) in world 4130:helper13-0 @ 0x41803399e303
描述：在以下任一情况下都会出现一般保护错误（异常 13）：正在请求的页面不属于请求该页的程序（未映射到程序内存中），或者程序无权在页面上执行读取或写入操作。有关异常 13 或页面错误的详细信息，请参见 Understanding Exception 13 and Exception 14 purple diagnostic screen events (1020181)。
l 类型：异常 14（页面错误）
错误示例：#PF Exception type 14 in world 136:helper0-0 @ 0x4a8e6e
描述：正在请求的页面未成功加载到内存时出现页面错误（异常 14）。有关异常 14 或页面错误的详细信息，请参见 Understanding Exception 13 and Exception 14 purple diagnostic screen events (1020181)。
l 类型：异常 18（计算机检查异常）
错误示例：Machine Check Exception: Unable to continue
错误示例：Hardware (Machine) Error
描述：计算机检查异常 (MCE) 由硬件生成并通过主机进行报告。出现 MCE 事件时，请咨询您的硬件供应商。通过评估显示的信息，可以确定报告错误的单个组件。有关 MCE 的详细信息，请参见 Decoding Machine Check Exception (MCE) output after a purple screen error (1005184)。
四：分析同一主机的多个错误
同一 ESXI 主机上出可能现多个紫色诊断屏幕时，可以使用多个紫色诊断屏幕示例确定问题与硬件还是与软件有关。为此，请确定紫色诊断屏幕的以下部分是否存在一些模式：
l 错误消息和堆栈跟踪：
如果多个 vmkernel 错误中的错误消息和堆栈变化很大，则表明同一错误并不总是软件造成的。尽管不是十分确凿，但这很可能意味着硬件问题。
如果多个 vmkernel 中的错误消息和堆栈始终相同，则表明同一错误都是由软件造成的。尽管不是十分确凿，但这很可能意味着软件问题。有关出现的错误消息的详细信息，请参见上述特定错误消息部分。
l 物理 CPU：
如果多个 vmkernel 错误中的物理 CPU 值始终相同，则表明软件总是在同一个物理 CPU 上出现错误。尽管不是十分确凿，但这很可能意味着 CPU 问题。有关详细信息，请参见 KB1003560
l 环境：
如果多个 vmkernel 错误中的环境值始终相同，则表明 vmkernel 从同一环境接收指令时出现错误。尽管不是十分确凿，但这很可能意味着发送指令的环境可能触发了 VMkernel 错误。
五：异常列表参考
异常类型 0 #DE：除法错误（Divide Error）
异常类型 1 #DB：调试异常
异常类型 2 NMI：不可屏蔽中断
异常类型 3 #BP：断点异常
异常类型 4 #OF：溢出（INTO 指令）
异常类型 5 #BR：界限检查（BOUND 指令）
异常类型 6 #UD：Opcode 无效
异常类型 7 #NM：协处理器不可用
异常类型 8 #DF：双重故障
异常类型 10 #TS：TSS 无效
异常类型 11 #NP：分段不存在
异常类型 12 #SS：堆栈分段错误
异常类型 13 #GP：一般保护错误
异常类型 14 #PF：页面错误
异常类型 16 #MF：协处理器错误
异常类型 17 #AC：对齐检查
异常类型 18 #MC：计算机检查异常
异常类型 19 #XF：SIMD 浮点异常
异常类型 20-31：预留
异常类型 32-255：用户定义（时钟调度程序）
六：示例
在实际环境中遇到过以下提示的紫屏情况，通过屏幕中的信息可以获知以下几点信息，故障的 ESXI 主机是 esxi 6.0 U2(build 3620759)，该主机自上次开机来正常运行了 35:18:32:21 也就是 35 天 18 小时 32 分。
同时关于该紫屏的关键代码信息是 PF Exception 14 in world 33168:memMapKernal 根据该关键代码信息可以在 VMware 的 KB 库中查到以下
https://kb.vmware.com/s/article/1020181?lang=zh_CN#q=esxi%E7%B4%AB%E5%B1%8F
https://kb.vmware.com/s/article/2071752?lang=zh_CN#q=esxi%E7%B4%AB%E5%B1%8F
根据 KB 介绍，信息可能如下：
如果要请求的页面未成功载入内存，则会出现页面错误（异常 14）。存在正常状态和非正常状态两种页面错误：
正常状态页面错误会导致页面从交换内存载入物理内存。这样便允许程序在数据正确载入物理内存后继续执行。
如果页面未载入内存，并且操作系统无法将页面从交换内存载入物理内存，则会出现非正常状态页面错误。
再配合后面的 MemMapKernal 字段大概可以判断本次的紫屏想象是由 ESXI 主机中的内存异常导致的，可能是内存载入或内存溢出，也有可能是在本示例中的 Horizon View 中虚拟内存共享机制导致的系统紫屏故障。
关于 ESXI 主机紫屏分析方法是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
