How hard can it be?
Today I had a discussion with a colleague who wanted to build alerts against some advanced host settings that were not collected by default. I argued that one could build a script that imports the settings.
That’s when I had one of those “How hard can it be?” moments.
It turned out, it’s not that hard at all.
What’s an Advanced Setting?
Objects in vCenter have a set of properties defining anything from licensing to file system buffers. Some of them have dedicated editors in the UI, but the bulk of them are just key/value-pairs accessible from the “Advanced Settings” menu option in vCenter.
Here’s what they look like in vCenter:
Alerting on Advanced Settings
Alerting on settings and properties can be useful when trying to detect configuration drift. For example, some storage arrays work best with certain settings on NFS.MaxQueueDepth. By importing this setting, we can build symptoms and compliance alerts on this property so that we get alerted anytime this setting is changed from its optimal value.
Some host properties and settings are already captured vRealize Operations, but a lot aren’t. Using the simple script I created, we can import any host settings and make them reportable and alertable.
How it’s Made
The script is very simple and uses plain old REST calls (no SDK library) to vRealize Operations and pyVmomi to communicate with vCenter. It reads its settings from a YAML-file. That’s pretty much it.
The script only runs one import. If you want it to import periodically, you should install it as a cron-job (or scheduled task in Windows). Since host settings aren’t likely to change very often, it’s probably enough to run it once every hour. The code isn’t exactly optimized, so you may run into problems if you try to run it too often.
Since there are hundreds of settings and most aren’t needed, the script uses filesystem-like wildcards to select the settings. For example “NFS.*” gets you all the NFS settings
The script uses a configuration file to determine hostnames, usernames, passwords etc. Here’s a self-explanatory example:
# vCenter details # vcHost: "my-vcenter.corp.local" vcUser: "firstname.lastname@example.org" vcPassword: "secret" # vR Ops details # vropsUrl: "https://my-vrops.corp.local" vropsUser: "demouser" vropsPassword: "secret" # Property pattern # pattern: "NFS.*"
What to do with it
There are many reasons one may need to import host settings. In my case, I needed to check the NFS.MaxQueue settings. In some environments, things tend to work poorly if it’s not set to exactly 64. So I collected that setting (and all the other NFS settings) by specifying the pattern “NFS.*”.
Here’s what I captured:
Then I created a couple of symptoms and an alert with subtype “Compliance”. The subtype is important, since it makes it show up under the Analysis -> Compliance tab.
Here’s what the end result looks like:
Where to Find it
You like it? Go get it!
The script can be found on my Github page: