Avoiding Those Pesky Reboots when Updating VMware Tools
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.
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:
Get-VM "Name Of VM" | Update-Tools -NoReboot
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.
Get-VM -Location (Get-Datacenter Foo | Get-Cluster Bar | Get-Folder Blah) | Update-Tools -NoReboot -RunAsync
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.
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.
having random problems where some VM’s DNS registration are deleted (normal behavior for a NIC being removed from a server) and not repopulated after upgrade completion. anyone else see an oddity like this? we’re using vmxnet3 NICs.
I’m assuming you mean the IP/Mask/Gateway information on the NIC, not the DNS registration on the DNS server? If so, I have not seen that issue outside of doing a virtual hardware upgrade from v4 to v7 where the non-vmxnet3 NIC is upgraded along with the VM (typically from flexible to vmxnet3).
Bizarrely enough, the actual DNS record from our AD servers gets randomly deleted during the tools upgrade.
We noticed the problem when upgrading to 4.1 update 1 originally.
After upgrading the tools manually and rebooting, we would notice that random VM’s are not pingable by DNS name. We have to run an ‘/ipconfig registerdns’ to fix as even a reboot doesn’t always work to bring it back. All the IP/Mask/GW content is saved, just something with the process of upgrading the vmxnet3 NIC driver fails to register the server back in DNS.
We opened a support ticket with VMware who watched us reproduce the issue but they couldn’t perform it again in-house so we moved on. I was hoping it was a weird ’4.1 update 1′ fluke but now happening again in update 2.
Understood, and I have actually seen that before. In my environment it only affected 2 VMs out of around 300 VMs updated, so I assumed it was some Windows glitch and wrote it off as such. vSphere 4.1u1 on a Server 2003 R2 VM, vmxnet3. I didn’t notice it until the local DNS cache had expired and the DNS name was not resolvable (this was in a pre-prod environment, not a huge deal). I too used the ipconfig /registerdns cmd to resolve.
If you do dig up the root cause, I’d be interested in hearing about it.
Unfortunately, it’s a bit more more common than your ratio for us and affecting our production network.
Even worse, it happened to the vCenter server itself and we didn’t realize it until DNS replicated everywhere and nothing could resolve it.
Will certainly post again if we determine what’s causing it.
thanks.
I have also had this happen when I got fancy and tried out the powershell script for about 150 vm’s
I would say at least 30 machines lost their dns registration when running the script.
In the end, it wasn’t worth the hassle as I had to go export all the vm’s to a text file, setup a script to ping each vm and identify the ones with lost dns…
It was then easier to just reboot the hosts then login and manually register the dns again.