vCenter 6.0服务无法启动？从依赖链、数据库到证书的完整排障指南

如果你管过Windows版的vCenter Server 6.0，大概率碰到过这种场景：某天打开vSphere Web Client，页面转圈半天之后直接超时；RDP到vCenter所在的Windows服务器，services.msc里一排VMware服务要么停在“已停止”，要么点启动后几秒又变回“已停止”，其中VMware vCenter Inventory Service和VMware VirtualCenter Server永远是最显眼的两个。标题里说的“inventory、virtualvcenter等服务无法开启”，其实就是这两个核心组件挂了。

这篇东西不打算复述官方文档，只写我在6.0环境里排查这类服务启动失败的完整思路和操作记录，适合正好被这个故障卡住的运维同事，也适合刚从5.x/6.0转手维护vCenter的人。先给个结论帮你稳住心态：绝大多数情况下不是服务本身坏了，而是它的依赖链出了岔子，按依赖顺序查下去基本能救回来。

1. vCenter 6.0服务栈：为何一个服务倒下会引发连环瘫痪

1.1 6.0组件与依赖关系速览

vCenter Server 6.0的Windows版是一套典型的“多个Windows服务协同工作”的架构，跟后来6.5、6.7的VCSA一体机完全不同。6.0里每个核心功能都是一个独立的Windows服务，互相之间有明确的先后依赖。当时排障的第一步，就是先把这张服务清单刻在脑子里：

装过6.0的人应该都有印象，安装向导会让你选SSO站点、填数据库DSN、开Inventory Service端口，这些配置装完后就固化在服务里。日常维护时，很多人很少主动去看这些服务，直到系统某个节点出问题，才发现它们是一个整体。

1.2 先搞清楚“启动顺序”再动手

服务之间的依赖关系是理解这个故障的核心。SSO在最上游，Inventory Service和vpxd在中下游，Web Client虽然前端独立，但登录和查询都要依赖背后的服务。

如果把服务启动看成一条流水线：SSO先起来，负责发令牌；随后目录服务提供用户数据；证书服务保证组件之间SSL通信互信；Inventory Service起来后才能向vpxd提供库存数据；最后vpxd才能正常注册并对外工作。任何一个上游没起来，下游服务要么启动失败，要么起来后因为连不上依赖又自动退出。

这就解释了为什么标题里的“inventory、virtualvcenter”会一起无法开启。很多时候你打开服务管理器，看到的是好几个服务都停在“已停止”，就容易误判为“多个服务同时损坏”。实际上源头往往只有一个：SSO没起、数据库连不上、证书过期，其中一个出问题，后面全军覆没。

我处理这类故障时，基本不直接狂点服务管理器里的“启动”按钮，会把重点放在确认“到底哪一层先挂的”。找到最上游的失败点，下游问题就迎刃而解。6.0这种Windows服务架构虽然维护起来繁琐，但排查链路反而清晰，比黑盒一体机容易定位多了。

2. 第一现场取证：服务状态、事件日志和各组件的日志路径

2.1 services.msc里的失败提示到底说了什么

服务管理器是大多数人打开的第一个窗口，但很多人只盯着服务状态看，忽略了Windows给的关键线索。手动启动服务后，系统会弹出错误提示，这些错误码是排障的第一手信息：

看到1053，说明服务已经接到启动命令但内部初始化没完成，重点查组件日志；看到1068，说明依赖链已经断了，先查依赖；看到1069，不用怀疑，直接看服务属性里的“登录”选项卡，检查那个账户还能不能用。

还有一种很容易让人抓狂的情况：点启动后服务管理器短暂显示“正在启动”，几秒后自动变回“已停止”，连错误弹窗都没有。这种往往是服务内部做了“依赖未就绪就主动退出”的处理，比如Inventory Service启动时连不上它依赖的服务，会直接结束进程。这时候服务管理器给不了更多信息，必须去事件查看器和日志文件里挖。

2.2 从日志关键字判断根因方向

vCenter 6.0把各组件的日志集中在ProgramData下，默认路径基本是C:\ProgramData\VMware\vCenterServer\logs。如果是更早的6.0小版本，可能在C:\ProgramData\VMware\VMware VirtualCenter\logs，找不到就用文件管理器搜索一下。

几个关键日志位置：

打开日志文件后，不要从头到尾读，直接搜关键字。先用findstr /i "error exception"把最近的错误行筛出来，然后重点看第一条Error出现的时间点和上下文。我习惯把第一条Error当作分水岭——它之前的日志表示启动流程走了多远，它之后的错误往往都是衍生问题。

如果发现日志文件时间戳根本没有更新，说明服务在初始化早期就卡死了，这时候Windows事件查看器（系统日志和应用程序日志）比组件日志更管用。事件日志里VMware相关来源的记录会给出异常堆栈，指向具体是哪一类资源访问失败。

从成百上千行日志里快速定位根因方向，我总结了几条高频关键字：

• SQLState 08001、Login failed for user——数据库连接失败或账号认证失败
• PKIX path building failed、CertificateExpiredException——SSL证书链不可信或证书过期
• UnknownHostException——主机名解析失败
• No space left on device——磁盘空间不足
• Access denied——文件或注册表权限被拒

看到哪一类，就去处理哪一类。这个“关键字先行”的习惯能省下大量时间。

3. 数据库链路排查：ODBC、密码过期与连接串

3.1 先用客户端工具验证数据库真实可用性

vCenter 6.0的数据库有两种常见形态：一种是安装时选的内嵌SQL Server Express，适合几十台主机的小环境；另一种是生产环境更常见的外部SQL Server或Oracle。无论哪种，Inventory Service和vpxd都要读写数据库，数据库这条链路挂了，两个服务必然起不来。

排查数据库，很多人容易犯一个错误：只在服务管理器里点“启动服务”，然后对着日志猜。正确做法是先绕过vCenter服务，直接向数据库发起一次真实连接，确认数据库本身是否可用。

在vCenter服务器上打开“控制面板 -> 管理工具 -> ODBC数据源管理器”，在“系统DSN”里找到vCenter相关配置项，点“配置”走一遍测试连接。这一步能验证ODBC驱动是否正常、DSN配置是否正确、网络是否通。

如果用的是SQL Server，更直接的办法是用sqlcmd实测：

sqlcmd -S <数据库主机名\\实例名> -U <用户名> -P <密码> -d <数据库名> -Q "SELECT 1"

能返回1，说明数据库连接串和网络没问题；报错就看是“无法连接”还是“登录失败”。前者查端口、防火墙、SQL Server服务状态；后者查账号密码和账户策略。

3.2 密码过期和ODBC位数的坑

数据库账号密码过期，是我在6.0故障里见到最高频的坑，没有之一。很多企业的数据库账号是DBA在建库时顺手建的，SQL Server默认策略里如果开了“强制密码过期”，180天后账号就会失效。失效那一刻，vCenter里所有依赖数据库的服务集体罢工，而且故障时间点非常规律，基本就是账号创建后的第N天。

遇到这类问题，先用T-SQL确认账号策略：

SELECT name, is_expiration_checked, is_policy_checked FROM sys.sql_logins;

如果一个登录名的is_expiration_checked为1，说明启用了密码过期。改掉策略：

ALTER LOGIN [vCenter用户] WITH CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF;

这是最稳妥的处理方式，不用改密码、不用动vCenter配置，策略关掉后数据库层面立即放行。

另一种常见问题是ODBC驱动位数不对。vCenter 6.0的部分组件是32位进程，部分组件是64位进程，DSN配置在“64位ODBC管理器”里能测试通过，但32位服务连不上。如果测试连接时遇到“找不到数据源名称且未指定默认驱动程序”，去“32位ODBC数据源管理器”里单独创建同名DSN，再测试一次。

3.3 数据库空间与日志文件膨胀

还有一种隐蔽的数据库问题：表空间或日志文件满了。vCenter数据库会持续写入任务记录和库存数据，如果磁盘被写满，服务在启动阶段写入一条记录就抛异常退出。

先检查数据库所在磁盘的空间，再检查SQL Server日志文件是否已经撑到上限。嵌入式数据库的话，数据文件就在vCenter本机，占用系统盘；外部数据库的话，检查远端数据库服务器的磁盘。

如果发现数据库日志文件特别大，不要在生产环境直接收缩，至少先确认是“已截断的正常增长”还是“异常膨胀”。6.0的数据库日志异常膨胀经常和vpxd在某个时间点疯狂写错误日志有关，根因不消除，收缩完很快又会涨回来。

改vCenter侧数据库配置前记住一条铁律：不管是改连接串还是改密码，先把vmware-vpxd.cfg、vminventory.properties这类配置文件完整备份一份。6.0的配置改动不像现代产品有完善的校验机制，一个分号写错位置都能让服务起不来，备份是唯一的后悔药。

4. SSL证书与主机名解析：Inventory Service拒启的第二大根因

4.1 证书过期后的典型日志特征

证书问题排第二，但实际处理起来比数据库更费劲，因为vCenter内部是多服务间互相走SSL通信，任何一个环节的信任链断裂，服务就拒绝启动。

日志里出现PKIX path building failed、unable to find valid certification path、CertificateExpiredException这类关键字，基本就是证书链路出问题了。vCenter 6.0的组件在启动时会互相校验证书，Inventory Service既是客户端又是服务端，既要校验别人的证书，也要把自己的证书交给别人校验。

最典型的场景就是证书过期。vCenter自签名证书都有固定的有效期，环境跑了好几年，某天突然集体“无法开启”，很多人第一反应想不到证书，因为在服务管理器里看证书是看不见的，只有日志里那一行CertificateExpiredException才是唯一提示。

4.2 检查证书有效性与修复边界

看证书有效期，在vCenter服务器上打开MMC，添加“证书”管理单元，选择“计算机账户”，到“个人”和“受信任人”存储里找包含vCenter主机名的证书，逐一检查有效期。也可以偷懒直接敲命令：

certutil -store My

命令列出来的结果比MMC直观，能快速看到所有证书的开始时间和结束时间。

如果确认是证书过期，下一步一定不要用MMC直接“删除证书”或“重新申请”。vCenter内部证书与SSO信任链是强关联的，手动删除会让问题扩大化，从“服务起不来”变成“SSO彻底紊乱”。

正确的做法是用VMware提供的证书轮换工具。vCenter 6.0安装目录里有vdcadmintool.exe和Certificate Manager这类管理工具，专门处理SSO、目录服务、证书服务之间的内部证书轮换。运行前务必把当前证书存储和C:\ProgramData\VMware\vCenterServer\cfg目录整体备份，证书轮换不是一键完成就万事大吉，换完还要把全部VMware服务重新启动一遍，让新证书在组件之间完成重新注册。

这里提醒一句：7.0以后很多人在网上问的方式不适配6.0，6.0的证书后台机制相对老旧，工具使用路径也不一样，排查时尽量找6.0对应的文档。

4.3 主机名解析错乱与服务通信失败

证书问题往往和主机名解析问题一起出现。vCenter组件之间通信时，会用vCenter的主机名去连接对方，如果DNS解析不到、hosts文件被清理，或者机器名改过，日志里就会出现UnknownHostException。

检查方法很简单：先nslookup vCenter主机名，再看hosts文件里有没有该主机名的记录，以及证书信息里的CN字段是不是和当前主机名完全一致。6.0对主机名大小写都敏感，即便看起来一样但大小写不同，也可能导致握手失败。

在处理主机名问题时，我踩过一次很典型的坑：机房搬迁移机后，vCenter服务器换了IP，DNS也改了，但hosts文件里还保留着旧IP，服务全部起不来。把hosts更新成新IP后，再按依赖顺序重启服务，几分钟恢复正常。这类问题数据库正常、证书也正常，卡就卡在一个最不起眼的名字解析上。

5. 按依赖链手工拉起服务：SSO到vpxd的完整顺序与等待节奏

5.1 推荐的恢复顺序与等待时间

在确认数据库、证书、主机名这些基础项没问题后，剩下的就是按依赖顺序把服务逐个拉起来。这个操作看起来简单，但节奏很重要，我见过太多人把所有服务框选后统一点“启动”，结果下游比上游先起来，最后全部失败。

推荐顺序如下：

1. VMware vCenter Single Sign-On
2. VMware vCenter Directory Service
3. VMware vCenter Certificate Service
4. VMware vCenter Inventory Service
5. VMware vSphere Web Client
6. VMware VirtualCenter Server

每一个服务启动后，不要急着启动下一个，至少等30秒到1分钟。SSO启动后尤其要等，它是整个认证体系的核心，起来后还需要时间完成令牌服务注册。Inventory Service起来后，建议等2分钟再启动vpxd，因为vpxd启动时要向Inventory Service同步库存数据，Inventory没完全就绪时vpxd会连接失败。

判断“服务是否真正就绪”，不要只看services.msc里显示“正在运行”，用sc query看服务状态更准确：

sc query "VMware VirtualCenter Server"

输出里STATE字段显示RUNNING的同时，最好再看一眼组件日志的时间戳确实在更新，才算真正起来了。

5.2 一键启动脚本与“反复自杀”的处理

手工逐个点击太累，我习惯在一个维护窗口内用批处理脚本按顺序启动，省心很多：

net start "VMware vCenter Single Sign-On" timeout /t 30 /nobreak net start "VMware vCenter Inventory Service" timeout /t 60 /nobreak net start "VMware vSphere Web Client" timeout /t 30 /nobreak net start "VMware VirtualCenter Server" pause

脚本的重点不是让所有服务同时起来，而是强制留出等待间隔。如果你不确定当前环境里服务显示名是否完全一致，先用sc query state= all | findstr /i "VMware"看一遍，再套进脚本。

遇到“服务起来后又自动停止”的情况，先看服务属性的“恢复”页签。很多人为了省事会把失败后的操作设成“重新启动服务”，但在6.0里这招往往适得其反。如果根源是依赖没就绪，服务重启多少次都会再退出，还会把日志刷得很大，给后续排查制造麻烦。

还有一种情况容易被忽略：服务登录身份。vCenter服务如果配置的是域账户，域账户密码过期或域控制站不可达，服务同样起不来。查看服务属性“登录”选项卡，如果服务原来用Local System就能跑，就保持Local System，不要随便改成域账户。很多“莫名其妙无法开启”的案例，排查到最后就是服务账户问题。

6. 其他隐藏诱因与日常巡检清单

6.1 磁盘空间、系统时间、杀毒软件三类隐形杀手

有几次排查到最后，问题不在服务本身，而在外部环境。系统盘空间被日志塞满，服务启动要写日志文件，写入失败直接退出，日志尾部能看到No space left on device。清磁盘时注意先停掉占用日志句柄的服务，否则日志文件删了空间也释放不了。

系统时间漂移也是个隐蔽问题。vCenter组件之间的SSL证书校验和SSO令牌都有时间有效期，时间差超过几分钟，就会表现为“证书校验失败”或“令牌无效”，日志里出现各种握手异常。让vCenter服务器跟域控或权威NTP服务器配置时间同步，能解决不少间歇性重启故障。

杀毒软件和安全软件也可能拦截VMware进程的关键操作，导致服务启动到某个环节就崩溃。如果环境里存在第三方安全软件，把VMware安装目录、日志目录和数据目录加入排除项，再观察服务是否恢复。

把常见诱因整理成一张自查表，遇到问题直接对照着过：

6.2 面向6.0环境的运维自查表

经历过几次深夜抢修后，我在管6.0环境时形成了一套固定习惯。每个月检查一次数据库账号的密码过期策略，这是最大的定时炸弹；每季度看一次证书有效期，给告警留提前量；平时注意给vCenter服务器所在分区保留20%以上的空闲空间。

vCenter 6.0已经是很老的产品了，新部署的系统现在基本都走VCSA一体机路线，维护方式完全不同。还在跑6.0的环境，多少都有历史包袱，但只要把数据库、证书、依赖顺序这三条主线盯住，大部分“服务无法开启”的问题都能在半小时内定位并解决。

我在6.0上反复踩坑后的体会是：服务起不来的场景，90%不是服务本身坏了，而是它依赖的数据库或证书通信失效。第一步永远是打开事件查看器看最近一次Error的时间点，再顺着组件日志找第一条Error，然后对号入座。一个小技巧，维护窗口内动任何配置前，先把C:\ProgramData\VMware\vCenterServer\cfg目录和证书存储完整备份一份，真出问题恢复起来比从零重建快得多，这是我被教训过好几次之后才养成的习惯。