An interesting subject was raised today. There are several clients in a datacentre. Each has their own vCenter implementation. There is also a private enterprise vCenter offering that the clients can move in and out of (multi-tenant private cloud). How do you move VMs in and out of this private enterprise offering and keep them up and running?

One way would  be to have a single vCenter instance to manage all the environments. This is fraught with issues around access control, AD integration, vCenter maximums, etc.

The other way is to keep all the vCenter instances separate and use a ‘swing host’. This is the method I will describe here.

There are two ways to provide a swing host. Either having a spare ESXi blade handy that you can use, or run a virtual ESXi instance.

Other considerations are the processor family of the hosts you are migrating between (cannot move between AMD & Intel hot, for example, and you cannot set EVC mode when VMs are using the higher-spec processor functionality), consistent networking between the different implementations (port groups need to have the same naming, VLAN needs to be visible to all 3 hosts involved in the migration), making the swing host a single point of failure during the swing stage, a swing LUN needing to be visible to all 3 hosts used during this migration. There may be other items to address outside this list.

However, if all these can be addressed, you have the ability to move VMs between environments without downtime, and here’s how you can do it:

1. Add your swing host to the source vCenter server as a standalone host in the vCenter datacentre that hosts your VM to be moved.
2. Ensure you have a portgroup on the swing host vSwitch that has the same name and VLAN configured as that used by the VM to be moved, and that the NIC(s) bound to this vSwitch can access the VLAN.
3. vMotion your VM onto the swing host, moving it to the swing host LUN (this can be SAN, NFS or iSCSI, it really doesn’t matter, but it must be visible to all 3 hosts – source, swing and destination)
4. Add the swing host to the destination vCenter server. Doing this will effectively rip it out of the source vCenter server.
5. If required, rename the network portgroup to match that on the destination vCenter environment.
6. vMotion your VM onto the destination host and datastore.
7. Remove the swing host from both vCenter instances

These steps will do the job, albeit a little clunky. The next stage of this is to automate the process, which I will be doing using Tidal Enterprise Orchestrator.