VM /ETC

Last week I had a customer ask me for help with a repetitive administrative task that is extra aggravating for shops with a lot of Linux virtual machines (VMs). The customer was frustrated with the manual process of upgrading VMware Tools after kernel upgrades in their VMs. It’s a problem unique to Linux since the Windows operating system kernel does not change very frequently, but the development cycle of several Linux distributions can mean multiple kernel versions each year. After each upgrade and subsequent VM reboot the VMware tools must be re-installed so the tools are compiled correctly with the new kernel. Not exactly fun to do when you have a lot of Linux VMs.

I suggested 2 alternatives for the customer. The first is a scripted solution configured inside each Linux VM and the second is a built in feature of VirtualCenter and ESX for versions 2.0.1 and 3.0.1 or greater. I have not tested either of these solutions. My reason for writing this post is partly to explain the options, but also to get some feedback from the community. Let me know if you use or have tried either of these solutions or anything similar. If there is a better way please comment on this post! If you try one of these for your Linux virtual guests let me know what works and what doesn’t.

The following methods require that VMware tools are already installed in the Linux guests. For instructions for installing the tools check out the current VMware .pdf guide titled Basic System Administration Update 2 Release for ESX 3.5, ESXi version 3.5, VirtualCenter 2.5. if you are wondering if you should even install VMware tools in Linux guests than check out my post “Why do I need to install VMware Tools?”.

Script to detect Linux kernel change and re-install VMware tools

I stumbled across this script from the post Automating VMware modules reinstall after Linux kernel upgrades – From the Recliner…

“Now, most admins note about the “–default” option which can be used when running the vmware-config-tools.pl (or vmware-config.pl) script to cause the script automatically answer all the questions with the default answer. All we need is a way to run this automatically when a new kernel is booted. It turns out, at least with Redhat systems (and I suspect other systems), that this is exceptionally easy. For legacy reasons the Redhat init scripts check for the existence of a file called /etc/rc.modules and, if it exist, execute it. The file is typically a simple shell script and thus all we need is a simple method for detecting if the currently booting kernel already has the VMware modules installed and, if not, run the vmware config script with the “–default” option.

Here’s the script that I’m currently using with Linux VM’s running in VMware ESX/Server:

#!/bin/bash

if [ ! -e /lib/modules/`uname -r`/misc/.vmware_installed ]; then
/usr/bin/vmware-config-tools.pl –default
touch /lib/modules/`uname -r`/misc/.vmware_installed
fi

Simply place these lines in /etc/rc.modules and make sure it is executable and your good to go. Note that it’s possible you may already have a rc.modules file so in that case you should just add the lines to the existing file. When you install a new kernel and reboot the “.vmware_installed” file will be missing from the /lib/modules directory for that kernel and it will run the vmware-config-tools.pl (or vmware-config.pl) with the “–default” option to reinstall the VMware kernel modules. Even better, because this is called very early during startup, long before the VMware services are started, eveything will work the first time with no interaction whatsoever.

One thing to look out for, if you install an upgraded vmware-tools (or VMware Workstation/Server release) without upgrading the kernel and you want the new modules to be installed on the next reboot you need to remove the “.vmware_installed” file. Simply run the following command and the new modules will be installed on the next boot:

rm -f /lib/modules/`uname -r`/misc/.vmware_installed

One major drawback, if your system uses a separate partition/logical volume for /usr, which is common, then the rc.modules script will probably be called before that system is mounted. Possible solutions include adding a command to mount /usr at least read-only before attempting to run the vmware-config script or, you could just move the commands to rc.local. The disadvantage of rc.local is that, for Linux guest VM’s using the “flexnet” adapter they will have already loaded the pcnet32 module in place of the vmxnet driver. You could easily script unloading this module and restarting the vmware-tools service, but I’ve seen a few applications that behave poorly if you stop networking after they’ve already been started.“

The concept of this solution is solid. If would recommend that you create a gold image template with the script already configured and deploy new VMs from this template. I imagine that slight variances in the script benefit different distributions. Read the entire post and it’s comments at the link above for some additional advice and user feedback.

Use the VI Client to update VMware Tools in multiple VMs simultaneously

The built in feature of VirtualCenter and ESX to bulk upgrade VMware tools works great for Windows VMs. VMware’s documentation confirms the process works for supported Linux guests as well. For a table of all supported guest operating systems go here.

Here are the step by step instructions for using the VI Client:

1. Launch the VI Client and log in to the VirtualCenter Server.
2. Click Inventory in the navigation bar and expand the inventory.
3. In the inventory list, select the host on which virtual machines you want to upgrade reside.
4. Click the Virtual Machines tab.
5. Select the virtual machines you want to upgrade with the new version of VMware Tools.
6. Right?click the virtual machines and choose Install/Upgrade Tools.

VirtualCenter provides two options to upgrade VMware tools:

• Interactive tools upgrade - Requires some user interaction and requires you to reboot the guest operating system manually.
• Auto tools upgrade – Upgrades tools without user interaction and reboots the guest operating system, if required. Auto tools upgrade is supported for tools version ESX 3.0.0 and above on Windows and Linux guest operating systems.
• Note: the field for Advanced Options can use any of the command line options

Command line options:

For more information about bulk upgrading VMware Tools and using the VirtualCenter command line as an alternative see my previous post Use the VI Client to bulk upgrade VM tools.

VMworld 2008 Session for VMware in a Linux Shop

If you are attending VMworld 2008 next month the session listed below may provide complimentary recommendations for managing Linux VMs. The presenter, Mike DiPetrillo, maintains his own blog titled From the VMware Field: Mike D’s Virtualization Blog and is a fellow resident of Atlanta, GA. Check out both Mike’s blog and his session if you can. I have a schedule conflict but will keep this session on my “preferred switch list”. If you are reading this and VMworld 2008 was in the past look up the presentation at VMworld.com. (It feels weird writing a message for someone in the future!)

Related Posts

• Why do I need to install VMware Tools? (11)
• Use the VI Client to bulk upgrade VM tools (2)
• FREE Disk space monitoring solutions for VMware virtual infrastructure (2)
• Update and Auto Patch ESX (1)
• Script for VMware HA Feature without VirtualCenter (5)
• Linux scripts to clone and rename VMware Server VMs (8)
• Linux Strategy and Roadmap #TA3201 (10)
• VMworld 2008 General Session Day 2 (2)
• Use the VI Client to configure ESX NTP time sync (8)
• Things that make you go hmmmm – March 28, 2008 (0)