Moving Host and vCenter to an EVC Cluster

[rpmora]

For a recent client, we needed to migrate VMs from one host to another. The goal was to use vSphere’s vMotion capabilities to move VMs from Host 1 to Host 2. Upon moving all hosts to the same vCenter Server, there was an incompatibility issue with the two hosts. Host 2 was using a Haswell generation Intel processor, the other, Host 1, an older Sandy Bridge. When vMotion is attempted, you get this error:

"

The virtual machine requires hardware features that are unsupported or disabled on the target host

General incompatibilities

If possible, use a cluster with Enhanced vMotion Compatibility (EVC) enabed, see KB article 1003212.

"

In order to perform the migration, vCenter needed an EVC cluster to be formed. This seems easy enough… simply forming a new cluster with EVC enabled for our lower Sandy Bridge processor and dropping in our hosts. It, however, was not so simple, because Host 2 was hosting the vCenter VM.

To sum it up, we wanted to create an EVC cluster and place Host 2 (that is hosting vCenter Appliance) into the cluster, in order to then migrate VMs from Host 1 (possessing an older Sandy Bridge processor) onto Host 2 using vMotion.

When trying to move Host 2 directly into the cluster, with the vCenter VM powered on, you will get an error because in order to move a host into an EVC cluster all of that hosts virtual machines must be powered off. This is where the issue arrives.

If you have hosts you can vMotion your vCenter VM to, then this is simple. Simply move it off of the host you wish to move, move the host to the EVC enabled cluster, then migrate vCenter back. But in my case, I didn’t have that sort of luxury. In order to move my host I needed to power off vCenter first, then migrate it. But, in order to migrate it, I needed to log in to vCenter, which I can’t do when it is powered off. The proverbial chicken and egg argument.

There are loads and loads of articles out there (notably KB article 1003212) that give you a complicated work around. But I have figured out something much more simple.

To recap, I want to do a hot migration (using vMotion) of VMs from Host 1 to Host 2. In order to do so, I need to my Host 2 to be in an EVC cluster to ensure CPU compatibility. To move Host 2 into an EVC cluster, I need this work around because Host 2 is hosting my vCenter:

0) Create a new cluster with EVC enabled for the limiting processor (in my case Sandy Bridge)

1) Clone your vCenter to another host (in my case, Host 1)

2) Name it vcentername-clone (vcentername is whatever your vcenter is named)

3) Power off your current vCenter

4) Login to Host 1 (where you moved vCenter to) through the vSphere Client

5) Power on the clone

  * Note: In my case, my vCenter has a static IP. If you are using DHCP you may run into issues at this stage.

6) Once its done powering up, you can log into your vCenter again through the vSphere Client

7) Move Host 2 to the EVC cluster

😎 Delete the original vCenter VM

9) Clone the vcentername-clone VM to Host 2 (the one that is in the EVC cluster) and name it vcentername (your original vCenter name)

10) Power off the vCenter clone

11) Power on the most recent clone in the EVC cluster by logging into Host 2 through the vSphere Client

12) Delete the vcentername-clone on Host 1

You now have Host 2 in an EVC cluster, hosting vCenter. This now enabled me to vMotion VMs from Host 1 (possessing a limiting processor) to Host 2.

[npadmani]

why don't you consider doing following?

1) user vSphere Client to login in your host 2 (which is hosting vCenter appliance)

2) shutdown appliance

3) remove it from invenotry

4) login in Host 1 using vSphere client

5) register vCenter Appliance VM there (Provided that Host 1 and 2 both are seeing vCenter Appliance datastore)

6) power on vCenter Appliance, it will come up with Host 1 CPU compatibility mode

7) login in web client and carry on your rest of the activity.

[rpmora]

That also seems like a viable solution to get vCenter onto Host 1. My end goal was to keep vCenter on Host 2, and also to get Host 2 into an EVC cluster in order to perform vMotion, however. But if you can bring vCenter up on Host 1 in CPU compatibility mode, that also maybe very useful for someone.

Thanks for your reply and thoughts.

[rpmora]

We also did not have shared storage between our hosts. If you did, the process of removing vCenter from the inventory and registering it on the other host is a great workaround.

[npadmani]

Shared storage is a mandatory requirement for vMotion, DRS, HA etc. and for higher availability of your vCenter server also, it's advisable that you keep it (vCenter VM) in a shared storage so in the situations like Host failure, if there's no vSphere HA, you can still register that VM on your remaining healthy host and power on.

[TempestChen]

I encountered the same issue but on a different type of setup.

1) I had 2 ESXi hosts with the same CPU type (e.g. Sandy Bridge). I definitely knew there are no differences in the CPU as it worked on vsphere 5.5 without turning on vsphere EVC

2) I installed ESXi 6.5a on both servers and uses VCSA.

3) When I try to perform vMotion, same error happens.

4) I tried all possible combinations of the EVC CPUS but in vain. Still unable to move the host and vm in that cluster.

What did I do to resolve it?

1) Shutdown VCSA

2) Edit the VCSA VM

3) Uncheck "Enable CPU Hot add"

4) Save the settings and Power On

You will be able to move it now in the cluster now.

Hope this helps someone. 😃