posted

7 Comments

2017 UPDATE:

A more recent article is now available with the latest information on VMware Tools lifecycle management.


In September we announced that VMware Tools 10.0.0 Released and that VMware is now shipping VMware tools outside of the vSphere releases. Since then, we have received a lot of feedback from the community, customers, and internal folks alike. I would like to let everyone know that we have listened and we continue on our path to make VMware Tools lifecycle (and ESXi lifecycle for that matter) easier and less painful than how it may appear today.

image

 

Before I get too far into this post, I thought I would add a FAQ section to try to answer some of the more common questions we have received:

FAQ

    • Where is the VMware Tools Download?
    • Why aren’t all the files from the ESXi tools directory found in the VMware Tools Download?
      • As of November 2nd, 2015 they are! We listened loud and clear. Now when users go to download VMware tools they will be presented with the option of downloading a VMware Tools packages ZIP or TAR.GZ file. Both have the exact same content but are in two separate formats for users to choose from. Once downloaded and extracted, you will find all the files that you would normally see within an ESXi host’s tools directory. This just makes life easier for the admins to have everything in one place.
    • I see files for Legacy VMware Tools packages for Windows and Netware OS, what is that?
      • These files are for any virtual machines running pre-Windows 2000 operating systems, hence the term ‘legacy’ if you have any of these in your environment, you will want to copy and paste these folders into each of your hosts, or into the shared product locker.
    • Can this set of VMware Tools be used with Update Manager (VUM)?
      • Yes it can, however I will explain how this works further down in the blog post. Click here to jump
    • Can you use the VM setting “Check and upgrade Tools during Power Cycling”?
      • Yes you can, you must first ensure that the VMware Tools files are in their correct locations (either within the host or in a shared product locker location). You can use PowerCLI to update this setting for every single virtual machine with the following code:

# Create the config object

$Config = New-Object VMware.Vim.VirtualMachineConfigSpec
$Config.Tools = New-Object VMware.Vim.ToolsConfigInfo
$Config.Tools.ToolsUpgradePolicy = “UpgradeAtPowerCycle”

 

# run through each virtual machine. ***NOTE*** this can be tweaked to look for specific VMs or groups of VMs

Get-View -ViewType VirtualMachine | foreach {
$_.ReconfigVM($Config)
}

#you can then disable this and set it back to the default value with this:

$Config = New-Object VMware.Vim.VirtualMachineConfigSpec
$Config.Tools = New-Object VMware.Vim.ToolsConfigInfo
$Config.Tools.ToolsUpgradePolicy = “manual”

Get-View -ViewType VirtualMachine | foreach {
$_.ReconfigVM($Config)
}

    • My VMs are not showing as out-of-date since I updated my VMware Tools files, why is that?
      • VMware Tools versions are recorded in each virtual machine’s VMX process memory. A Baseline query uses the version of VMware Tools found on the host (or sharedLocker) to determine if a VM’s Tools are out of date. This only happens when a VM is powered-on, vMotioned, or when the VMTools service is restarted within the guest VM. Currently the VM’s cached status can be refreshed via a vMotion or a full VM power-off/power-on or by restarting “VMtools”. We’ve recognized this as a limitation and are working to make this easier in a future release. For now, if you choose to restart the service to have it update the version check, here is a little PowerCLI script that can help you for Windows machines:

# Get all Virtual Machines that have the “windowsguest” attribute in ExtensionData.Guest.GuestFamily, and that are powered on

$windows = Get-View -ViewType VirtualMachine | where {$_.guest.guestfamily -eq “windowsguest” -and $_.runtime.PowerState -eq “poweredOn”}

# Foreach virtual machine from the results, run “restart-service” within the guest **Note the username and password will need to be updated. if all vm’s have the same admin account or an Admin AD account, use that… you can also use the –GuestCredential if you have the credentials (get-credential) stored in a variable, in place of the –GuestUser and –GuestPassword parameters. This way you won’t have to place your password in a script.

foreach ($vm in $windows) { Invoke-VMscript -ScriptText “restart-service -Name VMTools” -VM $vm.name -GuestUser “administrator” -GuestPassword “VMw@re123”  -errorAction SilentlyContinue }

#**Note that I use the –ErrorAction SilentlyContinue parameter. This is because Invoke-VMScript uses VMtools to invoke the command in the guest. Since we are restarting the VMTools service, this command will come back with an error, however if you check the windows logs you’ll see the command functions properly and this error is only because the Tools connection is being reset during the command execution (this is normal when running the restart-service VMTools command)

  • Can you use this with AutoDeploy?
    • Yep! Using this with the shared productlocker will allow you to use this with Auto Deploy. Click here to jump
  • Which version of tools should I use? VMware Tools 10 was released before vSphere 5.5u3 but u3 has a lower build number?
    • If you are trying to decide which version of tools to use, know that you can use either version without problems. However the out-of-band release will most likely be the latest release. In general, a single version of tools used in a vSphere release may be older than what is seen on the VMware Tools download page if it ran into the release freeze before the out-of-band version came out. (it’s a lot easier to ship newer versions of VMware Tools outside of ESXi)
  • Is there a VMware tools VIB that can be downloaded and used?
    • There is not. VIBs (vSphere Installation Bundles) are convenient when distributing a collection of files. However, most VIBs are relatively small. VMware Tools would be roughly 150 Megabytes and this is not conducive to a clean and small deployment of ESXi. Note that a VIB is similar to a ZIP archive which means that not only would distributing tools as a VIB require 150MB for the VIB itself, but ~150MB more once extracted to the VMware Tools folder, increasing the size of ESXi by 50%.

Getting Started

By default, ESXi includes VMware Tools under the /productLocker folder (which is actually a Symlink to the location on it’s local storage.. see the image below). When running ‘ls –n’ you will see that productLocker (cyan) just points to /locker/packages/5.5.0 (dark blue meaning the path exists. You also can tell this is an ESXi 5.5 host). ‘ls –n /productLocker’ will return only that line and be a little easier on the eyes for those who are not as familiar with unix.

image

Inside of the given folder are two other folders: “floppies” and “vmtools” these contain all necessary ISOs and files to allow VMware tools to be installed and updated on each supported VM on the host. If you are updating VMware Tools packages on each individual ESXi host, the new files would go in these two folders.

image

Know that if you are not just updating the tools within each ESXi Host, there are several steps you will need to take (these are also discussed in the FAQ as well as below in the AutoDeploy/Host Profiles section):

  1. Update the UserVars.ProductLockerLocation
  2. Add the VMware tools to it’s own folder in a shared datastore
  3. Update the ESXi Symlink that points to the location of the files on the shared datastore (OR) restart the ESXi host to have it update itself automatically

How Update Manager (VUM) works with VMware Tools Updates

To better understand how to make the VMware Tools lifecycle easier, you must first understand how VMware’s products, like Update Manager, interact with the environment. Update Manager does a great job of patching hosts and updating VMware Tools, but what’s actually going on under the covers? Update Manager uses APIs to talk to each ESXi host to perform remediation tasks. What this means is that Update Manager will use whichever version of VMware tools is installed locally on each host, unless that host is using a shared productLocker. VUM uses whatever configuration the host has, it does not have a Tools repository or additional logic to point to some other location. Keep in mind that if we are trying to update VMware Tools via Update Manager, we will either need to add the new version of VMware Tools to each host individually, or configure a shared product locker and point each ESXi host to it.

Once the VMware Tools are placed in the appropriate location, Update Manager will be able to perform updates of VMware Tools for each virtual machine in vCenter.

image

How Auto Deploy/ Host Profiles works with Shared ProductLocker

As I’ve mentioned in previous blog posts, when using Auto Deploy you have two options for ESXi:

  • Standard ESXi image
  • xxxx-no-tools image

The Standard ESXi image is what you find in any other deployment method, or if you were to perform the ESXi default manual installation. This will install VMware Tools on the ESXi host and the total image size will be roughly 300 Megabytes.

The xxxx-no-tools image is exactly that; an ESXi image without the VMware Tools folders. This drops the size of the installation in half down to roughly 150 Megabytes. There are definitely many PROS to doing it this way: Faster boot times, less network saturation, single location for VMware Tools (easier to manage Tools binaries), etc. However, just using xxxx-no-tools image with Auto Deploy is not enough, you must also configure your Host Profiles to point to the Shared Product Locker.

During your Host Profile creation, ensure that you add the ProductLockerLocation information into the profile. In the “Edit Host Profile” window, expand the “Advanced Configuration Settings”, “Advanced  Options”, and “Advanced configuration option”. Click the Green “Add” button to add an additional advanced option.

2015-11-03

In the Advanced Option drop-down box, select “Configure a fixed option”. The name of the option should be “UserVars.ProductLockerLocation” and the value of the option should be “/vmfs/volumes/<name of shared datastore>/<name of product locker folder>” in my case it was /vmfs/volumes/CPBU_PM_PMM1/productLocker. ***You need to make sure that this Datastore/folder is a shared datastore accessible by each host that will be using this Host Profile***. Also note that the value is CASE SENSITIVE!!!

2015-11-03 (2)

Once you have your Host Profile created the Host Profile, you can attach it to a cluster or an Auto Deploy rule and you are good to go. Just make sure that the Datastore/folder includes the two folders ‘floppies’ and ‘vmtools’ and their contents from the VMware Tools download ZIP/TAR.GZ

image

When the ESXi hosts are booted via Auto Deploy and the Host Profile is applied, the symlink will be updated to reflect the shared product locker location and all hosts booting this way will share this location.

Can we Automate Some More Please?

While I mentioned earlier in the post about this, I will mention again, that we are aware of the effort that takes place to update VMware Tools and we are working to make this easier on the customers in a future release. Rest assured, we are working on it. However, until then I have created a script that can help assist you in your efforts. It can be found on my personal blog (http://www.vtagion.com) as the script is not supported by VMware and has not been tested by GSS. However, I have used it several times in both of my environments without problem. As always when using someone else’s scripts you should read through every line and make sure you understand what is happening (BEFORE) running the script; secondly, you should always test things (OUTSIDE) of production. That being said, you can find the script and read more about it HERE.

Additional Resources

General VMware Tools installation instructions (1014294)

http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1014294

About the Author

Brian Graf

Brian Graf is a Senior Product Manager - Distributed Resource Management (DRS/HA/DPM) at VMware. Previous to Product Management, Brian worked as a Senior Technical Marketing Manager at VMware, focused on PowerCLI Automation and ESXi Lifecycle technologies. Previous roles also include: Consultant for EMC Consulting. His main focus was Data center migration methodologies and implementations. His background previous to VMware includes Operations Engineering, Virtualization, Business Intelligence, and Exchange/Blackberry Engineering. Get notification of new blog postings and more by following Brian on Twitter: @vBrianGraf