Resolving Inaccessible vSAN Objects and Orphaned Snapshots using objtool
search cancel

Resolving Inaccessible vSAN Objects and Orphaned Snapshots using objtool

book

Article ID: 428195

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

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

  • Violation of the "Failures to Tolerate" (FTT) Policy
  • Network Partitions
  • Maintenance Mode Failures

Environment

VMware vSAN (All Versions)

Cause

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."

Resolution

Warning: The following steps involve the manual deletion of storage objects. Ensure you have a valid backup of your environment and have definitively confirmed that the UUIDs in question are not associated with production data.

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>

 Please note that it is the Object UUID and not the Component UUID which will be listed in the Skyline alert.
 
Querying the Object UUID will return what is listed below :
 
--------------------------------------------------
structtype:
  ObjectInfo
Health:
  healthy
Object UUID:
  ########-####-####-####-############
 
 
The above Object will also show its Components - In this instance, they are marked as ABSENT
 
                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


WARNING: Using 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.

Additional Information

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.