ESX Virtualization

VMware ESXi, vSphere, VMware Backup, Hyper-V... how-to, videos....

VMware Tools 10 release – Not Tighten to ESXi Releases Any More

By | Last Updated:

Shares

VMware has released VMware Tools 10 as separate download through MyVMware. As you know, previously each time there was new release of VMware ESXi, then there was a new release of VMware tools. Both of those were tighten together and never released separately. This is now changing and VMware tools 10 and higher versions will be released on regular basis separately from ESXi.

It's important to note that VMware Tools 10.0.0 is backwards compatible with ESXi 5.0 as per the release notes. This version of VMware tools is also compatible with VMware Workstation 12.0 and VMware Fusion 8.0.

Why this change?

VMware says that it allows to get the latest new features and enhancements made to the VMware tools faster to the customers. And that there is no specific reason not to do so.

VMware Tools 10

What's new in VMware Tools 10.0?

New functionalities and enhancements has been added to this version of VMware tools. One of them is the possibility to report on true versions for Mware Tools Operating System Specific Packages.

From the release notes…

  • Common versioning: Infrastructure changes to enable reporting of true versions for VMware Tools Operating System Specific Packages. These changes will depend on host support.
  • Common Agent Framework: Common Agent Framework (CAF) provides the basic services necessary to simplify secure and efficient management of agents inside the guest virtual machines.
  • Quiesced snapshots enhancements on Linux: Robustness related enhancements in quiesced snapshot operation. vmtoolsd service supports caching of log messages when guest I/O has been quiesced. Enhancements in vmbackup plug in to use a separate thread to quiesce the guest operating system to avoid timeout issues due to heavy I/O in the guest.
  • Shared folders: For Linux distributions with kernel version 4.0.0 and higher, there is a new FUSE  based Shared Folders client which is used as a replacement for the kernel mode client.
  • ESXi serviceability: Default vmtoolsd logging is directed to a file instead of Syslog or Event Viewer. Enhanced VMwareToolboxCmd.exe on Windows andvmware-toolbox-cmd on Linux to change vmtoolsd logging levels.

GuestInfo enhancements: Plug in enhancements to report more than 64 IP addresses from the guest. These enhancements will depend on host support.

DirectX 10 and OpenGL 3.3 support

Also from the release notes…

VMware Tools 10.0.0 enables support for DirectX 10.0 and OpenGL 3.3 on Windows guests when used with VMware Workstation 12.0, VMware Fusion 8.0 and a future release of VMware vSphere where the virtual device supports the required feature.

What you'll find in the downloads?

  • VMware Tools CD image for Linux Guest OSes
  • VMware Tools CD image for Windows Guest OSes
  • VMware Tools CD image for Solaris Guest OSes
  • VMware Tools CD image for Freebsd Guest OSes
  • VMware Tools CD image for OS X Guest OSes

Note that the release notes also has Known issues section, which will tell you for example why Installing VMware Tools on OS X 10.10 fails (needs to uninstall before installing VMware Tools 10.0.0).

How to create a shared repository for VMware tools?

It would be best to create some kind of shared repository for those VMware tools so you could mass-update all your VMs, like you use to do after each ESXi upgrade. Right? Let's see how to do it.

  1. Create a folder on shared datastore visible to all your hosts, upload there the content of a productLocker folder from ESXi 6.0.

VMware Tools 10.0.0

2. Modify an advanced settings of each host on your cluster. Manage > Settings > Advanced System Settings > UserVars.ProductLockerLocation.

In my case, my shared datastore called drobo, the new path I entered looks like this:

/vmfs/volumes/drobo/latest_vmtools

vmtools

For the changes to take effect, restart the host.

There is a way to overcome this (without restart) by using SSH and create/delete/modify few shortcuts. You'll find on how to do it in Brian Graph's post in the link below.

Note that there is also a Manual Download VMware tools page. Check out my post about it.

Links:

Shares
5/5 - (2 votes)

About Vladan SEGET

This website is maintained by Vladan SEGET. Vladan is as an Independent consultant, professional blogger, vExpert x16, Veeam Vanguard x9, VCAP-DCA/DCD, ESX Virtualization site has started as a simple bookmarking site, but quickly found a large following of readers and subscribers.

Connect on: Facebook. Feel free to network via Twitter @vladan.

Comments

  1. Nick Godrey says

    Vladen-

    I used to keep VMware tools on a shared location on a VMFS volume as well, but discovered it caused issues with vMotion when any other VM had tools actively mounted. Our experience was that if you performed a vMotion, the VM that was migrating as part of the vMotion process attempted to place a seemingly exclusive lock on the product locker location to verify the version of tools that particular host was pointing to (likely so that it could display whether tools was up to date or not) – VMware support referred to this process as the “interactive tool check”. As the product locker location was mounted by another VM, the vMotioned VM took could not achieve an exclusive lock and took ~30 seconds to time out while attempting to achieve this VMFS lock. During this time, the VM had not entirely completed the vMotion process and lacked network connectivity – this caused some application timeouts on our end when databases were being vMotioned and was all sorts of fun to track down. We ended up having to remove the product locker location and returned to leveraging
    the locally deployed version of VMware tools to avoid this issue.

    This was experienced with 5.1, I have not experimented with this on 5.5 or 6.0 yet. I would recommend anyone thinking of converting to using a shared VMFS product locker location perform some tests related to this issue, otherwise any vMotions occuring while any VM has tools mounted could lead to unexpected VM outages.

x