Data Centre


You can survive the migration from Windows vCenter server

The promised land of VCSA – time to start packing

By Stuart Burns


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

Dell's hokey cokey IPO takes new turn – VMware in, VMware out....

Investor roadshow delayed as Mick D considers alternative plan

VMware, AWS preview database-on-vSphere

VMworld US Database ops need less 'muck' says AWS boss Andy Jassy

Fight, fight, fight. Gloves are off again between Nutanix and VMware

In the red corner we have Tweedledum and in the blue, Tweedledee

Slow your roll: VMware urges admins to apply workarounds to DoS-inducing 3D render vuln

Take your foot off the accelerator, admins told

Tax me if you can: VMware UK tosses shrunken offering to HMRC

Just 11.52% on pretax profit. Virtualization juggernaut doing well in the distie stakes

VMware and Lenovo are about to hit go-go on Project Dimension beta

Software-defined, hybrid cloud components, sold as-a-service that's delivered on-prem? WTF?

Who wants to read 34 pages about getting VMware Private Cloud to run on NetApp HCI?

Deployment in 'less than 30 min' – but not including reading the manual

VMware's latest financial figures look virtually healthy if you page out Pivotal cash-splash loss

Plus: Pat Gelsinger reckons tech will do well in 2020, even if the US economy tanks

Dell Tech: We'll let shareholders vote on VMware deal in Q4

Icahn hardly believe it

VMware bods – you back at work yet? Guess who's just poked their head into the software-defined data centre...

Data protector Acronis luring customers with virty storage Swiss roll