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未响应vCenter 联系不上主机的管理代理但主机可能仍在运行图标变灰虚拟机状态显示为不可访问或保持最后已知状态先确认虚拟机是否在跑Disconnected已断开主动或被动断开了与 vCenter 的连接通常是正常维护动作主机上无告警堆积通常是人为操作确认即可Not Reachable无法访问网络层面完全不可达ping 不通SSH 进不去优先排查链路与硬件Incompatible不兼容版本或证书不匹配主机在列表中但无法执行任何操作检查版本与证书有效期注意区分未响应和无法访问。前者经常是软件层面的问题进程卡死、内存耗尽、证书失效后者更偏向链路或硬件。我在现场遇到的大部分 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 四类典型场景的对照表看到什么现象先查什么把上面三组自检的结果组合起来基本能落到下面四类里。这张表是我自己整理的不一定覆盖全部情况但能覆盖我在现场见过的大多数场景类型现象组合大概率原因第一手动作链路型ping 不通SSH 不通但虚拟机正常管理网卡上行链路故障、交换机端口被策略阻断、VLAN 配置错位查esxcli network nic list和交换机端口状态代理型ping 通SSH 通443/902 不通hostd 或 vpxa 进程卡死内存泄漏日志分区写满查vdf -h与 hostd.log准备重启代理证书型部分主机报错其他主机正常时间或证书相关告警证书过期主机与 vCenter 时间偏差超过阈值比对时间源检查证书有效期硬件型一切连接中断DCUI 无响应带外无输出内存故障、CPU 异常、主板问题、存储控制器挂起走带外管理准备收集硬件日志第四类虽然少见但一旦出现判断必须果断。我处理过一次主机在 not responding 的状态下坚持了二十分钟最后带外界面刷出来的是内存多比特错误这种时候再纠结管理面就没意义了。3. 在 ESXi 自己身上抓包pktcap-uw 的抓包点位选择3.1 为什么不能只在上行链路抓点位决定你能看见什么很多人习惯拿一台笔记本接到交换机上做端口镜像抓完发现什么都看不到然后就开始怀疑人生。原因很简单ESXi 的虚拟交换机在默认策略下不会把流量泛洪到不需要的端口你在物理交换机的镜像口上看到的只是这段物理链路经过的帧而且还不一定配置正确。更重要的是ESXi 内部的虚拟交换机是一个完整的二层转发实体报文在主机内部就有多个可以观测的点虚拟机端口、vmkernel 端口、上行链路端口。不同点位看到的报文内容完全不同选错点位等于抓了个寂寞。我通常按下面的原则选点怀疑主机跟外部通信有问题抓上行链路怀疑某个 vmkernel 网卡有问题抓 vmk 点怀疑某台虚拟机有问题抓虚拟机端口。判断管理面失联属于第一种和第二种的结合一般先抓 vmk0 点再补一次上行链路两次结果对照就能区分是包没出去还是包出去了但没回来。3.2 pktcap-uw 的五个关键参数理解了就不用死记pktcap-uw是 ESXi 自带的抓包工具从 5.0 时代就存在语法比 tcpdump 复杂一些但逻辑很清晰。核心参数只有五个理解了它们的含义剩下的自然就通了。参数作用取值说明--uplink/--vmk/--switchport指定抓包点位三选一分别对应物理网卡、vmkernel 网卡、虚拟交换机端口--capture指定数据流方向类型配合点位使用如 UplinkIn、UplinkOut、VmkIn、VmkOut、PortInput、PortOutput--dir指定方向1 表示从该点向外发出2 表示进入该点3 表示双向--proto/--srcip/--dstip/--dstport过滤条件--proto用数字1 是 ICMP6 是 TCP17 是 UDP-o/--count/-s输出文件、抓包数量上限、快照长度抓心跳这种小流量--count一定要设别让它无限跑参数组合的原则是过滤条件能加多少加多少--count能设多小设多小。这不是为了省事而是为了安全。在高负载主机上无限量抓包轻则写满/tmp让主机雪上加霜重则影响转发性能。3.3 抓管理心跳的标准命令与逐行解释假设主机管理地址是 192.168.10.11vCenter 是 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 五种报文特征对应的根因直接照着结论走把常见的报文表现和结论对应起来能省掉大量猜测。这张表里每一条我都至少见过一次报文表现结论指向下一步查什么SYN 持续重传始终无 SYN-ACK目标侧没有响应或者回包被丢检查目标主机 hostd 是否在监听检查中间 ACL 和防火墙主机侧能看到 SYN 进入但看不到 SYN-ACK 发出主机收到请求但进程不响应hostd 卡死进程池耗尽内存不足TCP 窗口持续为 0反复出现 Zero Window 探测接收方应用层处理不过来缓冲区满hostd 处理能力瓶颈可能是数据库或日志写入阻塞收到 RST 而不是 FIN目标端口没有监听或者连接被主动拒绝hostd 未启动或被防火墙规则拒绝大量重传源和目的相同间隔规律物理链路质量问题或者 MTU 不匹配查网卡错误计数查巨型帧配置是否一致最后一条特别值得展开。MTU 不一致导致的问题非常隐蔽因为它只影响大包小包完全正常。ARP 正常、ping 正常、TCP 握手正常唯独传输大块数据的时候卡住然后超时断开表现就是能连上但很快断。vCenter 与主机之间的管理通信有时会走较大报文遇到这种规律性重传一定要去核对 vSwitch 上的 MTU 和交换机端口的 MTU。4.3 一条完整的排查链路从告警到定位的全过程说一个我印象比较深的例子用虚构的编号描述。某次一台主机在凌晨报 not responding业务侧反馈正常。第一步做室外检查从同网段机器 ping 管理地址通telnet 443不通。第二步进 Shellesxcli network nic list显示两块物理网卡都是 Upvdf -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 --loghostudp://192.168.10.100:514配置完重启一下 syslog 服务。这样即使本地日志分区写满或者主机彻底挂掉日志也有留存事后复盘不至于两眼一抹黑。6.3 抓包的习惯先设上限再谈排查最后回到抓包本身。我在团队里定了一条规矩写进了操作手册任何抓包命令必须带--count或者-c输出路径优先选数据存储而不是/tmp抓完必须在一个小时内清理。这条规矩不是小题大做前面那个因为脚本没设上限导致主机失联的案例代价是团队半夜折腾了三个小时。还有一个细节值得记录抓包前先记录一下当前时间date命令一行就够。事后在 Wireshark 里对时间轴的时候这个时间戳能帮你快速定位到故障发生的那一刻而不是在几十万条报文里反复拖动滚动条找。抓包文件命名也建议带上主机名、时间、点位三个要素比如esx01-vmk0-443-20240315.pcap。出问题的时候文件名混乱带来的时间浪费比想象中大得多特别是在一堆人同时排查的时候。我个人在实际操作中的体会是not responding 这个告警本身信息量很低它只告诉你联系不上不告诉你为什么。真正的诊断信息藏在三处主机上的进程状态、日志的尾部内容、以及抓包文件里那些没被回复的数据包。三处交叉验证结论基本不会错。至于抓包工具本身pktcap-uw的参数看着吓人但记住点位、方向、过滤这三件事剩下的都是组合。用得多了你会发现它比在物理交换机上折腾镜像端口省事得多毕竟虚拟交换机的所有转发点都在你手里随时可以停下来看一眼。