三月Moon早上一进办公室，邮箱里躺着两三封vSAN健康告警，打开vSphere Client切到集群的虚拟对象视图，整整齐齐五个对象状态是Inaccessible，红得像一排刹车灯。那一刻的心跳加速，干过VMware虚拟化运维的兄弟应该都懂。更尴尬的是，这五个对象里还有几个明明是从vCenter清单里移除了VM之后留下的磁盘残留，UI上想删又删不掉，点一次报一次错，容量还一直在那里占着。这篇就把我怎么手动定位和删除vSAN里Inaccessible对象、尤其是和VM磁盘相关的残留对象的完整思路写下来，包含排查路径、命令、风险确认和踩坑教训。适合正在维护vSAN集群的虚拟化管理员和运维工程师，对刚接手vSAN环境的新手来说，也可以当一份排障参考。
1. Inaccessible对象到底是什么，以及它是怎么出现的
想动手删对象之前，得先搞清楚你删的到底是什么。vSAN里所有东西本质上都是对象，一个VM的VMDK是一个对象，一个快照差分盘也是一个对象，VM的命名空间（namespace）在vSAN上同样是一个对象。每个对象不会单独存在，它会按照存储策略被拆成多个组件，分散在不同ESXi主机的磁盘上。比如FTT=1（Failures To Tolerate，允许容忍的故障数）的两副本策略，意味着一个对象会有两份副本组件，分布在两台主机上，坏一台主机数据还在。再比如纠删码FTT=1，会把数据切成4个数据块加1个校验块，分布在5台主机上，任意坏一台主机都能还原数据。
所以对象的状态本质上是由组件来决定的。组件全部或部分丢失，就可能导致对象进入ABSENT、DEGRADED或INACCESSIBLE状态。这几个状态的区别很重要：DEGRADED一般代表对象还能访问，但冗余度已经低于策略要求，比如原本两副本现在只剩一个副本；ABSENT通常指某个组件暂时失联，但系统还在尝试恢复；而Inaccessible是更重的一级，意思是这个对象已经无法被主机正常访问了。
哪些场景会把对象推到Inaccessible状态？我实际碰到的，基本可以归成这么几类：
- 主机故障且冗余不足：最常见的情况，比如FTT=0的对象（只有一份数据），主机一挂，对象直接inaccessible；FTT=1的对象，如果两台主机同时故障，也会inaccessible。
- 磁盘故障且组件无法在其他位置重建：比如磁盘组里物理磁盘彻底挂了，而vSAN又因为容量或策略原因找不到地方重建组件。
- 网络分区：vSAN的存储网络如果MTU不统一或者有丢包，主机之间的组件同步中断，某些对象也会被标记为inaccessible。这种情况下硬件没坏，但元数据已经认为组件不可达了。
- 人为误操作：对主机做维护模式时选了错误的数据撤离选项，或者误删了组件，也可能导致对象变成inaccessible。
一句话总结：Inaccessible等于告诉你——这个对象当前不可用，数据可能还在，也可能已经残缺。不到万不得已，不要把它当成“垃圾文件”直接清理。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从vSphere Client到命令行：定位Inaccessible对象的三条路线
定位是这个活儿的核心。记住一个原则：先看清楚到底是哪些对象，再决定怎么动手。下面是我常用的三条定位路线，从UI到命令行逐步加深。
2.1 UI视角的快速筛选
vSphere Client里是最快能看到对象状态的入口。路径是：选中vSAN集群，切到“监控 > vSAN > 虚拟对象”（Monitors > vSAN > Virtual Objects），右上角有一个筛选条件，可以按对象状态过滤，把Inaccessible筛出来。
这个视图中能直接看到的信息包括：对象名称（通常是VM磁盘文件名或namespace路径）、对象的UUID、存储策略、对象所在的主机（Owner）、还有组件分布情况。对于小环境或者对象数量不多的场景，这一步基本就够了。它的局限在于：UI只能看到对象，不能对Inaccessible对象直接执行删除操作——尤其是那些还被VM引用的对象，UI上根本没有删除入口，因为vSphere Client层面不允许你去破坏一个仍在使用的对象。
2.2 RVC命令行精确锁定对象UUID
如果你的环境里Inaccessible对象有好几十个，或者UI里看不出对象和VM的对应关系，就要上RVC了。
RVC（Ruby vSphere Console）是VMware提供的命令行工具，用来做vSAN底层对象操作非常顺手。虽然vSAN 7.0 Update 1之后官方逐渐推荐用新的Python版vsanmgmtSock工具，但在大量存量环境里RVC依然能用、依然高效。RVC的典型连法如下：
bash复制rvc -u administrator@vsphere.local@vcenter.example.com -p '你的密码'
实际生产环境我一般建议用带反斜杠转义的方式，或者直接在提示符里输入密码，避免密码写进shell历史。连接之后，RVC里可以像浏览目录一样切到vCenter、数据中心、集群：
bash复制ls /
cd /localhost
ls
比较关键的vSAN命令集中在vsan命名空间下，我常用的包括：
vsan.cluster_info：查看集群整体信息，包括版本、健康状态。vsan.object_info <UUID>：查看一个对象的详细信息，包括策略、组件分布和各组件状态。vsan.obj_status：查看所有对象的状态汇总。
用vsan.object_info查某个Inaccessible对象时，输出里能看到它的VMDK路径（一般长这样：[vsanDatastore] 虚拟机名/虚拟机名.vmdk）、SCSI地址、策略、组件数量，以及每个组件在哪个主机、状态是什么。有了这些信息，你能确认哪个对象对应哪个VM，也就能判断它到底是不是一个已经废掉的残留对象。
2.3 批量定位对象的自动化思路
对象数量多的时候，手工一条条看太累了。可以在PowerCLI里通过vSAN的Object API批量拉取对象状态，然后过滤出Inaccessible。PowerCLI里的实现大致是这样：
powershell复制# 按需安装并导入模块
Import-Module VMware.PowerCLI
Import-Module VMware.VsanPowerCLI
Connect-VIServer -Server vcenter.example.com -User administrator@vsphere.local -Password '密码'
$cluster = Get-Cluster -Name "你的集群名"
$objects = Get-VsanObject -Cluster $cluster
$objects | Where-Object { $_.Status -match "Inaccessible" } | Format-Table Name, Uuid, Status
不同PowerCLI版本的属性名可能有差异，拿到数据后先打印一两条看看再过滤。这条路的价值不只是定位，还能把对象UUID导出来，方便下一步在RVC里批量处理。
3. 删除VM相关Inaccessible对象的完整操作流程
定位完成后，真正动手删对象之前，有几件事必须确认到位。这一步做不好，轻则删不掉，重则把还在用的数据直接清零。
3.1 删除前必须完成的三个确认动作
- 第一，确认这个对象没有VM还在引用。去vCenter的“虚拟机”清单里核对，目标VM是否已经被移除并删除。如果VM还在清单里，这个VMDK对象是不能删除的——哪怕它已经inaccessible，删除对象等于把VM的数据目录直接抹掉，之后就算修好主机，数据也没有了。
- 第二，核对对象UUID和VM的对应关系。拿RVC的
vsan.object_info输出和UI里虚拟对象列表的UUID对着看，确认你手上这个UUID就是那个你已经不打算要的VM磁盘，而不是另一台同名虚拟机的。这个时候最忌讳想当然，名字相近的对象太多了。 - 第三，确认数据可丢弃或者有备份。Inaccessible对象常出现在小规模集群或测试环境里，往往数据并没有真正的备份。运维动作一旦执行就是不可逆的，删除前用手头的备份系统确认一下这个VM有没有可恢复的副本，没有的话就再想一遍“这个对象是不是真的不要了”。
三个确认做完，在纸上或者在笔记里写下将要删除的UUID列表，再进入下一步。
3.2 在RVC里执行对象删除
RVC里删除vSAN对象的标准命令是vsan.del_obj。先定位到对象，再执行删除：
bash复制# 假设已经进入RVC环境
vsan.object_info 6f4e5c2a-9b3c-4b3a-9d2f-3a1f2b3c4d5e
# 确认对象信息无误后
vsan.del_obj 6f4e5c2a-9b3c-4b3a-9d2f-3a1f2b3c4d5e
正常情况下，命令会返回删除成功的提示，对象从虚拟对象列表中消失。如果对象因为某些锁定原因无法删除，可以加force参数强制执行：
bash复制vsan.del_obj 6f4e5c2a-9b3c-4b3a-9d2f-3a1f2b3c4d5e --force
force删除是一把双刃剑。它能解决很多“对象卡住删不掉”的问题，但它等于告诉系统“不用管对象当前的状态，直接移除元数据”。所以我用force之前，一定会再跑一次vsan.object_info，确认这个对象没有被任何主机挂载，也没有处于正在读写或重构的状态。如果对象还有ACTIVE的组件在被使用，force删除可能造成正在工作的VM I/O错误。
3.3 删除后怎么确认真正清理干净了
删除命令返回成功只是第一步，我一般会等几分钟后，再回到vSphere Client的虚拟对象列表刷新一遍，确认目标对象已经不在列表里。同时用vsan.obj_status看看总对象数是否减少了。
还要注意磁盘容量的释放。vSAN删除对象后，组件空间并不是瞬间还给容量池的，后台会跑清理任务，真正释放容量有时候要等几分钟甚至更久。容量视图里“已用空间”会逐渐下降。如果过了很久容量依然没变，就需要检查是否有残留组件，用ESXi命令行在各主机上查：
bash复制esxcli vsan debug object list -t all
这个命令会列出该主机上所有vSAN对象的组件，如果还能看到被删除对象的UUID，说明组件没有清理干净，需要进一步处理（后文会讲）。
4. 几种“不好删”的场景和排错思路
真实的vSAN环境里，删除Inaccessible对象最耗时的往往不是命令本身，而是各种各样的“删不掉”的意外情况。下面几个场景我基本都踩过，记录下来给大家做参考。
4.1 VM还在但对象已经Inaccessible
这种情况最需要冷静。比如某台主机故障，上面的VM因为FTT=0导致磁盘对象inaccessible，VM直接开不了机。这时候的首要任务是恢复数据访问，不是删对象。
先用RVC的vsan.object_info查看组件到底还在不在、在哪些主机上。如果组件还在但主机离线，优先排查主机网络、存储问题，让主机重新回到vSAN集群。如果只有一个副本而且组件已经丢失（磁盘物理故障），那这个对象基本等于数据已经没了，这时才能考虑删除对象并重建VM。
这里有个反直觉的点：对象inaccessible不代表组件一定没了。很多情况下组件好好地在磁盘上，只是因为owner主机失联，对象暂时不可访问。我曾经碰到过一台主机因为存储适配器驱动异常和集群失联，导致上面几十个对象全部变成inaccessible，后来主机重启并恢复后，对象状态自动回到healthy。所以遇到VM还在的情况，先尝试恢复环境，不要急着删。
4.2 虚机已经从清单移除，但磁盘对象残留且删不掉
这是最常见的“孤儿对象”场景。某台VM你已经在vCenter里从清单移除（Remove from Inventory）但没有选“同时删除磁盘文件”，它的VMDK对象就留在vsanDatastore里。正常来说到虚拟对象列表里手动删除就好了，但实际经常遇到点击删除报错，提示对象正忙或者删除操作在几分钟后被回滚。
这类问题通常和DOM锁或者VASA Provider的缓存状态有关。vSAN对象删除本质上要修改DOM（Distributed Object Manager）的元数据，如果vCenter侧或者ESXi侧缓存的元数据还认为这个对象在被引用，删除就会失败。我处理过的一个典型案例：删一个残留的namespace对象，UI上报删除失败，RVC里用普通删除也报错，最后用force删除才成功。
这类场景的排错顺序，我建议是这样：
- 先确认对象没有被任何主机以挂载状态持有，用
esxcli vsan debug object get -u <UUID>看owner和组件状态。 - 用RVC的
vsan.del_obj <UUID> --force强制执行。 - 如果force依然失败，考虑vCenter服务层面的VASA Provider缓存问题，重启vSphere Client对应的VASA服务（在维护窗口操作）。
- 最后的手段是从ESXi侧确认组件状态并清理残留组件，但这步操作风险高，建议联系官方支持再执行。
网上也有人建议直接重启vCenter或对应主机的vSAN管理代理，这个过程我确实见过有人通过重启vpxd解决了问题，但代价是vCenter会短暂不可用。我个人的建议是：维护窗口允许的情况下可以尝试，生产环境务必先评估影响。
4.3 模板、ISO和快照残留对象的处理
除了VM磁盘，vSAN上还会留存内容库模板、ISO镜像、快照差分盘等对象。这类对象如果显示inaccessible，删除路径和普通VMDK稍有不同。
如果是内容库模板，vCenter里会把它注册为内容库条目，直接删vSAN里的对象而不删内容库条目，会导致内容库显示异常。所以处理顺序必须是：先在内容库/模板库中删除对应条目，再来清理vSAN对象。快照残留对象则相对简单——只要确认没有VM引用该快照链，可以直接用RVC删掉对应的差分盘对象。这里特别提醒：同名快照对象很多，删除前务必对着UUID仔细核对，别把当前快照链删了。
4.4 升级或版本迁移后出现的“幽灵对象”
vSAN从7.0升级到8.0，或者从混合架构迁移到全闪架构之后，偶发会看到一些对象状态显示Inaccessible，但健康检查又查不到数据丢失。这种对象有可能是元数据版本不一致导致的“幽灵状态”，而不是真正的数据损坏。
我的经验是，碰到这类情况不要急着删。先把对象的详细状态抓下来：
bash复制vsan.obj_status
vsan.object_info <UUID>
然后把输出保存成文件，确认真实数据和组件都还在之后，再决定是否需要删除或是否要联系官方支持修复元数据。vSAN 8.0的新架构里，对象操作方面官方工具已经转向Python版的vsanmgmtSock，里面提供了DOM相关的操作接口，用起来逻辑和RVC类似，但命令细节有差异。需要说明的是，具体命令在不同小版本里可能略有变化，运行的时候可以用--help先确认参数格式。
5. 删除之后的验证与日常预防
对象删除成功不是终点，后面还有几件事值得做。我自己的习惯是删除后第二天再复查一遍，确认环境没有因为清理动作产生新的告警。
5.1 删除后的验证三件套
- 第一，虚拟对象列表里目标对象彻底消失。等几分钟刷新，确认没有重新出现。
- 第二，容量趋势逐渐下降。去“监控 > vSAN > 容量”看数据是否开始回收。
- 第三，集群健康状态没有新增告警。特别是vSAN健康的“对象完整性”检查项，确认没有因为删除引出新的问题。
如果容量持续两天都没有下降，就需要检查是不是还有组件残留在磁盘组里。可以逐台ESXi执行：
bash复制esxcli vsan debug object list -t vm
对照已删除对象的UUID，寻找残留组件。
5.2 日常操作中减少Inaccessible对象堆积的习惯
很多Inaccessible对象其实是运维习惯造成的。比如删除VM时图省事只从清单移除、不删磁盘文件，日积月累就会在vsanDatastore里留下大量孤儿对象。或者把主机置入维护模式时选择“Ensure Accessibility”，如果一次性撤离的主机数量过多，vSAN在某些情况下无法保证所有组件立即重建，对象状态就会告警。
几个能落地的习惯：
- 删除VM时，如果确认数据不再需要，直接选择“从磁盘中删除”（Delete from Disk），不要只移除清单。
- 维护主机时，评估一下集群里可用的重建资源（CPU、容量、网络带宽），再决定撤离策略。
- 定期检查vSAN虚拟对象列表里的状态分布，早发现早处理。
- 保持vSAN存储网络的MTU配置一致，避免因为网卡配置差异造成对象组件同步失败。这一点在很多长期告警环境里都有体现，MTU不统一并不一定会立刻报错，但会被网络抖动放大成对象状态异常。
5.3 设置告警，把“救火”变成“防火”
vCenter里可以对vSAN健康状态配置告警，比如vSAN对象健康检查项、vSAN组件健康检查项等。让系统在对象从healthy变成degraded的时候就通知你，而不是等到变成inaccessible才告警。虽然inaccessible的告警也会来，但提前一天知道和当天早上才知道，处理节奏完全不一样。
这里补充一个我自己的体会：vSAN的健康检查面板越早成为你的日常巡检工具，后期“应急清理对象”的次数就越少。很多Inaccessible对象在degraded阶段如果及时处理，根本走不到需要手动删除那一步。
6. 删除失败时的完整排查链路
如果你在删除时遇到了错误，下面是我建议的排查链路，按顺序执行，绝大部分删不掉的问题都能在这个过程里找到根因。
6.1 查看对象当前挂在哪个主机上
在ESXi主机上执行：
bash复制esxcli vsan debug object get -u <UUID>
这条命令会返回对象owner的信息、组件所在主机列表及各组件状态。如果owner主机不在线，那删除失败大概率是因为owner还没恢复，需要等待或者先从集群侧处理主机状态。
6.2 看vCenter的事件日志
vCenter的事件视图里，删除vSAN对象失败时一般会产生对应的事件记录，包括错误码和提示信息。常见的信息是“Object is still in use”或“Object has pending reconfiguration”。前者说明有VM或服务还在引用，后者说明对象正处在重构或者策略变更的过程中，等一等再删通常就解决了。
6.3 确认是否有VASA Provider层面的残留
vSAN的高级功能（策略管理、虚拟机加密等）依赖VASA Provider。VASA Provider缓存里的旧对象条目如果没刷掉，会导致vCenter侧认为对象仍被引用。碰到这种情况，重启VASA Provider服务或者重启vCenter管理服务基本能解决。注意这属于影响较大的操作，建议在维护窗口执行。
6.4 最后的兜底方案
如果以上都试过还是删不掉，备份好RVC输出的对象信息，带上vsan.obj_status和vsan.object_info的输出，联系官方技术支持。很多时候兜底方案需要厂家用底层工具清理DOM元数据，自己硬搞反而可能把整个集群搞出问题。
最后再分享两个小教训。第一个是关于force参数的——有一次我对着一个删不掉的对象执行force删除，命令提示成功，结果容量一点没动，后来发现是vCenter侧和ESXi侧的对象视图没有刷新，重启vCenter服务后那个对象才真正消失。第二个是关于UUID的——我见过有人在笔记里把两个对象的UUID抄反了，结果把还在用的VM磁盘对象删掉了。虽然那台VM的数据有备份，但恢复也花了一整个下午。所以删除操作前，把UUID和VM路径都写在纸上，对着vSphere Client逐个确认，再笨的方法在关键时刻都最可靠。