I recently started to play around with the CIM API to monitor the hardware on an ESXi host. Instead of relying on hardware agents/scripts that would normaly run in the traditional Service Console of ESX, CIM is an API that allows you to monitor the health of your ESX or ESXi host. You can see the health status of your host by logging directly into the ESX(i) host using the vSphere Client and clicking on Configuration->Health Status tab.
I decided to start off with a small python script that would run on vMA and using the wbem python module to make a simple connection to query for the ESXi version. Here are the steps to get the following script working:
1. Download pywbem onto vMA
2. Extract the contents of pywbem
tar -zxvf pywbem-0.7.0.tar.gz
3. Install pywbem
sudo python setup.py install
4. The script expects the hostname/IP of your ESX(i) host as it's first argument and the username as the second argument and then you will be prompted for the password
./cim.py himalaya.primp-industries.com root
If everything went according plan, you should see the version of your ESX(i) host printed on the screen.
Next I wanted to create a dedicated service account so that I do not have to use the root account, I thought a read-only role would suffice.
To my surprise, when I ran the script again with this user, I received an unauthorized access error.
At first I thought the user account required an "Administrator" role to perform the operation but after further investigation, I found that the user account must be part of the "root" user group. Even for a read operation, it still needed to be in that that group.
After I made the change using the vSphere Client and re-ran the script, it executed as I expected.
After speaking to someone at VMware regarding this issue, it was confirmed by engineering that this is in fact a software bug and it should not require the user account to be part of the "root" user group to query from the CIM API.
I was still interested in using CIM, but I wanted to lock down the account as much as possible and came up with the following snippet of code which can be included in your ESX(i) kickstart configuration.
The script creates a regular user who does NOT have login access to the ESX(i) host. It then puts the user into the "root" user group and then creates a new role called CIM with a single privilege Host.Cim.CimInteraction and then associates this user with this role.This ensures that the account can only perform read-only operations against the CIM API and does not allow for host logins. Until the bug is resolved, this should be an acceptable work around.
So what type of monitoring can you do with CIM? Well pretty much anything and everything. There is a popular Nagios script that monitors the hardware health of an ESXi host using the CIM API called check_esxi_webem.py that one can implement to alert on your hardware components.
The script currently expects three arguments: hostname/IP of ESX(i) host, username and password on the command line (this can be changed with minor modifications). If you run it using those defaults, you will either get an OK or WARN/ERROR which will include additional information about the component that is alarming.
If you would like to get more details on the components being checked, you can pass in a fourth parameter called "verbose" and the script will provide more information on what is being checked.
If you are not big on python, there is also a Perl SDK for CIM/WSMAN as part of the vCLI installation and if you are using vMA, you can find some great examples under /usr/share/doc/vmware-vcli/samples/WSMan
The checksensorhealth.pl is definitely one to take a look at, here is an example output:
If you are interested to learn more about CIM, take a look at the these resources:
CIM SDK
7 Part series on ESXi Chronicles blogs about CIM and hardware monitoring
As I see any user who has 'Administrator' role assigned can monitor CIM, no need to be in 'root' user group.
How do you generate the value of 'USER_SHADOW_HASH'??
@bobbydamercer
Create a local user on an ESXi host, assign it a password and then take a look in /etc/shadow to extract the shadow hash.
This works great on my ESXi5 hosts, but my shiny new ESXi 5.1 host doesn't have any groups, and so won't let me add my monitoring account to the root group. In the end, I ssh'd in and edited /etc/group. Any better ideas?
In ESXi 5.1, you no longer need to add users to the root group. Take a look at this article for more details http://blogs.vmware.com/vsphere/2012/09/vsphere-5-1-full-admin-support-for-named-user-accounts.html
how can we take this monitoring on a webpage? How can I pull the vCenter Hardware status parameters right into my company's webpage. So that everyone in the back office team can monitor using just the url/internet ?
Re: The following statement on this post
"After speaking to someone at VMware regarding this issue, it was confirmed by engineering that this is in fact a software bug and it should not require the user account to be part of the "root" user group to query from the CIM API."
We recently reached out to VMware to understand why this behavior if a bug was still not addressed in most recent versions notably ESXi6.5 that we are using. We found out from VMware engineering that this is by design. So whether a bug or a feature 🙂 I thought I'd share this because we spent quite a bit of time going back and forth with VMware trying to understand why this bug still existed. I am hoping it saves someone else some time.