It is time to think about upgrading “older” vSphere environment to the latest version 6.5 U1. The journey to the cloud, VSAN and lots of other new possibilities as well as the approaching end of support date for vSphere 5.5 (2018/09/19) are more than enough reasons to start planning a vSphere Upgrade.
VMware recently announced the official end of Windows vCenter: https://blogs.vmware.com/vsphere/2017/08/farewell-vcenter-server-windows.html
Traditionally a lot of customers are still using vCenter on Windows. VMware’s longer term strategy is targeted to the modern vCenter Server Appliance (VCSA). This Photon OS based version of vCenter offers very good performance and as it is an appliance les complexity. All configuration and management task can easily be fulfilled using either the HTML management interface of the standard vSphere WebClients (the traditional Flex client as well as the HTML5 Web client). – So to make the story short – it is time to replace the Windows vCenter with the VCSA.
vSphere 6.5 or better the vCenter Appliance Installer has an integrated vCenter migration assistant which allows to migrate a Windows vCenter to a brand new vSphere 6.5 U1 vCenter Appliance.
This is a pretty easy task, which consists of two parts.
- Start the migration tool on your old Windows vCenter. – This automatically launches a Pre-Check. You current Windows vCenter is analyzed to verify if the migration has access to all resources needed – and if the current version can be migrated correctly.
- Launching the VCSA 6.5 U1 installer, and selection the Migration Option. – This will create a brand new vCenter Server Appliance, migrate all the data we want to migrate, then switch of the old Windows vCenter and change the personality of the new vCenter Appliance to match the old Windows vCenter.
This is pretty cool because:
- Your brand new Appliance will have the same name and IP as your old vCenter, so all users, scripts and other surrounding modules should work without any change. – Shure – before doing your upgrade you have to double check if these surrounding components, like plug-ins, Backup solutions, agentless antivirus solutions etc. will be compatible with vCenter 6.5 – and yes you might need to update some of these modules first to guarantee a error free migration, but that’s your personal pre-check before you start the vCenter migration.
- If something goes wrong and the new appliance should not be operational – you still have your Windows vCenter which is untouched, you just need to reboot it….
I won’t write too much about how this migration works, there are lots of colleague bloggers offering click thru migration samples. There is also a pretty complete official blog about this upgrade and the migration. So before jumping into the upgrade check these resources:
General information about vSphere 6.5 U1:
Upgrade Considerations Part 1:
Upgrade Considerations Part 2:
Upgrade Considerations Part 2:
vCenter Migration Assistant Walkthrough:
Errors in the Migration Assistant of Windows vCenter 5.5 6.0 to vCenter Appliance 6.5 U1
The Migration assistant in my lab produced the following error running it for the first time (and yep these are pretty typical):
You have to run the following command repeatedly if you have to fix any errors..
Most errors have a pretty good description in their log files. The following is just a sample of two errors that could occur which can be fixed quickly. SOme items cannot be rtansfered automatically, such as COntent Libraries stored directly on the Windows vCenter Server or old plugins that won’t work with vCenter 6.5.
Here is a sample run of the assistant:
D:\migration-assistant\VMware-Migration-Assistant.exe Initializing Migration Assistant... Enter Administrator@vsphere.local password: ************* Your vCenter Server service is configured to run under the 'LAB\svc-vcenter' service account. Enter 'LAB\svc-vcenter' service account password: *********** ============================================================== DO NOT CLOSE this console until the migration is complete. ============================================================== Extracting Migration Assistant scripts... Running Prechecks... Prechecks reported the following errors/warnings: Error: User running the upgrade does not have 'Replace a process level token' privilege. Resolution: Assign 'Replace a process level token' privilege to the user. Error: VMware Update Manager health status is red Cannot proceed with migration Resolution: Please check health status file at C:\Program Files (x86)\VMware\Infrastructure\Update Manager\docroot\vci\downloads\health.xml and follow make sure that VMware Update Manager health status is green before migration Migration Assistant log files have been zipped at: C:\Users\administrator.LAB\Desktop\VMware-MA-logs-20170421085022.zip
Failed to initialize Migration Assistant. Resolve the above error(s), and relaunch Migration Assistant.
- Error: My vCenter server service runs with a custom service account. This is something that can happen at customer’s installations. Usually these service accounts use the least privileges necessary to run the service successfully. As the Migration assistant uses the service account user to migrate, it will have to launch some privileged actions. – So in my case I will have to change the Windows local policy to allow the user to replace a process token. Open Local Computer Policy > Computer Settings > Windows Settings > Security Settings > Local Policies > User Rights Assignment > “Replace a process level token” and add the vCenter Service User to the list of privileged users.
- Error: Update Manager Service User? – In my lab Update Manager was using Local System User. As the script has to migrate the Update Manager service as well, the easisest way to fix this is – use the same user as for vCenter service – so I just reconfigured vCenter Update Manager Service to use the svc-vCenter account (same as above). – Restart service and retry the migration assistant.
I hope this gives you an idea what can happen. Just as an idea why not start the migration assistant before the actual migration and fix things before you start? This will give you less pressure on the actual day of migration.
What should you migrate? Does it make sense to migrate Events and Task information? If your vCenter database is really large this can take hours. Just migrating the important configuration information will speed up the process and give you a small vCenter database to begin with your new vCenter. If you want to migrate task and event data, it is maybe a wise idea to delete really old events and task data some days before you start the migration – by changing the vCenter settings for task cleanup and event cleanup (duration and activation).