In a previous postI talked about the upgrade of our vSphere environment. The first post described the upgrade and migration of the Platform Services Controller (PSC) from a version 6 running on Windows to a 6.5 Appliance.
Our upgrade path would be PSC -> vCenter -> Hosts. Our environment consists of several vCenters so this will take some time and we might upgrade hosts in a vCenter that has been upgraded to 6.5 before we finish upgrading all vCenters to 6.5
With that, let’s look at upgrading a vCenter server to 6.5!
There are several preparations that needs to be considered before migrating:
- Read documentation!
- In all upgrades and migration scenarios it is important to read Release notes, best practices etc. before starting. These will contain important information and maybe some tips and tricks that will help your upgrade.
- Ensure that any 3rd party plugins and solutions depending on vCenter supports 6.5
- Update! Check your database size and purge old logfiles!
- Backup the existing/source vCenter and database
- Copy installer files to source vCenter AND your management workstation
- You could of course run it from a network location, but just in case…
- Get a temporary IP for the appliance
- The appliance will be deployed and live alongside the source for a short while. The temporary IP needs access to the source VC so ensure that any firewall between the two will allow it
- Ensure that the workstation has access to ports on source VC (remember the migration port 9123)
- Rename existing source VM
- As the new VM (appliance) have to run at the same time the source vc does they should have different names. It will suffice to rename just the VM in vCenter. You could of course name the new one with a temporary name, but then you will have to rename it when you’re finished
With the prereq’s accounted for let’s kick off the actual migration!
The Migration is divided in two steps. First we have the deployment of the new appliance and the next step will be the actual migration of the data.
Step 1 - Deploy appliance
- Start the Migration Assistant on the source vCenter server
- The migration assistant opens a command prompt which will do some prechecks and then it will wait for instructions from the Migration installer which we will run from a workstation. Note! Do not close this command prompt!
- Start the Appliance installer on your workstation and select Migrate[
- Read the onscreen instructions to understand what is performed in this first step.
- Read and Accept EULA
- You did read it?
- Connect to the source VC with the local vCenter administrative account
- Now you will add the details for deploying the new appliance, these steps is what you will be used to from deploying other VMs
- Connect to deployment host/vCenter
- Select folder, compute cluster etc
- Specify name and root password. Here you will give it the same name as the existing vCenter
- Select deployment size, these are preconfigured templates based on the environment. The migration assistant on the source VC will suggest the size in the console, but you can change it if you want
- Select datastore and optionally select Thin provision
- Configure the network. As you would experience the dropdown of portgroups is not sorted which is kind of annoying if you have a lot of port groups.
- After finishing these steps you will get a Review page before you can start the deployment of the new appliance
- After the deployment Step 1 is finished
- When finished you will have two VMs[
Step 1 is finished and we will continue with Step 2 which will finalize the migration.
Step 2 - Migrate
- The wizard will give an Introduction to what will be performed in this step
- The wizard will connect to the source VC and do some pre-migration checks. I got a warning on Update Manager and files that cannot be used but we’re able to continue
- The Wizard will also prompt for credentials to join the VM to AD
- Finally you will be asked for what data you want to migrate and the size of the data
- Like Step 1 you are presented with a final review page before you can start the migration. You will also have to confirm that you have backed up the source vCenter and database. Note that when you confirm the backup and select Finish the data migration will start and eventually the source vCenter server will be shut down. You will lose connectivity to vCenter for a short while
- The copy from source to target has started
- The migration assistant console back on the source VC will also report the steps performed
- After data migration and shut down of the source vCenter, the appliance will change it’s IP to the one the source had and it will start it’s services. Finally the copied data will be imported to the vCenter. After all this is done the migration has finished!
- You can log in to the appliance console on port 5480 and verify that everything looks good
Post-migration steps and checks
After the migration all looks good. We had one host that had some issues with it’s HA agent not working. Tried first to reconfigure HA for this host only but without that solving it. After disabling and enabling HA on the cluster the issue was solved.
We also did a quick review and adjustments of some configurations on the appliance:
- Ntp settings
- Set update check to automatic
- Fix syslog settings
- Set Password expiration settings
A couple of additional things to check and consider after the upgrade:
- Remember that other web clients on 6.0 vc’s in the linked mode won’t be able to see a 6.5 vc
- We have 5 VC’s in Enhanced Linked Mode, 2 of these are now on 6.5 and 3 are still at 6.0. If I point my web client to one of the 6.0 VC’s I’m only able to connect to the 6.0 VC’s
- Fix static DNS records
- With the vCenter VM previously being a Windows server it updated it’s DNS records itself. Now with a Linux Appliance you will need to create static DNS records or else it will become stale
- Update any CMDB, monitoring solutions etc
- If you have any external systems depending on the vCenter, the VC VM etc be sure to update them if needed
The whole migration was finished in about two hours and was very straight forward. Of course the time consumed will vary based on the environment. This specific vCenter is one of the smaller ones so I expect the remaining three vCenters to take a bit more time.