I was working on one of my vSAN Clusters a few weeks back and I had noticed a bunch of vSAN Objects being listed under the "Other" category within the vSAN Virtual Objects Health view as shown in the screenshot below.



I could not figure out what files or VMs these vSAN objects were actually associated to and it was especially strange since all VMs that were deployed on my vSAN Cluster were already properly showing up under this view and I could not account for these "Other" vSAN Objects. I had reached out to a few folks to see if anyone knew how to identify these objects and the only suggestion I had received back was try to run this python vSAN Health Status script located on one of the ESXi hosts participating in the vSAN Cluster to see if it provided what I needed.

The script is located at /usr/lib/vmware/vsan/bin/vsan-health-status.pyc and you run it like the following:

python /usr/lib/vmware/vsan/bin/vsan-health-status.pyc > /tmp/output

The above command just runs the script and stores its output (which is quite extensive) to /tmp/output. Once the script finishes, you can then open up the file using vi and search for the specific vSAN Object UUID in question. I was able to eventually identify what these vSAN Object UUIDs were mapped to (more on this later), but the overall experience was not ideal and it required SSH access to ESXi host which most customers disable by default. In addition, the process was pretty manual and tedious if you wanted to check multiple vSAN Object UUIDs.

So what did I do, well I looked for a better way of course! It turns out the output produced by vsan-health-status.pyc is actually all available using the vSAN Management API. Not only can you obtain this information programmatically and remotely but you can also retrieve this information by simply going to vCenter Server rather than having to directly connect to an ESXI host which was huge negative for me regarding the previous solution.

To demonstrate the use of the specific vSAN Management API, I created a PowerCLI script called VSANUUIDTranslate.ps1 which contains two functions, the first one that we will take a look at is called Get-VSANUUIDToVM. You will need to ensure you have at least PowerCLI 6.5.4 installed before you can consume these two functions.

The function is pretty straight forward to use. You simply provide it with the name of your vSAN Cluster and the vSAN Object UUID you wish to query. In our example, lets try to query the first UUID which is e0ca085a-32d9-41a8-e14d-005056a8f116 and see what it returns:

Get-VSANUUIDToVM -Cluster "Primp-Cluster" -VSANObjectID "e0ca085a-32d9-41a8-e14d-005056a8f116"



There are a number of useful fields that is returned regrading a particular vSAN Object, but the one that stood out to me immediately was the Object Path. If you look at the screenshot, you can see that this vSAN Object is actually backing a VMDK which resides in a vSphere Content Library, which I was using in my environment. It turns out that all of these "Other" vSAN Object UUIDs were actually referencing VMs that I had cloned from my vSphere Inventory into my Content Library, which my vSAN Datastore was supporting. I suspect that because these VMs were cloned, they may have carried some additional data that vSAN kept track of and hence they were showing up under the "Other". If I upload a VM directly into my Content Library, this behavior is not observed. I was literally scratching my head for several hours, but at least I now know. More importantly, there is also now an easy way to identify vSAN Object UUIDs using the vSAN Mgmt API.

If you have multiple vSAN Object UUIDs that you wish to look up, the function actually accepts an array of UUIDs which you can use like the following:

Get-VSANUUIDToVM -Cluster "Primp-Cluster" -VSANObjectID @("e0ca085a-32d9-41a8-e14d-005056a8f116","9bca085a-f79e-a30d-3d59-005056a8f116")



Lastly, I knew it would be useful to go from a vSAN Object UUID to a VM, but what about performing the reverse look up? Well, I also found out that this was possible using the vSAN Mgmt API and the second function that I had created within the script called Get-VSANUUIDToVM which enables this use case.

Similar to the first function, you will need to specify the name of your vSAN Cluster and then simply provide the name of a VM you wish to lookup like the following:

Get-VSANVMToUUID -Cluster "Primp-Cluster" -VMName "vSphereReplication"



As you can see from output above, you will get full details about the VM's home, Virtual Disk(s) and Virtual Swap (if VM is powered on) and their respective vSAN Object UUID and the full path on the vSAN filesystem. In fact, the code used for this function was based on for my recently published PowerCLI Script for identifying vSAN VMs with Thick VM Swap.