Migrating to VMware 6.7 vCenter - xVmotion

I've had two 6.0 Windows vCenter instances with external MSSQL databases for quite some time. I've been reluctant to move to 6.5 due to the end of life of the desktop client. The workflow of the desktop client as well as sleek interface is unmatched and, apparently, un doable in the web browser interface. Further, we have had many issues with browsers and seems to have to switch every so often because one just stops working.

As time progresses, so we must adapt to changes even though they are backwards in ease of use and likability. The interface to 6.7 brings no improvements over the desktop client and only stunked workflows and heaps of frustrations.

I opted to deploy a new 6.7 vCenter appliance with embedded PSC and planned to migrate between vCenters.

• Partly because I am moving to a different Microsoft AD. 
• Partly rather than assign AD users access to VM folders, I created security groups in AD and assigned groups to vcenter resources. users are placed in AD security groups that correspond to vcenter resources. 
• Lastly, I planned to implement Distributed Virtual Switches and Distributed Virtual Port Groups which are supposed to make it a lot easier to deploy new hosts.  

First, distributed switches and port groups is a huge pain in the ass. I am shocked how complicated it is to deploy and how neither web interface (Flex or HTML 5) visualizes the configuration well. I wonder if the UI designers went on vacation and engineers put together the interface. Unscrewing my hosts of distributed switches caused so much grief, it was easier to reinstall ESXi and start again.

Then, I was burned buy licensing. I made a big mistake. I used the trial license when configuring distributed switches. When I went to license my host just before it expired, I was shocked to be rejected as has Standard licenses and not Enterprise. So, I slowly unwound the configuration and though I am not sure what I did and can't do it again, I was able to detach the host from the distributed switch and port groups, crease new standard switches and port groups and eventually delete all traces of the distributed switches and port groups. NOTE: If you do this, you will need console access to the host to reassign the management network to the NIC. Maybe it is easier if you have two NICs in the vswitch but I have just one.

Before unwinding the distributed switch, I tested XVMotion fling to migrate VMs from Old vcenter to New vCenter. Again, I ran into issues.

• First, there was a MTU issue that took way too long to figure out but was a big problem on 6.7 but not 6.0. 
• Next was duplicate folder names in a cluster. If you have, say, four folders A,B,C and D and under B you have a folder name A, xVmotion pukes. Well, you don't see any target folders and you have no idea why.

I successfully moved one cluster and about 100 VMs. I'd like to have been able to filter source VMs by folder rather than just a search which would have made moving a whole folder a lot easier.

When I tried to migrate on my next cluster, I ran into more problems. 

• A general system error occurred: Host not found
• I think this have been because DRS on the new vCenter cluster was not enabled
• License not available to perform the operation
• After enabling DRS started getting this error. I made sure the new host had a license. Problem persisted. Turns out the source host had a Standard license who doesn't support vMotion. How stupid is that? Once I applied an Enterprise license to the source host, I was able to migrate VMs.

Recap:

• Be careful using the evaluation key. It can bite you later
• You need Enterprise licenses to migrate VMs across vCenters
• Triple check all MTU setting on hosts and switches
• Make sure you don't have duplicate folder names
• Keep an eye on both source and destination vCenter event logs to identify where an issue may be arising from. I tended to think it was destination
• Make sure you have DRS on both source and destination 
• Make sure host NICs enable vMotion