WilliamLam.com

Search Results for: kickstart

CIM monitoring caveat with ESXi

by // 9 Comments

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

Potential ESX(i) 4.1 Update 1 upgrade caveat

by // Leave a Comment

If you are planing on upgrading to the recent release of ESX(i) 4.1 Update 1 from ESX(i) 4.1, you may want to verify that you will not be impacted by a previous security/password bug found in ESX(i)4.1. The security bug that was identified with ESX(i) 4.1 was the encryption algorithm which changed from default MD5 as previous releases of ESX(i) to legacy DES.

This bug has since been resolved and a VMware KB article (KB1024500) was released with a temporary fix by adding the keyword "md5" to system-auth PAM configuration entry. This fix also required the user to update the root password afterwards, as the previous password was encrypted using DES.

The potential caveat is if you did not apply the fix as mentioned from the above VMware KB article prior to upgrade, after the ESX(i) 4.1 Update 1 upgrade, you will continue to run into the same problem. The fix is to reset your root password after the upgrade of ESX(i) 4.1 Update 1, this will ensure that the new password will be encrypted using the MD5 algorithm. Though the fix is simple, it can be tedious and manual for users who do not regularly rotate their root passwords or have an automated password management system.

To check whether this will impact your upgrade, login to ESXi Tech Support Mode or classic ESX Service Console and check whether the root password was encrypted using MD5 or DES. To do so, you will cat out the contents of /etc/shadow

If the root password was encrypted using MD5 algorithm, you should see root hash start with "$1$"

If the root password was encrypted using DES algorithm, the root hash will not start with "$1$"

If it is the latter, you will need to either apply the fix and update the root password before upgrading or reset the password after your upgrade. To change the root password, you need to login to either the Serivce Console for ESX or Tech Support Mode for ESXi and run the passwd utility to change your password.

It is probably quicker to rebuild than to login to each host an update the root password, especially if you have an automated kickstart environment. This will ensure that that all hosts will be consistent and no manual fixes will be required. IMHO, this is something that VMware should have clearly pointed out in their release notes as not everyone may be aware of the VMware KB article and implemented the fix prior to upgrade.

Another way to enable management traffic on ESXi

by // 3 Comments

Here is another way in you can enable the management traffic type on a VMkernel interface in ESXi without having to resort to using the vSphere API, this especially useful when automating a kickstart installation.

When you enable a specific vmkX interface (esxcfg-vmknic -l) to allow for the management traffic type, there is an entry that is made in the /etc/vmware/hostd/hostsvc.xml file. The specific interface is denoted by a unique nic id which starts off at 0000 and is incremented by one for additional VMkernel interfaces that are added.

If you add a second VMkernel interface called vmk1 and you wanted to also enable it for management traffic, the file would look like the following:

For the changes to take effect, you will need to restart hostd agent by running /etc/init.d/hostd restart. You will also need refresh the network sub-system by using vim-cmd hostsvc/net/refresh which will refresh the vSphere Client view else you will have to do it manually before you can see the update.

This is probably overkill, but I decided to write a simple script in which you can pass the VMkernel interface name and the script will update hostsvc.xml file with the proper nic id/etc. Here is an example for enabling management traffic for vmk1:

Download: enableMgmt.sh

If you would like to integrate this into your ESXi kickstart, you can easily do so based on the number of VMkernel interfaces you will be creating during the installation. You can add the following into your %post section which uses a here document to overwrite the existing hostsvc.xml with the expected VMkernel interfaces that should have the management traffic type enabled.

HOSTSVC_FILE=/etc/vmware/hostd/hostsvc.xml

cat > ${HOSTSVC_FILE} << __CREATE_HOST_SVC__

  
    vmk0
    vmk1
    vmk2
  
  normal
  
    on
    on
    on
  

__CREATE_HOST_SVC__

This is a cleaner alternative than using python and connecting to the vSphere API locally on an ESXi host which is described in my blog article Automating ESXi 4.1 Kickstart Tips & Tricks Tip #7