How to install VMware tools on FreeBSD server

FreeBSD is my favorite operating system. All my FreeBSD servers (except embedded systems on physical microcomputers) run as virtual machines. VMware officially supports FreeBSD as GuestOS, so nothing stops virtualizing FreeBSD even for production use.

VMware Tools is a suite of utilities that enhances the performance of the virtual machine's guest operating system and improves its management of the virtual machine. Although the guest operating system can run without VMware Tools, you would lose important functionality and convenience. In other words, VMware tools are not necessary but highly recommended to use on virtual machines running on top of VMware ESXi hosts.

There are multiple options for how to install VMware tools on FreeBSD, but I personally use Open VM Tools native FreeBSD package as using Open VM Tools is actually the latest VMware's recommendation for unix like systems which is the case of FreeBSD. The reason why I use Open VM Tools instead of VMtools delivered by VMware on ESXi hosts or VMware download sites is that I can use the default FreeBSD package management system (pkg) for simple deployment. It is fast, convenient, and fully integrated with standard operating system updates and upgrade procedures.

As you can see below, the installation on FreeBSD 10.x and above is very straightforward. It is a single command to install the open-vm-tools package and 5 lines in the FreeBSD system config file.

# You have to switch to the administrator account (root)
su -l root

# and unattended install of Open VM Tools on server without X11 by FreeBSD package manager

pkg install -y open-vm-tools-nox11

 

# and unattended install of Open VM Tools on workstation with X11 by FreeBSD package manager

pkg install -y open-vm-tools

To run the Open Virtual Machine tools at startup, you must add the following settings to your /etc/rc.conf

sysrc vmware_guest_vmblock_enable="NO" # this is good for VMware Workstation or Fusion
sysrc vmware_guest_vmhgfs_enable="NO" # this is good for VMware Workstation or Fusion
sysrc vmware_guest_vmmemctl_enable="YES" # this is good for VMware vSphere Memory Ballooning
sysrc vmware_guest_vmxnet_enable="YES" # vmxnet is enabled by default anyway
sysrc vmware_guestd_enable="YES" # this is good for example to report IP address to vSphere Client

... and reboot the server.

Easy, right?

 

And just for your information, Open VM tools is set of four kernel modules (vmemctl, vmxnet, vmblock, vmhgfs) and one daemon (guestd).

vmemctl is a driver for memory ballooning. 

vmxnet is paravirtualized network driver
vmhgfs is the driver that allows the shared files feature of VMware Workstation and other products that use it. This is not optimal to use on the server therefore we do not enable it.
vmblock is block filesystem driver to provides drag-and-drop functionality from the remote console.

VMware Guest Daemon (guestd) is the daemon for controlling communication between the guest and the host including time synchronization.

On Windows and Supported Linux Distributions exists other VMtools modules/drivers but those are not supported on FreeBSD. For further information about all VMtools components look at

• Names of VMware Tools Components
• VMware Tools FAQ

PowerCLI script to report VMtools version(s)

UPDATE 2018-02-05: I have just been told about very nice PowerCLI command-lets allowing to manage VMtools.  Leveraging command-lets Get-VMToolsInfo, Get-VMToolsGuestInfo and Get-VMByToolsInfo is definitely the better way then my script below. All VMtools management command-lets are available on GitHub here
https://github.com/vmware/PowerCLI-Example-Scripts/blob/master/Modules/VMToolsManagement/VMToolsManagement.psm1

But if you are interested in my approach and simple script below I will be more than happy if it helps you.

###################################################################

This week I had a talk with one of my customers about VMtools versions and benefits of VMtools updates/upgrades. Few months ago I wrote another blog post discussing centralized version of VMtools repository (aka shared productLocker) so you can read it here.

Nevertheless, in large environments with multiple vCenters and thousands of VMs it is pretty handy to have single report with all VMtools versions to be able to asset and plan potential VMtools update/upgrade.

The problem with VMtools versions is that APIs reports just a single integer number of VMtools identification like 9354, 10246, etc. These numbers are also visible as Tools version on NGC/VI Client. However, vSphere admins are more familiar with human readable VMtools version also visible in guest OS which looks like 8.3.19, 9.4.6, 10.0.8, etc. For all VMtools version numbers and mapping you can check text file at https://packages.vmware.com/tools/versions

I have invested an hour or so to write simple PowerCLI script reporting VMtools identification and also human readable version for all VMs in particular vCenter or even across multiple vCenters. I have also included VM hardware version which can be handy information as well.

So initial PowerCLI code is below and the latest version will always appear on github here.

 ######################################################################################################################################  
 # Author: David Pasek  
 # E-mail: david.pasek@gmail.com  
 # Twitter: david_pasek  
 # Creation Date: 2016-11-25  
 #  
 # Use case:  
 #  Key use case of this script is to report VMtools from all VMs in vCenter  
 #  
 # Disclaimer:  
 #  Use it on your own risk. Author is not responsible for any impacts caused by this script.   
 ######################################################################################################################################  
 #   
 # CHANGE FOLLOWING VARIABLES BASED ON YOUR SPECIFIC REQUIREMENTS   
 # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv  
 #  
 # Report type - table, grid, file, csv-file  
  $REPORT_TYPE = "csv-file"  
 # Report file name without file extension. Extension is automatically added. File is created in current working directory.   
  $REPORT_FILE_NAME = "report-vmtools"  
 ######################################################################################################################################  
 Clear-Host  
 # We need VMware PowerCLI snapin  
 $o = Add-PSSnapin VMware.VimAutomation.Core  
 $o = Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false  
 # Connect to vCenter  
 Write-Host "Connecting to vCenter ..."  
 $VC = Read-Host "Enter one vCentre Server or multiple vCenter servers delimited by comma."  
 Write-Host "Enter vCenter credentials ..."  
 $CRED = Get-Credential  
 Connect-VIServer -Server $VC -Credential $CRED -ErrorAction Stop | Out-Null  
 # Add new property (ToolsVersion) to VM  
 New-VIProperty -Name ToolsVersion -ObjectType VirtualMachine -ValueFromExtensionProperty 'Config.tools.ToolsVersion' -Force | Out-Null  
 # Initalize report  
 $Report = @()  
 foreach ($vm in Get-VM) {  
  # Numbers mapping is from https://packages.vmware.com/tools/versions  
  Switch ($vm.ToolsVersion) {  
      7302 {$GuestToolsVersion = "7.4.6"}  
      7303 {$GuestToolsVersion = "7.4.7"}  
   7304 {$GuestToolsVersion = "7.4.8"}  
   8192 {$GuestToolsVersion = "8.0.0"}  
   8194 {$GuestToolsVersion = "8.0.2"}  
   8195 {$GuestToolsVersion = "8.0.3"}  
   8196 {$GuestToolsVersion = "8.0.4"}  
   8197 {$GuestToolsVersion = "8.0.5"}  
   8198 {$GuestToolsVersion = "8.0.6"}  
   8199 {$GuestToolsVersion = "8.0.7"}  
   8290 {$GuestToolsVersion = "8.3.2"}  
   8295 {$GuestToolsVersion = "8.3.7"}  
   8300 {$GuestToolsVersion = "8.3.12"}  
   8305 {$GuestToolsVersion = "8.3.17"}  
   8306 {$GuestToolsVersion = "8.3.18"}  
   8307 {$GuestToolsVersion = "8.3.19"}  
   8384 {$GuestToolsVersion = "8.6.0"}  
   8389 {$GuestToolsVersion = "8.6.5"}  
   8394 {$GuestToolsVersion = "8.6.10"}  
   8395 {$GuestToolsVersion = "8.6.11"}  
   8396 {$GuestToolsVersion = "8.6.12"}  
   8397 {$GuestToolsVersion = "8.6.13"}  
   8398 {$GuestToolsVersion = "8.6.14"}  
   8399 {$GuestToolsVersion = "8.6.15"}  
   8400 {$GuestToolsVersion = "8.6.16"}  
   8401 {$GuestToolsVersion = "8.6.17"}  
   9216 {$GuestToolsVersion = "9.0.0"}  
   9217 {$GuestToolsVersion = "9.0.1"}  
   9221 {$GuestToolsVersion = "9.0.5"}  
   9226 {$GuestToolsVersion = "9.0.10"}  
   9227 {$GuestToolsVersion = "9.0.11"}  
   9228 {$GuestToolsVersion = "9.0.12"}  
   9229 {$GuestToolsVersion = "9.0.13"}  
   9231 {$GuestToolsVersion = "9.0.15"}  
   9232 {$GuestToolsVersion = "9.0.16"}  
   9233 {$GuestToolsVersion = "9.0.17"}  
   9344 {$GuestToolsVersion = "9.4.0"}  
   9349 {$GuestToolsVersion = "9.4.5"}  
   9350 {$GuestToolsVersion = "9.4.6"}  
   9354 {$GuestToolsVersion = "9.4.10"}  
   9355 {$GuestToolsVersion = "9.4.11"}  
   9356 {$GuestToolsVersion = "9.4.12"}  
   9359 {$GuestToolsVersion = "9.4.15"}  
   9536 {$GuestToolsVersion = "9.10.0"}  
   9537 {$GuestToolsVersion = "9.10.1"}  
   9541 {$GuestToolsVersion = "9.10.5"}  
   10240 {$GuestToolsVersion = "10.0.0"}  
   10245 {$GuestToolsVersion = "10.0.5"}  
   10246 {$GuestToolsVersion = "10.0.6"}  
   10247 {$GuestToolsVersion = "10.0.8"}  
   10249 {$GuestToolsVersion = "10.0.9"}  
   10252 {$GuestToolsVersion = "10.0.12"}  
   10272 {$GuestToolsVersion = "10.1.0"}  
   0   {$GuestToolsVersion = "Not installed"}  
   2147483647 {$GuestToolsVersion = "3rd party - guest managed"}  
      default {$GuestToolsVersion = "Unknown"}  
      }  
  $vminfo = New-Object -Type PSObject -Property @{  
             Name = $vm.Name  
     VMhardwareVersion = $vm.Version  
           ToolsVersion = $vm.ToolsVersion  
           GuestToolsVersion = $GuestToolsVersion  
      }  
  $Report += $vminfo  
 }  
 # Show report  
 Switch ($REPORT_TYPE) {  
      "grid"   { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Out-GridView }  
   "file"   { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Out-File -FilePath "$REPORT_FILE_NAME.txt" }  
   "csv-file" { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | export-csv "$REPORT_FILE_NAME.csv" }  
   default  { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Format-Table }  
 }  
 Disconnect-VIserver -Server $VC -Force -Confirm:$false  

The script can be configured for different report types by changing variable $REPORT_TYPE

Following report types are supported:

• Standard PowerShell table report to output terminal (table)
• PowerShell GridView (grid)
• Standard text file including same content as table (file)
• Comma separated values file (csv-file)

Different sample reports are visible in screenshots below

CSV-FILE

FILE

GRID

Hope this helps some other folks in VMware community. Any feedback or feature requests are welcome.

Related links:

• VMware Tools 10 and "shared productLocker"
• VMware Tools 10.0.8 is now GA
• Powershell Script Upgrade VMware tools without a reboot - looks interesting but I did not test it so far.

VMware Tools 10.0.8 is now GA

VMware Tools 10.0.8  is now GA and live on www.vmware.com and available to all Customers.

Resolved Issues
Virtual machine performance issues after upgrading VMware tools version to 10.0.x in NSX and VMware vCloud Networking and Security 5.5.x

While upgrading VMware Tools version to 10.0x in a NSX 6.x and VMware vCloud Networking and Security 5.5.x environment, the performance of the guest operating system in the virtual machine becomes slow and unresponsive. A number of operations like, logging in and logging off through an RDP session, response for an IIS website and launching applications become slow and unresponsive.
This issue occured due to a known issue with VMware Tools version 10.0.x. This issue is resolved in this release. For more information see KB 2144236.

Full Release Notes are available here.

Broader context ...
In the past, some customers who did not needed vShield components did not installed these VMtools components to mitigate these performance and unavailability risks. It is possible to remove vShield component from installation process.

 VMware-tools-9.x.x-yyyy.exe /v /qb-! REINSTALLMODE=vomus ADDLOCAL=All REMOVE=Hgfs,WYSE,Audio,BootCamp,Unity,VShield REBOOT=ReallySuppress  

Please be aware, that in newer VMtools version vShiled component was split to two more specific components -  FileIntrospection and NetworkIntrospection.

 VMware-tools-9.4.12-2627939-x86_64.exe /v /qb-! REINSTALLMODE=vomus ADDLOCAL=All REMOVE=Audio,BootCamp,FileIntrospection,Hgfs,NetworkIntrospection,Unity REBOOT=R  

For further information of all Names of VMware Tools Components Used in Silent Installations see. VMware vSphere documentation here.

Keywords:
vmtools, vshield,  fileintrospection, networkintrospection

VMware Tools 10 and "shared productLocker"

VMware tools (aka VM tools, vmtools) were always distributed together with ESXi image however it changed with VMware Tools 10. VMware is now shipping VM tools also outside of the vSphere releases. For more information look at this blog post.

Where can I get VMware Tools?

Option 1/ VMware Tools 10 can be downloaded from my.vmware.com. More specifically from this direct URL. Please be aware, that you must be logged in to my.vmware.com before direct link works.

 

UPDATE: Direct link to Broadcom is https://support.broadcom.com/group/ecx/productdownloads?subfamily=VMware%20Tools

Option 2/ VMware Tools can be also downloaded from here without any login credentials required. The latest version (10.0.6 at the moment of writing this blog post) is available here. Benefit of option (2) is that there are binaries which can be use directly within guest operating systems.

Option 3/ Open-vm-tools. This option is available for linux based and FreeBSD operating systems. You can read more about it here , in SourceForge or in GitHub. Optimally the open-vm-tools should be available through standard package manager of your unix-like operating system.

It is worth to mention that

• VMware Tools 10 are backward compatible and are independent on ESXi version.
• You can share VMware Tools 10 packages with application/OS owners and they can update VMware Tools by them selves during OS update procedure. But even your OS owners will do VMtools update by them selves it is still worth to have VMware tools available in ESXi to have ability of VMtools comparison from vSphere point of view.

VMtools versions

VMtools reports version as a number. For example version number 9536 is version 9.10.0. You can map VMtools version number to human readable version by leveraging this file.

Updates

Ok, so what? If you update your VMware Tools in old way (together with ESXi image) you - or VMware Update Manager - have to upload VMware tools to each ESXi host with following impacts

1. It takes significantly more time especially in bigger environments.
2. You can potentially end-up with different VM tools version in different ESXi hosts in your datacenter. It can be reported as outdated VM tools after vMotion of particular VM across different ESXi hosts.

The thing is that VMware Tools 10 and above doesn't need to be updated automatically with ESXi update on each ESXi host. You can update ESXi hosts without VMware Tools and later update VMware tools bundle just on single shared place - in shared productLocker location.

So what actually the "productLocker" is? The "productLocker" is essentially VMware Tools directory. This directory is on each ESXi host by default however it can be reconfigured and pointed to directory on shared datastore. Such configuration is called "shared productLocker" and it enables us to do centralize update of VM tools. It is worth to mention that all your ESXi hosts must be reconfigured to use this shared location.

Reconfiguration has to be done via ESXi host advanced configuration option UserVars.ProductLockerLocation. So it has to be changed manually on each host, you can change it automatically via custom PowerCLI script or if you have Enterprise Plus Edition you can leverage Host Profiles. The last option works for me perfectly.

Below is screenshot showing /productLocker directory structure and content on ESXi 6 host ...

/productLocker directory structure and content 

If you use central location for VMware Tools then you don't need update ESXi hosts with full ESXi image but only with ESXi image without VMware Tools. See example of different profiles in ESXi 6 Update 2 image below.

[root@esx01:~] esxcli software sources profile list -d /vmfs/volumes/NFS-SYNOLOGY-SATA/ISO/update-from-esxi6.0-6.0_update02.zip
Name                              Vendor        Acceptance Level
--------------------------------  ------------  ----------------
ESXi-6.0.0-20160301001s-no-tools  VMware, Inc.  PartnerSupported
ESXi-6.0.0-20160302001-standard   VMware, Inc.  PartnerSupported
ESXi-6.0.0-20160301001s-standard  VMware, Inc.  PartnerSupported
ESXi-6.0.0-20160302001-no-tools   VMware, Inc.  PartnerSupported

Profile names with postfix no-tools can be used for ESXi update without updating VMware Tools to each ESXi host. For further details how to update ESXi hosts with particular profile see my other post - How to update ESXi via CLI.

Current ESXi host product locker location can be displayed by esxcli command

esxcli system settings advanced list -o /UserVars/ProductLockerLocation 

and the output should looks like ...

[root@esx01:~] esxcli system settings advanced list -o /UserVars/ProductLockerLocation   
Path: /UserVars/ProductLockerLocation   
   Type: string 
   Int Value: 0
   Default Int Value: 0
   Min Value: 0   
   Max Value: 0   
   String Value: /locker/packages/6.0.0   
   Default String Value: /locker/packages/6.0.0   
   Valid Characters: *   
   Description: Path to VMware Tools repository

To change location you can use following esxcli command

esxcli system settings advanced set -o /UserVars/ProductLockerLocation --string-value "/vmfs/volumes/NFS-SYNOLOGY-SATA/VMtools/latest" 

And you can verify that setting was changed ...

[root@esx02:~] esxcli system settings advanced list -o /UserVars/ProductLockerLocation
   Path: /UserVars/ProductLockerLocation
   Type: string
   Int Value: 0
   Default Int Value: 0
   Min Value: 0
   Max Value: 0
   String Value: /vmfs/volumes/NFS-SYNOLOGY-SATA/VMtools/latest   
   Default String Value: /locker/packages/6.0.0   
   Valid Characters: *   
   Description: Path to VMware Tools repository

ESXi host has to be rebooted to activate new Product Locker Location.

Hope this helps other folks in VMware community to simplify operations with VMware Tools.

UPDATE 2018-02-05: I have just been told about very nice PowerCLI command-lets allowing to manage VMtools.  Command-let Update-VMToolsImageLocation updates the link /productLocker in ESXi host directly to avoid host reboot and command-let Invoke-VMToolsUpgradeInVMs in the combination with shared productLocker is a very nice way how to automatically update VMtools.
All VMtools management command-lets are available on GitHub here
https://github.com/vmware/PowerCLI-Example-Scripts/blob/master/Modules/VMToolsManagement/VMToolsManagement.psm1

UPDATE 2019-04-04: New VMware blog post about this topic has been published in January 2019. The blog post is here Configuring a VMware Tools Repository in vSphere 6.7U1.
In comments is the link to PowerCLI code leveraging vSphere API to change the productLocker location. The link to the code is here. The code is clear and simple ...

 $esxName = 'MyEsx'  
 $dsName = 'MyDS'  
 $dsFolder = 'ToolsRepo'  
 $esx = Get-VMHost -Name $esxName  
 $ds = Get-Datastore -Name $dsName  
 $oldLocation = $esx.ExtensionData.QueryProductLockerLocation()  
 $location = "/$($ds.ExtensionData.Info.Url.TrimStart('ds:/'))$dsFolder"  
 $esx.ExtensionData.UpdateProductLockerLocation($location)  
 Write-Host "Tools repository moved from"  
 Write-Host $oldLocation  
 Write-Host "to"  
 Write-Host $location  

References

• Installing VMware Tools in vSphere (VMware KB 2004754)
• Installing and upgrading the latest version of VMware Tools on existing hosts (2129825)
• Manfred Hofer : VMware Tools Part 1 – An Overview
• VMware Tools User Guide
• VMware vSphere Central : Configure a Centralized VMware Tools Installation Repository