凌晨两点被微信震醒群里一位兄弟连发三条消息“vCenter登不上了root密码忘了SSO密码也忘了控制台还飘着log Disk Exhaustion on vc的红色报警怎么办”这种场景我太熟了——以前在客户现场三台VCSA全这样最后救回来用了三个小时。先说结论root密码、SSO密码和日志盘满看着像三个问题但实际上是一条线root权限没了SSO重置就无从下手SSO认证反复失败日志盘就会被刷满。这篇就按真实救火顺序把VCSA的root密码恢复、SSO管理员密码重置、日志盘满排障讲透。正在带vCenter 6.5/7.0/8.0的环境或者眼前正好出事的同学可以直接照着做。1. 故障组合拳密码丢失和日志盘满为什么会同时出现1.1 三个故障之间的因果关系先说一个经常被误解的点log Disk Exhaustion on vc报警不是因为磁盘本身坏了而是/storage/log分区使用率超过了安全阈值。真正需要问的是日志分区为什么会在短时间内被写满。如果排查后发现大量日志来自vmafd和vpxd的认证失败记录那多半就是root或SSO密码失效后在后台持续报错。vCenter里的root密码和SSO密码完全是两套体系。root是VCSA底层Photon OS操作系统的超级管理员SSOvSphere SSO是整个vCenter的身份认证服务默认管理员是administratorvsphere.local。很多人把这两个密码混在一起管理一旦交接文档没更新或者密码库丢失就会出现“root也忘了、SSO也忘了”的双重尴尬。更重要的是这两个故障会相互放大。SSO密码失效后vpxd服务向SSO发起认证会一直失败这个失败过程会不断往/storage/log/vmware/vpxd/vpxd.log和/storage/log/vmware/vmafd/vmafd.log里写错误日志。管理员在这段时间如果又反复用错误密码尝试登录vSphere Client认证组件会记录更多失败日志。日志增长速度在故障期间可能远高于正常水平于是本身就紧张的分区直接爆掉。所以正确的故障观不是“我要分别搞定root、SSO和日志盘”而是“我必须在root权限中断的情况下先把本地root恢复再重置SSO最后清理日志”。顺序反了后面每一步都会很被动。1.2 root、SSO、日志盘各自的管理入口用一张表理清它们的差异故障对象所属层次日常入口丢失影响恢复工具root密码VCSA底层OS账号SSH、控制台、VAMI5480无法进入系统维护、无法执行shellGRUB引导重置SSO管理员密码vCenter身份认证域账号vSphere Client、API、SDK无法登录UI和API服务认证异常vdcadmintool日志盘满/storage/log分区root shellvCenter服务异常、告警风暴日志清理与轮转这张表里的核心逻辑是SSO密码和日志盘满的恢复都依赖root权限。没有rootvdcadmintool跑不了日志分区也清不了。所以不管头上有多少个报警第一步永远是恢复root shell。1.3 动手前必须做的安全准备救火前先给自己留后路。这台VCSA如果运行在ESXi上我强烈建议在操作前打一个虚拟机快照。快照会占用数据存储空间但相比误操作把VCSA搞到无法启动这点代价完全值得。快照位置选择C:\Users\Administrator\Documents\这种习惯不是ESXi的虚拟机操作菜单里右键“快照”即可命名记上时间。另外一定要确保你能通过ESXi Web Client或直连方式打开VCSA的虚拟控制台。因为接下来要重启VCSA并在GRUB阶段按键SSH大概率是不可用的。如果你连VCSA虚拟机在哪个ESXi上都不知道先花五分钟查清单不要盲目登录一堆主机找。还有一个细节修改密码前顺手记录一下当前vCenter的版本和构建号。方法是在ESXi控制台登录root后运行vCenter-Server.conf没必要直接看VAMI页面或者/etc/vmware/下的版本文件。至少在解决后你需要在文档里写下这次事故发生的版本上下文。后面排查时可能要用到。2. 恢复起点在GRUB引导阶段重置VCSA的root密码2.1 版本差异6.5/7.0/8.0的GRUB操作基本一致VCSA从6.5开始就是基于Photon OS的虚拟设备7.0和8.0的内核引导方式没有本质变化都是用GRUB2。所以下面的重置方法适用于6.5到8.0。唯一要注意的是不同版本的GRUB菜单默认是否显示不太一样。6.5默认会显示菜单7.0开始很多构建版本把菜单隐藏了需要开机时按住Shift键调出GRUB。如果你的VCSA是通过ESXi控制台访问的重启进入BIOS自检后要立刻连按e或Shift。按晚了就可能直接进系统而你又没有密码只能再重启一次。这里没有捷径纯靠手速和耐心。2.2 一步一步拿到root shell完整的操作顺序如下在ESXi中右键VCSA虚拟机选择“电源” - “重新启动”。如果虚拟机没有响应就用“关闭电源”再“打开电源”但尽量优先软重启防止文件系统受损。打开虚拟控制台在启动画面阶段按Shift或e调出GRUB菜单。找到以linux开头的那一行。注意不是linuxefi也不是vmlinuz那一行而是包含BOOT_IMAGE的长行。把光标移到行尾先打一个空格然后追加以下内容rw init/bin/bash这里有两个关键参数。init/bin/bash告诉内核跳过正常启动流程直接进入一个bash交互环境rw则要求内核在挂载根分区时直接以读写模式挂载。如果只写init/bin/bash很多VCSA版本进入后根分区是只读的你执行passwd时会看到“cannot lock /etc/passwd”之类的报错。按CtrlX或F10启动稍等十几秒会看到类似bash-5.2#的提示符。如果根分区还是只读执行mount -o remount,rw /如果不确定当前挂载状态可以先执行mount | grep / 查看输出里有没有rw。执行修改密码passwd root输入两遍新密码。密码要求满足VCSA的系统密码策略至少8位最好包含大小写和数字。如果密码太简单PAM会直接拒绝。修改成功后不要直接断电重启执行exec /sbin/init或者reboot -f这样系统会按照正常流程继续完成启动避免文件系统状态异常。2.3 重置后如何判断是否成功重启后先用root账号在控制台登录一次确认能正常进入shell。然后访问VAMI管理界面也就是https://vcenter-ip:5480用root和新密码登录。如果能进VAMI说明底层OS的root已经恢复可以继续处理SSO。这里有个很容易忽略的细节VAMI的登录账号就是OS的root账号不是SSO账号。如果你在VAMI能登录但vSphere Client仍然报认证失败那就说明问题出在SSO层而不是root层。很多人在这一步误判以为root没改好其实root已经修好了下一步该做SSO密码重置了。2.4 这个阶段常见的坑我在实际环境里见过两种典型的翻车。第一种是没加rw参数passwd写不进去报错却提示“authentication token lock busy”很多人会怀疑是密码策略问题其实只是文件系统只读。解决办法就是重新挂载。第二种是修改完密码后直接强行关闭电源导致Photon OS的LVM元数据不一致重启后进入文件系统修复界面卡住。这种时候不要慌让它跑完修复如果修复完还是起不来再用快照回滚。还有个小经验如果VCSA上有多个网卡或远程控制卡GRUB阶段按键时最好用ESXi控制台不要用第三方远程管理工具因为键盘输入时序可能滞后按e的时候容易被吞。我见过在Docker容器里跑vCenter不是远程控制台延迟导致进不了GRUB。稳妥起见直接站到机房或者用ESXi Web Client的虚拟控制台。3. SSO管理员密码重置vdcadmintool与ldapmodify双通道3.1 为什么你不需要重装vCenterSSO密码存储在VCSA本地的vmdir数据库中管理工具是VMware自带的vdcadmintool。这个工具可以在不失去vCenter配置和已有数据的情况下强制重置vCenter单点登录域中的管理员账号密码。它相当于“门锁钥匙丢了但你可以拿着房产证去换锁芯”不需要砸墙更不需要把整栋楼推倒重建。如果有人告诉你“SSO密码忘了只能重装vCenter”绝对不要信。重装意味着丢失所有配置、历史告警、权限设置、标签和分布式交换机配置代价极其惨重。遇到SSO问题先找vdcadmintool。3.2 vdcadmintool标准操作用root账号SSH登录VCSA执行/usr/lib/vmware-vmdir/bin/vdcadmintool此时会出现一个交互式菜单。不同构建版本的选项略有差异但“Reset account password”这一项基本都在选项3。输入3回车工具会提示输入账号DN。默认SSO管理员DN是cnAdministrator,cnUsers,dcvsphere,dclocal如果你的SSO域不是默认的vsphere.local而是自己在部署时改成corp.local那DN就要对应改成cnAdministrator,cnUsers,dccorp,dclocal然后连续输入两次新密码。密码策略默认要求至少8位且包含大写字母、小写字母、数字和特殊字符。如果工具返回类似Password is modified successfully就说明重置成功。如果返回错误常见原因是DN写错或者vmdir服务状态异常。重置完成后退出工具等1到2分钟让SSO服务缓存刷新再用vSphere Client登录。如果你在重置之前已经因为多次失败导致账号锁定可能需要稍等一会儿或重启vmafd服务。3.3 当vdcadmintool无法正常修改密码时绝大部分情况下vdcadmintool都能成功但如果它报了LDAP连接错误或数据库错误通常表示vmdir服务状态不正常。这时候先检查服务service-control --status --all | grep -E vmdir|vmafd如果vmdir没有运行先启动它service-control --start --all如果服务死活起不来看日志tail -n 200 /var/log/vmware/vmafd/vmafd.log另一种备用通道是直接用ldapmodify但前提是你能在root shell下连接到本地的LDAP端口。命令类似ldapmodify -h localhost -p 389 -D cnAdministrator,cnUsers,dcvsphere,dclocal -x -W回车后输入管理员密码。但这里有个逻辑悖论——管理员密码本身已经忘了除非你通过vdcadmintool或底层数据库手段重置了管理员密码否则ldapmodify也无法认证。所以在SSO密码全丢的场景下vdcadmintool是唯一现实可靠的手段ldapmodify更多是在vdcadmintool已经改完密码但后续还有字段需要微调时才会用到。3.4 SSO密码重置后立刻要做的事改完SSO密码别急着关控制台。先做三件事用新密码登录vSphere Client确认UI能正常进入。确认vCenter各项服务运行正常重点看vpxdservice-control --status --all | grep vpxd检查环境里是否有依赖administrator密码的集成账号比如vCenter HA、内容库、备份调度器、vRealize Operations等。如果这些系统配置里使用的是旧密码要同步更新否则后续会陆续出现认证失败。另外提醒一句如果这次密码泄露是因为人员离职、共享账号滥用建议重置后立刻修改SSO域内的其他管理员密码并检查vsphere.local域中是否有多余的权限组。4. 日志盘满的紧急清理从df到揪出日志元凶4.1 先确认报警来源和分区占用处理完root和SSO接下来才是让VCSA真正恢复健康的关键——日志盘。log Disk Exhaustion on vc报警的根源是/storage/log分区使用率超过阈值。进入root shell后第一时间执行df -h /storage/log你会看到类似Filesystem Size Used Avail Use% Mounted on的输出Use%如果超过80%基本就能确认报警原因是本地产出日志太多。再用du查看具体目录维度du -xh --max-depth2 /storage/log 2/dev/null | sort -rh | head -30-x是限制在同一文件系统内避免统计到挂载的其他分区--max-depth2可以控制目录层级避免递归信息过深。4.2 日志爆涨到底是谁的锅通过du拿到了占用Top目录后逐一看这些文件的末尾内容早一分钟定位到元凶就能早一分钟止血。下面这张表是VCSA上最常见的日志爆涨元凶日志文件常见爆涨原因初步处理建议/storage/log/vmware/vpxd/vpxd.logSSO认证失败、数据库连接失败、证书错误检查vpxd配置与SSO连通性必要时清空文件/storage/log/vmware/vpostgres/postgres.log慢查询、vPostgres异常、归档堆积检查数据库负载清理旧归档日志/storage/log/vmware/vmafd/vmafd.logSSO认证风暴、LDAP连接失败查看具体错误码确认SSO服务状态/storage/log/ssh/sshd.logSSH被扫描或暴力破解尝试配置防火墙限制禁用密码登录/storage/log/message/ 或 syslog系统服务崩溃循环查看具体服务单元错误举个例子如果SSO密码错误导致vpxd反复认证失败vpxd.log里会频繁出现SSO authentication failed或Failed to authenticate。这种情况下光删日志没用必须先修复SSO密码。如果证书过期那vpxd.log里还会出现certificate verify failed那就需要进一步检查VCSA的证书有效期。4.3 紧急清理的具体操作确认了分区情况和日志元凶之后开始清理。最直接有效的命令是清空已知的大日志文件内容cat /dev/null /storage/log/vmware/vpxd/vpxd.log为什么要用cat /dev/null 而不是rm因为vpxd服务正在运行它持有这个文件的文件描述符。如果你rm了文件空间不会立刻释放反而会形成一个删不掉、看不见的“幽灵日志”直到服务重启。清空文件内容则能马上让磁盘空间回到可用状态。如果需要删除早期轮转日志可以按时间过滤find /storage/log -type f -name *.log.* -mtime 3 -delete也可以手动触发logrotate让系统按正常规则压缩和轮转/usr/sbin/logrotate -f /etc/logrotate.d/vmware-vpxd如果分区已经满到连服务都无法正常重启先清出至少10%到20%的空间再执行service-control --start --all。不要一上来就直接重启服务否则磁盘满情况下服务启动过程中可能写入更多日志导致卡死。4.4 长期措施防止下一次爆盘紧急清理只是止血。要避免日志盘再次被写满建议做这几件事检查并调整VCSA日志轮转策略。/etc/logrotate.d/下有一堆vmware-*.conf默认策略不一定适合你的日志增长速度。可以在对应配置中加入daily、rotate 7、compress、maxsize 100M等参数让单文件超过100MB时就强制轮转。配置远程日志转发。VCSA支持通过syslog把日志发送到集中日志平台本地只保留最近几天。这样即使某个服务疯狂刷日志本地存储压力也会大幅降低。在vCenter告警阈值里把日志分区使用率预警调到75%。默认的log Disk Exhaustion触发时往往已经到90%以上留给你的反应时间太短。5. 复盘与常态化防御把这次事故变成制度5.1 一次完整事故的时间线为了让你对处理节奏有概念我模拟一个典型时间线00:30 收到log Disk Exhaustion on vc告警通过vSphere Client登录失败。00:50 确认SSO密码和root密码均失效决定走GRUB恢复流程。01:10 通过ESXi控制台重启VCSA进入GRUB编辑模式重置root密码成功。01:30 用root SSH登录执行vdcadmintool重置administratorvsphere.local密码。01:45 使用新密码登录vSphere Client成功开始排查日志分区清空vpxd日志。02:00 vCenter恢复正常后续所有服务启动正常更新密码记录。这个时间线里最耗时间的不是执行命令本身而是确认GRUB按键时机和等待服务重启。越熟练整个过程越接近30分钟。5.2 恢复后的服务健康检查救火成功后不要急着关电脑。建议按照这个清单过一遍service-control --status --all确认没有红色[DOWN]状态的服务。然后检查证书有效期尤其是机器证书和SSO证书。证书过期是VCSA很多“奇怪故障”的幕后黑手包括vpxd反复报错、登录跳转异常、日志突然暴涨等。如果你对命令行不熟可以直接登录VAMI在证书管理页面查看每个证书的到期时间。同时检查一下备份状态。如果你配置了VCSA内置文件备份确认最近一次备份是成功的。如果从没配过备份那这次事故之后赶紧补上这比任何救援技巧都重要。5.3 几条防呆建议最后分享几条我自己的习惯不威逼只利诱。第一密码库要“双人可见”。无论是团队共用的Keepass还是Bitwarden必须保证至少两个人知道主密码避免某个管理员突然失联后整个团队被锁在vCenter外面。第二root和SSO密码每90天轮换一次。这个周期足够短也足够让管理员记住。轮换时同步更新密码库、计划任务和备份脚本。第三把这篇事故处理流程沉淀成团队内部的一页纸应急手册。不用长篇大论只要把GRUB改密码命令和vdcadmintool菜单选项写清楚。下次有人遇到同样问题按手册执行就行。我把这套流程沉淀成了团队内部的一页纸应急手册后来再遇到类似问题基本30分钟解决。说句实在话vCenter本身并不容易坏大多数所谓“灾难”都源于密码管理失控和日志空间裸奔。别等到凌晨被震醒现在就打开VAMI看一眼日志分区剩余空间把密码存进共享密码库五分钟后你会感谢自己。