A vSAN cluster may report "Inaccessible Objects" within the Skyline Health monitoring dashboard. These objects represent data components that reside on physical disks but are no longer reachable or recognized by the vSphere management layer.
These inaccessible entries result in persistent health alarms and can lead to "zombie" data consumption, where storage capacity is occupied by files that are no longer associated with any active virtual machine.
One possible cause of inaccessible objects are orphaned snapshot objects. This KB specifically covers this scenario. To investigate inaccessible objects with other causes, please see KB 389599, or open a case with Broadcom support KB 142884 to investigate.
Other possible causes of Inaccessible Objects in vSAN might be attributable to any of the following
VMware vSAN (All Versions)
The primary cause of these inaccessible objects is the presence of Orphaned Snapshot Objects.
This typically occurs following failed snapshot consolidations, interrupted VM deletions, or backup software errors.
In these scenarios, the parent descriptor files are removed from the VMFS/vSAN metadata directory, but the underlying vSAN objects (the data components) remain on the physical disks.
Because the links to the virtual machine’s configuration have been severed, the vCenter and ESXi management agents cannot resolve the state of these objects, causing them to be flagged as "Inaccessible."
1. Identify the Affected UUIDs
Log in to the vSphere Client and navigate to Monitor > vSAN > Skyline Health. Locate the "Data" category and identify the specific UUIDs flagged under vSAN Object Health.
2. Direct Object Inspection
esxcli vsan debug object list -u <objectUUID>
--------------------------------------------------structtype: ObjectInfoHealth: healthyObject UUID: ########-####-####-####-############ Component: ########-####-####-####-############ Component State: ABSENT, Address Space(B): ############# (62.50GB), Disk UUID: ########-####-####-####-############, Disk Name: naa.##############:1 Votes: 1, Capacity Used(B): 12138315776 (11.30GB), Physical Capacity Used(B): ########## (11.19GB), Total 4K Blocks Used(B): ########## (X.X0GB), Host Name: hostname.acme1234.com Component: ########-####-####-####-############ Component State: ABSENT, Address Space(B): 26843545600 (25.00GB), Disk UUID: ########-####-####-####-############, Disk Name: naa.##############:1 Votes: 1, Capacity Used(B): ############# (1.30GB), Physical Capacity Used(B): ########## (1.28GB), Total 4K Blocks Used(B): ########## (0.93GB), Host Name: hostname.acme1234.com
3. Force Deletion of the Orphaned Object
Once the object is confirmed as orphaned/stale and irrelevant to production, manually purge the object from the vSAN datastore using the force flag:
/usr/lib/vmware/osfs/bin/objtool delete -u <Object_UUID> -f
objtool delete will permanently destroy the targeted vSAN object. This action is final and non-reversible; there is no way to restore the object once the command has been issued. Use with extreme caution.4. Verify Cluster Health
Return to the vSphere Client and perform a Retest in the vSAN Skyline Health dashboard. The "Inaccessible Objects" alarm should clear, and the cluster health status should return to green.
Standard vCenter cleanup tasks and "Purge Unused Indicators" often fail to remove these objects because the management layer has lost the metadata links required to track them. The objtool utility provides a low-level interface to the vSAN Object Directory Service, allowing administrators to interact directly with the storage layer.
Using the -f (force) flag allows the command to override standard management locks and manually purge these "ghost" references. This process is essential for maintaining a clean vSAN datastore and ensuring that capacity reporting remains accurate.