You can survive the migration from Windows vCenter server

The promised land of VCSA – time to start packing

By Stuart Burns

Posted in Virtualization, 5th March 2018 09:34 GMT

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. ®

Sign up to our NewsletterGet IT in your inbox daily


More from The Register

VMware's GM for networking and security jumps to Google

Veteran Jeff Jennings to get the band back together with VMware founder Diane Greene

VMware vids revealing new vSphere vanish

Blink and you’ll have what missed what looks like a premature promo release

VMware ponders baking backup into VSAN

And disaster recovery too, by painting a target on AWS

VMware to finally deliver full-function HTML5 vSphere client

It’ll only have been two-and-a-half years from launch to landing

Beware VMware! Nutanix sprays all over Virtzilla's networking territory

Teases FLOW product as alternative to NSX

Dell sell-off saga gets weird: Subsidiary VMware may buy parent in 'reverse merger'

Buy-out would let Big Mike swerve IPO headaches

Roses are red, violets are blue, VMware's made a new vSphere for you

Version 6.7 should land in Q2, may end support for older CPUs

Forking hell! VMware now has TWO current versions of vSphere

One for vSphere veterans, one for hybrid hipsters, plus a security surprise

VMware sticks finger in Meltdown/Spectre dike for virtual appliances

Proper patches under way, but for now - to your command lines, vAdmins!

Slick HCI trick: VMware smooths off vSAN's rough edges

Wants to hang on to sales dominance