ESXi在vCenter显示未响应：心跳超时定位与pktcap-uw抓包排查

ESXi 主机在 vCenter 里突然变成灰色的“未响应”同时告警邮件一封接一封地来这件事凡是维护过虚拟化平台的人都遇到过。它最让人难受的地方不在于故障本身而在于信息量极少主机还活着没有虚拟机还在跑没有是网络断了还是服务挂了从 vCenter 这一个界面你什么都看不出来。我这几年处理过的“not responding”至少有几十次从最开始只会重启管理代理到后来能根据日志和抓包结果定位到具体是哪一跳出了问题中间踩的坑不少。这篇内容就把这套排查逻辑完整拆一遍重点讲清楚两件事一是“not responding”这条告警到底是谁在报、报的是什么二是当常规排查走不通时怎么在 ESXi 主机上抓包以及抓到的包该怎么看。内容偏实战适合已经能独立登录 ESXi 命令行、日常负责虚拟化平台运维的读者也适合刚接手 vCenter 环境、遇到告警只会重启的同行参考。1. not responding这条告警的真实含义1.1 告警的传递链条很多人以为 vCenter 显示“未响应”就等于主机宕机了这个理解偏差是排查走弯路的开始。实际上 vCenter 并不是直接去 ping 主机它依赖主机侧的一个代理进程vpxa与上层的hostd通信。完整的链路是这样的vCenter Server 通过 443 端口连到 ESXi 的管理地址ESXi 上的vpxa负责接收指令并转交给hostdhostd再去调用底层的 vmkernel 完成实际操作。任何一环卡住vCenter 侧的连接就会超时界面上的表现就是主机变灰、显示“未响应”。所以这条告警的本质是“vCenter 与 vpxa 之间的管理通道心跳超时”而不是“主机物理上没了”。理解这一点非常关键因为它直接决定了你的排查方向主机可能完全正常虚拟机跑得好好的只是管理面的某一段断了。我见过最典型的例子是管理网卡的网线松动业务流量走另外的物理网卡虚拟机一点没受影响但 vCenter 上全红值班的人吓得差点去机房重启机器。再往细里说超时的判定还分几种情况。如果vpxa进程崩了但hostd还在vCenter 会尝试重连重连失败后标记为“未响应”如果hostd也挂了那么连直接登录 ESXi 的 vSphere Client 都会异常如果只是网络不通那两个进程其实都好好的。这三种情况的处理手法完全不同所以第一步永远是区分它们。1.2 三类根因的快速区分我把导致“not responding”的原因归成三类实际排查时按这个顺序过一遍八成的问题能定位到。管理面故障指的是 vCenter 到 ESXi 管理地址之间的通路出了问题。包括物理网卡 down、交换机端口 err-disable、VLAN 配置被改、管理 vmkernel 网卡的 IP 冲突、路由不可达、MTU 不一致导致的丢包。这类故障的特征是用vmkping从别的 ESXi 主机 ping 目标主机的管理地址不通或者通但丢包严重。服务面故障指管理网络是通的但hostd或vpxa这两个进程出了问题。常见诱因是日志分区写满、证书过期、进程内存泄漏被 OOM 干掉、主机负载过高导致进程响应超时。特征是从 vCenter 连不上但从同一网段的工作站能 SSH 上主机登录后esxcli network ip connection list看不到 443 端口的监听。资源面故障指的是主机整体处于“假死”状态。比如存储链路全部丢失导致hostd在等待 I/O 时阻塞、CPU 被某个虚拟机吃满导致管理进程拿不到时间片、内存耗尽触发 vmkernel 的交换风暴。这类情况往往伴随虚拟机卡顿而且 SSH 登录会非常慢甚至超时。提示不要一上来就重启管理代理。/etc/init.d/hostd restart这条命令我见过太多人当成万能药但如果根因是存储链路问题重启完照样卡死反而把现场日志覆盖掉了后面想查都没得查。2. 排查前置动作先把边界判定清楚2.1 三条独立通道验证主机存活在动任何命令之前先做三件事确认主机的真实状态。这三件事花不了两分钟但能帮你省掉大量瞎猜。第一条通道是 ICMP。从同网段的另一台机器ping目标主机的管理地址。注意不要从 vCenter 那台机器 ping因为 vCenter 本身的管理网络可能就有问题容易误判。持续 ping 观察丢包率如果 100% 丢包基本可以确认网络层断了如果时通时不通重点怀疑链路质量、MTU 或者网卡协商问题。第二条通道是 SSH。ESXi 默认关闭 SSH如果之前没开那就没法用这条通道这也提醒我们平时应该把 SSH 临时开启的策略想清楚。如果能 SSH 上去说明管理网络和 vmkernel 的网络栈都是好的问题大概率在服务层。如果 SSH 连接超时结合 ICMP 的结果就能判断是网络问题还是主机整体卡死。第三条通道是直接访问。用浏览器打开https://管理地址/ui看 vSphere Host Client 能不能出来。能出来但 vCenter 连不上几乎可以锁定是vpxa的问题出不来但 SSH 能进说明hostd的 Web 服务挂了。这两条信息交叉起来指向性非常明确。我一般会在一张纸上或者一个临时文档里记下这三条通道的结果因为排查过程中状态会变化人是记不住的。比如一开始 SSH 能进十分钟后进不去了这个时间点的变化本身就是重要线索。2.2 一份信息采集清单确定了主机存活状态之后接下来要采集一批基础信息。这些东西在后续判断根因时会反复用到一次性拿全比来回登录高效得多。下面这份清单是我自己常用的字段可以按环境调整。采集项命令或位置关注点管理网卡链路状态esxcli network nic listLink Status 是否为 UpSpeed 是否协商正常vmkernel 网卡配置esxcli network ip interface ipv4 getIP、掩码、网关是否与预期一致默认路由esxcli network ip route ipv4 list是否存在指向是否正确DNS 配置esxcli network ip dns server list是否可达解析是否正常时间同步ntpq -p或esxcli system ntp get偏移量是否在可接受范围主机运行时长uptime是否发生过意外重启日志分区使用率df -h/var和/tmp是否接近 100%管理服务状态/etc/init.d/hostd status、/etc/init.d/vpxa status是否 running证书有效期查看/etc/vmware/ssl/rui.crt是否已过期虚拟机运行状态esxcli vm process list数量是否与预期一致这张表里的每一行都对应过至少一次我实际遇到过的故障。比如日志分区写满这一条/var满了之后hostd写日志失败会直接退出表现就是 vCenter 显示未响应、SSH 能进、Host Client 打不开非常典型。再比如证书过期症状更隐蔽服务看着都在跑但 vCenter 就是握手失败日志里有明显的 SSL 报错不主动去看根本发现不了。2.3 时间线的对齐这一步经常被忽略但在多主机环境里特别重要。vCenter 的日志、ESXi 的日志、交换机的日志时间戳如果对不上你根本没法判断谁先谁后。我遇到过一次主机显示未响应的时间点比交换机端口 down 的时间晚了十分钟原因就是 ESXi 的 NTP 没配好时钟漂了。最后查了半天网络实际上是主机侧时间不准导致日志顺序错乱。做法很简单先确认 vCenter 和 ESXi 的时间偏差esxcli system time get看一眼偏差超过几分钟就先把 NTP 修好然后再重新梳理时间线。虽然修 NTP 不解决当前故障但能让后续的证据链站得住。3. 分层排查实操3.1 第一层管理网络与链路状态从最底层开始。登录 ESXi如果 SSH 进不去就用 DCUI 现场操作执行esxcli network nic list看管理流量走的那个物理网卡是不是 Up。这里有个细节网卡显示 Up 不代表链路质量好要看 Speed 和 Duplex 的协商结果正常应该是 10000 或者 25000 全双工。如果显示 100 半双工那基本可以确定是网线或者模块的问题这种降速协商在千兆环境里极常见。接着看 vSwitch 的拓扑。esxcli network vswitch standard list能看到管理 vmkernel 绑在哪个 vSwitch 上esxcli network vswitch standard portgroup list能看到端口组策略。重点检查两个东西一是管理 vmkernel 是不是绑在正确的端口组上有没有人误操作把它挪走了二是端口组的 VLAN ID 有没有被改过。再往下是二层连通性。vmkping -I vmk0 网关地址用管理接口去 ping 网关这个命令的好处是强制从指定的 vmkernel 网卡发出绕开了路由表的干扰。我遇到过主机默认路由指向另一个网段的情况普通 ping 能通但用的是错的出口vmkping -I一测就露馅了。再往上一层vmkping -I vmk0 -s 1472 -d 对端地址可以做 MTU 探测-d是不分片如果小包通大包不通MTU 不匹配无疑。1472 加 28 字节的 IP 和 ICMP 头正好等于 1500这是标准以太网的 MTU 上限。注意vmkping的-s是载荷大小不是总包长。很多人在排查 MTU 问题时直接-s 1500结果永远不通反而误判。想测 9000 的巨帧用-s 8972才对吧。还有一个容易被忽略的点esxcli network ip connection list这条命令能列出当前所有 TCP 连接。如果 vCenter 正在尝试连接但连不上你可能会看到大量处于 SYN_SENT 或者 TIME_WAIT 状态的 443 连接这本身就是一条有价值的证据说明主机侧网络栈在尝试通信但对端没回应。3.2 第二层DNS、时间与证书这三样东西放在一起讲因为它们的共同点是“平时没问题一出问题就很费解”。DNS 的作用在很多人印象里只是解析主机名但 vCenter 和 ESXi 之间的通信、证书校验、日志里的主机标识都依赖它。如果 ESXi 上配置的 DNS 服务器不可达hostd在做反向解析时会卡住表现出来就是阶段性无响应过一会儿又好了。验证方法很直接nslookup或者直接用vmkping测 DNS 服务器地址通不通。如果环境里没有 DNS建议在 ESXi 的/etc/hosts里把 vCenter 和自己都写上避免解析超时。证书这块更隐蔽。平台默认用自签证书有效期是若干年但具体时长和版本相关很容易被遗忘。证书到期后hostd和vpxa的 TLS 握手就会失败vCenter 连不上但主机本身跑得好好的。查看证书有效期可以直接在 Host Client 里看也可以命令行openssl x509 -in /etc/vmware/ssl/rui.crt -noout -dates。如果确实过期了用openssl重新生成一对自签证书替换或者用环境里的证书管理工具重新签发然后重启管理代理。3.3 第三层hostd 与 vpxa 服务前面三层都排除了那就该怀疑服务本身了。先看状态/etc/init.d/hostd status和/etc/init.d/vpxa status输出 running 说明进程在但进程在也不代表健康可能已经卡死。这时候要看日志。ESXi 的日志位置相对固定/var/log/hostd.log记录 hostd 的所有活动/var/log/vpxa.log记录与 vCenter 的通信细节/var/log/vmkernel.log是内核层/var/log/syslog.log汇总系统消息。用tail -f盯着看同时从 vCenter 侧发起一个连接操作比如右键主机点“重新连接”观察日志里有没有新的报错。我印象比较深的一次是vpxa.log里反复出现Connection reset by peer同时hostd.log里有大量 pending task。最后查出来是某个虚拟机的快照任务卡住了vpxa在等hostd完成hostd在等存储 I/O一条链全堵死。这种情况重启hostd是没用的得先把卡住的任务清掉。如果确认是进程本身的问题重启顺序很重要先vpxa再hostd或者直接services.sh restart一把梭。但重启前一定要先抓一份日志出来cp /var/log/vpxa.log /vmfs/volumes/数据存储/保存下来因为重启后日志会被覆盖。3.4 第四层资源与存储导致的假死如果到这一步还没找到原因那就得考虑主机是不是整体过载了。esxcli vm process list看虚拟机数量和状态如果某个虚拟机的 CPU 占用达到百分之百并且持续很久管理进程确实可能抢不到 CPU。这种情况下esxcli vm process kill把问题虚拟机干掉是合理的处置。存储的问题更容易造成假死。esxcli storage core path list看所有路径的状态如果有大量dead或者off的路径hostd在枚举设备时会被阻塞。更典型的是 NFS 或者 iSCSI 存储无响应所有访问该存储的操作都会挂起包括读取配置文件这种基础操作于是整个管理面就瘫了。判断方法看vmkernel.log里有没有NMP或者timed out相关的记录或者用esxcli storage core device list看设备是不是处于off状态。内存方面esxcli hardware memory get看物理内存但更有意义的是看交换和压缩的使用情况。如果主机内存严重超配vmkernel 会做内存回收管理进程的内存页被换出去再换回来响应就慢了。这种情况短期无解只能迁移虚拟机或者扩容。4. ESXi 侧抓包全流程常规排查走完之后如果还是没有明确结论或者你想拿到确凿证据证明“不是我们的问题”那就该抓包了。抓包是这类故障排查里的终极手段因为它不带任何主观判断包里有就是有没有就是没有。4.1 为什么 ESXi 上没有 tcpdump先纠正一个很常见的误解。ESXi 是一个裁剪过的系统里面的用户态工具集非常有限标准的tcpdump并不存在。有些人尝试用yum或者apt安装这是行不通的也不该在生产环境里往 hypervisor 上装非官方组件风险远大于收益。官方提供的是pktcap-uw这个工具从名字能看出来它工作在 user world用户态和 vmkernel 之间能抓取到非常底层的数据包括 vSwitch 转发前后的包、丢包事件、防火墙处理前后的包。这实际上比 tcpdump 更强大因为它能看到虚拟交换内部发生了什么而不只是网卡上收到的字节。pktcap-uw的另一个好处是不需要先开启混杂模式也不依赖虚拟机的网卡配置直接在 vmkernel 层面工作。这避免了一个经典问题在虚拟交换机上抓包必须开混杂模式开了之后同 vSwitch 上所有虚拟机都能嗅探到别人的流量安全风险很大。pktcap-uw没有这个副作用。4.2 定位抓包点抓包之前必须先想清楚“我要抓哪一段”因为不同的抓包点看到的流量完全不同。pktcap-uw支持的主要抓包点有这么几类--uplink vmnicX物理上行链路看到的是真正进出物理网卡的流量--vmk vmkXvmkernel 接口看到的是管理流量、NFS 流量等--switchport 端口ID虚拟交换机上的某个端口通常是某个虚拟机的网卡--dvfilter分布式虚拟交换机上的过滤器用于抓经过特定 VM 的流量排查“not responding”的时候最常用的是--vmk和--uplink两个组合。思路是这样的同时在管理 vmkernel 和物理上行口上抓如果 vmk 上能看到 vCenter 发来的 SYN 包但 uplink 上没有说明包在 vSwitch 内部就被丢了如果 uplink 上能看到进来的包但 vmk 上没有说明是物理层或者上行链路的处理有问题如果两边都能看到包但没有响应包那就是主机侧没回问题在服务层。这就是所谓的“分段定位”把一条完整的路径切成几段一段一段确认流量有没有过去逻辑上非常清晰比盯着日志猜靠谱得多。找端口 ID 用net-stats -l或者esxcli network vm list输出里每个网卡对应一个端口号比如33554439这种大数字。这个数字在每次重启或者网卡重连后会变所以抓包前一定要重新查不要用之前记的旧值这是我踩过的坑抓了半天一个包没有原因是端口 ID 早就变了。4.3 常用命令与参数最基本的一条抓包命令长这样pktcap-uw --vmk vmk0 --capture VmkInput --dir 1 --outfile /tmp/vmk0_in.pcap参数含义逐个说清楚。--vmk vmk0指定抓哪个接口--capture VmkInput指定抓入方向的包对应的还有VmkOutput--dir 1是方向1 表示入、2 表示出--outfile指定输出文件。注意这个文件是标准的 pcap 格式可以直接用 Wireshark 打开。抓物理上行口pktcap-uw --uplink vmnic0 --capture UplinkInput --dir 1 --outfile /tmp/vmnic0_in.pcap抓虚拟交换机上某个端口pktcap-uw --switchport 33554439 --capture PortInput --dir 1 --outfile /tmp/port.pcap还有一个特别有用的抓包点是Droppktcap-uw --capture Drop --outfile /tmp/drop.pcap这条命令抓的是被丢弃的包。当你在怀疑“包是不是被防火墙规则或者端口组策略拦掉了”的时候这个抓包点能直接给你答案包里会带上丢弃原因非常有价值。我就是靠这个功能定位过一次端口组安全策略配错导致管理流量被拦的问题。加过滤条件可以大幅减少抓包体积避免抓到一堆无关流量。基础过滤参数包括--srcip、--dstip、--srcport、--dstport、--protopktcap-uw --vmk vmk0 --capture VmkInput --dir 1 \ --srcip 10.20.30.40 --dstip 10.20.30.10 --proto 6 --dstport 443 \ --outfile /tmp/mgmt_443.pcap新版工具还支持 tcpdump 风格的表达式过滤具体支持程度随版本不同建议先用pktcap-uw --help确认当前版本的能力不要照搬网上的参数。注意抓包文件写在/tmp下这个分区大小有限满流量抓几分钟就能写爆。写爆之后不光抓包失败还可能影响其他依赖/tmp的服务。所以一定要配合体积控制参数或者在抓包前确认/tmp的剩余空间。4.4 体积控制与参数估算这一块是很多人翻车的地方。抓包不是打开就完事你得算一下空间够不够。先算带宽。一条 10Gbps 的链路上如果跑满理论吞吐是 1.25GB/s。假设你要抓 5 分钟那就是 375GB任何主机的临时分区都放不下。即便是 1Gbps 链路跑满5 分钟也有 37.5GB。所以生产环境抓包必须做两件事一是加过滤只抓关心的五元组二是限制抓取长度snaplen只抓包头不抓载荷。snaplen 怎么定如果你只是分析 TCP 握手、DNS 解析、TLS 协商这些控制面行为96 到 128 字节足够了。以太网头 14 字节、IP 头 20 字节、TCP 头 20 字节加起来 54 字节再留一点余量给 TCP 选项和 TLS 头128 字节基本能覆盖。如果要看 HTTP 内容那得设到 1500 以上。粗略估算1500 字节的包按 snaplen 128 抓体积能压缩到原来的十分之一左右效果非常明显。新版pktcap-uw支持--snaplen控制抓取长度还有类似--maxfilesize和--filecount的参数做文件滚动配合起来就是“环形缓冲”写满一个文件自动切下一个最多保留 N 个文件永远不会把分区写爆。这套机制在长时间观察间歇性故障时特别有用。参数名在不同版本上可能有差异动手前先用帮助命令核对一遍。还有一个隐性开销是 CPU。抓包本身要复制数据在高流量场景下会消耗 vmkernel 的 CPU。我一般会在业务低峰期操作并且在抓包期间盯着主机的 CPU 使用率如果明显上涨就缩短抓包时长。4.5 抓包文件导出与本地分析抓完的文件在/tmp或者你指定的路径下接下来要弄到本地分析。最直接的方式是用scp从工作站拉取scp root10.20.30.10:/tmp/mgmt_443.pcap ./前提是主机开启了 SSH 服务并且在防火墙规则里放行了 SSH。如果没有 SSH 权限可以换个思路把文件复制到某个数据存储上然后在 vSphere Client 的数据存储浏览器里下载。cp /tmp/mgmt_443.pcap /vmfs/volumes/datastore1/这个方法的限制是文件不能太大通过浏览器下载大文件很容易超时中断。如果是几百兆以上的包还是想办法走 SCP 或者用支持断点续传的工具。本地分析用 Wireshark 就够了。针对“not responding”这个场景我的分析顺序一般是这样的第一步用显示过滤器tcp.port 443筛出管理流量看 TCP 三次握手是否完整。如果只看到 SYN 没有 SYN-ACK说明对端根本没回问题在对端或者中间链路如果看到 SYN-ACK 但随后没有 ACK说明回程路径有问题。第二步看有没有 TLS 握手失败。过滤tls.alert或者直接看ssl相关字段证书问题会在这一层暴露出来能看到明确的告警类型。第三步看重传和乱序。过滤tcp.analysis.retransmission如果重传比例很高说明链路有丢包这时候再回去查物理层。第四步如果抓到的是Drop点的包重点看 Wireshark 里的注释字段通常会有丢弃原因的说明。这一套下来基本能给出一个结论是网络不通、是服务没响应、还是证书或协议层的协商失败。4.6 备选方案交换机端口镜像pktcap-uw虽然强大但它有个前提——你得能登录主机。如果主机卡到 SSH 都进不去那就得换思路在物理交换机上做端口镜像。做法是在接入交换机上把 ESXi 管理网卡对应的那个物理口镜像到另一个空闲口然后把笔记本接上去抓。这种方式的好处是完全不依赖主机状态主机彻底死机也能抓到进出的流量坏处是只能看到物理链路上的流量虚拟交换机内部的转发细节一概看不到而且要做交换机配置可能需要网络组的配合。实际操作时要注意镜像方向是做入向镜像、出向镜像还是双向。排查“not responding”一般要做双向因为你需要同时看请求和响应。另外镜像口的带宽要足够别用一个百兆口去镜像万兆流量那样会大量丢包抓到的东西没法用。5. 常见问题与排查速查5.1 现象与根因对照下面这张表是我这些年攒下来的经验总结遇到“not responding”先照着对一遍能省下不少时间。现象组合最可能的根因优先验证动作ICMP 不通SSH 不通Host Client 打不开管理网络中断或主机宕机查物理网卡链路、交换机端口状态ICMP 通SSH 不通Host Client 打不开hostd 进程卡死或退出查/var分区使用率、hostd 日志ICMP 通SSH 通Host Client 正常vCenter 连不上vpxa 进程异常或证书问题查 vpxa 日志、证书有效期间歇性失联几秒后自愈链路质量、MTU 不匹配、DNS 超时vmkping 大包测试、DNS 可达性失联同时虚拟机卡顿存储链路中断或资源耗尽查存储路径状态、CPU 和内存使用重启管理代理后短时间恢复又复发根因未解决服务反复崩溃抓包 日志联合分析这张表的用法是从左往右对先看三条通道的组合再看附加症状。大部分情况在第一列就能锁定方向。5.2 几个印象深刻的坑第一个坑是关于日志分区的。ESXi 的/var分区默认大小有限如果主机上跑了很多虚拟机并且开了详细日志或者 syslog 配置错误导致日志往本地狂写/var满了之后hostd会因为写日志失败而退出。这个故障的特点是“看起来像网络问题”因为表现就是 vCenter 连不上。后来我养成了一个习惯任何“not responding”都先df -h看一眼这个动作只要两秒钟但能避免大量无用功。第二个坑是证书。有一次主机频繁失联重启管理代理能撑几个小时然后又挂。查了半天网络和负载都没问题最后在 vpxa 日志里看到 SSL 握手失败的记录才发现是自签证书到期了。证书这种东西平时没人关注到期那天集中爆发如果环境里主机多建议做个定期检查的清单。第三个坑是端口 ID 变化。用pktcap-uw --switchport抓包时端口 ID 是动态分配的虚拟机迁移、网卡重连、主机重启都会变。我第一次用这个功能的时候照着文档里的示例端口号去抓抓了半天文件是空的还以为工具不支持折腾了一个多小时才反应过来是端口号不对。现在我的做法是先net-stats -l拿到当前实际的端口号复制粘贴到命令里绝不凭记忆。第四个坑是抓包文件把/tmp写满了。有一次排查一个间歇性丢包问题抓包忘了加 snaplen十几分钟就把/tmp写爆了结果不光抓包文件截断连带着主机上其他临时文件也写不进去本来只是管理面失联搞成了主机整体异常。从那以后我抓包必算空间宁可少抓一会儿也不冒这个险。第五个坑比较有意思是关于“假性未响应”的。有一次 vCenter 上几十台主机同时变灰值班的人以为机房断电了结果去现场一看全都好好的。最后查出来是 vCenter 所在的那台虚拟机所在的宿主机出了存储问题导致 vCenter 自身卡住对外表现成所有主机都失联。这个案例说明看到大规模失联的时候先怀疑管理端而不是被管理端。提示做任何抓包或者重启操作前先确认当前是否有变更窗口、是否有人在用这台主机上的虚拟机。我见过在业务高峰期重启管理代理导致所有虚拟机的管理通道中断十几分钟的虽然虚拟机没停但监控告警和自动化任务全乱了善后比排查本身还累。如果一定要我在所有经验里挑一条最重要的那就是把“未响应”当成一个症状而不是一个结论。症状背后的原因可能分布在从物理网卡到应用进程的任意一层唯一可靠的办法是分层验证、逐段排除用抓包把每一段的实际情况固定下来。这套方法用熟了之后你会发现大部分看起来玄学的故障其实都有非常明确的证据链。