1. 故障背景：VCSA服务集体“invalid”的真相
搞虚拟化的同行看到这个报错应该都不陌生：某天vCenter Server Appliance（VCSA）管理界面打不开，浏览器刷不出登录页，外部PSC/VC通信断掉，SSH上去执行service-control --all-services --status一看，大量服务状态不是running，也不是stopped，而是“invalid”。
先说这个状态的准确含义。invalid不是“服务挂了”那么简单的概念。它指的是systemd或者vmon守护进程无法识别该服务的注册状态——具体来说，服务单元（unit）没有被正确加载，或者该服务的启动依赖出现了不可解析的环路/断链，又或者服务残留的状态数据与当前单元定义对不上。很多刚接触VCSA的人第一反应是“服务崩了，重启一下”，但直接restart往往没有任何效果，因为systemd对invalid状态的单元默认拒绝执行start操作。
这个故障的高发场景很典型，我见过的基本集中在这么几类：
- VCSA所在ESXi主机非正常断电，虚拟机强制关机后重启。
- 存储滞后或快照回滚，导致VCSA文件系统状态与实际配置不一致。
- 磁盘空间被日志塞满，服务状态持久化失败。
- VCSA版本升级/补丁安装过程中断。
这个故障最麻烦的地方在于表面现象和真实原因脱节。一眼看过去是“服务无效”，实际上八成都不是服务本身损坏，而是服务管理器（vmon）或系统级的依赖环境出了问题。所以处理这个问题的核心逻辑不是“修某个服务”，而是“先修能让服务被系统识别的基础环境”。下面就把我的排障过程完整拆开讲。
2. 诊断思路：先搞清楚是“谁病了”
2.1 第一步：SSH进VCSA，确认系统基本状态
在浏览器打不开vCenter界面的时候，SSH是唯一可靠的入口。VCSA默认SSH服务是关闭的，但当你已经能登入ESXi主机时，可以从VCSA虚拟机的控制台直接操作，或者在ESXi的“编辑设置”里临时开启SSH。成功登录后，第一件事不是急着看服务，而是确认系统本身还喘不喘气。
先看磁盘，看内存，看根文件系统是否只读。我用过的检查命令组合：
df -h free -h systemctl status uptime这一步极其关键。VCSA的/存储分区如果满了，后面的所有修复动作都会失败。我遇到过一次故障，表面现象是服务全部invalid，实际原因只是/storage/log被vpxd的日志撑到100%，systemd在写状态文件时直接报只读文件系统，于是所有服务状态全部失效。那次如果不先看磁盘，上来就重启服务，大概率把系统搞得更糟。
磁盘确认无误后，第二步要确认网络和DNS解析是否正常。VCSA对内网DNS依赖非常强，/etc/hosts里写死了主机名对应的IP，如果IP变了或者hosts内容被篡改，vmon和vpxd都会拒绝正常启动。
hostname cat /etc/hosts我当时处理的案例里，就是因为某次迁移后IP变了，但主机名解析还是旧的，导致所有vCenter服务起不来。ping 主机名能通，但要确认解析到的IP是不是当前网卡实际IP。
2.2 第二步：用service-control看服务状态，读懂invalid含义
VCSA的常用服务管理命令是service-control，而不是直接用systemctl。这里解释下为什么：VCSA里有相当一部分服务（vpxd、vsphere-ui、vmonapi、sso等）是由vmon守护进程管理的，不是原生systemd服务。service-control是vmon对外封装的命令行工具，它会跟vmon通信，而不是直接操作systemd。
所以当你执行：
service-control --all-services --status看到的输出大致是这个样子的：
vmonapi RUNNING vpxd INVALID vsphere-ui INVALID sps INVALID vcha STOPPED ...RUNNING好理解，STOPPED也好理解，INVALID就是vmon无法加载该服务的定义。注意，这里的INVALID和systemd的failed不是一个概念。systemd里failed是指服务启动失败，而INVALID在vmon体系里的意思是“vmon不认识这个服务，或该服务的依赖状态让它无法启动”。
我习惯用一句话概括：INVALID是“服务管理者本身不知道该拿这个服务怎么办”，不是“服务拒绝工作”。
所以继续排查的方向就变成：为什么vmon会不认识这些服务？
2.3 第三步：查看vmon日志，定位元凶
VCSA里vmon是连接systemd和上层vCenter服务的中间层。它的日志在：
/var/log/vmware/vmon/vmon.log搜索包含INVALID、ERROR、FATAL的记录。我在实际故障中看到过典型报错分为两类：
一类是“unit file not found”或“unit is masked”——单元文件被屏蔽/丢失，比如/etc/systemd/system/multi-user.target.wants里的软链接被意外删除。另一类是“dependency loop”或“failed to load unit”，说明服务的依赖关系无法建立。
第一类问题大概率出在文件系统损坏或人为误操作上；第二类问题往往跟/etc/hosts、网络配置、证书目录等基础条件相关。vmon在加载服务定义时会去解析这些条件，一旦条件不满足，就标记为INVALID。
看完vmon日志后，再去systemd层面确认单元状态：
systemctl list-unit-files | grep -i "service" | grep -i "vpxd" systemctl status vpxd如果systemctl显示Loaded: not-found，说明单元文件确实不存在或链接断了。如果Loaded正常但Active是failed，说明服务启动过但中途退出。这两种情况的后续处理方式完全不同，诊断这一步不能偷懒。
3. 核心原因剖析：服务为什么会“无效化”
3.1 非正常关机和快照回滚：最常见的起源
VCSA本质上是一个预优化过的虚拟机操作系统（Photon OS），它对文件系统一致性的要求比传统通用Linux更严格。非正常断电后，文件系统虽然能通过fsck自动修复，但服务状态文件和单元文件的软链接底层inode可能已经损坏，尤其是/etc/systemd/system下的动态链接。
快照回滚也是个高频诱因。很多管理员习惯在对VCSA做升级前打快照，回滚时直接把虚拟磁盘状态拉回旧时间点。但注意：vCenter的数据库、证书、配置文件和缓存之间是有“时间戳咬合”的。快照回滚后，磁盘文件回到过去，但vmon守护进程的一些运行期状态可能没能同步回滚，或者更糟糕——某些存储在内存RPC通道里的会话状态直接错乱，最终造成服务注册表出现无效项。
3.2 /etc/hosts与主机名解析错乱
这个问题容易忽略，但它在我处理的故障里至少占三成。VCSA安装时绑定了FQDN和IP，/etc/hosts里有类似这样的行：
127.0.0.1 localhost ::1 localhost x.x.x.x vcsa.corp.local vcsa注意，VCSA不允许在hosts里把实际IP映射到localhost，而且hostname必须与hosts里配置的名称一致。vpxd启动时要大量依赖内部DNS解析做节点间通信，一旦hosts配置出问题，比如IP写错、旧的IP没有清理，vmon加载服务时就会反复重试然后超时，最终状态被标记为INVALID。
3.3 磁盘空间和文件系统只读
这个是物理层面的隐形杀手。VCSA默认分区不算宽裕，长时间运行的vCenter会产生海量日志。如果/storage或者/var/log被占满，systemd和vmon在创建临时状态文件、PID文件或者写套接字时就会失败。很多时候服务本身没坏，但因为systemd连PID文件都写不进去，最终单元被标记为INVALID。
检查命令：
df -h / /var /tmp /storage/log特别关注/storage/log，如果Use%接近100%，先释放空间。日志清不掉怎么办？可以临时删除过期的vpxd日志归档：
find /storage/log/vmware/vpx/ -name "*.gz" -mtime +3 -delete这一步是治标，能抢出几GB空间让服务先起来。
3.4 单元文件损坏与依赖断裂
VCSA里有些服务单元文件是从模板动态生成的，比如vpxd的unit里会包含环境变量引用和User指定。如果某个引用的环境变量文件被破坏或不存在，systemd加载单元文件时会报解析错误。这种情况下的invalid不是vmon的锅，而是systemd的unit parser就拒绝了。
验证手段是执行：
systemd-analyze verify /etc/systemd/system/vpxd.service如果输出报错，说明单元文件本身有问题。修复思路是定位到缺失的引用项，补齐文件或修正单元定义，而不是尝试强制启动服务。
4. 故障处理实操：从快速恢复到深度修复
4.1 动手前的备份与回退策略
修VCSA有一个原则：能快照，先快照。无论当时的故障看起来多紧急，只要ESXi主机上还有快照能力，就应该先给VCSA做一个一致性快照。快照成本很低，但能让你在修复失败后有后悔药吃。
如果VCSA本身无法做在线快照（比如存储不支持），至少执行一次关键配置的备份：
ls /etc/vmware-vpx/ tar -czf /tmp/vcsa-config-backup.tar.gz /etc/vmware-vpx/ /etc/vmware-sso/把备份包拷到外部存储，然后再开始修复。这一步不是浪费时间，是给后面的所有命令兜底。
4.2 方法一：快速重置加重启（适用于轻度故障）
如果你执行service-control --all-services --status发现invalid的只是少数几个辅助服务，且vmon本体RUNNING，可以尝试快速重置：
service-control --reset service-control --start --all-services--reset是vmon提供的一个特殊参数，它会重新注册和加载所有服务定义，重置运行状态缓存。这个命令不会格式化数据，不会改动配置文件，它的作用是让vmon“忘掉”当前的无效状态，重新去读一遍服务定义。
执行完reset后不要立刻启动，先执行：
service-control --all-services --status确认INVALID是否已变成STOPPED。变成STOPPED意味着vmon已经重新认识这些服务了，此时再启动成功率会高很多。
如果reset后仍然是INVALID，说明不是运行期状态问题，而是服务定义/依赖层面的硬伤，往下看方法二和方法三。
4.3 方法二：按依赖顺序手动拉起关键服务
VCSA服务之间有严格的启动顺序，犯懒直接--start --all-services在健康状态下没问题，但在故障状态下会触发依赖竞争。正确做法是手动按顺序拉起。
我整理的关键服务启动顺序如下（不同版本略有差异，但核心骨架一致）：
# 1. 先确认vmon本身能跑 service-control --start vmonapi # 2. 启动基础服务 service-control --start vmafdd service-control --start vmdird service-control --start vmcad # 3. 启动中间层 service-control --start vmonapi service-control --start vpxd # 4. 启动UI service-control --start vsphere-ui每个命令之间建议间隔10到15秒，给服务一点初始化时间。不要直接串行用 && 连接，因为前一个服务只是“开始启动”，并不代表“完成启动”，等它完全ready后再拉起下一个更稳妥。
验证是否完全就绪的方法有两种：
# 查看vmon判断的启动状态 service-control --status vpxd # 直接看端口是否监听 netstat -tlnp | grep 443 netstat -tlnp | grep 5480如果12345表示端口正常监听，说明服务起来了。如果服务状态从STOPPED变到了RUNNING，但端口没出现，那要怀疑服务内部是否在反复崩溃——这时候去看/var/log/vmware/vpxd/vpxd.log。
4.4 方法三：处理单元文件级别的损坏
如果reset无效，方法二的拉起也报“unit not found”或“job failed”，说明要处理unit文件层面的问题了。
先列出所有标记为invalid的服务对应的unit：
systemctl list-units --all | grep invalid这里的invalid对应systemd的行，注意看行首的UNIT名和LOAD列。如果LOAD列显示error，表示单元文件加载失败。
典型修复场景如下：
场景一：unit文件miss掉软链接。正常unit文件在/usr/lib/systemd/system/或/etc/systemd/system/中，但multi-user.target.wants里的软链接丢了，导致虽然服务二进制还在，但系统不知道要在多用户模式下拉起它。
修复方式：
systemctl enable vpxd注意，enable不只是设置开机启动，它会从unit文件所在目录重新生成软链接到target目录。这往往能修复软链接丢失问题。
场景二：unit文件引用了不存在的环境变量文件。查看报错：
systemd-analyze verify /usr/lib/systemd/system/vpxd.service输出如果出现EnvironmentFile: No such file or directory，找到文件中引用的路径，比如/etc/sysconfig/vpxd，看这个文件是否被误删。解决方案是重建该文件或从同版本VCSA中拷贝同文件过来。
场景三：服务被mask了。VCSA中有些服务如果系统判定为不安全，会把它mask掉，导致即使enable也无法启动。mask在systemd里比disable更严厉，它把unit入口指向了/dev/null。
处理：
systemctl unmask vpxd systemctl start vpxd操作层面，以上每一步操作都要在vmon服务仍存活的前提下进行。如果vmon本身已经挂了，systemd和vmon之间会出现连锁的invalid，这时候要先修vmon：
systemctl restart vmon这个命令是直接在systemd层面重启vmon守护进程。vmon起来之后，再尝试service-control --reset。
4.5 实操记录：一次典型的INVALID恢复过程
下面完整记录一次我处理过的故障操作流程，供参考。某套VCSA 7.0升级后重启，vSphere Client无法登录，且执行status后大量服务显示invalid。
当时我的操作序列是：
- SSH登录VCSA，执行
df -h，确认磁盘有空间。 - 执行
service-control --reset，发现无效状态不消失。 - 查看
/var/log/vmware/vmon/vmon.log，定位到错误：Failed to load vpxd: unit failed to load metadata。 - 执行
systemctl status vpxd，报Loaded: error。 - 执行
systemd-analyze verify /usr/lib/systemd/system/vpxd.service，发现EnvironmentFile /etc/vmware/vpxd-env不存在。 - 检查发现
/etc/vmware/vpxd-env为空文件且被误删，从同版本VCSA的备份中恢复该文件，权限设置为600，属主root:root。 - 执行
systemctl daemon-reload，重新加载unit定义。 - 执行
systemctl reset-failed vpxd，清除系统记录里该单元之前的失败状态。 - 执行
service-control --start vpxd，服务由invalid变为running。
恢复过程看起来步骤不多，但关键转折点在找到那个丢失的环境变量文件。如果没有做第3步的日志排查，没有第5步的verify验证，后面可能就会陷入“重启无效、服务还是invalid”的死循环里。
5. 常见问题与排查技巧实录
5.1 故障速查表
下面把我在多次排障中用到的判断路径整理成表格，方便直接对照操作：
| 现象 | 优先排查方向 | 推荐动作 |
|---|---|---|
| 大量服务显示invalid | /etc/hosts与主机名解析 | 比对hostname与网卡IP，清理hosts残留 |
| 服务invalid+vmon报unit error | 单元文件缺失/损坏 | systemctl enable + daemon-reload |
| 服务invalid+磁盘全满 | /storage/log占用 | 清理日志归档，释放空间 |
| 服务invalid+系统时钟偏差大 | NTP与证书时间窗 | ntp同步，重启vmon |
| 少数服务invalid且reset能恢复 | vmon运行期状态错乱 | service-control --reset再启动 |
| 所有服务invalid且vmon都起不来 | 文件系统只读/脏状态 | fsck或快照回滚替换 |
5.2 排障命令自查清单
经常有运维同行问我，能不能给一个“万能命令”一次搞定。说实话，VCSA的故障很少有万能药，但如果非要列一个最常用的动作序列，我通常是这个顺序：
# 查看磁盘，排除空间问题 df -h # 检查vmon日志，找根因 tail -100 /var/log/vmware/vmon/vmon.log # 重置服务注册状态 service-control --reset # 先拉起vmonapi service-control --start vmonapi # 按依赖顺序拉起关键服务 service-control --start vpxd service-control --start vsphere-ui # 最后看全局状态 service-control --all-services --status注意：上述命令中如果某一条执行报错，先停下来分析报错内容，不要硬着头皮继续跑后面的命令。VCSA的排障最怕“脚本式执行”——照着网上的攻略一条条敲，却忽略了当前环境的实际报错。每个环境报错不一样，处理路径就不一样。
5.3 几个容易踩坑的小细节
细节一：不要轻易重启VCSA虚拟机。有些管理人员一看到vCenter打不开了，第一反应是在ESXi里强制重启VCSA虚拟机。这个动作如果遇到根本原因是磁盘损坏或者文件系统不一致，强制重启会加重损坏。先SSH进去看一圈，确认物理资源无碍再做重启决策。
细节二：不要把systemctl和service-control混为一谈。前面说过，VCSA里的vCenter域服务由vmon管理，而系统级服务（如sshd、networkd）由systemd管理。理论上，用systemctl直接操作vCenter域服务虽然能触发启动，但不会更新vmon里的服务状态。如果只是用systemctl启动服务而vmon状态不同步，服务表现还是invalid，这会让你误以为故障没有解决。
细节三：证书过期也会导致服务invalid。有些VCSA服务启动时会校验证书有效期，如果机器时间被拨乱或者证书过期，vmon会拒绝加载服务定义。遇到怎么reset都无效的情况，不妨看一眼/var/log/vmware/vmware-sso/idm.log或者时钟同步状态。之前遇到过某台VCSA时间慢了两个小时，SSL握手全面失败，看起来像服务故障，实际是对时问题。
5.4 关于日志的补充说明
排障过程中日志永远比看命令输出重要。VCSA各个服务的日志分布比较散，我常用的是这几个位置：
/var/log/vmware/vmon/：vmon日志，第一排查对象。/var/log/vmware/vpx/：vpxd日志，服务起不来时候配合查看。/var/log/vmware/vsphere-ui/：UI服务日志，登录页打不开时重点看。/var/log/vmware/vmware-sso/：SSO相关日志，认证依赖问题看这里。
在外面干活没有完整日志的情况下，很多判断都是盲猜。有日志的情况下，每个invalid都有明确背锅方——这个观念要建立起来，能避免走很多弯路。
6. 写在最后的经验之谈
我个人处理VCSA故障十几次下来，最大的体会是：vCenter服务大量显示invalid，多半不是服务坏了，而是服务被“看不见的手”掐住了。这只看不见的手可能是磁盘、可能是hosts解析、可能是单元文件、也可能是vmon本身。遇到这个故障，宁可多花10分钟把基础检查做完，也不要急着甩出“重启大法”。
另外一个值得养成的习惯是：VCSA的维护窗口期尽量避开频繁快照回滚。vCenter不像普通虚拟机可以随意“时间旅行”，它的组件间时间咬合太紧了。做任何操作前，多用service-control --all-services --status确认服务状态，并且在每次生产变更前备份好vmon相关的服务状态记录——哪怕只是把service-control --all-services --status的输出保存为文本，都能在故障恢复时省掉大量定位时间。
最后分享一个小技巧：如果遇到大批服务invalid且修复时间紧迫，在确认vmon本身正常的前提下，可以尝试：
service-control --stop --all-services把vmon的守护连接全部断开，再执行：
service-control --start --all-services这种“全停全启”比只启单个服务更能重置vmon内部的依赖图，有时候反而比service内部的小操作管用。但它有个前提：磁盘空间充裕、hosts解析正常、且没有单个服务卡死导致整体启动超时。满足这三个条件时，偶尔能有奇效。当然，这招不适合频繁使用，毕竟vCenter服务的优雅起停优先级高于一切粗暴操作，能用精确启动解决的问题，就不要用全局重启去试探。
