Lessons learned while using the Cross-VC Migration Fling

While I was working with a customer to migrate some workloads from an old vCenter Server to a new one, I ran across some minor bumps before I could successfully do a migration.

So why a migration in the first place? Well, the world basically becomes a bit brighter if you know that the source vCenter was a windows based physical vCenter server which has been upgraded time after time (onwards from version 4.x apparently). I decided to first migrate it to an appliance (6.0u3 since this is the minimal requirement for running Cross vCenter vMotion) and then migrate away from it all together to ensure I have a “fresh” vCenter appliance for our new environment.

Some stuff you will have to consider before migrating:

• VMware EVC mode
• DVS versions (it is not possible to migrate from a 6.0 DVS to a 6.6 DVS for example – so setup your DVS with the same version as your source and upgrade it afterwards)
• Perform proper network testing (you can easily create portgroups and assign them the same VLAN tags as your source portgroups, but if the physical network won’t allow them, you will lose connectivity to your VM’s directly after vMotioning them!)

With all pre-reqs in place we should be good to go and have the fling do our job for us. Well no, not quite yet. Because or source and destination environment resided in different domains we encountered 2 other issues:

1. Certificates – The source site vCenter had a self-signed certificate in place and the target vCenter had a certificate signed by the windows CA in the “new” domain.
   1. Since the old vCenter server is not joined to the “new” domain, it does not trust its provisioned certificates. This can be easily solved by exporting your root/subordinate chain and import it into the trusted key store on the old vCenter. One can accomplish this by logging into the PSC (in my case it was embedded PSC so the URL would be: https://<vCenter-FQDN/psc). Next, go to Certificate Management and authenticate using admin credentials

Now, click the Trusted Root Certificates and click Add certificate. Select your exported cert chain and import it to your vCenter/PSC.

• DNS – DNS was setup to resolve from the new domain to the old domain properly but not the other way around
  • To mitigate this, I have used the nasty solution of modifying the hosts files on the source vCenter and “migration” ESXi hosts (include target vCenter, hosts and the server running the xvm utility). Obviously, the correct way of resolving this would be to setup DNS correctly for bi-directional resolving.

After fixing those 2 issues, the migration tool worked like a charm. For massive workload migration (100’s of VM’s I would still consider a scripted approach) but in my opinion if you don’t have to many workloads to migrate, this is the tool to use.  

Recently there has been a new version release. During a (great) VMworld session delivered together with Emad Younis, William Lam released the latest version of the fling. Major feature is that it can now integrate with the HTML-5 client so you can schedule your migrations from the client you already know!! The specific VMworld session can be viewed here