Most of you will be intimately familiar with vCenter Server. It provides the main management capabilities in a VMware Virtualized Datacenter, including provisioning, monitoring, patching etc for all your hosts and virtual machines. You’ll spend a lot of your time using it if you’re a VMware Admin. But you may not know that it is advisable to reboot your hosts after you upgrade the version of vCenter Server. Otherwise you may get a little surprise the next time you go to patch or upgrade your hosts. I ran into this myself just recently after upgrading to the latest version of vCenter and then immediately attempting to upgrade my ESXi hosts in my lab. Fortunately this isn’t really a problem and is very easy to fix. This article will explain why.
During a vCenter Upgrade the VMware HA Agent on all of the ESXi hosts will be updated. After this happens the “require reboot” flag is set on the hosts, as explained in VMware KB 2034945. There is no visual cue that this is the case, so it is very easy to miss. The most likely time you’ll pick this up is if you are using Update Manager to scan your hosts for updates, or you’re attempting to upgrade ESXi. If you upgrade ESXi manually and haven’t already rebooted, then it’s very likely that the HA agent will fail to initialize the first time when the host restarts. This is very easily resolved by right clicking on the host and selecting the “Reconfigure for vSphere HA” option. This takes about a minute and you’re hosts HA Agent will be reconfigured and working again. Until the HA Agent is fully working and initialized successfully you will not be able to run any VM’s on the host.
If you want to run a PowerCLI Command to see if your hosts need a reboot or not prior to an upgrade check out this article titled How to find VMware ESX(i) servers that need a reboot using PowerCLI.
This is really only a minor inconvenience and is easily fixed by reconfiguring HA. But it is better to catch this and know about it first, rather than finding out only after HA fails to initialize, especially in a highly automated environment where the problem might not be caught for a couple of days and you could have problems starting VM’s.
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2015 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.