周一早上进办公室手机里已经攒了十多条告警群里开发同事接二连三地说系统卡死了存储没响应应用起不来了。我下意识先 ping 了一下 vCenter能通但打开 vSphere Web Client页面上就一行字——503 Service Unavailable。如果你也遇到过这个页面心里应该很清楚那种感觉vCenter 本身没挂SSO 登录也能过但整个资源池的操作全部瘫痪。这个场景十有八九指向 vmware-vpxd 这个 vCenter 核心服务出了问题。这篇文章我会把 VCSA 上的 vpxd 服务失败、Web 端 503 的完整排查链路写清楚先从503 到底是谁报的开始再讲怎么用 service-control 和 vmon 摸清服务状态接着分析 vpxd 日志里几类典型死因的识别方法然后给出按依赖顺序拉起服务的实操步骤最后聊一聊这个坑为什么容易反复踩、日常要盯哪些指标。无论你是刚接手虚拟化的运维新人还是被 503 折磨过几轮的老油条这套方法都能直接抄作业。1. 现象确认与影响范围先搞清楚 503 是谁在报1.1 vpxd 在 VCSA 里到底是个什么角色讲到 vCenter 故障很多人第一反应是Web 界面挂了但单说界面挂了其实很笼统。VCSA 从 6.5 之后就是一个 Photon OS 上的虚拟设备里面跑着一大堆服务vmafd 负责认证框架、vmdird 负责目录服务、vpostgres 负责嵌入式数据库、vsphere-ui 负责 Web 客户端的界面中间还有一层叫 rbd 的反向代理做请求转发。而真正干活、管着整个数据中心清单的是 vmware-vpxd。vpxd 的历史可以追溯到 Windows 版的 vCenter那时它叫 vpxd.exe。到了 VCSA 时代功能一直延续主机和虚拟机的清单管理、任务的创建和调度、事件与告警的收集、权限模型以及一切通过 vSphere API 发过来的操作基本都要过它这一手。你可以把 vpxd 理解成 vCenter 的大脑vsphere-ui 只是展示层你想把清单树、虚拟机状态拉回来展示靠的其实是 vpxd 给的数据。这也就解释了为什么 vpxd 挂了以后你看到的不是整台虚机宕机而是管理平面全部不可用。底层 ESXi 上跑的虚拟机其实没有任何影响网络、存储、业务照常只是你没有任何办法通过 vCenter 去管理它们了。这就是 503 和真正的业务中断之间最大的差别也是排查时为什么不需要惊慌、可以先冷静定位的原因。1.2 Web 端 503 的常见表现有哪些这次故障里503 的长法其实不止一种我先把我见过的情况列一下方便你对照自己的现场打开 vSphere Client 的登录页账号密码敲完点击登录之后页面就卡住随后返回 503 Service Unavailable。登录页能过但一进入主页左侧清单树不加载右上角报错浏览器开发者工具里看到大量的 /api/ 请求全部是 503。整个界面白屏刷新多次也没用换浏览器也一样。用 PowerCLI 连 vCenter报 VI SDK connect failed 或者类似连接失败。VCSA 的整体管理界面https://vcsa:5480能打开但这并不代表 vpxd 是好的。这里有个判断技巧如果 5480 管理端口正常说明这台 VCSA 的操作系统层和大部分基础设施服务活着如果 443 的 Web Client 出现 503重点就要落到 vpxd、vsphere-ui、rbd 这一条链路上而不必先去怀疑主机本身。换句话说503 只是前端和浏览器能看到的症状真正的病灶在服务链的最深处。2. 排障第一步用 vmon 和 service-control 摸清服务状态2.1 服务状态的几种字段怎么读VCSA 上的服务由 vmon 这个进程来管理这和传统用 systemctl 管服务不太一样。虽然你直接敲 systemctl 也能查到一些东西但标准姿势是用 service-control 这个命令它能识别 VCSA 上所有由 vmon 托管的服务并且对依赖关系做处理。SSH 登录 VCSA 之后如果 SSH 没开先在 5480 界面里把 SSH 服务打开先跑这条service-control --status --all输出会分成很多行一行一个服务。有几点要注意Running 指该服务进程活着但进程活着不代表功能正常后面还要看日志。Stopped 指服务没起来这是最常见的情况。某些服务显示 Unknown说明 vmon 对它的状态也拿不准这时候多数是 vmon 本身或服务启动到一半卡住需要重点观察。如果服务启动中反复重启vmon 会显示 Started 又立刻 Stopped这种 crash loop 靠 status 可能看不太准要看 vmon 日志。看当前问题服务时单独看一个也行service-control --status vmware-vpxd这里要补充一句VCSA 上的服务状态不是非黑即白的服务显示 Running 但实际不可用的情况很常见。比如我遇到过 vpxd 显示 Running但访问 API 全是 503最后发现是它内部的一个线程池卡死了。所以 status 只用来做初步定位不能作为恢复完成的依据。2.2 排障前先做三件基础检查磁盘、内存、时间很多人在服务起不来的时候第一反应就是把服务反复 start、stop这个操作我强烈建议你先忍一忍。vpxd 起不来很多时候不是它自己的问题而是底座出事了。在碰服务之前我会先检查三样东西。第一是磁盘。VCSA 的磁盘规划和普通 Linux 不一样/storage/db 放的是 vPostgres 的数据文件/storage/log 放的是各种服务的日志/storage/archive 放支持包、补丁包。这些分区一旦写满轻则服务报错重则 vpxd 直接启动失败。检查命令df -h df -idf -i 看 inode这个经常被忽略。日志目录里如果有几百万个小文件df -h 可能还有空间但 inode 已经满了同样会导致服务创建文件失败。这种情况只盯着 df -h 是看不出来的。第二是内存。VCSA 对内存的要求比很多人想象的高小规模环境建议至少 12GB如果跑 VCHA 或管理的主机数量多还要往上加。内存不够的时候内核 OOM Killer 可能会直接把 vpxd 或 vpostgres 干掉。检查命令free -h如果看到 free 很少并且日志里有 Out of memory: Kill process ... vmware-vpxd 之类的内容那问题就定位了。第三是时间同步。这一点容易被新人忽略。vpxd 和 vmafd、vmdird 之间的通信依赖票据和证书而票据体系对时钟偏差非常敏感。NTP 一旦偏了 5 分钟以上就会出现各种奇奇怪怪的鉴权失败。检查命令date timedatectl ntpq -pVCSA 7 之后默认使用 chrony所以你也可以用chronyc tracking来查看同步状态。如果发现时钟确实不对先把时间同步配好再手动校时然后再去动服务。顺序错了的话服务起来也活不了多久。3. vpxd 日志里最常见的几类死因定位法3.1 数据库连接失败的报错特征与现场还原vpxd 的所有数据都存在 vPostgres 里所以 vpxd 启动的第一件事基本是连库。数据库连不上vpxd 就会启动失败或者启动后反复重试。对应的日志在 /var/log/vmware/vpxd/vpxd.log排查的时候先看最后一段错误grep -i error /var/log/vmware/vpxd/vpxd.log | tail -20比较有代表性的数据库报错有这么几类日志中的典型片段含义常见诱因Failed to connect to database连接 vPostgres 失败vpostgres 服务没起来FATAL: remaining connection slots are reserved连接数被打满连接池耗尽通常是某个程序过度使用连接Sorry, too many clients alreadyPG 最大连接数耗尽同上connection to server on socket ... failed本地 socket 连接失败vpostgres 未监听或已挂FATAL: terminating connection due to administrator command连接被数据库端终止数据库主动关闭连接可能是重启或故障转移遇到数据库类错误第一步不是去动 vpxd而是确认 vpostgres 本身是否健康service-control --status vpostgres如果 vpostgres 显示 Stopped那就需要先把它拉起来。如果它显示 Running但连接还是失败可以试着手动用 psql 测一下连接建议切到 postgres 用户执行直接以 root 跑通常会因为认证方式问题失败/opt/vmware/vpostgres/current/bin/psql -U postgres -c select 1;也可以看 vPostgres 是否在监听 5432 端口ss -lnpt | grep 5432我记得有一次现场vpostgres 明明显示 Running但 vpxd 就是连不上后来发现是磁盘满了Postgres 进程其实是僵死的select 任何表都卡住。所以再次强调数据库问题里的隐蔽元凶永远是磁盘和内存先把地基查干净再往上层看。3.2 证书过期类的报错识别vpxd 和 vsphere-ui、vmafd 之间的通信会校验证书。证书一旦过期表现和数据库故障很像都是服务起不来但日志里会出现完全不同的关键字SSLHandshakeExceptioncertificate verify failedPKIX path building failedX.509 certificate has expiredVCSA 在版本升级、克隆、或者时钟被改回过去的时候特别容易触发证书问题。查证书过期时间比较直接的方式是看 VCSA 的机器证书openssl x509 -enddate -noout -in /etc/vmware-vpx/ssl/rui.crt这个路径在某些版本里是个软链接指向 /etc/vmware/ssl/certs/ 下的实际文件但 openssl 能正常读取就行。如果确实是证书过期不能简单把证书文件删了重新生成因为 vmdir 的数据库里还记着旧的证书指纹直接换会导致 SSO 校验不通过。正规做法是先备份再用 VCSA 自带的 certificate-manager 工具走一遍替换流程/usr/lib/vmware-vmca/bin/certificate-manager这个工具是交互式的会让你选用 VMCA 重新生成还是导入自定义证书。在没把握的情况下选 VMCA 重新生成是风险最小的方案生成完它会把 vpxd、vsphere-ui 等服务的证书都一起替换掉。3.3 磁盘空间打满和内存耗尽类日志里如果出现 No space left on device那基本不用往下分析了直接去清空间。VCSA 上有几个目录是最容易涨满的/storage/log所有服务日志都在这长时间不清理一定会涨。/storage/archive支持包、补丁包、备份文件都在这过期不删很容易写满。/storage/dbvPostgres 的数据目录如果这个满了说明数据库已经出问题了。清理的时候如果你确定日志不再需要可以先把旧的 rotated 日志删掉。拿 vpxd 的日志举例/var/log/vmware/vpxd/ 下面会有带时间戳的旋转日志保留最近几份、删掉一个月前的通常能腾出不少空间find /var/log/vmware/vpxd/ -name vpxd-*.log -mtime 30 -delete/var/log 下其他服务同理但动之前最好确认一下这些日志是否有合规保留需求内部环境一般没事生产环境建议先备份再删。内存耗尽的情况则可以在 /var/log/messages 或 journalctl 里找 OOM 记录journalctl -k | grep -i out of memory | tail -20确认是内存不足后除了调大 VCSA 的内存需要把虚拟机停机再调调完再开机还要反思一下是不是这个 VCSA 管的规模已经超出了它的规格。VCSA 的内存不能热加这是个很头疼的限制所以在规划阶段就要把余量留够。3.4 服务启动时序与 VCHA 的坑还有一种情况vpxd 日志里其实没有明显的报错只有启动到一半就退出。这种通常是依赖链上的服务还没就绪vpxd 去连的时候被拒了然后退出去vmon 又把它拉起来反复循环。表现就是 service-control --status 里 vpxd 一会儿 Running 一会儿 Stopped。遇到这种建议把日志时间轴拉出来看确认崩溃的次数和间隔tail -100 /var/log/vmware/vmon/vmon.log同时看一眼 vpxd 日志里最后几行是在哪个环节中断的。如果反复停在同一位置基本可以确定是某个上游依赖没有就绪。另外如果这台 VCSA 配了 VCHA高可用还要考虑双节点之间的数据同步问题。被动节点如果数据落后太多切换或回切时 vpxd 也会起不来。VCHA 相关的日志在 /var/log/vmware/vcha/ 和 /var/log/vmware/vcha-ha/ 下面必要时先看这两个目录。4. 完整恢复实操按依赖顺序拉起服务4.1 先单点重启 vpxd失败了不要慌拿到现场如果基础检查磁盘、内存、时间都没问题vpostgres 也健康那可以试着先单独启动 vpxdservice-control --start vmware-vpxd如果它顺利变成 Running后面再逐步验证功能。但如果你执行完之后几秒又变回 Stopped或者一直卡在 STARTING那就不要再反复执行 start 了这样只会让日志越来越乱。正确的做法是把整个服务组按依赖顺序重新拉一遍。依赖关系大致是这样vmon基础监控 → vmafd认证框架 → vmdird目录服务 → vpostgres嵌入式数据库 → vpxdvCenter 引擎 → vsphere-uiWeb 界面所以比较稳妥的重启顺序是service-control --stop --all service-control --start vmafd service-control --start vmdird service-control --start vpostgres service-control --start vmware-vpxd service-control --start vsphere-ui先执行--stop --all的意义是把整个互相依赖的服务组都停在一个干净状态避免某个服务带着半残的状态活着干扰后面的启动。这个操作在维护窗口内做是安全的因为 VCSA 只是管理平面停了不会影响底下虚拟机运行。4.2 嵌入式 vPostgres 的修复细节如果问题出在 vpostgres单独启动它service-control --start vpostgres启动后一定要验证它真正能接受连接而不是只看服务状态。用前面说的 psql 方式或者看它的日志ls -lt /var/log/vmware/vpostgres/ tail -100 /var/log/vmware/vpostgres/postgresql-*.log日志文件名里的日期部分按你现场实际来VCSA 的 postgres 日志文件名带时间戳。日志里如果能看到 database system is ready to accept connections那说明数据库起来了。如果 vpostgres 起不来并且日志里出现 could not open file ... No space left on device那就是磁盘问题先清空间再启动。如果出现 invalid page checksum、database files are corrupted 这类内容就比较严重了大概率要动 vPostgres 数据修复这个操作风险极高建议先联系厂商支持或者在动手前确认备份完整。VCSA 的备份功能是一个保底手段日常一定要开这个后面会再讲。4.3 证书与 vmdir 联动问题怎么收尾如果日志指向证书问题处理完后不要急着认为就完事了因为 vpxd 恢复的前提是 vmafd、vmdir 都能正常提供认证和目录查询。证书替换完成后建议把这三个服务依次拉起来service-control --start vmafd service-control --start vmdird service-control --start vmware-vpxd拉起来之后还要确认 vmdir 的数据库里没有残留的旧机器账号记录。用 VCSA 自带的 vdcd 命令可以查目录服务的状态/usr/lib/vmware-vmdir/bin/vdcd --status如果 vdcd 状态异常说明目录服务还没恢复这时候 vpxd 起来也会有问题。证书这块的经验是不要在生产环境手动去改证书文件权限或软链接。你以为只是换个文件实际上 vmdir 里的指纹、vmafd 的本地缓存、还有 rbd 反向代理里的证书引用全是配套的只改一个文件会造成更深的故障。4.4 验证 vpxd 真正可用而不是只看着它 Running服务状态变成 Running 之后还得做功能验证。我的习惯是分四步。第一步看进程和服务状态service-control --status vmware-vpxd第二步看 vpxd 日志最后的启动部分tail -50 /var/log/vmware/vpxd/vpxd.log如果出现启动完成、成功连接内部组件之类的信息说明各组件连接都建立起来了。注意不同版本的日志措辞不一样但核心是看有没有后续的 FATAL、ERROR。第三步用命令行工具跑一个真实的 vCenter 操作。比如用 curl 打 REST API 获取会话先证明 API 层是活的curl -sk -X POST https://localhost/api/session -u administratorvsphere.local:你的密码 -H Content-Type: application/json能正常拿到 session ID说明 vpxd 的 API 层已经可以对外服务了。如果你手头有 PowerCLI 或 govc也可以直接用它们连一下 vCenter登进去能列出数据中心就算通过。第四步回 Web 端刷新页面。这一步看起来傻但很关键。有时命令行 API 通了Web 端因为浏览器缓存或反向代理的旧连接仍然会看到 503。刷新或者用无痕窗口重新登录一次确认清单树、虚拟机状态、任务都正常显示才算恢复完成。还有一个容易被忽略的点vpxd 起来后vCenter 会开始补记它在宕机期间错过的任务和事件所以刚恢复的几分钟内Web 端任务列表可能看起来有点跳跃这通常是正常的历史任务补记不用慌张。但如果你发现虚拟机状态持续显示未知超过十几分钟那就要排查 ESXi 主机到 vCenter 的重新连接情况了。5. 复盘与预防这坑为什么容易反复踩5.1 这次故障的根因到底值不值得深挖vpxd 挂掉之后很多人把服务拉起来就完事了这是我最不推荐的做法。503 只是表象如果你不找到让 vpxd 挂掉的那个因同样的故障大概率会在几周后再来一次。所谓根因至少要能回答三个问题为什么当时它会挂为什么我们没提前发现下一次怎么避免以我接触过的现场为例vpxd 挂掉的根因排在最前面的其实就三类日志磁盘写满、证书老化、以及内存不足被 OOM。这三个都不是偶发故障而是积累型问题。也就是说它们发生前一定有一段漫长的恶化过程只要监控和巡检到位完全可以提前拦截。5.2 日常监控清单要盯哪些指标VCSA 的监控不需要搞得太复杂但下面这几个指标建议你至少放进监控平台监控项阈值建议为什么重要/storage/log 使用率超过 80% 告警日志写满是 vpxd 崩溃的首要诱因/storage/db 使用率超过 75% 告警数据库分区满会导致 vPostgres 不可写/storage/archive 使用率超过 80% 告警支持包/补丁包堆积经常被忽略机器证书剩余有效期小于 90 天告警给证书更换留足时间NTP 偏移超过 1 秒告警避免票据鉴权类隐性故障vpxd 进程存活进程消失立即告警第一时间发现服务中断如果你的监控平台管不到 VCSA 内部也可以用 VCSA 的管理接口去做基本的健康检查或者直接写一个简单的定时脚本采集 df 和证书有效期推到内部通信工具。重点不是工具多高级而是指标要全、阈值要合理。5.3 备份策略和灾备兜底VCSA 的文件级备份功能是个被严重低估的保命功能。在 5480 管理界面里可以配置备份计划把备份放到共享存储或 FTP。我建议至少每周做一次全量备份并且每个月做一次恢复演练。真到了 vPostgres 数据损坏、需要重建 VCSA 的那一步有备份和没备份恢复时间是几小时和几天的差别。另外VCHA 虽然能减少 vpxd 故障的恢复时间但它本身也有成本双倍资源、双节点数据同步、故障切换的复杂度。如果你管理的环境不大备好备份和恢复流程可能比盲目上 VCHA 更实际。我见过不止一次VCHA 配置不当导致的故障比它原本要救的故障还多。5.4 顺手再分享两个小技巧第一个VCSA 的 SSH 一定在平常就保持开启或者至少确保你有控制台访问权限。不然故障时想执行 service-control 都没入口在 5480 里开 SSH 虽然不麻烦但故障时多一步就是多一分钟恢复时间。第二个给 vpxd 日志做个简单的持久化。VCSA 本身的日志轮转会清理掉很多旧日志如果你想复盘故障前两小时到底发生了什么建议日常把 vpxd 和 vmon 的日志同步一份到外部日志平台。踩过几次坑之后你会发现这些历史日志在定位疑难问题时价值千金。 
长河君 · 2026/10/4 13:00:54 · 阅读 1.2k vCenter Web 503 故障排查：vpxd 服务恢复完整指南
周一早上进办公室手机里已经攒了十多条告警群里开发同事接二连三地说系统卡死了存储没响应应用起不来了。我下意识先 ping 了一下 vCenter能通但打开 vSphere Web Client页面上就一行字——503 Service Unavailable。如果你也遇到过这个页面心里应该很清楚那种感觉vCenter 本身没挂SSO 登录也能过但整个资源池的操作全部瘫痪。这个场景十有八九指向 vmware-vpxd 这个 vCenter 核心服务出了问题。这篇文章我会把 VCSA 上的 vpxd 服务失败、Web 端 503 的完整排查链路写清楚先从503 到底是谁报的开始再讲怎么用 service-control 和 vmon 摸清服务状态接着分析 vpxd 日志里几类典型死因的识别方法然后给出按依赖顺序拉起服务的实操步骤最后聊一聊这个坑为什么容易反复踩、日常要盯哪些指标。无论你是刚接手虚拟化的运维新人还是被 503 折磨过几轮的老油条这套方法都能直接抄作业。1. 现象确认与影响范围先搞清楚 503 是谁在报1.1 vpxd 在 VCSA 里到底是个什么角色讲到 vCenter 故障很多人第一反应是Web 界面挂了但单说界面挂了其实很笼统。VCSA 从 6.5 之后就是一个 Photon OS 上的虚拟设备里面跑着一大堆服务vmafd 负责认证框架、vmdird 负责目录服务、vpostgres 负责嵌入式数据库、vsphere-ui 负责 Web 客户端的界面中间还有一层叫 rbd 的反向代理做请求转发。而真正干活、管着整个数据中心清单的是 vmware-vpxd。vpxd 的历史可以追溯到 Windows 版的 vCenter那时它叫 vpxd.exe。到了 VCSA 时代功能一直延续主机和虚拟机的清单管理、任务的创建和调度、事件与告警的收集、权限模型以及一切通过 vSphere API 发过来的操作基本都要过它这一手。你可以把 vpxd 理解成 vCenter 的大脑vsphere-ui 只是展示层你想把清单树、虚拟机状态拉回来展示靠的其实是 vpxd 给的数据。这也就解释了为什么 vpxd 挂了以后你看到的不是整台虚机宕机而是管理平面全部不可用。底层 ESXi 上跑的虚拟机其实没有任何影响网络、存储、业务照常只是你没有任何办法通过 vCenter 去管理它们了。这就是 503 和真正的业务中断之间最大的差别也是排查时为什么不需要惊慌、可以先冷静定位的原因。1.2 Web 端 503 的常见表现有哪些这次故障里503 的长法其实不止一种我先把我见过的情况列一下方便你对照自己的现场打开 vSphere Client 的登录页账号密码敲完点击登录之后页面就卡住随后返回 503 Service Unavailable。登录页能过但一进入主页左侧清单树不加载右上角报错浏览器开发者工具里看到大量的 /api/ 请求全部是 503。整个界面白屏刷新多次也没用换浏览器也一样。用 PowerCLI 连 vCenter报 VI SDK connect failed 或者类似连接失败。VCSA 的整体管理界面https://vcsa:5480能打开但这并不代表 vpxd 是好的。这里有个判断技巧如果 5480 管理端口正常说明这台 VCSA 的操作系统层和大部分基础设施服务活着如果 443 的 Web Client 出现 503重点就要落到 vpxd、vsphere-ui、rbd 这一条链路上而不必先去怀疑主机本身。换句话说503 只是前端和浏览器能看到的症状真正的病灶在服务链的最深处。2. 排障第一步用 vmon 和 service-control 摸清服务状态2.1 服务状态的几种字段怎么读VCSA 上的服务由 vmon 这个进程来管理这和传统用 systemctl 管服务不太一样。虽然你直接敲 systemctl 也能查到一些东西但标准姿势是用 service-control 这个命令它能识别 VCSA 上所有由 vmon 托管的服务并且对依赖关系做处理。SSH 登录 VCSA 之后如果 SSH 没开先在 5480 界面里把 SSH 服务打开先跑这条service-control --status --all输出会分成很多行一行一个服务。有几点要注意Running 指该服务进程活着但进程活着不代表功能正常后面还要看日志。Stopped 指服务没起来这是最常见的情况。某些服务显示 Unknown说明 vmon 对它的状态也拿不准这时候多数是 vmon 本身或服务启动到一半卡住需要重点观察。如果服务启动中反复重启vmon 会显示 Started 又立刻 Stopped这种 crash loop 靠 status 可能看不太准要看 vmon 日志。看当前问题服务时单独看一个也行service-control --status vmware-vpxd这里要补充一句VCSA 上的服务状态不是非黑即白的服务显示 Running 但实际不可用的情况很常见。比如我遇到过 vpxd 显示 Running但访问 API 全是 503最后发现是它内部的一个线程池卡死了。所以 status 只用来做初步定位不能作为恢复完成的依据。2.2 排障前先做三件基础检查磁盘、内存、时间很多人在服务起不来的时候第一反应就是把服务反复 start、stop这个操作我强烈建议你先忍一忍。vpxd 起不来很多时候不是它自己的问题而是底座出事了。在碰服务之前我会先检查三样东西。第一是磁盘。VCSA 的磁盘规划和普通 Linux 不一样/storage/db 放的是 vPostgres 的数据文件/storage/log 放的是各种服务的日志/storage/archive 放支持包、补丁包。这些分区一旦写满轻则服务报错重则 vpxd 直接启动失败。检查命令df -h df -idf -i 看 inode这个经常被忽略。日志目录里如果有几百万个小文件df -h 可能还有空间但 inode 已经满了同样会导致服务创建文件失败。这种情况只盯着 df -h 是看不出来的。第二是内存。VCSA 对内存的要求比很多人想象的高小规模环境建议至少 12GB如果跑 VCHA 或管理的主机数量多还要往上加。内存不够的时候内核 OOM Killer 可能会直接把 vpxd 或 vpostgres 干掉。检查命令free -h如果看到 free 很少并且日志里有 Out of memory: Kill process ... vmware-vpxd 之类的内容那问题就定位了。第三是时间同步。这一点容易被新人忽略。vpxd 和 vmafd、vmdird 之间的通信依赖票据和证书而票据体系对时钟偏差非常敏感。NTP 一旦偏了 5 分钟以上就会出现各种奇奇怪怪的鉴权失败。检查命令date timedatectl ntpq -pVCSA 7 之后默认使用 chrony所以你也可以用chronyc tracking来查看同步状态。如果发现时钟确实不对先把时间同步配好再手动校时然后再去动服务。顺序错了的话服务起来也活不了多久。3. vpxd 日志里最常见的几类死因定位法3.1 数据库连接失败的报错特征与现场还原vpxd 的所有数据都存在 vPostgres 里所以 vpxd 启动的第一件事基本是连库。数据库连不上vpxd 就会启动失败或者启动后反复重试。对应的日志在 /var/log/vmware/vpxd/vpxd.log排查的时候先看最后一段错误grep -i error /var/log/vmware/vpxd/vpxd.log | tail -20比较有代表性的数据库报错有这么几类日志中的典型片段含义常见诱因Failed to connect to database连接 vPostgres 失败vpostgres 服务没起来FATAL: remaining connection slots are reserved连接数被打满连接池耗尽通常是某个程序过度使用连接Sorry, too many clients alreadyPG 最大连接数耗尽同上connection to server on socket ... failed本地 socket 连接失败vpostgres 未监听或已挂FATAL: terminating connection due to administrator command连接被数据库端终止数据库主动关闭连接可能是重启或故障转移遇到数据库类错误第一步不是去动 vpxd而是确认 vpostgres 本身是否健康service-control --status vpostgres如果 vpostgres 显示 Stopped那就需要先把它拉起来。如果它显示 Running但连接还是失败可以试着手动用 psql 测一下连接建议切到 postgres 用户执行直接以 root 跑通常会因为认证方式问题失败/opt/vmware/vpostgres/current/bin/psql -U postgres -c select 1;也可以看 vPostgres 是否在监听 5432 端口ss -lnpt | grep 5432我记得有一次现场vpostgres 明明显示 Running但 vpxd 就是连不上后来发现是磁盘满了Postgres 进程其实是僵死的select 任何表都卡住。所以再次强调数据库问题里的隐蔽元凶永远是磁盘和内存先把地基查干净再往上层看。3.2 证书过期类的报错识别vpxd 和 vsphere-ui、vmafd 之间的通信会校验证书。证书一旦过期表现和数据库故障很像都是服务起不来但日志里会出现完全不同的关键字SSLHandshakeExceptioncertificate verify failedPKIX path building failedX.509 certificate has expiredVCSA 在版本升级、克隆、或者时钟被改回过去的时候特别容易触发证书问题。查证书过期时间比较直接的方式是看 VCSA 的机器证书openssl x509 -enddate -noout -in /etc/vmware-vpx/ssl/rui.crt这个路径在某些版本里是个软链接指向 /etc/vmware/ssl/certs/ 下的实际文件但 openssl 能正常读取就行。如果确实是证书过期不能简单把证书文件删了重新生成因为 vmdir 的数据库里还记着旧的证书指纹直接换会导致 SSO 校验不通过。正规做法是先备份再用 VCSA 自带的 certificate-manager 工具走一遍替换流程/usr/lib/vmware-vmca/bin/certificate-manager这个工具是交互式的会让你选用 VMCA 重新生成还是导入自定义证书。在没把握的情况下选 VMCA 重新生成是风险最小的方案生成完它会把 vpxd、vsphere-ui 等服务的证书都一起替换掉。3.3 磁盘空间打满和内存耗尽类日志里如果出现 No space left on device那基本不用往下分析了直接去清空间。VCSA 上有几个目录是最容易涨满的/storage/log所有服务日志都在这长时间不清理一定会涨。/storage/archive支持包、补丁包、备份文件都在这过期不删很容易写满。/storage/dbvPostgres 的数据目录如果这个满了说明数据库已经出问题了。清理的时候如果你确定日志不再需要可以先把旧的 rotated 日志删掉。拿 vpxd 的日志举例/var/log/vmware/vpxd/ 下面会有带时间戳的旋转日志保留最近几份、删掉一个月前的通常能腾出不少空间find /var/log/vmware/vpxd/ -name vpxd-*.log -mtime 30 -delete/var/log 下其他服务同理但动之前最好确认一下这些日志是否有合规保留需求内部环境一般没事生产环境建议先备份再删。内存耗尽的情况则可以在 /var/log/messages 或 journalctl 里找 OOM 记录journalctl -k | grep -i out of memory | tail -20确认是内存不足后除了调大 VCSA 的内存需要把虚拟机停机再调调完再开机还要反思一下是不是这个 VCSA 管的规模已经超出了它的规格。VCSA 的内存不能热加这是个很头疼的限制所以在规划阶段就要把余量留够。3.4 服务启动时序与 VCHA 的坑还有一种情况vpxd 日志里其实没有明显的报错只有启动到一半就退出。这种通常是依赖链上的服务还没就绪vpxd 去连的时候被拒了然后退出去vmon 又把它拉起来反复循环。表现就是 service-control --status 里 vpxd 一会儿 Running 一会儿 Stopped。遇到这种建议把日志时间轴拉出来看确认崩溃的次数和间隔tail -100 /var/log/vmware/vmon/vmon.log同时看一眼 vpxd 日志里最后几行是在哪个环节中断的。如果反复停在同一位置基本可以确定是某个上游依赖没有就绪。另外如果这台 VCSA 配了 VCHA高可用还要考虑双节点之间的数据同步问题。被动节点如果数据落后太多切换或回切时 vpxd 也会起不来。VCHA 相关的日志在 /var/log/vmware/vcha/ 和 /var/log/vmware/vcha-ha/ 下面必要时先看这两个目录。4. 完整恢复实操按依赖顺序拉起服务4.1 先单点重启 vpxd失败了不要慌拿到现场如果基础检查磁盘、内存、时间都没问题vpostgres 也健康那可以试着先单独启动 vpxdservice-control --start vmware-vpxd如果它顺利变成 Running后面再逐步验证功能。但如果你执行完之后几秒又变回 Stopped或者一直卡在 STARTING那就不要再反复执行 start 了这样只会让日志越来越乱。正确的做法是把整个服务组按依赖顺序重新拉一遍。依赖关系大致是这样vmon基础监控 → vmafd认证框架 → vmdird目录服务 → vpostgres嵌入式数据库 → vpxdvCenter 引擎 → vsphere-uiWeb 界面所以比较稳妥的重启顺序是service-control --stop --all service-control --start vmafd service-control --start vmdird service-control --start vpostgres service-control --start vmware-vpxd service-control --start vsphere-ui先执行--stop --all的意义是把整个互相依赖的服务组都停在一个干净状态避免某个服务带着半残的状态活着干扰后面的启动。这个操作在维护窗口内做是安全的因为 VCSA 只是管理平面停了不会影响底下虚拟机运行。4.2 嵌入式 vPostgres 的修复细节如果问题出在 vpostgres单独启动它service-control --start vpostgres启动后一定要验证它真正能接受连接而不是只看服务状态。用前面说的 psql 方式或者看它的日志ls -lt /var/log/vmware/vpostgres/ tail -100 /var/log/vmware/vpostgres/postgresql-*.log日志文件名里的日期部分按你现场实际来VCSA 的 postgres 日志文件名带时间戳。日志里如果能看到 database system is ready to accept connections那说明数据库起来了。如果 vpostgres 起不来并且日志里出现 could not open file ... No space left on device那就是磁盘问题先清空间再启动。如果出现 invalid page checksum、database files are corrupted 这类内容就比较严重了大概率要动 vPostgres 数据修复这个操作风险极高建议先联系厂商支持或者在动手前确认备份完整。VCSA 的备份功能是一个保底手段日常一定要开这个后面会再讲。4.3 证书与 vmdir 联动问题怎么收尾如果日志指向证书问题处理完后不要急着认为就完事了因为 vpxd 恢复的前提是 vmafd、vmdir 都能正常提供认证和目录查询。证书替换完成后建议把这三个服务依次拉起来service-control --start vmafd service-control --start vmdird service-control --start vmware-vpxd拉起来之后还要确认 vmdir 的数据库里没有残留的旧机器账号记录。用 VCSA 自带的 vdcd 命令可以查目录服务的状态/usr/lib/vmware-vmdir/bin/vdcd --status如果 vdcd 状态异常说明目录服务还没恢复这时候 vpxd 起来也会有问题。证书这块的经验是不要在生产环境手动去改证书文件权限或软链接。你以为只是换个文件实际上 vmdir 里的指纹、vmafd 的本地缓存、还有 rbd 反向代理里的证书引用全是配套的只改一个文件会造成更深的故障。4.4 验证 vpxd 真正可用而不是只看着它 Running服务状态变成 Running 之后还得做功能验证。我的习惯是分四步。第一步看进程和服务状态service-control --status vmware-vpxd第二步看 vpxd 日志最后的启动部分tail -50 /var/log/vmware/vpxd/vpxd.log如果出现启动完成、成功连接内部组件之类的信息说明各组件连接都建立起来了。注意不同版本的日志措辞不一样但核心是看有没有后续的 FATAL、ERROR。第三步用命令行工具跑一个真实的 vCenter 操作。比如用 curl 打 REST API 获取会话先证明 API 层是活的curl -sk -X POST https://localhost/api/session -u administratorvsphere.local:你的密码 -H Content-Type: application/json能正常拿到 session ID说明 vpxd 的 API 层已经可以对外服务了。如果你手头有 PowerCLI 或 govc也可以直接用它们连一下 vCenter登进去能列出数据中心就算通过。第四步回 Web 端刷新页面。这一步看起来傻但很关键。有时命令行 API 通了Web 端因为浏览器缓存或反向代理的旧连接仍然会看到 503。刷新或者用无痕窗口重新登录一次确认清单树、虚拟机状态、任务都正常显示才算恢复完成。还有一个容易被忽略的点vpxd 起来后vCenter 会开始补记它在宕机期间错过的任务和事件所以刚恢复的几分钟内Web 端任务列表可能看起来有点跳跃这通常是正常的历史任务补记不用慌张。但如果你发现虚拟机状态持续显示未知超过十几分钟那就要排查 ESXi 主机到 vCenter 的重新连接情况了。5. 复盘与预防这坑为什么容易反复踩5.1 这次故障的根因到底值不值得深挖vpxd 挂掉之后很多人把服务拉起来就完事了这是我最不推荐的做法。503 只是表象如果你不找到让 vpxd 挂掉的那个因同样的故障大概率会在几周后再来一次。所谓根因至少要能回答三个问题为什么当时它会挂为什么我们没提前发现下一次怎么避免以我接触过的现场为例vpxd 挂掉的根因排在最前面的其实就三类日志磁盘写满、证书老化、以及内存不足被 OOM。这三个都不是偶发故障而是积累型问题。也就是说它们发生前一定有一段漫长的恶化过程只要监控和巡检到位完全可以提前拦截。5.2 日常监控清单要盯哪些指标VCSA 的监控不需要搞得太复杂但下面这几个指标建议你至少放进监控平台监控项阈值建议为什么重要/storage/log 使用率超过 80% 告警日志写满是 vpxd 崩溃的首要诱因/storage/db 使用率超过 75% 告警数据库分区满会导致 vPostgres 不可写/storage/archive 使用率超过 80% 告警支持包/补丁包堆积经常被忽略机器证书剩余有效期小于 90 天告警给证书更换留足时间NTP 偏移超过 1 秒告警避免票据鉴权类隐性故障vpxd 进程存活进程消失立即告警第一时间发现服务中断如果你的监控平台管不到 VCSA 内部也可以用 VCSA 的管理接口去做基本的健康检查或者直接写一个简单的定时脚本采集 df 和证书有效期推到内部通信工具。重点不是工具多高级而是指标要全、阈值要合理。5.3 备份策略和灾备兜底VCSA 的文件级备份功能是个被严重低估的保命功能。在 5480 管理界面里可以配置备份计划把备份放到共享存储或 FTP。我建议至少每周做一次全量备份并且每个月做一次恢复演练。真到了 vPostgres 数据损坏、需要重建 VCSA 的那一步有备份和没备份恢复时间是几小时和几天的差别。另外VCHA 虽然能减少 vpxd 故障的恢复时间但它本身也有成本双倍资源、双节点数据同步、故障切换的复杂度。如果你管理的环境不大备好备份和恢复流程可能比盲目上 VCHA 更实际。我见过不止一次VCHA 配置不当导致的故障比它原本要救的故障还多。5.4 顺手再分享两个小技巧第一个VCSA 的 SSH 一定在平常就保持开启或者至少确保你有控制台访问权限。不然故障时想执行 service-control 都没入口在 5480 里开 SSH 虽然不麻烦但故障时多一步就是多一分钟恢复时间。第二个给 vpxd 日志做个简单的持久化。VCSA 本身的日志轮转会清理掉很多旧日志如果你想复盘故障前两小时到底发生了什么建议日常把 vpxd 和 vmon 的日志同步一份到外部日志平台。踩过几次坑之后你会发现这些历史日志在定位疑难问题时价值千金。