IT Operations Management (ITOM)
cancel

VMware tools and why it is important for monitoring and what-not

VMware tools and why it is important for monitoring and what-not

Ramkumar Devana

I am a huge fan of Big Bang Theory - so I am letting Dr. Sheldon Cooper's quotes drive the meaning in this blog post. Excuse the references :) if you are not a fan of the show.

 

Whenever someone says 'I told you so',  I am reminded of Sheldon's famous quip I informed you thusly (youtube video clip).

 

This blog article talks about why having VMware tools running on your VMs is important for monitoring so i can tell i told you so. Think of this as a best practice idea, if you are attempting to monitor a VMware vSphere environment using one or a few of HP's BSM products.

 

First the generic stuff that VMware anyway likes to say, how VMware tools package helps -

 

  • Running VMware tools in your guest OS enhances graphics, by adding a guest side graphics driver.
  • Running VMware tools in your guest OS activates the vmmemctl (balloon) driver that ensures more optimal memory allocation to VMs.
  • Running VMware tools in your guest OS ensures that guest time is synchronized regularly with the host.
  • Running VMware tools in your guest OS running windows also provides accurate perfmon counters on MS Windows if you turn on guest statistics collection.
  • And finally, running VMware tools lets vCenter know the guest OS ip address and hostname. 

 

Wait a minute...

 

Sheldon quote here, his scientific deduction (read as stating the obvious) -

"Scissors cuts paper, paper covers rock, rock crushes lizard, lizard poisons Spock, Spock smashes scissors, scissors decapitates lizard, lizard eats paper, paper disproves Spock, Spock vaporizes rock, and as it always has, rock crushes scissors."

 

Does VMware vCenter not know a guest's ip address without VMware tools?

Yes. The guest OS's IP address is something specific to the networking within the guest OS and the ESX / ESXi host does not know this unless there's some VMware tools running in the guest.

 (By the way, the same applies to any other hypervisor and guest - Xen, KVM, HyperV, etc. In case of Hyper-V there are host integration packages available for Linux. Windows 2008 and later OS version on guests, already run the host integration packages.)

 

NOTE: This would not apply in a private/public cloud context running on Openstack or so, where a VM is created with a specific IP address, and there is automation to assign the particular IP address to the VM. In these cases, the provider (IaaS / Paas) *knows* the IP address it has assigned.

 

 

See the picture above showing the VM properties in vSphere client. When VMware tools is running on the guest, the IP address is visible in vCenter (and so in the vSphere client). When VMware tools is not running, the IP address is blank (unknown).

 

Extend this a bit, and you will realize thusly that when a VM is powered off or suspended, vCenter will not know any IP address of the VM.

 

How does this affect Discovery and node reconciliation in a CMDB?

 

Ok imagine you have HP Virtualization Performance Viewer (vPV) monitoring the VMs via vCenter. While most of the VMs have VMware tools running in the guest OS, consider a new VM that was brought up for test/dev purpose. This VM (call it cooper if you like), does not have VMware tools running in it.

 

So from vPV the VM's IP address (and also hostname 'cooper', fully qualified dns name 'cooper.bigbang-theory.com') is not known. Let's assume that such a node CI does get into  run-time service model via vPV's OM integration.

We have a node that is built on few attributes of the node CI - namely the BIOS UUID, the display label of the VM.

 

Assume that now we run an operations agent or SiteScope monitor on this VM, giving the VMs full name. In either case the node CI that goes into OMi RtSM will have a valid dns name since in these cases the discovery is done from the guest OS, not from vCenter.

 

In RtSM with no identical CI properties matching, these two CIs will never match and will remain duplicates pointing to the same VM. The moment VMware tools is installed on the VM, and started, vCenter will obtain the IP address of the VM and then the nodes will get reconciled.

 

Consider if there about 500 or 700 such dev-test VMs, then one can easily run into equivalent number of duplicate CIs.

In effect alerts about performance of the VM will correlate to the vPV CI and alerts sent from the guest OS will correlate to the guest OS CI, which is really not anything close to what we generally want to present.

 

Just to break the monotony of all that tech talk, here's a Sheldon joke (a technical one still) -

A neutron walks into a bar and asks how much for a drink. The bartender replies "for you, no charge".

 

 

How does  having VMware tools enhance monitoring?

Ok, the OM agent is smart enough to know that VMware tools is installed on a guest and will obtain a lot of counters from the guest SDK. Look for all the GBL_LS_* metrics in the OM agent's metric set. The metrics obtained via guest SDK are more accurate than those obtained from standard OS system calls.

 

 

Rajesh: Why so glum, chum?
Sheldon: Apparently you can't hack into a government supercomputer and then try to buy uranium without the Department of Homeland Security tattling to your mother.

 

VMware tools mass installation suggestions

So how can you ensure that VMware tools is installed on all the VMs in your vSphere environment? There are a couple of typical configuration management suggestions.

 

  1. Get all your VM templates pre-fitted with VMware tools
  2. As part of VM creation run a post install action, mostly before the time you would commission monitoring on the VM, to install VMware tools
  3. If deploying from vCenter is a headache for Linux VMs think about setting up a yum repository, or apt-get package for the VMware tool packages.
  4. use a report like what you get in HP vPV (VMware Tools status report) to identify the existing VMs without VMware tools installed or running, and take steps like using PowerCLI commands to mass deploy the tools.

    See the relevant segment in this video.

 

Regarding 3. above, do you know that VMware hosts a web location from where the open-source version of the VMware tool packages can be downloaded? Here are the steps to install the VMware tools OSP on RHEL (without a 'X' display), using yum. There are other 

 

wget http://packages.vmware.com/tools/esx/5.0latest/repos/vmware-tools-repo-RHEL6-8.6.14-1.el6.x86_64.rpm
rpm -i vmware-tools-repo-RHEL6-8.6.14-1.el6.x86_64.rpm
yum install vmware-tools-esx-nox
/etc/init.d/vmware-tools-services start

 

 

End game for BSM / OMi admins - Keep pushing your VMware admins to ensure that all VMs are running VMware tools. If you are monitoring Hyper-V, think of host integration packages. Let me know if this pic helps soften things.

HPE Software Rocks!
  • infrastructure management
About the Author

Ramkumar Devana

Ramkumar Devanathan (twitter: @rdevanathan) is Product Manager for HPE Cloud Optimizer (formerly vPV). He was previously a member of the IOM-Customer Assist Team (CAT) providing technical assistance to HP Software pre-sales and support teams with Operations Management products including vPV, SHO, VISPI. He has experience of more than 14 years in this product line, working in various roles ranging from developer to product architect.