The last topic that I would like to explore before concluding my VSAN API blog series are some of the advanced VSAN disk statistics that are available for either troubleshooting or informational purposes. One such statistic that would be handy to know about is the number of VSAN Components per ESXi host, which I have already demonstrated in my recent VSAN configuration maximum query script and VSAN PowerCLI vCheck Plugins.

VSAN-components
These disk statistics are made available through the VSAN InternalSystem manager and using the QueryPhysicalVsanDisks() vSphere API method, we can either retrieve all or a specific set of properties for each ESXi host. I have created a sample vSphere SDK for Perl script called vsanDiskStatsQueries.pl that will demonstrate the use of this API.

Disclaimer:  These scripts are provided for informational and educational purposes only. It should be thoroughly tested before attempting to use in a production environment.

Here is an example of running the script against a VSAN Cluster which will produce the number of VSAN components for each ESXi host:

./vsanDiskStatsQueries.pl --server vcenter55-1.primp-industries.com --username root --cluster VSAN-Cluster

vsan-disk-component-query
If we take a look at the script, you will notice we filtered on two specific properties: lsom_objects_count and owner. One thing to note is the output for this method is JSON string, so you will need to parse the output accordingly.

The owner property indicates the UUID of a specific ESXi host and the lsom_objects_count represents the number of VSAN components. To be able to identify the particular ESXi host and compare it to the owner property, we use the QueryHostStatus() API which was discussed in Exploring VSAN APIs Part 5. Once we have a match for the current ESXi host, we simply extract the lsom_objects_count property which I use a simple hash table to keep track of the results and display it at the very end of the script.

This concludes my 9-part series of exploring the new VSAN APIs. Hopefully for those of you who followed the series have enjoyed it, I know I definitely had fun learning about the new APIs and how you can automate every aspect of VSAN from a scripting and programmatic perspective.

  1. Exploring VSAN APIs Part 1 – Enable VSAN Cluster
  2. Exploring VSAN APIs Part 2 – Query available SSDs
  3. Exploring VSAN APIs Part 3 – Enable VSAN Traffic Type
  4. Exploring VSAN APIs Part 4 – VSAN Disk Mappings
  5. Exploring VSAN APIs Part 5 – VSAN Host Status
  6. Exploring VSAN APIs Part 6 – Modifying Virtual Machine VM Storage Policy
  7. Exploring VSAN APIs Part 7 – VSAN Datastore Folder Management
  8. Exploring VSAN APIs Part 8 – Maintenance Mode
  9. Exploring VSAN APIs Part 9 – VSAN Component count
  10. Exploring VSAN APIs Part 10 – VSAN Disk Health

3 thoughts on “Exploring VSAN APIs Part 9 – VSAN Component count

  1. Is there a simple way to list the associated VM’s whose components are being hosted by the host’s vsandatastore?

    The idea is to easily see how VM’s are distributed across the vsandatastore.

    Example:
    ESXi Host 1
    — Disk Group 1
    – Component for VM1
    – Component for VM3
    — Disk Group 2
    – Component for VM2
    – Component for VM4

    • Yes, an example of a similar implementation is in RVC’s VSAN vsan.vm_object_info command. You can take a look at vsan.rb (Ruby Module) to get an idea of how to call the appropriate APIs to fetch this information. Regarding your other question, there is no such property that VSAN provides to verify whether components are evenly distributed.

  2. I forgot to say in the previous post that you have a really helpful blog. A couple additional questions…

    Is there a flag which indicates that a vsandatastore believes it has been optimally distributed across the cluster?

    How about a trigger that tells VSAN to immediately optimally re-distribute its components across the cluster starting now. For example, you migrate a lot of components off of 2 hosts going into Maintenance Mode.

    I imagine this reconfiguring activity could be monitored with “vsan.resync_dashboard”, but I’m looking for a state indicator.

Thanks for the comment!