VMware Cloud Community
SolutionsPro
Contributor
Contributor

Unable to purge Detected inaccessible objects in VSAN

Hello Folks,

I've got a situation with my VSAN in my home lab. I recently did an upgrade to 6.0 and VSAN needs to be upgraded so when I do that from RVC, using the command:

/localhost/vNEST Datacenter> vsan.v2_ondisk_upgrade ~cluster

+--------+-----------+-------------+----------------+----------------+

| Host   | State     | ESX version | v1 Disk-Groups | v2 Disk-Groups |

+--------+-----------+-------------+----------------+----------------+

| node02 | connected | 6.0.0       | 1              | 0              |

| node03 | connected | 6.0.0       | 1              | 0              |

| node04 | connected | 6.0.0       | 1              | 0              |

| node01 | connected | 6.0.0       | 1              | 0              |

+--------+-----------+-------------+----------------+----------------+

2015-06-12 12:18:32 -0700: Running precondition checks ...

2015-06-12 12:18:33 -0700: Detected inaccessible objects in VSAN. Upgrade has been

2015-06-12 12:18:33 -0700: halted. Please fix or remove them and try again. Try

2015-06-12 12:18:33 -0700: "vsan.purge_inaccessible_vswp_objects" command which can be

2015-06-12 12:18:33 -0700: useful to purge inaccessible vswp objects. Following

2015-06-12 12:18:33 -0700: inaccessible objects were detected:

2015-06-12 12:18:33 -0700: ed237554-c8aa-e810-05d9-047d7bb280a4

2015-06-12 12:18:33 -0700: 6f8b7654-8e41-5c31-a679-047d7bb2810e

2015-06-12 12:18:33 -0700: a49e7654-64eb-c437-43dc-089e019341b0

2015-06-12 12:18:33 -0700: f88e7654-61e4-b143-234d-089e019341b0

2015-06-12 12:18:33 -0700: 9f937754-5aba-ae5f-0529-089e019341b0

2015-06-12 12:18:33 -0700: cffb7554-690b-9563-a8b8-089e019341b0

2015-06-12 12:18:33 -0700: fe8e7654-0be7-9f8d-6d5c-089e019341b0

2015-06-12 12:18:33 -0700: 5b9d7654-efb7-2efb-6f75-089e019341b0

/localhost/vNEST Datacenter>

It says, it detected the objects, fine, but when I go to purge these objects:

/localhost/vNEST Datacenter> vsan.purge_inaccessible_vswp_objects ~cluster

2015-06-12 12:23:54 -0700: Collecting all inaccessible Virtual SAN objects...

2015-06-12 12:23:54 -0700: Found 8 inaccessbile objects.

2015-06-12 12:23:54 -0700: Selecting vswp objects from inaccessible objects by checking their extended attributes...

2015-06-12 12:23:55 -0700: Found 0 inaccessible vswp objects.

/localhost/vNEST Datacenter>

What is happening here? I've moved all the VMs out of vsandatastore to another datastore. I was thinking about deleting the vsandatastore and recreating it but I do want to figure this out and know what the issue is?

thanks

Tags (1)
Reply
0 Kudos
3 Replies
zdickinson
Expert
Expert

I had the exact same issue.  Called support and they were unable to remove the inaccessible objects either.  I had to move all VMs off the datastore, delete, and recreate.   Turns out the reason was that a replication solution I was using did not support vSAN 6/vCenter 6/etc...  So when it would delete files, it did not actually delete them.  If you look through the forum archives you will see this as a common problem.  If you or a solution does not remove objects from vSAN correctly, it will cause problems.

Not sure if this is relevant to you, but that's my story.  Thank you, Zach.

Reply
0 Kudos
SolutionsPro
Contributor
Contributor

Hi Zach,

thanks. I ended up deleting the disk groups and recreated them... not a good solution for such high profile, hyped up product.

Reply
0 Kudos
cdekter
VMware Employee
VMware Employee

Zack, SolutionsPro: thanks for posting your experiences with upgrading VSAN. I am sorry to hear that VMware technical support were not able to resolve the inaccessible objects blocking the upgrade. We have a well-defined process in place for identifying and removing these objects, and technical support certainly should have been able to walk you through this process. It should definitely not be necessary to evacuate the VSAN datastore and rebuild the cluster.

Speaking in general terms, these inaccessible objects are usually the result of a previous hardware failure or other form of outage. They can also result, as mentioned by Zack, from the use of third party software that makes use of the datastore browser API to delete VMs. It is worth pointing out that manipulating VM files directly on the datastore is not the correct supported method as the structure of these files/folders are an internal implementation detail that may chance in any future vSphere release.

Reply
0 Kudos