We recently added native support for VMware tags in Virtualization Manager (VMAN) (as of 2020.2.6), but I wanted to expand on the basic introduction provided there and get a little deeper into the details of the implementation and walk through some examples of how this new feature will make your life easier if you’re using VMAN to monitor your VMware environments.
Before I dive into the technical details, I want to make sure everyone is on the same page about what VMware tags are and why they’re useful to a virtual admin. Tags are simply a mechanism to assign metadata to an object. They’re used to assign logical groupings and “friendly” names to objects or collections of objects that might otherwise seem like a disorganized mish mash. As an example, let’s say I had several VMs and datastores exclusively used by the Finance team in my organization. Those VMs and datastores may not have easily understood names assigned to them that make it obvious who they belong to and what purpose they serve. They may also be mixed in with hundreds of other unrelated objects. Tags to the rescue! I can assign a “Finance Team” tag to each appropriate object and from then on, anytime I need to troubleshoot, report, or otherwise inspect those objects, I can quickly group them and isolate them from other unrelated objects. Magic!
To be clear, tags are not an exclusive feature of VMware. You’ll find tags and tagging features in many IT products in the market. Anywhere you find a need to put friendly names, metadata, or logical containers around a set of objects in your IT infrastructure, tags are likely a feature you can use to do so. While all this is interesting at the high level, what it means to you as a VMAN user is reporting, alerting, and several other things are suddenly much easier to manage. More on that later…
Now that we have the basics covered, let’s look at how support for VMware tags is implemented in VMAN as of the 2020.2.6 release. One important item to note before reading further is that VMware tag support is a feature of licensed VMAN only. If you’re using the lightweight virtual polling included with SAM or NPM, you won’t be able to leverage the VMware tags feature.
Polling of VMware tags is automatic. You don’t need to configure anything special to make it happen. VMAN will poll for the tags via the vCenter REST API on the default port 443. (If necessary, you can change the port VMAN polls on via an advanced configuration.) Polling will occur on two default intervals. Relationships between entities and tags are checked every 30 minutes, and every 3 hours, VMAN will check for new definitions. VMAN will automatically take care of removing tags from SWIS and custom properties during database maintenance anytime they’re removed on the VMware side.
Once the tags have been discovered and the relationships established, they’ll be stored in two places. First in SWIS located in a table called: Orion.VIM.Tags and second and most importantly for most users, they’ll be stored as a custom property associated to the appropriate entity in the Orion Platform and the value set to “True.” This means creating customization based on your existing VMware tags is now as easy as a custom SWQL query or finding the tag in a filtered list when creating an alert or report. There’s also a new widget added to any virtual entity detail page that displays the VMware tags assigned to that entity. Let’s look at a few examples below…
First, let’s see how the tags look in their SWIS data table:
Next let’s look at some tags as seen in the custom properties management interface. Easy to use just like all your other custom properties… There is a maximum of 999 defined custom properties per object due to a limitation in SQL Server. Most folks won’t encounter or need to worry about such a limitation but keep that in mind if there are a large number of tags in your environment.
Here you can see the tags, and note we’re using the vCenter or TLE (Top Leve Entity) as a source of disambiguation. If you have multiple vCenters, you may have the same tag name used in multiple vCenters, so being able to clearly see the source of the tag in the Orion Platform is crucial. Since spaces and some other characters aren’t allowed in the display name for custom properties, we replace those with underscores. In the example above, you can see the VMware tag “Finance Team” originating from the vCenter at 10.x.x.x Don’t worry though, the name with spaces intact is also stored and used to display the tag elsewhere. (See examples below of alerts and reports.)
As mentioned earlier, a new default widget is added to relevant virtual details page to show VMware tags assigned to the entity.
Creating a report driven off a VMware tag is as simple as finding the tag in the report builder. Continuing with our example tag from above, you can see the tag “Finance Team” can be found by searching the custom properties section of the report builder.
Similarly, creating an alert based on VMware tags is a matter of finding the tag in the drop down on the trigger conditions page.
You can also summarize a chargeback report based on VMware tags now.
Hopefully this has provided some insight into how we implemented VMware tags support and how it might be useful to you as you work in VMAN from day to day. If we missed something or you have a great idea about how we can improve the support for VMware tags, feel free to comment below or create a feature request!