With VMware vCenter Server Appliance 6.5 patching has become very straightforward and both the vCenter software and the underlying Photon OS can be updated using a simple GUI. This short run through covers patching a single VCSA where the VCSA High Availability has not been configured.
Login to the vCenter Server Appliance admin console at https://my-vcenter-name:5480/
Click on Images to Enlarge
Select “Update” from the Navigator menu on the left hand side, and then choose “Check Repository” from the “Check Updates” drop down in the main panel. This will check the VMware website for any new patches.
The deployment of High Availability in the vCenter Server Appliance 6.5 is very slick and there’s a great step-by-step walkthrough of how to implement it. However, sometimes things go wrong – in my case a misconfiguration in the underlying network meant that the hosts I was trying to deploy to couldn’t reach each other on the new HA network.
The good news is the smooth Installation process is accompanied by a smooth uninstaller when things have gone wrong. It’s nice to see that this part of the application lifecycle process hasn’t been ignored by the development team at VMware. With the right planning and a bit of luck, you’ll never have to see this yourself- but here’s some example screenshots.
The install has failed, the wizard was unable to configure HA, and we are left with a situation looking like this:
The vSphere Web Client is telling me “vCenter HA has an invalid configuration. Click the remove button to destroy the current vCenter HA cluster configuration”. And it is really as simple as that, clicking Remove starts the process- this doesn’t destroy your vCenter environment- just the failed HA attempt – and vCenter reverts back to the model it was using beforehand. We get a nice clear explanation of what is going to be done, details of what manual steps may be necessary, and an option to change our mind.
The task proceeds like any other vCenter operation, showing as Completed in the Recent Tasks bar- in my homelab this removal task took just 11 seconds.
Once done it was just a case of powering down and removing the defunct Passive and Witness VMs, fixing the pre-existing fault that had caused the error in the first place, and then running the install again.It should end up looking something like this:
It’s always good to see that development effort has been put into helping the user when something unexpected has occurred and this is a good example of that.
VCSA Upgrade via the Appliance Installer
The vCenter Server Appliance (VCSA) upgrade from 6.0 to 6.5 is a slick, well managed, process. The installer deploys a new appliance, transfers all the settings from the old one (including IP address and identity) and then powers the old appliance VM off. This provides a neat roll-back option if something has gone wrong- you just power down the new appliance and turn the old one back on.
In upgrading my homelab I came across a small gotcha in this however. If you have your old VCSA VM set to auto power on when the host is then the next time you reboot that host (for example when you’ve done a Hypervisor upgrade) the old VCSA will turn on. You could now, like me, be in the situation where two VCSAs are running at the same time and sharing an IP. In a larger environment this is unlikely to happen- the host-based VM Startup/Shutdown feature is largely replaced by HA and DRS rules – but in a smaller setup this is a common practise to ensure that the vCenter comes up when the lab is switched on.
Automatic VM Startup and Shutdown with 2 vCenters
The solution is to switch the Startup behaviour to manual for the old VCSA, and just to make sure disable the virtual NIC on that old VM. Of course once you are happy with the upgrade the old Virtual Machine can be archived/deleted altogether.
The log file disk was nearly full on a vCenter Server Appliance instance, showing a warning message in the vCenter console and the VAMI (Login to https://vCenterHostName:5480). After a bit of investigation (and I’d recommend looking at this article by Brandon Lee and Knowledge Base 2143565 ) I found an old Support Bundle was taking up 2GB of the log disk unnecessarily and tripping the alert threshold.
SSH into the VCSA using the username root (see KB2143565) and navigate to the folder
And look for files named “*_vmsupport.tgz“, check the timestamp on these files and remove any old ones that are no longer required.
Hopefully the warning should clear and the health status should return to green in the vSphere Appliance Management Interface