The cliff notes for this process are:
- Mount/extract/etc. the ISO
- On the old VCSA, turn ssh on
- Run installer.exe
- Point to an existing vCenter/ESXi in order to provision the new VCSA instance (read more below)
- Specify what data will be migrated
- Power-off the old VCSA
- Import the data defined earlier
- Enjoy VCSA 6.5 GA
It is important to note that during this process the original VCSA is powered off but is not deleted. You will need to delete the appliance yourself. VMware is kind enough to let you do this at your own leisure in case anything goes whacky during the process.
Now, let’s get started!
Download the VMware vCenter Server Appliance 6.5 ISO from
https://my.vmware.com and either mount it or burn it to DVD. Once mounted, you can run the installer in [CD]:\vcsa-ui-installer\win32\installer.exe and will be presented with the following window. For this effort we’re going to choose “Upgrade” from the menu below:
The following screen introduces the product and process:
You have to accept the usual terms and conditions:
The “Deploy appliance” screen is a little confusing since we’ve chosen to upgrade our existing VCSA. However, what the upgrade does is actually deploy a new VCSA and migrate settings and database over to the new appliance. Sneaky, VMware, sneaky!
Enter your existing appliance FQDN or IP along with your SSO username and password, then specify a vCenter or host that manages the existing appliance:
Accept the certificates from both the vCenter and host:
The next screen allows you to specify where the new appliance is deployed. Specify the FQDN or IP of your host or vCenter server along with credentials necessary:
Again, accept the certificate for the ESXi host or vCenter server you’re using as a target:
Provide the VM name of your new vCenter server. Again, we’re going to end up with a new appliance, so name it in accordance to whatever your standard is. Obviously, you cannot use the same VM name as the existing VCSA:
If you’re experienced with deploying VCSA 6.0 then you might recognize that the resources changed a bit in the next screen shot. I am going to use a “Tiny” deployment, but this size used to require 2 vCPU and 8GB of RAM. Now, it looks like it requires 10GB of RAM:
As usual, pick your storage and choose whether or not you want to deploy the VCSA thick or thin:
Next up is the network configuration page. Specify your temporary IP address – this is the IP address that the new upgraded VCSA will be stood up with, but will ultimately be redefined with the IP of the original appliance:
Review your configuration and click finish to begin the actual deployment:
The actual deployment kicks off:
Very soon thereafter, you’re done!
Well, hold on a second – we’re done Stage 1. There’s more to this. You can see the message in the above window stating that you can visit https://[IP of new VCSA]:5480 to continue the upgrade if you get disconnected. Or, you can hit continue. Once you continue, you’ll the following screen explaining that we’re now going to move data (taking a snapshot on the original VCSA may not be a bad idea at this point). Click next to continue:
Next, we… oh no!
Well jeez – would have been nice to know that we need to connect to the existing VCSA via ssh! So, we’ll go enable ssh on the existing VCSA and click close, then back, and retry the pre-upgrade checks (you can enable ssh by going to https://[IP of original VCSA]:5480 and turning on ssh from the Access tab). If you have any firewalls between the new instance and old instance of your VCSA then you’ll need to make sure TCP port 22 is open.
Once we retry the pre-checks, we pass but with warnings:
The warnings above simply state to turn off fully automated DRS during the upgrade while also letting us know that the vSphere Replication extension that I have in use may not be compatible with the new vCenter server. Onward!
This is the cool part – we get to pick whether we want to import just the configuration, the configuration with events and tasks, or the configuration, events, tasks, and performance metrics. I am going to choose the third option – Configuration, events, tasks, and performance metrics. You may choose another option if your environment has significant data and migrating it is unreasonable or you just don’t care:
The next screen is the typical Customer Experience Improvement Program opt-in which I am choosing to defer:
One more review screen – this screen shows you again that you’ll have a temporary IP on the new instance as well as the FQDN of the new instance once the migration is complete. Of course we’re going to check the box “I backed up the source vCenter Server“, right? Click finish!
The following screenshots so the next few screens you’ll click through:
If you have the vSphere client open directly to your host, you can open the console of your existing VCSA 6.0 and watch it shutdown, etc. VMware is so nice – I would have just yanked the power
After some more waiting, the Active Directory configuration is setup, the VMware Identity Management services are started, Postgres is setup, all sorts of cool data is imported (like the Content Library!), etc. Finally, we’re done:
Everything was successful as noted by the message beneath the completion bar. Perfect!
:
While I did install the Enhanced Authentication Plugin, I was not able to check the “Use Windows session authentication” on the page. I was, however, able to login with my AD credentials:
Everything is looking good! One thing worth mentioning is that when visiting https://[VCSA].domain.local/ you’ll find that there is a vSphere client with flash and without, but that the client without is listed as “partial functionality” at this time. Sad face.
Still, everything works well! Thanks for following along. I’ll report back with any other findings.
