Recently I had to upgrade VMware Tools on a number of VMs due to ESXi being upgraded on the hosts. I remember a few years ago that there was talk of being able to upgrade VMware Tools without having to restart the VM. Great I thought but I couldn’t remember which version this came in with but as my VMs were on a version of VMware Tools that came with ESXi 6.something and I was going to a later version of 6.something then I was sure that I was going to be able to upgrade VMware Tools on my production VMs without having to restart them.
After a bit of research I discovered that yes you could upgrade VMware Tools without rebooting the VM but any driver updates required a reboot on Windows servers and running the VM for a prolonged time without rebooting following the VMware Tools upgrade was not recommended.
If you just right click on a VM and select “Upgrade VMware Tools” it WILL reboot the VM without warning you, although I think you can put an advanced option in to suppress the reboot, it is something like /reallynoreboot or you can perform a VMware Tools Upgrade from PowerCLI without a reboot e.g.
Get-VM <vmname> | Update-Tools -NoReboot
You can use what you like to select multiple VMs at once, e.g.
Get-VM WINSRV* | Update-Tools -NoReboot
(to get all of the VMs starting WINSRV)
Get-VM –Location Production | Update-Tools -NoReboot
(to get all of the VMs within the Production folder – think this includes subfolder)
Get-VM –Location ESXCluster01 | Update-Tools -NoReboot
(to get all the VMs on the vSphere ESXCluster01 cluster)
If you are selecting multiple VMs then it is probably best to also add the -RunAsync option on to the Update-Tools command so that they are updated at the same time and not sequentially, e.g.
Get-VM –Location ESXCluster01 | Update-Tools –NoReboot -RunAsync
You can also update the Tools using VMware Update Manager, there is a Predefined baseline for VMware Tools Upgrade to Match Host. You attached this baseline to a VM folder, cluster or even the top level, i.e. the vCenter Server. When you remediate this baseline you have the option of running it immediately, scheduling it at a specific time, e.g. 7am, or at the next Power Cycle. Of course, even if you have attached the baseline to the top level you can select to remediate at a lower level (even down to a single VM). It would be worth attaching this baseline to the top level if only to use it to scan for VMs that are non-compliant. There is also a baseline for upgrading the VM Hardware and can be used to confirm all the VMs were on the latest VM Hardware.
On some of my VMs I used VMware Update Manager to update VMware tools at next power cycle. When you do this it enables the option in the VM to “Check and upgrade VMware Tools before each power on”, see below
I rebooted one of the VMs to confirm that it would work. It does not update tools before the reboot but after the VM powers back on, so once booted up VMware Tools are updated then the following message is displayed on the console (as you are unlikely to be on the console you will not see the message) and the server reboots a 2nd time.
It appears to leave the “Check and upgrade VMware Tools before each power on” option set on the VM, so next time there is a VM Tools update it will update the VMs again at the next power on of the VM. Not sure if I like the fact this is left on or not. Also, you need to manually do a scan of the baseline against the VMs again for the updated VMs to change from non-compliant to compliant.
When you schedule the VMware Tools upgrade with VUM you can select an option to create a snapshot before upgrading. The good thing about this is that you can set how long the snapshot stays for before it is deleted, the default is 36 hours (maybe this can be changed in the VUM settings) but I reduced it to 12 hours and in one case only 2 hours. All of the snapshots were removed automatically.
I had a problem with using VUM to update some of the servers that I scheduled to run and set them to create a snapshot. Included in the list were a couple of the clustered SQL servers. I could see that the task failed in recent tasks but could not find an error message to explain why but assuming it was down to not being able to snapshot the clustered servers so I ran it again on these two servers WITHOUT a snapshot and it worked.
Using the option to update at next reboot is a risk as it might catch someone out. Also doing a VMware Tools upgrade and suppressing the reboot causes a risk as if there is a problem with one of the new drivers it will not get detected until the server is rebooted by which time you probably don’t remember that VMware Tools was updated so makes troubleshooting the issue harder.