Update [2022-10-17] The VMware APIs for the KnowledgeBase have introduced a breaking change. This means the releases can no longer be updated without further development.

Update [2021-03-09] The repository has been renamed to VMware-vSphere-Release-Tagging as the future scope should include the vCenter as well. Thank you for all the feedback!

In this blog post I want to show you a practial application for the automation that I have built in my last project:
I have created a script that tags ESXi hosts with a canonical release name (e.g. ESXi_7.0_Update_1c).

Motivation

When I talk with customers about lifecycle operations (i.e. patching) it can become confusing when we need to establish “where we are” and “where we need to go”. Usually, we’re constantly translating build numbers into release names that humans can understand (e.g. build x means Express Patch y). Obviously, I am not the only one and William Lams tweet with his referenced blog post have been the final push to give me the motivation I needed.

The workflow

The script requires a JSON file with ESXi build data from here: Machine-readable VMware release data.
From the list of all ESXi hosts, the unique set of build numbers will extracted and compared to the information in the JSON file.
For every matching build number a tag will created and grouped into a tag category.
Then, every ESXi host will be tagged with a release name tag.

Note: The setup will be explained in the GitHub repo.

Output example

The first screenshot shows a collection of the required tags for the ESXi hosts registered in this vCenter

Image Caption
All tags created on demand and grouped in a Category

The second screenshot shows a tag applied to an ESXi host:

Image Caption
Tags applied to an ESXi host

I replaced the spaces in the releases names with underscores to avoid issues with escaping characters.

Hurdles

Again, exception handling is a big PITA. Starting with a few lines of code to get the core functionality, handling exceptions triples the code base and you’re soon into debugging exception handling.
Update [2021-03-09]: I moved the TODO-list to GitHub issues, the inital improvements have been implemented. Apart from that, there are two things left I need to address:

  • Data source: The JSON file needs to be manually downloaded and provided as an argument to the script. Wouldn’t it be nice if it could be read directly from GitHub? The file parameter could then be reserved for offline usage.
  • Target scope: Currently, all ESXi hosts in a vCenter are targeted. I will need to figure out how handle the user scenario where the user wants to pass an entity (Folder, Cluster, Datacenter) either as named parameter or pipeline input.

Takeaway

Again, it was fun to do some coding and this time with a practical approach in mind.
I am not 100% sure why I switched from Python to PowerShell for writing this script. I suspect it is like an old habit as I started out automating vSphere with PowerCLI - thanks to the influence of people like Alan Renouf, Luc Dekens and William Lam. However, I would love to see a Golang implementation of this to see how lightning fast it would run in comparison.
Thanks to Michael for being the brave tester, I swear it worked on my laptop flawlessly…