There are numerous ways to upgrade VMware Tools, which you should have installed on all of your VMs, but not quite as many that allow you to suppress a guest reboot afterwards. There are many reasons both for and against suppressing the reboot process, and I certainly don’t recommend avoiding the reboot for prolonged amounts of time. However, if you want to do a non-invasive update and let the reboot occur during your corporate patch cycle, the information in this post may appeal to you.
Contents
Using the vSphere Client
Probably the most known, and easiest method, to update VMware Tools is via the vSphere Client. It’s simple and straightforward.
- Right click on a VM in the vSphere Client
- Choose Guest
- Choose Install/Upgrade VMware Tools
You will be prompted to choose how you would like the upgrade to take place, either Interactively or Automatically. Along with the Automatic option comes the ability to enter some arguments, listed as “advanced options” in the GUI, that will be passed to the install.
I did a lot of web searching but could not find anyone with the updated string to put in this box after the VI3 days. Also, the official VMware documentation seems to ignore any recommended values for the advanced options box. A former colleague of mine asked what to put in the box, so I did some digging with procmon to see exactly what the advanced options box does.
Behold! The string that I have found to work is as follows:
/s /v/qn ADDLOCAL=ALL REBOOT=ReallySuppress
I’ve tested this on ESXi 4.1 and ESXi 5.0 with the same results – the VM is updated without a reboot. I will caution that you shouldn’t fully take my word for it, as perhaps some newer or older version of tools will not respond to this exact phrasing as planned. Test it out first to make sure it will go as planned. I won’t take responsibility when your production SQL box reboots. 😉
Using a PowerCLI Script
The second method is a little more difficult, but not by much. It requires that you have installed PowerCLI onto your workstation or server.
It also gives me a chance to use my incredibly awesome PowerCLI graphic featuring Spongebob.
You can read the documentation on the cmdlet here, or you can see some further examples on VMware’s KB site or on ICT-FREAK’s page of PowerCLI one-liners, but the basic code is:
[sourcecode language=”Powershell”]
Get-VM "Name Of VM" | Update-Tools -NoReboot
[/sourcecode]
You can get as fancy as you want with the Get-VM portion by using the –Location argument. In this example, I’ve nested 3 Get cmdlets to specify a datacenter, cluster, and folder to search. The script will update every VM it finds in that location.
[sourcecode language=”Powershell”]
Get-VM -Location (Get-Datacenter Foo | Get-Cluster Bar | Get-Folder Blah) | Update-Tools -NoReboot -RunAsync
[/sourcecode]
Note that in this case I’ve added the -RunAsync argument to avoid having to wait for each VM’s tools to start updating. Also, it’s important to know that the Update-Tools command does not accept -WhatIf or -Confirm.
[symple_box color=”black” fade_in=”false” float=”center” text_align=”left” width=””]You can find all of my various PowerShell scripts in my GitHub repository[/symple_box]
Using a Remote Execute Program (PSEXEC)
The final method is by calling the installer using some remote execution software. This could be any of your third party installers, and I use the example of PSEXEC because it’s so well known. You can use the same arguments I supplied in the vSphere Client example to accomplish this.
