There has been a lot of buzz around vSphere Lifecycle since VMworld. My last few blog posts on VMware Tools have had a tremendous amount of traffic, so I decided to continue with the theme and give you all what it appears you want more of. So in this post, LET’S TALK TOOLS!
I Feel Like VMware Tools is Always Out-Of-Date… Why is that?!
Well, there are a number of reasons that this can happen. But to better understand what’s going on here, we need to understand a little bit more about VMware Tools and how they work.
Within each ESXi installation, there is a folder called “productLocker”, which contains two folders, “vmtools” and “floppies”. These are the files used to install and update VMware Tools on all the VM’s running on the given ESXi host.
If we take a look inside the “vmtools” folder you will see that there are several types of files included.
ISO – These are the files that get mounted to the guest OS to install tools.
SIG – Signature files for the ISOs to prevent others from tampering with or changing the ISO
MANIFEST – file that describes the names, versions, and resources of the files/drivers within tools.
The “floppies” folder contains virtual floppy images that are used for specific OS’s to install specific drivers/functionality.
As you can see, the productLocker folder actually consumes roughly half of the size of your ESXi Installation (~150MB). This is why if you are using Auto Deploy, we recommend you using the “no-tools” ESXi Image to cut the amount of data being pushed to each host at reboot by roughly 50%, increasing boot performance and reducing boot times.
OK, so how does this affect whether or not vSphere states that my virtual machines are up-to-date or not?
Here’s the problem. Each version of ESXi in your environment is going to have a different version of VMware Tools in its productLocker folder. This means, if you have a virtual machine on a specific host, let’s say an ESXi 5.5 host, and you updated VMware Tools on said VM, vSphere would show you that VMware Tools is current and running…
All good, right? Well… Here’s the problem, if you move that virtual machine to another host in your environment that differs in version from the host that was originally running that VM, it will show “VMware Tools: Running (Out-of-Date)”
You look in vSphere and it tells you your tools are Out-of-date but you swore you just updated them! This continues across all versions of vSphere in your environment.
So, What’s the solution?
The solution is two-fold…
The first part of this is to understand that VMware Tools is backwards compatible with previous versions of ESXi up to a given version (see the Interoperability Matrix here) This means, if you have a number of different ESXi versions running in your virtual environment, depending on which versions of ESXi are running, the latest VMware Tools could potentially run on all your hosts, regardless of the fact that you have hosts that are out of date. We can see from the interoperability matrix that the VMware Tools from vSphere 6.0 are compatible back all the way to ESX/ESXi 4.0! while the tools from 6.0 U1 are compatible back to ESXi 5.0. WOW! I think we are on to something!
.
So if you have a mixed environment, and want all of the hosts to be upgrading the same version of tools, we now know that 6.0 Tools is compatible all the way back to ESX/ESXi 4.0
Now that we know which version of VMware Tools we are going to use, the second part of thisprocess is to figure out how/where to place the tools for total consumption from all the hosts. I opened up PowerCLI, Connected to vCenter and ran the following code:
Get-Datastore | where {$_.ExtensionData.summary.MultipleHostAccess -eq “true”}
which returned my Shared Datastore “SDT”:
Since SDT is a shared datastore, I will create a folder in it which will be accessible to all my hosts. I will then copy the contents of productLocker from my ESXi 6.0 host into this folder:
My folder now looks like this, just as it did within ESXi…
Now that we have a new shared location for the VMware Tools files, select a host, go to Manage > Settings > Advanced System Settings > UserVars.ProductLockerLocation.
You will now need to edit this value with the updated path which should read as follows:
/vmfs/volumes/<name of shared datastore>/<name of product locker folder>
in our case it looks like this:
/vmfs/volumes/SDT/productLocker
Once you save this, the last step is to either restart your host for the changes to update internally, or SSH the host and update the product link as well there (this will require you to SSH but will not require a server restart).
***NOTE*** to do this via PowerCLI follow these steps:
This will set this value across all hosts in the given cluster.
Restart the Host or SSH
if you SSH into your host and change the directory to /productLocker, you will see that the directory change takes you to the original default location for this host, and not the new path.
From here we will need to delete the shortcut and create a new one to our new location.
And you are done, as you can see we now have our updated productLocker shortcut on our ESXi hosts and are good to go.
This may be a number of steps to take, but by doing this you can greatly decrease the level of effort required to keep all of your virtual machines’ VMware Tools versions up to date. With a single central repository you will now have a single source of truth for VMware Tools versions and can base everything else off of the sharedLocker folder.
