vCenter Server Migration Tool: vSphere 6.0 Update 2m

Last year I blogged about the vCS to vCSA converter tool that VMware Labs released as a fling and how I had used it to pretty much convert all my lab vCenters (all bar one) to vCSAs….. since then I’ve been following the releases and a few months ago I noticed the Fling was deprecated (ie you can’t download it). I didn’t think much of it as VMworld 2016 was only round the corner, so thought it might be rolled into an impending vSphere/vCenter release….. unfortunately that never quite materialised in Las Vegas, and rumours are that vSphere 6.5 might be released in Barcelona.

So I was quietly surprised when I got an email notification from VMware Blogs to inform me that a new minor update of vSphere had been released specifically for migration puposes – vSphere 6.0 Update 2m (where the ‘m’ stands for migration).

vSphere 6.0 Update 2m is an automated end to end migration tool from a Windows vCenter Server 5.5 (any update) to a vCenter Server Appliance 6.0 Update 2 (so pretty much what the Fling used to achieve).

It’s common knowledge that trying to migrate from a Windows vCenter Server (with a SQL backend) to a vCenter Server Appliance was not an easy task – in fact in 90% of my customers I’ve just told them to start a fresh rather than go through the pain of scripting a migration. However, I’m so glad that VMware have rolled out the Converter fling into an actual production release – now we have an end-to-end migration tool which takes all the pain out of the equation!

Those of you who are interested in migrating from your Windows vCenter Server 5.5 (any update) to a vCenter Server Appliance 6.0 Update 2 should download and use this release. The vSphere 6.0 Update 2m download is an ISO consisting of the Migration Tool and vCenter Server Appliance 6.0 Update 2, roughly about 2.8GB in size.

Note: you cannot use this release to deploy a new installation of vCSA! To do that you just use the vCSA 6.0 Update 2 install.

What’s Supported:

  • Previous versions of Windows vCenter Server will need to upgraded to vCenter Server 5.5 prior to migration.
  • The best thing is that all database types currently supported with vCenter Server 5.5 will be migrated to the embedded vPostgres database in the vCSA!
  • It’s worth noting that if VMware Update Manager is installed on the same server as the Windows vCenter Server 5.5, it will need to be moved to an external server prior to starting the migration process.
  • VMware and 3rd party extension registrations are migrated, but may need to be re-registered.
  • vCenter Server 5.5 both Simple and Custom deployment types are supported.
  • Configuration, inventory, and alarm data will be migrated automatically, historical and performance data (stats, tasks, events) is optional.
  • If the source was a Simple vCenter Server 5.5 install (so SSO + vCS) then it will be migrated to a vCSA with embedded PSC.
  • If the source was a Custom vCenter Server 5.5 install (so separate SSO and vCS) then it will be migrated to a vCSA with external PSC.

Somethings that are worth mentioning prior to starting a migration are:

  • It preserves the personality of the Windows vCenter Server which includes but not limited to IP Address, FQDN, UUID, Certificates, MoRef IDs.
  • Changing of your deployment topology during the migration process is not allowed. For example, if your vSphere 5.5 Windows vCenter was deployed using the Simple deployment option, then your Windows vCenter Server 5.5 will become an embedded vCenter Server Appliance 6.0.
  • During the migration process the source Windows vCenter Server will be shutdown, plan accordingly for downtime.
  • The migration tool will also be performing an upgrade, standard compatibility and interoperability checks will still apply. Please use the interoperability matrix to make sure all VMware solutions are compatible with vSphere 6.0. Also talk to your 3rd solution vendors to make sure those solutions are also compatible with vSphere 6.0.


The only annoying thing is that because I’ve used the fling previously to convert all my Windows vCenter Servers, I now don’t have anything I can test this migration tool on!! >_<”

I’m currently in the process of digging out an old vCenter Server 5.5 ISO so that I can deploy it and upgrade it using the new release!


Anyways, those of you who haven’t yet upgraded to vCenter Server 6.0 and to an appliance, now there’s no reason why you can’t as you have a fully supported tool from VMware!

Best of all, they’re in the process of improving the migration tool so that it can be used to migrate from a Windows vCenter Server 6.0 install to a vCenter Server Appliance 6.0. One feature I hope they will also include is the ability to migrate from an existing vCSA to another vCSA.

vCenter Server 6.0 Update 2m links:


vCenter Server (Windows) to vCenter Server Appliance Converter

A couple of days ago, the clever bods at VMware Labs released a new fling that allows you to migrate from a Windows-based vCenter Server to the vCenter Server Appliance:

This is a great Fling idea as a lot of end-users are now considering the vCSA given the enhancements made to it in 5.5! (BTW, vCSA has been further enhanced in vSphere 6.0!!!)
Check out my previous blog article on the subject……

Anyways, one of the problems in the past was how would a customer go about migrating data from their old Windows-based vCenter Server onto the new Linux-based vCenter Server Appliance!
Previously I’ve had to ensure that the customer was aware that moving to the appliance means they can’t migrate over their vCenter Server data – and the majority of the time they’re happy to bite the bullet and do a fresh install!

Having used the Fling to migrate my lab vCenter Server to the appliance, I can say that it works pretty well! The Fling migrates the vCenter database, roles, permissions, privileges, certificates and inventory service… It even migrates events/tasks lists, folders, vApp settings and pretty much anything that’s stored in the VCDB! The only thing it didn’t do was migrate the SSO configurations which has to be setup manually (pretty simple to re-do).

There are some limitations though (this is not the full list):

  • The new vCSA needs to have the same hostname and IP address of the old vCenter Server.
  • Both vCenters have to be running the same version.
  • Old vCenter Server must have all components installed on the same server.
  • SQL Server database must be on a separate server to the vCenter Server and can’t be the integrated SQL Express.
  • 3rd party plugins will not be migrated and may need to be re-configured.

Diagram to visualise the migration process:

TBH, the one thing the documentation doesn’t mention is whether it migrates Distributed vSwitches, and having played around and used the Fling, I’m happy to say that it looks like it does as I could view and manage the dvSwitch on the vCSA after migration (although if I’m honest I haven’t delved into all the nitty-gritty configs you can do with a dVS).

I found the process pretty simple to follow, deploy a vCSA, ensure it is configured with the same IP and hostname as the old vCenter Server, fire up the migration appliance and follow the wizard!

The only issue I encountered was when trying to configure the Active Directory settings during the vCSA configuration wizard and I got the following error:

Failed to execute '/usr/sbin/vpxd_servicecfg 'ad' 'write' CENSORED ''':
 VC_CFG_RESULT=302 (Error: Enabling Active Directory failed.)

This was easily rectified by changing the hostname of the vCSA to the FQDN and checking the DNS entry is correct as outlined in this VMware KB:

Once this was sorted, the migration was quite pain-free……. this is one great Fling, and I hope they continue to work on it and enhance it!! Well done VMware engineers!!


VM displays to two port groups after migrating to a distributed vSwitch

Do you ever encounter the same issue over and over again and forget how you solved it the first time, or what caused it to happen in the first place?!?

It happened to me today on a customer site….. we were migrating a couple hundred VMs off a standard vSwitch onto a newly created Cisco Nexus 1000v switch and several VMs were showing to be connected to the old port group on the standard vSwitch as well as the new port group on the distributed vSwitch.
The VM Summary showed connections to 2 port groups even though there was only 1 vNIC and what made it more confusing was if you went and edited the VM hardware settings the vNIC was configured with the correct port group….. hmmm…..

It was a case of Déjà vu…. I sat there thinking “Damn, I’ve seen this before… but for the life of me I can’t remember what’s causing the problem!”

After a quick “Google”, I stumbled across the following KB and my foggy brain suddenly cleared!!

……If the virtual machine has snapshots associated with the old network, when you reconfigure the virtual machine to use a new network configuration, both old and new networks are associated with the virtual machine……”

“Doh…. Snapshots!!!”……. it’s all down to the VMs possibly having a snapshot attached to it!!


Basically someone had taken a few snapshots of the affected VMs, and because it’s a “snap shot” of the VMs state at that point in time, the snap shot had the old vSwitch port group whilst the new ‘delta’ VMs had been re-configured with the new 1000v port groups!
Kinda makes sense right? If you wanted to roll back to the old snapshot then it must have the configuration of the VM from the point in time when the snapshot was taken – ie with the old vSwitch port group!

Anyways, a quick check with the client and after a lengthy consolidation process all the VMs were happily only showing connections to the 1000v port group!


….. and so to make sure I don’t forget that I’ve encountered this issue millions of times before, I’ve decided to post up a blog entry about it….
(Which was one of the reasons I started blogging in the first place – a place where I can not only share my knowledge but also somewhere I can access solutions to past problems!)