Six Methods for Keeping VM Tools Up to Date

When it comes to keeping VM Tools up to date, there are six different approaches that vSphere administrators can use. That may sound like a lot, but after seeing each of the various options, it is clear that the intention is to accommodate nearly any workflow customers require for flexible datacenter operations. These different techniques allow optimizing either for automation and standardization or for separation of responsibilities. A previous article provides an overview of the three types of VM Tools.

VMware Tools Status is Relative to Underlying Host

Recall that each ESXi host has a storage location for VM Tools installers, which is a configurable option and visibly referenced by the /productLocker symlink.  The target can be either local to each host or point to a centralized repository of VM Tools on a shared datastore. For more information about setting up a shared Tools repository, see this earlier post or KB 2004018.

VM Tools status for any given VM is always in the context of the underlying host. As demonstrated below, two different versions of Tools are considered “Current” because the underlying hosts are not identical.

When certain virtual machine events occur, such as power-on or vMotion, the version of VM Tools running on that guest is compared to the version associated with the underlying ESXi host. If the host has a newer version, the VM is considered out of date.

Note that there is no mechanism for VMs running on vSphere to contact the mother ship and learn about new versions of VM Tools – only the VM to host relationship is relevant. This explains why a VM may suddenly complain about having out of date VM Tools after migrating from one host to another – the destination host has a more recent version in the product locker.

VM Tools Type Determines Update Choices

Recall from the previous post that there are three types of VM Tools – the familiar Tools ISOs for all supported operating systems, plus two additional offerings in the form of binary packages for Linux. There are several ways to initiate VM Tools updates from vSphere or from within a guest. The following applies only to Windows and Linux guests using VM Tools ISOs except where noted. The VM Tools Linux packages – OVT and OSP – are not managed via vSphere, so they can only be installed and updated from within each guest OS using native package management tools.

Six Ways to Keep VM Tools Updated

1. Automatic update on VM boot

The simplest way to keep VM Tools up to date is to check a box and forget about managing this element of infrastructure. Upon VM reboot, such as after installing guest OS patches, VM Tools status will be checked and an update installed if needed. In many cases, this will result in one additional reboot after VM Tools installation completes.

This approach may be viable for less-critical workloads, perhaps labs or test/dev environments. Imagine a scenario where VMs are rebooting unexpectedly due to a widespread infrastructure outage. After scrambling to get applications back online, administrators could find themselves facing unanticipated subsequent reboots if a VM Tools update happened to be available. This is an edge case, but one to keep in mind.

2. Initiate update to one or more VMs through the vSphere UI

In the vSphere Web Client, when a VM indicates that VM Tools are outdated an adjacent button can be used to automatically initiate an update. This can be done interactively or in a completely hands-off fashion. In the latter case, administrators also have the option of suppressing any potential reboots on Windows VMs – this is a good option that enables coordination of reboots required after routine guest OS patching.

Important note for guests other than Windows and Linux: Solaris, FreeBSD, and Mac OS VM Tools can only be updated using the manual interactive method. There is currently no automatic Tools update for these guests.

Going a step further, it is also possible to select multiple VMs in the Web Client UI and initiate a VM Tools update on all of them at once.

3. VMware Update Manager: immediate, scheduled, or on boot

VMware Update Manager (VUM) has two very different roles to play when it comes to updating VM Tools. The first one has to do with fetching updated VM Tools ISOs in the form of the ‘tools-light’ VIB that is offered when needed in the normal ESXi patch stream. This patch is then pushed out to all managed hosts according to baselines established by administrators. Once this occurs, individual VMs will begin to detect that a new version of VM Tools is available and will be eligible for update.

The second role VUM has in managing VM Tools is to trigger updates for individual VMs according to baselines. Keep in mind that VUM does this work by leveraging the vSphere methods described in the two previous sections. In one mode, VUM can be used to make a bulk configuration change to multiple VMs so that a Tools update is checked and performed as necessary on each guest reboot, just like an administrator can do using the technique shown in #1 above. The advantage of using VUM is that many VMs can be configured or un-configured for this option at once.

The other mode VUM uses is to trigger a VM Tools update either immediately or at a scheduled time, just as an administrator can do manually as described in #2 above. One added benefit of using VUM to initiate these updates in this way is the ability to also remediate powered-off or suspended VMs, subsequently returning them to their initial state after update.

4. In-guest update – delegating control to app owners

For scenarios where application owners demand tight control over activities that occur in the guest OS, there is an option to allow in-guest updates of VM Tools. A tray icon in Windows will indicate that an update is available, and the VM Tools configuration dialog box will permit interactive initiation of an update at a convenient time.

For equivalent functionality from a command-line utility, vmware-toolbox-cmd is offered for Linux as well as Windows guests. Keep in mind that for Linux this is only for the VM Tools ISOs, since OVT and OSP use a different process, as described in #6 below.

Enable guest-initiated updates by modifying the isolation.tools.guestInitiatedUpgrade.disable VM setting, which can be done easily to one or more VMs with PowerCLI:

5. Mass updates through PowerCLI automation

In very large environments or for those that have established more mature operational processes, PowerCLI provides a powerful option for updating VM Tools. This approach can target particular groups of VMs in many convenient ways, such as by cluster, by guest OS version, tags, VM state, or other vSphere attributes.

6. Native Linux package management processes

By nature of their design, Linux guests running OSPs or OVTs update VM Tools as part of a broader patching and updating workflow used for other components. This allows administrators to leverage existing Linux package managers or broader patch management and monitoring solutions without need to coordinate with vSphere administrators.

7. BONUS:  VM Tools Upgrade Method (pun intended)

For advanced use cases where vSphere APIs are being used for deeper integration with other processes, consider the UpgradeTools_Task for programmatic upgrades of VM Tools.

Summary

With these flexible means of updating VM Tools, there is a suitable approach for any VMware datacenter, whether the requirement is centralized control, automation, delegation to app owners, or integration with existing patch management processes.