Migrating an ESXi Host and VMs from one vCenter to Another

One of my customers was transitioning into a cloud service provider, and as such their ESXi infrastructure needed to be changed around to support this decision.  A fairly standard design element of a provider datacenter is to break up the environment into 2 vCenter environments; one for management elements and one for customer VMs.  As such, we stood up the second vCenter server... but then we had the challenge of how do we move the exiting customers into the new customer resource vCenter?

It wasn't that hard, although it took a little planning to ensure that we didn't cause any service disruption to the VMs that were already running.  Adding to the complexity of the move was the fact that Distributed vSwitches were in use at this site.  Given that vCenter owns the Distributed vSwitch, we weren't sure how the system would behave if we simply took over ownership of the ESXi servers into the new vCenter, so we settled on the following procedure:

  1. Remove vShield components from the ESXi Servers 
    1. This was done because the vShield Managers have a 1:1 relationship with vCenter servers.  Since we were changing vCenter servers, we would be changing vShield Managers as well.
  2. Convert any Templates that will migrate into normal Virtual Machines
    1. This was done because Templates are vCenter objects and we didn't want them to deregister during the transition from one vCenter to the other.
  3. Move all VMs onto Standard vSwitches
    1. Since Standard vSwitches are defined entirely on the ESXi host, moving the VMs onto the standard vSwitch ensured that they would maintain network connectivity throughout the transition.
  4. Remove the ESXi Host from the Distributed vSwitches
    1. Once the VMs were all off of the vDS, we were able to cleanly remove the ESXi Host from it
  5. Register the ESXi Host on the new vCenter
    1. With everything as cleaned up as possible, we added the ESXi Host to the new vCenter (which disconnects it from the original vCenter).  We did it this way because we didn't want to evacuate the host before the transition by going into Maintenance Mode; the whole purpose of this was to bring the VMs into the new vCenter!
  6. Add the ESXi Host to the new Distributed vSwitch in the new vCenter
    1. Just the inverse of step 3, really.
  7. Convert the template VMs back into Templates
  8. Reinstall vShield Components
Most of those steps are really straight forward, but I wanted to expand a little bit on steps 3 and 6.  In this environment, the VM traffic was flowing out through the Distributed vSwitch which had 2 uplinks to the physical network.  No Channel-Groups were configured; instead, the vSwitch was set to route based on physical NIC load.  This made things much easier for us, in that it allowed us to remove 1 leg from the DVS without interrupting the VMs that were using it.

With that pNIC removed from the DVS, we created a VMware Standard Switch using that uplink.  We then copied the DVS port groups onto that VSS.  With the VSS fully configured, we moved each link from each VM onto the VSS (so if the VM was on VLAN 100 on the DVS, we moved it onto the VLAN 100 port group on the VSS).  Once all VMs were on the VSS, we were able to move forward.

Step 6 was accomplished trivially, just by "migrating virtual machine networking" when we added the host to the new DVS.

Once all was said and done, we were successful!  We basically used the ESXi hosts as boats to carry the VMs from one vCenter to the other.  The migration was done without causing a big VM outage and everyone was happy at the end of the day.

Comments

Popular posts from this blog

Orphaned VMDK Files

Migrating from one vCenter to Another, Improved

Copying VM Folders and Permissions from One vCenter to Another