Finally got around to upgrading my vCenter 6.7 deployment to 7U1. I did run in to a couple snags; one with a solution, one I am still trying to figure out.
I used the UI installer, so just ran setup.exe and ran through the wizard.
Select the Upgrade option, so it will then run you through the data and configuration migration.
Starts the wizard, so just click Next.
The usual EULA stuff, so we need to accept then click Next.
Provide information for connecting to the source vCenter, then click Connect to Source.
It will then request additional information for connecting to the vCenter. Use the SSO account then click Next.
Then you get the certificate warning, which we will click Yes to accept.
I have a VCHA deployment, so I got a prompt informing me that the new appliance will be deployed to the same resources the current VCSA is running on. *(There was an issue with the VCHA deployment, detailed more in a bit.)
It still prompted for a computer resource, with the host pre-selected. Next.
Prompted for root credentials.
Deployment size. I selected Small since, in the past, I have had issues with Tiny not providing enough memory for the vsphere-client or vsphere-ui process. You can manually increase the memory heap size, but I have resources available to support resources requires for Small.
Select storage for the new appliance.
Provide temporary network details for the appliance. Being a homelab, it’s on DHCP. FQDN not necessary.
Review settings and if all looks correct, click Finish.
Deploying the OVA.
Continuing to set up the new appliance.
Appliance deployment has completed. Click Continue to launch your default browser and connect to the VAMI of the new appliance.
Since we are upgrading, we will select the Upgrade option to migrate the configuration.
That will launch the wizard. Click Next.
Provide appropriate SSO credentials and details for the source vCenter.
It will then do some pre-checks on the source appliance.
Here is where I had the first issue. Pre-checks failed, but no real information. The error and source detail was not accurate, as both appliances were running on the same ESXi host.
While VMware documentation states an upgrade is supported on a VCHA configuration, I decided to just destroy the VCHA on my current deployment anyway. It’s easy enough to recreate. Logged in to my production vCenter, Configure vCenter HA. Status reports all green (though it previously reported out of sync, so maybe that was the cause?)
Select Destroy, delete passive and witness VMs, then OK.
Re-ran upgrade checks, though it came back with another error. This one even more lacking in detail. Simply “internet error occurs during pre-upgrade checks.” I clicked Close.
I also got a prompt with some warnings about unsupported plugins and files that cannot be used with Update Manager 7.0.0 will not be copied. This is nothing for me to worry about.
Next we select what data we want to migrate. I wanted to migrate all of it. This also notes the default partition does not have sufficient space available. This is because it needs to back up all the data before it can copy it.
To find a path with sufficient space, SSH to the current appliance shell and do a:
df -h
/storage/updatemgr had 90GB available, so I just chose that.
I should have kept “Join CEIP” selected, since it’s needed for vCenter to validate compatibility. Click Next.
Review details and click Finish when ready.
Warning that the source vCenter will be powered down. OK to continue.
Source configuration being captured for copying.
Destroying the VCHA did not remove the secondary NIC from the source vCenter, so I got the following warning. No concern, so clicked Close.
Starting up the new vCenter appliance.
Importing configuration to the new appliance.
Warning about secondary NIC again, along with a couple other messages. No concerns, so Close.
Deployment of new appliance completed, with configuration migrated. Click the link to launch in to the new appliance then launch the HTML5 client.
Don’t forget that we can close out of the original installer.
Also need to install the new vCenter license, which you get reminded of at first login.
We can validate that our internal CA signed certificate is still being used.
As I forgot to remove some old plugins, like the vSphere Integrated Containers and old NSX, I had to remove those from the MOB (Managed Object Browser.)
That’s accessible via https://vcenter/mob and log in with SSO.
Select Content.
Then ExtensionManager.
Select More if the plugins aren’t display in the top few results.
Note the plugin names. In my case, it was com.vmware.nsx.ui.h5, com.vmware.vic, and com.vmware.vShieldManager.
Select UnregisterExtension under Methods.
Enter the name then click Invoke Method. It will (should) return void
You may need to restart the vsphere-ui service for changes to take effect.
You can SSH to the appliance shell and run:
service-control --restart vsphere-ui
Don’t forget that vSphere 7U1 introduced the new vSphere clustering service VMs. By default, these just get deployed to some available storage. If shared storage is not (yet) available, it will deploy to local storage. If shared storage is available, it seems to deploy to a random volume. I svMotioned the 3 to the shared VMware storage I have. Disregard the error about losing vSphere HA protection; one of my hosts was having issues installing the HA agent. Pretty sure it was just a fluke, as the host would also not enter maintenance mode or even reboot.
You will get the following when you go to migrate one of the vCLS VMs, which was not a concern.
Don’t forget to clear your browser cache, otherwise some of the items will not load any detail like these below.
