After reusing hosts that were removed from a vSAN cluster, the cluster they are added to contains a number of unassociated objects with missing paths and references to incorrect datastores.
Looking at output from "esxcli vsan debug object list" shows many objects which are healthy, but have paths showing as
/vmfs/volumes/vsan:521cfa72f6202c14-################/appvolumes/packages/<vmdk_name>.vmdk (Missing)
Looking at normal expected objects we see path attributes with correct datastore and not Missing state.
/vmfs/volumes/vsan:5236cdd44cf208fa-################/appvolumes/packages/<vmdk_name>.vmdk (Exists)
vSAN 7.x
vSAN 8.x
The disk groups were not removed from the hosts when the hosts were decommissioned from the previous cluster. This leaves data components available related to objects from the old cluster which are picked up by vSAN in the new cluster.
This is demonstrated by the previous vSAN datastore ID present in the object Path attribute:
Looking at output from "esxcli vsan debug object list" shows many objects which are healthy, but have paths showing an incorrect datastore
/vmfs/volumes/vsan:521cfa72f6202c14-################/appvolumes/packages/<vmdk_name>.vmdk (Missing)
Looking at normal expected objects we see path attributes with correct datastore.
/vmfs/volumes/vsan:5236cdd44cf208fa-################/appvolumes/packages/<vmdk_name>.vmdk (Exists)
Prevent the issue from occurring by following KB 392097 when decommissioning a vSAN cluster or KB 326861 when removing a single node from a vSAN cluster.
To address the problem you may choose to perform one of the following to remove the inaccessible objects:
If there are inaccessible objects please see After reusing hosts from decommissioned vSAN cluster the new cluster reports inaccessible objects in the vSAN object health alert.