Is it possible to enforce EVC/vMotion compatibility on a single VM in a (non-EVC) vSphere 6 cluster?

I have an old Nehalem based host which I would like to use as a backup host in case I need to restart my main Haswell based machine without shutting down my AD.

But on the other hand, I wouldn't want to move every VM in an EVC cluster because of the lack of CPU features.

UPDATE: - At the moment, the cluster only consists of those two hosts. - Adding a 2nd DC could work but this would result in more "maintenance work" and I would also need to spend another Windows license for this.

So my main goal would be a way to ensure vMotion capability between Haswell and Nehalem for specific VMs.

UPDATE (final): As ewwhite pointed out, there is no solution except enabling EVC for the cluster. Therefore I have removed the initial "accepted answer", although it works for me, and accepted his answer.

  • Are there only two host servers here? – ewwhite Nov 19 '15 at 11:44
  • Why not just setup a second DC on the other host? – GregL Nov 19 '15 at 13:22
  • I'm not clear on what you want to do. The way I understand your question is that you have two hosts in your cluster. If the newer (Haswell) host fails you want some of the vm's to be restarted on the older (Nehalem) but not all of them. Is that correct? – David King Nov 19 '15 at 16:14
  • Sorry if it's unclear. No, instant failover restart isn't a topic for me (at the moment). It's all about being able to live migrate specific VMs (Mail- and/or AD-Server) to the older platform in order to perform emergency maintenance tasks on the main host without interrupting mission critical services. – oxident Nov 19 '15 at 20:04

UPDATE: - At the moment, the cluster only consists of those two hosts. - Adding a 2nd DC could work but this would result in more "maintenance work" and I would also need to spend another Windows license for this.

Then enable EVC on your cluster. There's no better way to accomplish what you're asking.


Given the setup you described you want EVC enabled on the cluster regardless of what else you do with it. Not having EVC will surely cause you problems later on.

To accomplish what (I think) you're wanting you should use DRS and HA. Within the HA configuration you can specify what should be done with VM's when there is a host failure or isolation. In the DRS configuration you can specify the desired automation level for moving VM's around within the cluster and additionally specify VM overrides for that automation level.

  • The OP likely doesn't have licensing that would enable DRS. – ewwhite Nov 19 '15 at 17:00
  • HA / DRS isn't included in my license, you're right ... but I don't think that I need this for what I'm trying to accomplish. HA or automatic failover isn't a requirement for me. It's just about being able to live migrate specific VMs manually (see above comment). Of course, enabling EVC would work but this would globally disable many CPU features I rely on (for example SSE4.2) because we use some VMs for raster image processing reasons. – oxident Nov 19 '15 at 20:06
  • Then why don't you just set the EVC mode to ensure you'll be able to migrate when you need to? – David King Nov 19 '15 at 20:07
  • 1
    Enabling EVC would disable SSE4.2 for every VM and I would really use that feature for "non mission critical" VMs. I didn't find a way to enable EVC exclusively for infrastructure VMs like DCs or mail servers. – oxident Nov 26 '15 at 13:49
  • Then buy another Haswell-equipped host. Avoid EVC! – ewwhite Nov 27 '15 at 4:02

not entirely true, the VDP and vCenter appliance are coming with "EVC Mode Westmere" no matter what your cluster has

in the .vmx-file: evcCompatibilityMode = "TRUE"

set this value to "FALSE" and you have them after the next power-cycle at the same mode as the cluster itself and in your case you can restrict guests this way to "Westmere"

  • Interesting. Did not find this in the documentation but it seems to work. – oxident Dec 31 '17 at 9:02

After talking to VMware's technical support, there seems to be no way to enforce EVC for specific VMs. Therefore, I'll use the following workaround:

  1. shutdown the mission critical VMs on the main host
  2. cold migrate them to the old Nehalem host
  3. power on those VMs (now they'll use only Nehalem compatible CPU instructions)
  4. hot migrate (aka vMotion) those VMs to the new Haswell host

Now I'm able to vMotion these VMs between Haswell and Nehalem without any problems (as long as I won't shut them down and power up again on the Haswell host).

Thanks for any hints!

  • Or... You enable EVC on the cluster and set it to the Nehalem level. Nothing you're doing requires the specific CPU extensions available on the newer processors. If you do have something that does, you should be using host servers of the same generation. Downvoting this because it ignores best practices and good advice and because the "workaround" is unnecessary. – ewwhite Nov 27 '15 at 4:01
  • Ok, thanks for your answer. You're right, we should consider buying a dedicated new host for this. I was just thinking about "recycling" existing hardware. – oxident Nov 27 '15 at 8:51

I'm adding this for reference and just to prove that this request wasn't so "uncommon": With the release of vSphere 6.7, VMware introduced a feature called "per VM EVC" which does exactly what I asked.

  • At the time of your question (posted over two years ago), the solution provided was context appropriate given the capabilities of the systems at the time. – ewwhite Apr 22 '18 at 15:45
  • Yes, of course. I just wanted to deny that it was against "best practices" because it seems that this feature/demand was indeed requested by the community. – oxident Apr 22 '18 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.