We migrated a vCenter against an ESXi host which was using a distributed switch and the corresponding portgroup as a target network.

Since we add the virtual network adapter directly on the ESXi host to the distributed switch we need to have an ephemeral portgroup (otherwise only the vCenter could add the VMs network adapter to this portgroup).

The general process of the migration look like the following.

• Deploy a new and empty vCenter Server appliance and connect it to the network
• A temporary IP-address is given to this vCenter Server appliance
• All relevant data of the source windows based vCenter Server is exported and transferrred over the network to the new vCenter Server appliance
• When the whole data-set is transferred, shutdown the original vCenter and give the new vCSA the network identity of the original vCenter

Unfortunately the last step was not working properly. After a certain amount of time (and coffee) the migration process has stuck at 50% – Shutting down source machine

Since we had other stuff to do we repeated the steps and did the migration wizard again……..

……… with the same result (after even more coffee).

Now it was time to analyze it further. I recognized that neither the temporary nor the static vCenter IP was reachable on the network.

Connecting to the ESXi host directly looking at the network configuration offered the following:

The port status of the new vCenter VM was blocked. Digging through further logs we figured out that the vCenter Server appliance tried to change the mac address.

That is a setting that is by default not allowed within the security policy of a distributed switch portgroup.

The good thing is: During the migration the original VM remains ‘untouched’, therefore a fallback is quite easy. Reboot the original windows based vCenter VM and wait until all services are up again.

Important: Change the security policy within the network settings of your distributed switch portgroup where the vCenter Server appliance will be connected to.

Maybe a feature that can be included in the migration-pre checking if you ask me. Maybe there are also other security mechanisms in your network messing up with a successful migration here!

Maybe @Adam Eckerle is reading this and can give forward this information :)

Original Post: https://vlenzker.net/2018/01/vcenter-server-appliance-migration-fails-at-50-shutting-down-source-machine/

‍