干过虚拟化运维的应该都有印象vCenter Server 6.0那个年代Windows版控制台里列着一大串VMware开头的服务看着心里就发怵。VMware Inventory Service和VMware VirtualCenter Server也就是大家常说的vpxd有些人口语里叫它virtual vCenter这几个服务一旦变成“已停止”你点“启动”十有八九会弹个错误框要么1053要么1067要么干脆一直卡在“正在启动”几分钟后报超时。这个问题不新鲜但每次遇到都挺折腾因为它的根因往往不在服务本身而在服务背后的数据库、证书和目录服务上。这篇文章就把我这些年排查和修复vCenter 6.0服务无法启动的过程一次性讲透包括依赖关系、日志定位、典型场景和修复步骤。不管是刚接手vCenter的运维新手还是被这个老版本折腾许久的老人应该都能从里面找到能直接用的排查思路。先声明一点以下内容都以vCenter Server 6.0的Windows版为背景。6.0的Linux版VCSA虽然是同一个版本号但服务机制完全不一样不在本文讨论范围。Windows版vCenter 6.0的核心服务基本都是Windows服务可以在services.msc里看到所以排查逻辑也更偏向系统服务和数据库这一套。1. 故障现象与依赖链为什么服务会一个带一个地挂掉1.1 先看清故障现象很多时候客户的反馈就一句话“vCenter打不开了。”打开vSphere Client或者Web Client连不上vCenter Server后台一看服务列表里一堆VMware服务停在“已停止”状态。这时候第一件事不是着急点启动而是先看清楚到底哪些服务停了哪些还在跑。以vCenter Server 6.0在Windows Server 2008 R2或Windows Server 2012上的典型部署为例服务管理器里常见的VMware服务包括服务显示名服务名作用VMware VirtualCenter ServervpxdvCenter核心管理服务VMware Inventory Servicevpxd-invsvc管理库存对象数据供vpxd调用VMware Directory Servicevmdird提供SSO的LDAP目录服务VMware Certificate Servicevmafd管理与签发vCenter相关证书VMware Identity Management Servicevmware-vmon管理vCenter内部组件状态VMware Postgresvmware-vpostgres嵌入式数据库不选SQL Server时使用我在排查时习惯先用命令行确认状态比图形界面快sc query vpxd sc query vpxd-invsvc sc query vmafd sc query vmdird sc query vmware-vpostgres每个服务会返回STATE字段如果是1 STOPPED那基本可以确认故障范围。把这些状态列出来你很快就能发现规律有些服务停了有些还在跑而这个“停了和没停”的分布往往就指向问题的源头。1.2 理清服务启动顺序和依赖关系vCenter Server 6.0的设计里服务启动关系大致是下面这样的数据库最先起来无论是后端的SQL Server还是嵌入式PostgreSQL。vmafd证书服务和vmdird目录服务要在vpxd之前就位它们负责vCenter的SSO登录和证书校验vpxd启动时要向它们查询令牌和证书。Inventory Servicevpxd-invsvc在vmafd和vmdird之后启动它要把vCenter对象库的数据加载进来然后监听来自vpxd的请求。最后才是VMware VirtualCenter Servervpxd。vpxd启动时不仅要连数据库还要连Inventory Service还要和SSO交互任何一环不通它都会报错。打个比方这就像一条流水线数据库是原材料仓库vmafd和vmdird是质检和门禁Inventory Service是半成品仓库vpxd是最后的组装车间。上游任何一个环节停工下游就会跟着停。这也是为什么很多人手动去启动vpxd会直接失败因为前置服务压根没起来。Windows服务管理器里也能看到依赖右键服务 → 属性 → 依赖项能看到vpxd依赖Inventory Service、vmafd等。但光看Windows层面的依赖还不够还要理解它们逻辑层面的依赖比如vmafd和vmdird之间的证书互信关系这个在Windows服务依赖里未必显示得那么清楚。所以我的经验是不要只依赖服务管理器那一栏的依赖列表要把vCenter自己的服务链路背下来。1.3 区分“起不来的服务”和“起来了又自己挂掉的服务”排查时还要区分两种现象一种是服务点了启动转几圈直接报错服务还是停止状态另一种是服务显示“正在启动”过几秒变成“已停止”中间没有任何提示。这两种情况对应的排查方向差别很大。前一种多半是Windows服务控制管理器层面就拒绝了常见于依赖服务没启动错误1068或者服务配置损坏。后一种则是服务进程已经在跑但启动过程中检测到自己所需的外部条件不满足主动退出。这时候Windows层面未必有详细的错误码必须去看vCenter自己的日志文件。我遇到过不止一次客户反馈“所有VMware服务都停了”最后定位发现是C盘空间耗尽vpostgres日志把磁盘撑满然后数据库服务异常退出连带vpxd、Inventory Service全部停掉。这种就是典型的“服务自己挂掉”而不是“起不来”处理起来反而简单先把空间释放出来再按顺序启动。2. 日志与系统状态排查前先搞清楚要看哪里2.1 Windows事件日志与服务错误码遇到服务起不来第一步永远是打开事件查看器eventvwr.msc看System和Application日志。服务启动失败的时候系统日志里会记录Service Control Manager的报错常见的几个错误码一定要眼熟错误码含义排查方向1068依赖服务或组无法启动看哪个依赖服务没起来先解决前置服务1053服务没有及时响应启动或控制请求服务启动超时常见于数据库连接超时、网络等待1067进程意外终止服务进程直接崩掉需要看服务自己的日志7024服务特定错误服务返回了自定义错误码需要结合服务日志别小看这几个数字它们能帮你大大缩小排查范围。1068基本可以断定问题是依赖服务没起1053和1067就需要深入看vCenter自己的日志判断是数据库连不上、还是证书校验失败、还是配置有问题。有一次我碰到vpxd报1053一开始以为是服务超时设置太短正想调注册表里的ServicesPipeTimeout后来查了vpxd.log才发现是数据库连接串里填的实例名写错了SQL Server根本连不上。所以错误码只是入口真正定位还得靠日志。2.2 vCenter服务日志的位置与关键字段vCenter Server 6.0的日志目录一般在C:\ProgramData\VMware\vCenterServer\logs\下面按组件分了子目录vpxdvCenter核心服务日志比如 vpxd.loginventoryserviceInventory Service日志比如 inventoryservice.log、inventoryservice-wrapper.logvmafd证书服务日志vmdird目录服务日志查看的时候有个小技巧vpxd.log通常写得比较啰嗦报错信息反而不容易被一眼抓到建议重点看包含ERROR、FATAL、Exception、Failed的行再看这些关键字前后的几十行上下文。用命令过滤会快很多findstr /i ERROR FATAL Exception Failed C:\ProgramData\VMware\vCenterServer\logs\vpxd\vpxd.loginventoryservice.log如果报的是一条数据库连接失败的错误比如Connection refused或者Invalid credentials那基本可以确认问题出在数据库层。如果报的是和vmafd握手失败那就要去查证书服务和目录服务。2.3 数据库层排查无论是vpxd还是Inventory Service启动时都会去连数据库。如果数据库服务没起来或者连接串配置不对或者账号密码不对服务都会失败。两种常见部署SQL Server部署服务端是Windows上的SQL Server。要确认SQL Server服务MSSQLSERVER或命名实例是不是在运行能否用sqlcmd或SSMS连上。嵌入式PostgreSQL部署vCenter自带的vmware-vpostgres服务要确认它是否在运行数据目录是否有足够空间。在6.0上嵌入式数据库默认端口是5432数据目录通常在C:\ProgramData\VMware\vCenterServer\data\vpostgres\检查端口监听netstat -ano | findstr :5432如果端口都没有监听说明数据库服务根本没起来。如果端口在监听再用客户端工具连接测试sqlcmd -S localhost -E -Q SELECT VERSION或者对PostgreSQLpsql -h localhost -U postgres -p 5432 -c select 1;数据库服务能正常响应再往上走查vmafd和vmdird数据库本身有问题就先解决数据库。磁盘满、文件损坏、服务账户权限变了都可能导致数据库服务起不来。数据库起不来的话后面所有VMware服务都是空转。3. 从依赖服务到核心服务几个典型故障场景的修复过程3.1 场景一数据库服务异常这是最常见的原因。我遇到过好几次客户反映vCenter所有服务都停了最后定位发现是C盘空间耗尽vpostgres日志把磁盘撑满然后数据库服务异常退出连带vpxd、Inventory Service全部停掉。处理步骤先看磁盘空间。在vCenter服务器上打开资源管理器确认系统盘和数据库所在盘剩余空间。如果空间不足先清理比如Windows临时文件、旧日志、Windows更新缓存。这个操作没有风险当场就能执行。确认数据库服务状态。服务管理器里找VMware Postgres嵌入式或SQL Server实例如果没在运行尝试手动启动。如果数据库能启动再尝试启动vmafd和vmdird然后启动Inventory Service最后启动vpxd。如果数据库服务本身起不来查看vpostgres日志常见错误是数据目录空间不足、数据文件损坏比如断电造成。数据文件损坏且没有备份时修复成本很高可能需要用PostgreSQL的工具做恢复但这一步风险很大建议先打虚拟机快照。注意服务启动顺序很重要。一次全选“启动”并不是好办法Windows会按依赖关系尝试但vCenter 6.0的依赖关系在逻辑上比Windows服务依赖更严格。手动按 数据库 → vmafd → vmdird → invsvc → vpxd 的顺序来一步步看哪一步失败比一次性乱点更容易定位问题。3.2 场景二vmafd和vmdird不稳定vmafdVMware Certificate Service和vmdirdVMware Directory Service是SSO的地基。它们出问题时一个典型现象是vmafd能启动但vmdird总是失败或者vmdird起来了vpxd仍然报SSO错误。排查方法查看vmafd.log和vmdird.log搜索ERROR、Failed。确认vmafd和vmdird之间是否建立了正确的互信。证书链出问题时vmdird日志里常能看到证书验证失败。检查配置目录是否完整比如vmdird的数据目录。处理方式如果vmafd或vmdird状态异常但数据库正常可以尝试重启这两个服务然后立即查看日志看是否恢复正常。如果日志里明确报了证书校验失败或者磁盘上证书文件缺失那就涉及到从备份恢复证书或者用vdcadm之类的工具重建SSO。注意6.0的证书管理工具不如6.5以后那么完善操作前务必先做虚拟机快照或者文件备份。这个场景下最怕的就是凭感觉乱删文件。vmafd和vmdird的数据目录一旦丢了整个SSO体系都会崩掉那时候就不是重启服务能解决的了。3.3 场景三证书过期导致服务无法接续vCenter 6.0里vpxd启动时要去vmafd那里做证书校验如果证书过期或者主机名不匹配vpxd也会启动失败但报错信息可能误导你去查数据库。实际上很多vCenter服务起不来的案例最后都指向证书。判断方法查看vpxd.log里有没有和证书、SSL、STS相关的错误。查看vmafd.log里有没有证书过期、证书链构建失败之类的日志。检查系统时间是否正确。这是个容易被忽略的点服务器系统时间不对证书校验必然失败。我遇到过整台服务器时间慢了好几天结果vpxd一直启动失败后来同步了时间就好了。处理方式如果只是证书过期可以尝试重新生成STS证书但步骤比较绕不同小版本命令不一样。建议先确定版本再查对应的官方KB。如果有之前的SSO备份可以通过vdcadm restore的方式恢复证书和SSO配置。命令大致是vdcadm.exe restore --file 备份文件 --password 密码这个场景下的核心建议是不要在没有备份的情况下做任何证书重置操作。证书一乱整个SSO体系都会崩塌到时候就不是重启服务能解决的了。3.4 场景四磁盘空间不足与数据库日志膨胀磁盘空间不足在vCenter 6.0上很常见尤其是嵌入式PostgreSQL部署。vpostgres的数据文件和WAL预写日志文件会持续增长如果运维监控没做到位C盘或数据盘爆满是迟早的事。处理步骤确认占用空间的“元凶”。用WinDirStat或PowerShell查看大文件目录重点检查以下几个方面C:\ProgramData\VMware\vCenterServer\data\C:\Windows\Temp\C:\Windows\SoftwareDistribution\Download\vCenter日志目录 C:\ProgramData\VMware\vCenterServer\logs\清理日志。老日志如果确认没用了可以压缩或迁移到其他磁盘。如果是SQL Server检查数据文件.mdf和日志文件.ldf占用考虑收缩日志。先做日志备份再执行DBCC SHRINKFILE不要直接删物理日志文件。如果是嵌入式PostgreSQL检查WAL目录不推荐手动删除WAL文件正确做法是先做vacuum和checkpoint再观察空间是否释放。提醒一句vCenter 6.0对数据库的读写很敏感数据库所在磁盘空间一旦告急服务状态会迅速恶化而且数据库日志会先把空间填满。所以日常监控里磁盘空间要放在最前面。3.5 场景五主机名解析和hosts文件惹的祸这个场景容易被人忽略但它确实能卡住vpxd的启动。vCenter安装之后主机名解析依赖系统自身的主机名和IP对应关系。如果服务器改了IP或者DNS记录被清掉了vpxd启动时做SSL握手就会失败。排查方法在vCenter服务器上ping自己的主机名看能不能解析到本机IP。执行nslookup确认DNS解析。查看hosts文件C:\Windows\System32\drivers\etc\hosts确认有没有异常条目。处理方式如果确认是解析问题可以在hosts里添加一条本地解析记录127.0.0.1 vcenter.mydomain.com vcenter注意别写错写错反而会让问题更复杂。改完hosts之后重启vmafd和vpxd再测试。4. 排查技巧与常见问题实录4.1 常见问题速查表症状可能原因处理方式vpxd启动报1053数据库连接超时、SSO交互超时检查数据库服务、网络、主机名vpxd启动报1068依赖服务未启动按顺序手动启动数据库 → vmafd → vmdird → invsvc → vpxdInventory Service一直“正在启动”数据库连接卡住、端口被占用检查数据库服务、监听端口、连接串vmdird起不来数据库目录异常、证书链损坏查看vmdird日志恢复证书或快照回滚vpxd.log里全是SSL握手失败证书过期或主机名不匹配检查系统时间、恢复或重建证书所有VMware服务全部停止数据库挂掉、C盘满先清理空间再按顺序启动服务4.2 几个值得留意的操作细节第一修改服务启动类型要谨慎。有些人为了“保险”把vpxd、Inventory Service等服务全部设为“自动”其实没必要vCenter 6.0的这些服务本身启动类型就是自动问题是它们依赖的服务没起来。而且有些服务即使设了自动启动顺序也不一定对Windows服务之间没有严格的依赖排序控制。第二检查服务账户密码。vCenter 6.0服务默认使用本地系统账户但如果你当时手动改成了域账户密码过期就会导致服务无法启动。排查时可以看一下服务属性的“登录”选项卡确认账户类型和密码状态。如果密码确实过期了重新输入新密码再启动服务。第三不要一上来就改服务超时时间。网上有些文章会教你改注册表里的ServicesPipeTimeout把服务启动超时从默认的30秒改成60秒甚至更长。这个操作在某些场景下有用但会掩盖真正的启动慢原因。我建议先定位问题而不是先延长等待时间。4.3 启动顺序与脚本化修复服务起不来的时候手动点服务管理器太慢了。我自己的习惯是写一个简单的PowerShell脚本按顺序做状态判断和启动$services (vmware-vpostgres, vmafd, vmdird, vpxd-invsvc, vpxd) foreach ($svc in $services) { $s Get-Service -Name $svc if ($s.Status -eq Stopped) { Write-Host Starting $svc ... Start-Service -Name $svc } elseif ($s.Status -eq Running) { Write-Host $svc already running } Start-Sleep -Seconds 5 }这个脚本只适合初步启动场景真正定位问题仍然需要看每步是否成功。如果你想更稳一点可以在Start-Service之后检查服务状态如果没过几秒又停了说明这一环还有问题脚本就停下来等你排查。5. 换个思路vCenter 6.0服务故障的长期方案5.1 服务起不来的根因往往在日常排查多了就发现vCenter 6.0服务无法启动根子往往不在服务本身而在长期缺乏维护监控不到位磁盘满了没人发现。补丁没打证书库处理旧版bug。虚拟机快照长期保留导致底层磁盘I/O变差数据库服务启动超时。服务账户被管理员清理或改密码影响服务启动。所以处理完眼前故障之后我一般会给客户一个后续建议把这台vCenter纳入监控尤其是磁盘空间、服务状态、证书有效期这三个维度。磁盘空间可以看性能计数器服务状态可以用监控平台的服务探测功能证书有效期可以写个脚本定期检查。这些都属于低成本的日常巡检但能避免绝大多数vCenter服务“突然起不来”的尴尬。5.2 从6.0向更高版本迁移的考量还有一个长期方向值得考虑。vCenter Server 6.0的架构里Inventory Service是独立服务它既是功能也是故障点。到了6.5之后vCenter的组件模型做了整合vpxd和Inventory Service合并到一个进程里整个服务关系简单了很多部署形态也转向了VCSAvCenter Server Appliance。如果你的vCenter 6.0已经维护了很多年而且这台机器越来越不稳定我建议在做完数据备份后认真评估一下升级或者迁移而不是反复在6.0上做修补。当然升级不是一刀切要评估现有环境的ESXi版本、vSphere Client兼容性、数据库迁移方式以及业务中断窗口。但至少从服务稳定性的角度看升级到新架构能避开一大半“服务起不来”的坑。5.3 日常巡检建议给一台vCenter 6.0做基础巡检我觉得至少要覆盖这几项磁盘空间系统盘、数据盘、数据库日志盘。服务状态核心VMware服务是否全部Running。系统时间与标准时间源偏差不要超过5分钟。证书有效期vCenter证书和SSO证书的到期时间。数据库备份vCenter本身的配置和数据库是否有定期备份。这些巡检项不需要很复杂的工具脚本加告警就能覆盖。我见过太多客户平时不管等到vCenter挂了才想起来备份结果恢复成本非常高。说了这么多其实最想分享的就一句话vCenter Server 6.0的服务问题本质上是依赖链问题找对链条按顺序排查比什么都重要。我自己在排查这类问题时习惯先把服务管理器、事件日志、vCenter日志三样东西摆在面前再动手很少一上来就重启。因为有些时候重启反而掩盖了根因过几天又出问题。如果你现在正被Inventory Service和VirtualCenter Server起不来折磨建议先别慌按这篇文章的顺序一层层查。数据库服务、vmafd、vmdird、磁盘空间、证书这五个点里大部分情况下能找到病根。最后再分享一个小技巧处理完故障之后记得在当前环境里把服务启动顺序和关键日志路径记下来做成一张故障排查卡。下次再遇到类似问题翻一下这张卡能省下一两个小时。这台vCenter 6.0就算再老摸透了它的脾气维护起来也没那么可怕。