You can survive the migration from Windows vCenter server

The promised land of VCSA – time to start packing

Up until relatively recently, VMware’s vCenter was a Windows-only affair. With version 5 came the VCSA (vCenter Server Appliance) based on a hardened Linux installation. It essentially left behind the legacy issues around management and patching (and all manner of other issues) that impact Windows. The next major release of vSphere is to be the last that supports a vCenter sat on Windows.

For the first couple of releases, the VCSA was missing a few key functions (such as vSphere Update Manager capabilities) but now the features of the VCSA exceeds those of the Windows server. For example, integrated backup is only available on the VCSA. VMware itself has stated that all the engineering resource dollars moving forward are being spent on the appliance, not the Windows installation. There is just no reason not to go with appliance. No malware, no Windows patches and no weird Windows server compatibility bugs.

The migration itself is actually well-honed and relatively straightforward as long as the administrator has done their due diligence.

For those who have been dragging your feet, don't. Don’t be that techno-Luddite. If any better reason was needed, vSphere 5.x is nearing end of supported life (19 September 2018). Now is the time to grasp that nettle. But before getting into the specifics of the "how to", it is important to realise how it all works. The migration functionality is built into every major release from 6.0 U2M onwards.

Before running through the migration, it is key to understand that it is both a migration and an upgrade. Here is all it essentially consists of:

1. Run the Migration assistant script on the Windows server to check for known issues.
2. Run the appliance installer and select the migration option from the main menu.
3. In the background the installer deploys an empty VCSA appliance.
4. Select which options you want to pull over (ie, the personality and configuration of the old VC).
5. At this point, in the background, the new VCSA (with the new IP configuration) will boot up and the first boot scripts will start to pull across the data.
6. Power down Windows server (done automatically).
7. Reboot the VCSA to complete the migration.

The great thing about this is that no changes are ever made to the Windows server so if something goes really wrong during the migration, the Windows server can be rebooted and will still perform as the vCenter. The only action that needs to be taken is to re-connect to the AD infrastructure. The removal was done because the new VCSA has to be connected.

Obviously, once the migration is completed and the VCSA is in use, it’s a whole different matter. Just don't.

Wait! Before you saddle the horses...

There are, however, a few things that the admin needs to do before the migration in terms of due diligence. Firstly, any plugins that are used need to be checked and upgraded (if needed). Check vendor support for VCSA. Secondly, the pre-upgrade script does a fair bit of checking of its own. It looks for known issues or problems on start-up and will let you know if it finds anything. The script looks for certain configurations and will give the administrator advice on how to resolve a lot of these. For example, if the company is using an SRM system (Site Recovery Manager) and it is hosted on the VC, it will need to be migrated to a different server. Doing that preserves the SRM capabilities. (Don’t forget, you are going to be decommissioning the box that was the Windows vCenter.)

The administrator will also need to manually check for other VMware solutions to check compatibility, ie, vRealize infrastructure or other CMP platforms. For most external platforms that talk to the vCenter there will be no difference, but it is critical to check.

If the migration goes wrong, it can always be stopped and the Windows server restarted and service restored. Whilst this may seem quite straightforward there are a number of things to consider.

Pro tips

Before the upgrade process is run, it is really important to ensure that the administrator has a local account on the Windows vCenter. The reason for this is that whilst running through the migration tool, part of that process is to remove the Windows vCenter from the domain (so that the appliance may take its place). If you need to get back into it, only that local account will work.

Secondly, and just to an abundance of safety, disconnect the NICs on the old Windows VC. That way no one can accidentally power it up and cause duplicate IP issues whilst the server is in cool-down.

If you do need to roll back, don’t forget you will need to perform all the AD connectivity steps to re-establish domain trusts. The actual roles are still there because they are part of the VC and not AD. AD is, however, frequently required to allow people access to the environment. It depends on your setup but I would hope the administrator would know their own setup.

Secondly, there is the option to migrate a variety of items and is separated out into three separate scenarios. If you have a large estate I recommend that all the data is exported – because losing performance metrics or events, tasks etc can make troubleshooting that bit more difficult. Not pulling across the data is obviously much quicker. It becomes a personal choice. Keep it and wait, or don’t and get the upgrade done more quickly.

Frequently, by volume of data in the vCenter DB, the vast majority is SEAT (Stats, Events, Alarms and Tasks). It is important to note that with this migration assistant, it is not possible to change any of the configuration. It also doesn’t carry across the VUM downloads of the servers.

In any environment where there are multiple VCs linked together, it is advisable to upgrade as quickly as possible once started, but the whole point is that the vCenter and vCenter appliance should work in exactly the same way. More information on this can be found here, in VMWare’s words.

One last tip. Make sure that if stand-alone PSCs are used, that they are upgraded to the correct release before performing the migration. This isn’t an issue for those administrators who opted for the all-in-one solution.

The biggest suggestion from VMware is to make sure you read and fully understand the documentation, especially with regard to the compatibility matrix. ®