0

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.

4
  • Are there only two host servers here?
    – ewwhite
    Nov 19, 2015 at 11:44
  • Why not just setup a second DC on the other host?
    – GregL
    Nov 19, 2015 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, 2015 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, 2015 at 20:04

5 Answers 5

2

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.

1

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.

5
  • The OP likely doesn't have licensing that would enable DRS.
    – ewwhite
    Nov 19, 2015 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, 2015 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, 2015 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, 2015 at 13:49
  • Then buy another Haswell-equipped host. Avoid EVC!
    – ewwhite
    Nov 27, 2015 at 4:02
0

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"

1
  • Interesting. Did not find this in the documentation but it seems to work.
    – oxident
    Dec 31, 2017 at 9:02
-1

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!

2
  • 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, 2015 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, 2015 at 8:51
-1

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.

2
  • 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, 2018 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, 2018 at 16:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .