ESXi主机Not Responding排查：管理心跳与pktcap-uw抓包定位

凌晨两点被叫起来处理告警，这件事做运维的都躲不过。屏幕上 vCenter 里那台跑着几十个虚拟机的主机图标是灰的，状态挂着Not Responding，点进去转圈，虚拟机列表刷不出来，但业务侧的反馈是——部分业务还在正常跑。这个"看起来死了但其实没死透"的状态，是新手上路时最容易误判、老手也偶尔会翻车的场景。我处理过的几次同类故障里，真正需要拔电源的只有一次，其余几次要么是管理代理自己卡住了，要么是交换机上某个端口被策略挡了，虚拟机全程毫发无损。

这篇内容就围绕两件事展开：ESXi 主机为什么会出现 not responding（未响应），以及在这个状态下怎么在 ESXi 本机上抓包，把"到底是网络丢包还是服务卡死"这件事用数据包说清楚。前者决定了你该不该动手、能不能动手；后者决定了你能不能把一段模糊的现象变成可复现的证据。全文适合有基础 vSphere 运维经验、能进 ESXi Shell 敲命令的读者，刚从物理机转向虚拟化的朋友也能看懂，因为我会把每个动作背后的判断逻辑一并写清楚，而不是甩一串命令让你自己猜。

需要提前说一句：抓包本身不解决故障，它只回答"有没有收到""回没回""谁先不回"这三个问题。真正值钱的是你拿着这三个答案，能不能推到最后一步。

1. 把"未响应"这个词拆开：vCenter 到底在等谁的回复

1.1 三条彼此独立的心跳通道，只盯着一条会走偏

vCenter 判断一台主机是否健康，并不是靠单一信号。理解这一点，是后面所有排查的起点。第一条通道是管理面通信：vCenter 的 vpxd 进程通过 443 端口跟主机上的 hostd 通信，同时通过 902 端口跟主机上的 vpxa 代理通信。vpxa 是 vCenter 在主机侧的一个"派驻人员"，负责把主机的状态定期汇报上去。这条通道断了，页面就是灰的。

第二条通道是HA 心跳，走的是集群内主机之间的 vmkernel 网络，主节点和从节点互相确认对方活着。第三条通道是存储心跳，主机在共享数据存储上写心跳文件，作为管理网络全断时的兜底判断依据。

三条通道的意义在于：它们走的是不同的网络路径、不同的协议、不同的进程。管理面通信断了，HA 心跳可能还在；HA 心跳断了，存储心跳可能还在。我见过一次典型的误判，值班同事只 ping 通了主机就断定网络正常，结果问题出在 vpxa 进程上，网络完全没毛病，白白排查了两小时交换机配置。

所以遇到 not responding，第一句话不该是"网是不是断了"，而该是"哪条通道断了"。

1.2 "未响应"和"已断开""无法访问"不是同一件事

vSphere 界面上的主机状态有好几种，很多新手把它们混为一谈，这直接导致处置方向跑偏。下表是这几种状态的区分方式，我把它贴在过值班室的墙上：

注意区分"未响应"和"无法访问"。前者经常是软件层面的问题（进程卡死、内存耗尽、证书失效），后者更偏向链路或硬件。我在现场遇到的大部分 not responding，主机本身其实活得好好的，ping 得通，SSH 进得去，只是 hostd 或者 vpxa 不干活了。

1.3 管理面挂了不等于数据面挂了，这是最容易被忽略的事实

虚拟机运行在 VMkernel 的调度之上，网络转发由虚拟交换机完成，跟 hostd、vpxa 这两个管理进程没有直接依赖关系。管理进程只是"管理"的入口，不是"运行"的前提。这就解释了一个常见现象：vCenter 里主机灰了，业务却还在正常跑。

这个认知直接决定了处置动作的激进程度。反过来说，如果你为了"让页面变绿"而草率重启主机，那就是拿正在跑的业务去换一个图标颜色，非常不划算。

我个人的经验判断标准是这样的：只要虚拟机的业务端口还有响应、共享存储上的锁还在，主机就还有救的价值，处置应该从"修复管理面"入手，而不是"重启主机"。真正需要立刻断电的场景只有一种——主机已经彻底失去响应，DCUI 键盘没反应，带外管理也看不到输出，同时存储侧出现了大量锁冲突和写超时，这时候拖下去反而会污染整个集群的数据一致性。

2. 三分钟分型：用四组自检题把故障缩小到一类

2.1 第一组：主机还能不能被寻址，能不能建立管理连接

拿到告警第一件事，从一台跟主机同网段的机器上做三件事：ping 管理地址、telnet 443 端口、telnet 902 端口。这三个动作能在三十秒内把问题切成三类。

ping 不通，说明二层或三层就走不通了，往下查网卡状态、交换机的端口状态、VLAN 配置。ping 通但 443 不通，说明网络到达了主机，但 hostd 没有在监听或者被防火墙挡了。ping 通、443 通但 902 不通，问题大概率在 vpxa 上。

这里有个实操细节值得说：用 ESXi 自己内部的 ping 比用外部机器更有诊断价值。在能进 Shell 的前提下敲下面这条：

esxcli network diag ping -H vmk0 -I vmk0 -c 4 --netstack defaultTcpipStack 192.168.10.1

-H指定源地址，-I指定出口网卡，这两个参数必须显式给出。很多人在这一步栽跟头，直接用默认 ping，结果走的是别的 vmkernel 网卡，ping 通了也不能说明管理网卡是好的。我曾经遇到过一台主机，vmk1 是通的，vmk0 因为上行链路的一个物理网卡处于 down 状态而完全不通，外部 ping 主机的另一个地址正常，白白浪费了四十分钟。

2.2 第二组：ESXi Shell 能不能进，进去之后先看哪几个地方

能进 Shell 意味着主机内核还在正常调度，这已经是好消息。进去之后别急着敲重启命令，按顺序看四个地方。

第一个，vdf -h，看分区使用率。/var和/tmp是重点，前者写满会导致 hostd 无法写日志进而挂掉，后者是内存盘，容量有限，几个 GB 的抓包文件很容易把它撑爆。我见过最离谱的一次，是有人前一天抓包忘了删文件，第二天主机就 not responding 了，查了两个小时才发现是/tmp满了。

第二个，esxcli network ip interface list和esxcli network ip interface ipv4 get，确认管理网卡的标记是否正确。管理网卡需要带上Management这个 tag，可以用esxcli network ip interface tag get -i vmk0查。tag 丢了的情况不多见，但确实发生过，尤其是在有人调整过 vSwitch 策略之后。

第三个，esxcli network nic list，看所有物理网卡的链路状态。Link Status列显示Down的，就是嫌疑对象。

第四个，/var/log/hostd.log的尾部，用tail -n 100 /var/log/hostd.log看。如果里面刷的是内存分配失败、线程池耗尽、SOAP 请求超时之类的信息，基本可以锁定是代理层的问题，跟网络无关。

2.3 第三组：虚拟机到底还在不在跑

这组判断最直接的办法是登录主机本地查：vim-cmd vmsvc/getallvms会列出这台主机上注册的所有虚拟机。如果命令返回正常的列表，说明主机上的 VM 注册信息还在，服务层面的管理功能是可用的，只是 vCenter 那条链路断了。

如果想进一步确认某台虚拟机是否在运行，用esxcli vm process list，它会列出当前正在运行的虚拟机进程和对应的 World ID，能看到的就是真的在跑，看不到的就是真的停了。这个方法比在 vCenter 界面上猜可靠得多。

还有一个很实用的旁路验证手段：如果虚拟机的业务网络和主机管理网络不在同一个网段，直接从办公网去 ping 虚拟机、访问业务端口。通了，说明数据面完好，处置策略就可以从容一些；不通，说明问题已经传导到数据面，需要提高优先级。

2.4 四类典型场景的对照表：看到什么现象，先查什么

把上面三组自检的结果组合起来，基本能落到下面四类里。这张表是我自己整理的，不一定覆盖全部情况，但能覆盖我在现场见过的大多数：

第四类虽然少见，但一旦出现，判断必须果断。我处理过一次，主机在 not responding 的状态下坚持了二十分钟，最后带外界面刷出来的是内存多比特错误，这种时候再纠结管理面就没意义了。

3. 在 ESXi 自己身上抓包：pktcap-uw 的抓包点位选择

3.1 为什么不能只在上行链路抓，点位决定你能看见什么

很多人习惯拿一台笔记本接到交换机上做端口镜像，抓完发现什么都看不到，然后就开始怀疑人生。原因很简单：ESXi 的虚拟交换机在默认策略下不会把流量泛洪到不需要的端口，你在物理交换机的镜像口上看到的，只是这段物理链路经过的帧，而且还不一定配置正确。

更重要的是，ESXi 内部的虚拟交换机是一个完整的二层转发实体，报文在主机内部就有多个可以观测的点：虚拟机端口、vmkernel 端口、上行链路端口。不同点位看到的报文内容完全不同，选错点位等于抓了个寂寞。

我通常按下面的原则选点：怀疑主机跟外部通信有问题，抓上行链路；怀疑某个 vmkernel 网卡有问题，抓 vmk 点；怀疑某台虚拟机有问题，抓虚拟机端口。判断管理面失联属于第一种和第二种的结合，一般先抓 vmk0 点，再补一次上行链路，两次结果对照，就能区分是"包没出去"还是"包出去了但没回来"。

3.2 pktcap-uw 的五个关键参数，理解了就不用死记

pktcap-uw是 ESXi 自带的抓包工具，从 5.0 时代就存在，语法比 tcpdump 复杂一些，但逻辑很清晰。核心参数只有五个，理解了它们的含义，剩下的自然就通了。

参数组合的原则是：过滤条件能加多少加多少，--count能设多小设多小。这不是为了省事，而是为了安全。在高负载主机上无限量抓包，轻则写满/tmp让主机雪上加霜，重则影响转发性能。

3.3 抓管理心跳的标准命令与逐行解释

假设主机管理地址是 192.168.10.11，vCenter 是 192.168.10.5，要在主机侧确认 vCenter 发来的管理连接到底有没有到达。使用下面这条命令：

pktcap-uw --vmk vmk0 --capture VmkIn --dir 2 \ --srcip 192.168.10.5 --dstip 192.168.10.11 \ --proto 6 --dstport 443 \ -o /tmp/hb_443.pcap --count 500 -s 0

拆开看每一段在做什么：--vmk vmk0表示在管理 vmkernel 网卡这个点上抓；--capture VmkIn表示关注进入该点的流量类型；--dir 2进一步限定为进入方向；后面三个过滤条件把范围收窄到"vCenter 发往主机 443 端口的 TCP 报文"；-o写到临时目录，--count 500抓够五百个包自动停止，-s 0表示保存完整报文不做截断。

跑完之后，/tmp/hb_443.pcap就是成品。用scp拉回本地，或者通过数据存储浏览器下载下来用 Wireshark 打开。这里提醒一句，/tmp在重启后会清空，重要抓包文件建议直接输出到数据存储路径，比如/vmfs/volumes/datastore1/tmp/，当然前提是数据存储可用。

如果要在上行链路侧做对照，把点位换成--uplink vmnic0，--capture UplinkIn，其他过滤条件保持不变。两次抓包的时间窗口尽量重合，否则对照起来会很痛苦。

3.4 老版本走 tcpdump-uw，语法跟 Linux 那套几乎一样

ESXi 5.5 及更早的版本没有pktcap-uw，用的是tcpdump-uw。即使在 6.x 之后，tcpdump-uw依然保留着，语法跟标准 tcpdump 高度一致，习惯 Linux 的朋友用起来更顺手：

tcpdump-uw -i vmk0 -n -s 0 -w /tmp/hb_tcpdump.pcap \ 'host 192.168.10.5 and tcp port 443' -c 500

两者的区别在于观测层次：tcpdump-uw工作在更上层，看到的是经过协议栈处理后的报文，对于分析 TCP 层问题足够用；pktcap-uw工作在虚拟交换机的转发层面，能看到更原始的帧，对于判断"包到底有没有进到主机"更准确。我的习惯是，先 tcpdump-uw 快速看一眼有没有流量，如果有但表现异常，再上 pktcap-uw 深挖点位。

3.5 抓不到包的四个常见原因，每个我都踩过

第一个是过滤条件写错。--proto 6是 TCP，不是 ICMP，也不是 UDP，数字写混了自然什么都抓不到。地址写成主机自己发出去的源地址而不是 vCenter 的地址，也是常见错误。抓包前先在脑子里过一遍：这个包是从谁到谁，方向是什么。

第二个是点位和方向不匹配。用--capture VmkIn却把--dir设成 1，逻辑上就矛盾了。方向参数一定要跟 capture 类型配合着用，实在不确定就用--dir 3双向抓，代价是文件体积翻倍。

第三个是混杂模式没开。ESXi 的虚拟交换机默认安全策略里，混杂模式是关闭的。抓虚拟机端口的流量时，如果只想抓发往该虚拟机的单播包没问题，但如果想抓广播或者其他端口的流量，就得把端口组的混杂模式打开。这个操作有安全影响，改完记得改回去，别长期开着。

第四个是抓包文件写满了内存盘。/tmp的可用空间跟主机内存相关，一般不会太大。开抓之前先vdf -h看一眼，几百兆的余量抓个几十兆的 pcap 没问题，抓几 GB 就一定要换路径或者加更严格的过滤。

4. 把 pcap 读明白：心跳报文里藏着的五种结论

4.1 先看 ARP 和 TCP 握手，别一上来就翻应用层

拿到 pcap 文件，很多人的第一反应是找 SOAP 请求、找 XML 内容，这是费力不讨好的做法。管理面失联的绝大多数原因，在二层和四层就已经暴露了。正确的阅读顺序是从下往上：先看有没有 ARP 交互，再看 TCP 三次握手有没有完成，最后才看应用层有没有正常数据。

ARP 层面，如果主机一直在发 ARP 请求或者 ARP 应答，说明主机还活着并且还在尝试通信，只是没得到回应，问题偏网络。如果连 ARP 都看不到，说明主机的网络栈可能根本就没动起来，问题偏内核或者网卡驱动。

TCP 层面看握手序列。能看到完整的三次握手（SYN → SYN-ACK → ACK），说明网络通路是好的，主机上的 hostd 也是在监听的。握手完成之后就断、或者一直重传，那问题就在后面。

4.2 五种报文特征对应的根因，直接照着结论走

把常见的报文表现和结论对应起来，能省掉大量猜测。这张表里每一条我都至少见过一次：

最后一条特别值得展开。MTU 不一致导致的问题非常隐蔽，因为它只影响大包，小包完全正常。ARP 正常、ping 正常、TCP 握手正常，唯独传输大块数据的时候卡住，然后超时断开，表现就是"能连上但很快断"。vCenter 与主机之间的管理通信有时会走较大报文，遇到这种规律性重传，一定要去核对 vSwitch 上的 MTU 和交换机端口的 MTU。

4.3 一条完整的排查链路：从告警到定位的全过程

说一个我印象比较深的例子，用虚构的编号描述。某次，一台主机在凌晨报 not responding，业务侧反馈正常。第一步做室外检查，从同网段机器 ping 管理地址，通；telnet 443，不通。第二步进 Shell，esxcli network nic list显示两块物理网卡都是 Up，vdf -h显示/tmp用了 97%。第三步看 hostd.log，尾部刷的是"failed to write to log file"。

到这里已经七成把握了。第四步抓包确认，抓 vmk0 上 443 端口的进入流量，发现 SYN 能正常进入，但主机侧始终不回 SYN-ACK。结合日志和磁盘状况，结论是/tmp写满导致 hostd 无法工作，进而不响应连接。

第五步处置，先清掉/tmp下的旧文件和旧日志，然后/etc/init.d/hostd restart，再/etc/init.d/vpxa restart，大约两分钟后主机在 vCenter 里恢复绿色。整个过程没有动虚拟机，业务完全无感。

第六步，也是最重要的一步——查/tmp为什么会被写满。最后发现是一个早期的抓包脚本没有设置--count和清理逻辑，每天定时跑一次，跑了半个月把内存盘塞爆了。把脚本加上数量限制和自动清理之后，这类故障就再没出现过。

这个案例的价值不在于故障多复杂，而在于它说明了一件事：抓包的意义是把"我猜是 XX 问题"变成"数据显示是 XX 问题"。如果当时不抓包，光看日志也能猜到八九分，但要说服团队做架构层面的整改，光靠猜是不够的。

5. 现场处置的动作顺序：什么能重启，什么绝对不能动

5.1 分级处置：从最轻的动作开始试

处置的原则是从影响面最小的动作开始，每一步之后都停下来观察恢复情况。跳过中间步骤直接上大招，是新手最容易犯的错误。

一级动作：不做任何变更，只做观测。清空浏览器缓存重新登录 vCenter，检查是不是 vCenter 自身的问题。有时候多台主机同时报 not responding，问题其实在 vCenter 侧，重启 vpxd 服务就能解决，主机上一根手指都不用动。

二级动作：清理与释放。删掉/tmp和/var/log下的旧文件，给系统腾出空间，然后观察几分钟看是否自行恢复。对于写入阻塞导致的代理卡死，这一步有时就够了。

三级动作：重启管理代理。先 hostd 后 vpxa，顺序不能反，因为 vpxa 依赖 hostd。等 hostd 完全起来（用esxcli system process list | grep hostd确认进程存在）再重启 vpxa。

四级动作：进入维护模式或者迁移虚拟机。这个动作需要主机已经部分恢复可用，通常不适用于完全失联的场景。

五级动作：带外重启。这是最后的选项，前面所有努力都无效，并且已经确认虚拟机侧出现严重数据一致性风险时才考虑。

5.2 重启 hostd 和 vpxa 的正确姿势，以及可能翻车的地方

命令本身很简单：

/etc/init.d/hostd restart

等大概三十秒，确认 hostd 进程重新起来，再执行：

/etc/init.d/vpxa restart

风险在哪里？如果主机上有正在执行的管理类任务，比如虚拟机克隆、快照合并、vMotion 正在进行，重启 hostd 会中断这些任务，快照合并被打断可能留下需要人工处理的残留文件。所以在重启之前，先看一眼有没有正在跑的任务，能等就等，等不了再动手。vim-cmd vmsvc/getallvms配合esxcli vm process list能快速确认虚拟机的状态，任务层面则需要在 vCenter 的任务列表里看。

还有一个坑要提醒：不要用services.sh restart。这条命令会把主机上所有服务都重启一遍，包括一些不该在故障状态下重启的组件，在管理面已经异常的情况下，很容易导致主机彻底失去响应，从"可以救"变成"只能带外"。我当时带过的一个新人就干过这事，后果是多停了一个小时的业务。

如果发现 hostd 进程反复起来又挂，说明不是简单的卡死，而是有更深层的问题，可能是证书损坏、可能是配置文件损坏。这时候别硬刚，先收集vm-support支持包，把证据留下来，再考虑更激进的手段。

5.3 什么情况下该果断放弃抢救

有几个信号出现，说明继续在管理面上折腾已经没有意义了。

一是 DCUI 界面卡住或者黑屏，键盘输入无反应。二是带外管理界面（服务器自带的远程控制台）里能看到硬件告警，比如内存错误、处理器异常、风扇或电源故障。三是同一台主机上的虚拟机在业务侧同时全部失联，且共享存储上出现锁超时告警。四是主机上所有 vmkernel 网卡都显示 down，物理网卡指示灯全灭。

这几种情况出现任意一种，处置方向就应该切换到硬件层面，先收集带外日志，再联系硬件侧的支持人员。别在这时候还想着"再重启一次管理服务试试"，那只是在消耗时间。

6. 复盘之后做的几件事：让下一次失联变得可观测

6.1 心跳冗余：管理网卡不要只有一块

管理面的单点问题，是 not responding 高发的根本原因。常规做法是给管理网络配两块 vmkernel 网卡，分别绑定到不同的物理上行链路，然后在 vSwitch 的故障切换策略里设置成"故障切换"而不是"负载均衡"，确保主链路断了之后备用链路能接管。

这个配置在 vSphere 客户端里可以改，命令行也能改，esxcli network vswitch standard policy failover set -v vSwitch0 -f vmnic0,vmnic1是关键的一条。改完之后用esxcli network vswitch standard policy failover get -v vSwitch0确认生效。

注意一个细节：如果两块网卡连接到同一台物理交换机，那交换机本身就成了新的单点。有条件的话，管理网卡应该分到两台不同的交换机上，才能真正消除单点。

6.2 监控维度：把"进程还活着"也纳入观测

大多数现成的监控方案只监控主机是否可达、CPU 和内存使用率，这些指标在 hostd 卡死的时候依然是正常的，因为 ping 走的是内核，跟 hostd 无关。我后来补了几条自定义监控：hostd 和 vpxa 进程的存在性、/tmp和/var的写入权限是否正常、hostd 的日志大小增长速度、管理端口的 TCP 连接数。

连接数这个指标特别有用。hostd 卡死之前，往往会出现连接数持续攀升然后突然归零的特征，这个拐点如果能提前捕捉到，就能在用户感知之前介入。实现方式不复杂，定时跑esxcli network ip connection list | grep 443 | wc -l，超过阈值就告警。

另外建议把 syslog 配置到远端服务器，esxcli system syslog config set --loghost='udp://192.168.10.100:514'，配置完重启一下 syslog 服务。这样即使本地日志分区写满或者主机彻底挂掉，日志也有留存，事后复盘不至于两眼一抹黑。

6.3 抓包的习惯：先设上限，再谈排查

最后回到抓包本身。我在团队里定了一条规矩，写进了操作手册：任何抓包命令必须带--count或者-c，输出路径优先选数据存储而不是/tmp，抓完必须在一个小时内清理。这条规矩不是小题大做，前面那个因为脚本没设上限导致主机失联的案例，代价是团队半夜折腾了三个小时。

还有一个细节值得记录：抓包前先记录一下当前时间，date命令一行就够。事后在 Wireshark 里对时间轴的时候，这个时间戳能帮你快速定位到故障发生的那一刻，而不是在几十万条报文里反复拖动滚动条找。

抓包文件命名也建议带上主机名、时间、点位三个要素，比如esx01-vmk0-443-20240315.pcap。出问题的时候，文件名混乱带来的时间浪费比想象中大得多，特别是在一堆人同时排查的时候。

我个人在实际操作中的体会是，not responding 这个告警本身信息量很低，它只告诉你"联系不上"，不告诉你为什么。真正的诊断信息藏在三处：主机上的进程状态、日志的尾部内容、以及抓包文件里那些没被回复的数据包。三处交叉验证，结论基本不会错。至于抓包工具本身，pktcap-uw的参数看着吓人，但记住点位、方向、过滤这三件事，剩下的都是组合。用得多了你会发现，它比在物理交换机上折腾镜像端口省事得多，毕竟虚拟交换机的所有转发点都在你手里，随时可以停下来看一眼。