“移除”这个东西卡住了比你装不上还难受。在 vCenter 里点了移除 Supervisor任务列表转圈十几分钟甚至一整天进度条纹丝不动事件日志里又看不到明确的报错——如果你负责 vSphere with Tanzu 或 Workload Management 环境大概率遇到过这种“删不掉”的尴尬。这篇日志排查实战就是我处理多个 vSphere Supervisor 移除卡住场景后的完整记录。这篇文章会从移除任务后台到底在做什么讲起然后带你按顺序检查 vCenter 侧和 ESXi 侧的日志最后给出常见卡住根因和对应的处理建议。全程以一个虚拟化运维工程师的实际视角展开没有绕弯子的理论每一步都有具体命令和过滤关键字。适合正在做 vSphere with Tanzu 下架、Workload Management 清理、或者接手了“前人留下的半死不活环境”的同行参考。1. 先搞清楚Supervisor 移除时后台到底在做什么很多人一遇到移除卡住就直接在群里问“能不能强制删”我建议先按住这个冲动。移除 Supervisor 不是简单地把一台虚拟机销毁它背后是一套编排流程在逐个清理依赖对象。不明白这个流程日志放在你面前你也看不出来问题在哪。1.1 移除前必须满足的前置条件vSphere Supervisor 本质上是一个运行在 vSphere 集群上的 Kubernetes 控制面它负责承载 TKGTanzu Kubernetes Grid工作负载集群通过 vSphere Namespace 给开发团队提供资源隔离。当你执行移除操作时WCPSVCWorkload Control Plane ServicevCenter 里的管控面服务会先做依赖检查。依赖检查没过移除任务就会卡在最初阶段甚至直接失败。我整理了一下实际环境中最常见的几个硬性前置条件所有 TKG 工作负载集群必须先删除干净包括 UI 里还能看到注册信息的集群。所有 vSphere Namespace 里的 PVC、Pod、服务必须已经清理不能有残留对象处于 Terminating 状态。如果使用了 NSX-T 作为容器网络插件NSX Manager 必须可达网络相关组件必须健康。承载 Supervisor 管理虚拟机的那几台 ESXi 主机必须在线、可管理。vCenter 本身的 WCPSVC、vpxd 等服务要处于正常状态不能已经僵死。你可以把 Supervisor 移除想象成拆一栋楼先搬空家具工作负载、再拆隔断墙命名空间和网络对象、最后才能炸承重墙Supervisor VM。顺序错了或者前面没拆完后面必然卡住。1.2 移除流程的执行链路与三种典型卡点移除任务的链路大致是这样的你在 vSphere Client 点击“移除 Supervisor”后vpxd 创建一个任务调用 WCPSVC 的接口WCPSVC 在内部编排各个子任务包括删除 Kubernetes Namespace、清理网络对象、删除资源池和文件夹最后销毁 Supervisor 管理虚拟机、更新 Workload Management 状态。这个过程中WCPSVC 会通过 vpxd 与 ESXi 通信也会直接调用 NSX 的 API。我遇到的移除卡住90% 都集中在三个环节上第一个是前置校验反复不过。界面上会提示“仍有工作负载集群存在”或“仍有命名空间未清理”但你去检查却发现 UI 里看不到东西这种往往是 TKG 集群注册信息残留WCPSVC 每次重试都卡在同一个校验上。第二个是网络对象清理挂起。尤其是接了 NSX-T 的环境WCPSVC 要删除 Tier-1 路由器、分段、组等对象一旦 NSX 有问题Manager 失联、API 超时、对象被占用移除任务会一直重试日志里反复出现 nsx 相关的报错。第三个是 Supervisor VM 销毁阶段超时。任务走到最后一步要先把 Supervisor 管理虚拟机关机再销毁。如果虚拟机里的组件没有正常响应、VMware Tools 不工作、宿主机进入维护模式就会在 power off 或 destroy 这一步卡住。搞清楚这三个卡点之后你才知道为什么要去日志里定位“具体是哪个环节”。接下来就是日志清单和收集姿势的问题。2. 排查前先把日志清单和收集姿势弄明白日志排查最忌讳的是漫无目的地翻文件。vCenter 和 ESXi 的日志目录很大全量翻一遍既浪费时间也看不出重点。我通常的建议是知道哪个组件负责什么事对应去查哪份日志能省下至少一半时间。2.1 vCenter 侧需要重点看的日志文件vCenter 侧最重要的日志是 WCP 服务相关的也就是 WCPSVC 的日志。它记录了 Workload Management 生命周期中绝大部分操作细节包括命名空间删除、网络清理、Supervisor 创建和销毁。日志文件作用优先级/var/log/vmware/wcpsvc/wcpsvc.logWCPSVC 主日志移除 Supervisor 时核心排查文件最高/var/log/vmware/wcpsvc/wcpsvc.log.0滚动后的历史日志任务跨天时可能要看高/var/log/vmware/vpxd/vpxd.logvCenter 任务框架日志可以看到 UI 任务如何下发、有没有抛 fault高/var/log/vmware/inventoryservice/inventory-service.log库存信息同步日志一般是辅助排查中/var/log/vmware/vmafd/vmafd.logSSO/证书相关日志仅在怀疑身份认证影响任务时看低如果你通过 SSH 登录 vCenter可以看到这些文件。注意 wcpsvc.log 有时候会非常大尤其卡了好几天的情况下几百 MB 甚至几 GB 都很正常。先看修改时间确认你关心的移除操作发生在哪个时间段再去过滤。2.2 ESXi 侧需要重点看的日志文件当 vCenter 侧日志指向“对某台主机操作失败”或“虚拟机删除超时”时你要登录对应的 ESXi 主机看宿主机侧的日志。ESXi 侧的关键文件有这几个日志文件作用/var/log/hostd.log宿主机代理日志记录从 vCenter 收到的虚拟机操作比如关闭电源、注销、销毁/var/log/vmkernel.log存储和虚拟机磁盘相关的内核日志VMDK 删除失败时这里会有线索/var/log/crx/ 目录如果 ESXi 启用了容器运行时CRX相关服务日志在这里可辅助判断 Supervisor VM 内部状态ESXi 侧的排查思路是这样的vCenter 发出的删除操作最终会落到 hostd 上hostd 执行成功或失败都会留痕迹。你去看某个 VM 的 Unregister、Destroy 操作有没有执行、返回了什么错误就能知道问题到底是在 vCenter 编排层还是在宿主机执行层。2.3 三种日志收集方式对比实际环境里我根据情况不同会用三种方式收集日志第一种是最快的直接在 vSphere Client 的监控菜单里看任务与事件这个我们下一步详细讲。第二种是 SSH 到 vCenter 或 ESXi直接 grep 关键字适合已知大概时间范围和目标关键字的情况快速定位。第三种是通过 vCenter 的 VAMI 管理界面5480 端口导出支持包适合要给厂商技术支持提供完整日志、或者你想一次性打包留档的场景。如果有 PowerCLI 环境也可以用 Get-VCLog 这种现成命令拉日志但说实话在紧急排查时SSH 进去 grep 是效率最高的。我甚至会把 grep 结果直接重定向到 /tmp 下的文件然后用 scp 拉回本地分析避免 SSH 会话卡在超大日志上。3. 手把手实操从任务详情一路查到根因这一部分是最核心的实操章节。我按照实际排查顺序把它拆成四步。每一步做什么、看什么、得到什么结论都会写清楚。这套顺序是我多次处理下来总结出的路径基本能覆盖绝大多数移除卡住场景。3.1 第一步先把“任务与事件”里的细节读全很多人卡住之后第一件事就是翻日志我反而建议先回 UI。vSphere Client 的“监控”菜单里“任务”面板会列出所有 vCenter 任务移除 Supervisor 对应的任务通常在列表里。点开任务详情你能看到它的目标对象、状态和发起时间。任务详情里如果有“子任务”列表每一行都是一个阶段比如“正在删除 vSphere Namespace”“正在关闭 Supervisor 虚拟机”。子任务停在哪个阶段你的日志排查就集中到哪个阶段身上。比如我见过任务死在“正在删除命名空间”阶段那就去 wcpsvc.log 里查这个命名空间为什么删不掉。这里要说一个容易误判的点进度条不动不代表任务一定死锁。WCPSVC 内部很多操作是带重试机制的重试等待期间 UI 进度不会更新但后台日志里时间戳还在走。所以判断“真死”还是“慢”的唯一标准是看日志时间戳是否持续更新。3.2 第二步从 vpxd.log 追出调用链UI 任务信息只是表象接下来要进 vCenter 日志确认任务有没有正常下发到 WCPSVC。SSH 到 vCenter进入 /var/log/vmware/vpxd 目录过滤 vpxd.log 里的关键字grep -i supervisor\|workloadmanagement /var/log/vmware/vpxd/vpxd.log | tail -n 300vpxd 是 vCenter 的调度引擎UI 上所有任务都在这里留痕。你会看到任务被创建、调用目标服务、返回结果等一系列记录。重点关注有没有异常 fault比如 NotFound、InvalidState、Timedout 这类字眼。vpxd 日志的好处是能帮你在任务层面确认这个移除任务到底有没有真正递交给 WCPSVC还是 UI 都已经显示失败了、后台却有幽灵任务。如果 vpxd 里压根没有这个任务记录问题可能出在前端或者会话层面不是 WCPSVC 本身的问题。不过说实话vpxd 日志信息粒度比较粗它更像一个“总调度台”真正的细节要往下走。3.3 第三步从 wcpsvc.log 定位报错原话这是整个排查的核心环节。WCPSVC 的日志记录了移除编排过程中每个操作的执行情况和报错信息。登录 vCenter 后执行grep -iE remove|delete|destroy|namespace|supervisor|nsx /var/log/vmware/wcpsvc/wcpsvc.log | tail -n 300如果日志量太大先把时间窗口缩小比如你知道任务开始于 2025-03-15 凌晨就先用这段日志查那一个小时的内容grep 2025-03-15T02: /var/log/vmware/wcpsvc/wcpsvc.log | grep -iE ERROR|WARN | tail -n 200WCPSVC 日志里的报错往往比较明确。这里我贴一段典型的报错样式具体内容以你实际环境为准但关键字结构类似2025-03-15T02:33:12.123Z WARN [nsx-client] Failed to delete Tier-1 router /infra/tier-1s/ns1-t1, exception: connection timeout, retrying... 2025-03-15T02:34:10.456Z ERROR [wcpsvc] Error deleting Namespace ns1 due to exception: NSX API invocation failed after 5 retries, task will be aborted看到这段东西你就能直接判断卡在 NSX 网络清理而不是什么玄学问题。同样如果日志里反复出现 “Timed out waiting for VM to power off” 或者 “VM not found”那就是虚拟机销毁阶段的执行问题。这里提醒一句wcpsvc.log 是会滚动的如果任务是几天前开始的你还需要检查 wcpsvc.log.0 这些旧日志文件。别只盯着当前日志文件看。3.4 第四步到 ESXi 上验证残留对象日志指向 ESXi 侧时你就要去宿主机的日志和对象状态里确认。比如 wcpsvc.log 里明确写“对主机 192.168.10.20 上的虚拟机执行销毁操作超时”那就 SSH 到那台 ESXi先看虚拟机还在不在vim-cmd vmsvc/getallvms | grep -iE supervisor|wcp|namespace拿到 VMID 之后看它的电源状态vim-cmd vmsvc/power.getstate VMID如果虚拟机还在已注册状态而 vCenter 显示移除任务已经失败你需要判断是这台虚拟机还留在 vCenter 清单里那就从 UI 或 PowerCLI 删除还是它只残留在 ESXi 的存储目录里那就检查 hostd.log 为什么没删干净。hostd.log 里通常会有类似 “Failed to delete VM files: file locked by another process” 这样的具体原因。到了这一步基本就能把问题到底在哪一层看得很清楚了要么是 WCPSVC 编排层面要么是 NSX 网络层面要么是 ESXi 执行层面。下一步就该针对根因做处理了。4. 常见卡住根因速查与处理建议日志看多了之后你会发现移除卡住的原因也就是那么几类来来回回就那几个坑。我按实际遇到频率高低整理了一份速查表后面逐个展开。日志中的典型表现根因方向处理建议wcpsvc.log 里反复出现 namespace 删除失败 / Kubernetes Namespace 清理超时工作负载集群或 PVC 残留先重新确认并删除遗留 TKG 集群清理 PVC/Pod再重试移除日志中出现 NSX API 调用失败 / Tier-1 删除超时NSX-T 组件异常或网络对象残留恢复 NSX Manager 可用性人工清理残留网络对象后重试日志中出现 VM power off / destroy 超时Supervisor VM 状态异常恢复主机在线确认业务已摘除后强制关机再删除虚拟机wcpsvc.log 长时间没有任何输出任务也不推进WCPSVC 服务僵死在维护窗口重启 wcpsvc 服务观察新的重试时间戳任务显示失败但 UI/事件里仍有残留或重复任务vCenter 任务框架或数据库冲突避免并发删除操作必要时重启 vpxd 任务服务4.1 工作负载命名空间与 PVC 清不干净这是最常见的卡住原因之一。移除 Supervisor 时WCPSVC 要求所有 vSphere Namespace 下不能还有未清理的对象。但很多时候你觉得自己已经删干净了实际上还留着一堆 Terminating 状态的 PVC、Pod或者某个 TKG 集群的注册信息还挂在 vCenter 里。排查思路是如果环境里 Workload Management 还留有一口气就先用 kubectl vsphere 插件连上 Supervisor逐个命名空间检查 PVC 和 Pod。发现 Terminating 状态的资源先确认业务已经停了然后手动清理。如果 TKG 集群的注册信息残留在 vCenter你需要找到对应集群条目确认它已经不存在后清掉引用。这类问题处理完善之后重新发起移除任务往往就能往前走。4.2 网络对象残留或 NSX 不可用NSX 相关的问题在带 NSX-T 的环境里占比很高。WCPSVC 在删除命名空间和 Supervisor 时会调用 NSX 的 API 去清理 Tier-1、分段、安全组等对象。如果 NSX Manager 失联、证书过期、或者某个 Tier-1 下还挂着负载均衡器等依赖对象API 调用就会失败并不断重试。日志里的关键字一般是 nsx、tier-1、segment、group、timeout 这种。处理方法分两步先把 NSX 服务恢复健康确认 Manager 的状态、连接器和节点都正常然后登录 NSX UI 检查残留对象手动清理掉“应该随命名空间一起消失但没消失”的网络资源。这里要特别小心的是NSX 的网络对象可能被多个集群共享你不能凭感觉乱删。确认对象只属于这台 Supervisor、没有被其他工作负载引用再清理。4.3 Supervisor VM 状态异常Supervisor 管理虚拟机本身也是一个普通虚拟机跑在某个 ESXi 主机上。如果它进入了不可控状态比如内核 panic、VMware Tools 失去响应、虚拟机文件存储故障移除任务在 power off 这一步就会超时。处理思路是确认这台 VM 对应的业务已经不再需要比如所有工作负载集群都已经删除然后在 vCenter 里尝试正常的关闭电源操作。如果正常关机超时可以考虑使用“强制关闭电源”之后重新执行移除任务。生产环境务必确认这台 VM 上没有还在跑的业务再操作。移除失败后期你就会发现日志里看到 “Timed out waiting for VMware Tools to shutdown” 这类字样时大概率就是虚拟机内部失控。4.4 WCPSVC 服务僵死有些时候不是移除本身卡住了而是编排服务 WCPSVC 本身出了问题。怎么判断看 wcpsvc.log 的时间戳。如果任务开始后的半小时内日志还能持续滚动突然就完全静默了而且 vpxd 里显示调用 WCPSVC 接口超时那就说明服务僵死或内部线程池被占满了。这时候可以在维护窗口执行服务重启。vCenter 8 上可以通过 service-control 命令操作service-control --stop wcpsvc service-control --start wcpsvc重启后观察到 wcpsvc.log 出现新的重试日志说明服务恢复了任务会重新进入编排流程。这里我要多嘴一句重启之前你要知道这个操作会影响正在进行的 Workload Management 生命周期操作不要在业务高峰期随手执行。4.5 vCenter 任务残留或数据库冲突还有一种情况比较隐蔽任务其实已经失败或恢复了但 UI 上还挂着旧的任务记录或者之前有一次移除操作没跑完你再次发起移除时新旧任务互相冲突。遇到这种情况先确认当前没有第二个并发的移除任务在跑必要时等它超时或失败。如果一直残留可能需要重启 vpxd 服务让任务框架清理异常状态。涉及到数据库层面的冲突我强烈建议先整理日志联系 VMware 支持不要自己去动数据库自己改库的风险远大于收益。5. 这套流程用下来的几点实操心得与注意事项前面几章把排查路径讲完了这一部分写写我在实际操作中总结的经验和注意事项。这些东西一般不写在官方文档里但遇到问题时特别能救命。5.1 几条必须遵守的底线先说底线。移除 Supervisor 是一个破坏性很强的操作一旦执行出错恢复成本远大于新建环境。我在处理这类问题时一定会遵守这几条也建议你照做操作前给 vCenter 做配置备份或快照。vCenter 本身如果是虚拟化部署快照是最省事的同时保留一份数据库备份更稳。移除前把所有业务集群和命名空间清理完整再动手。宁可多花半小时确认也不要让移除任务自己去做收尾。尽量在维护窗口执行移除。就算遇到卡住你也有充足时间去排查而且重启相关服务不会误伤业务。拿不准根因的时候先把日志打包留档再去尝试处理手段。日志一旦滚动覆盖你会后悔的。这里也提醒一句如果是在测试环境你也许可以“猛操作”但在生产环境真的不建议。环境越大残留对象越多移除流程越容易在某个中间环节被卡住这一步不能省。5.2 高效过滤日志的几个小技巧翻日志这件事方法和工具错了会非常痛苦。wcpsvc.log 动辄几 GB你用编辑器打开是看不动的。我常用的过滤技巧是这几条先按时间范围缩小范围比如任务开始时间是 2025-03-15 02:00就先把该时段全部日志抓出来grep 2025-03-15T02: /var/log/vmware/wcpsvc/wcpsvc.log /tmp/wcpsvc_0215.log再在这个临时文件里过滤关键字。关键字组合建议写成这样一次命中大多数有用信息grep -iE ERROR|WARN|delete|remove|destroy|timeout|nsx|namespace /tmp/wcpsvc_0215.log | less轮转日志文件也要照顾到。比如 wcpsvc.log.0 里可能藏着任务第一天的报错zcat 和 tail 都可以组合使用。另外排查过程中我会把每个关键时间点的 grep 结果都存成独立文件方便对照“重试前后报错信息有没有变化”。5.3 一个通用排查顺序的建议处理这类问题我个人的排查顺序是UI 子任务看阶段 - vpxd 日志确认任务链路 - wcpsvc 日志看具体报错原话 - ESXi 侧验证执行结果。从 UI 到日志、从调度层到执行层这个顺序符合任务实际流转路径而且每一层信息都能指导你下一步往哪里翻。不要一开始就跑到 ESXi 上删虚拟机文件。ESXi 侧的操作应该是“验证性”的而不是“尝试性”的。如果你还没通过 wcpsvc.log 确认问题出在宿主机执行层就直接去 ESXi 里强删很可能把一个可恢复的任务彻底搞坏。这套排查方法不止适用于 vSphere Supervisor类似的编排型删除任务比如 vCenter 里删集群、删存储策略卡住也能复用。核心思路其实就一句话顺着任务链路逐层看日志先定性再动手。我在实际运维里发现真正能高效处理这类问题的人往往不是操作更猛的人而是更愿意先看日志的人。希望这篇记录能帮你在“移除卡住”的时候少走弯路。