Effects of EVC mode changes

[itguy81]

Hi. We had a cluster that was originally westmere cpu hosts and over time one after another they were replaced. the evc mode is westmere and we have 1 westmere host left. the rest are broadwell or skylake. Couple of questions:

1. How do you determine what 'benefits' you're going to get by upgrading to a higher evc mode? In the gui in 6.7 at least it names the benefits but I have no idea if we'll actually use and benefit from them (see list below).

2. it is mentioned that we may need to reboot VMs for it to take effect. If we have the buffer on the hosts, is an alternative to evacuate a host, put it in a new cluster with that new evc mode on it, migrate vms to that host and evacuate another host, and migrate, etc? is there any downside/risk to this? Does this prevent having to reboot our hundreds of VMs?

3. what if we have a spare host that's older and we really want it to be in the cluster as a last resort spare? It may not be in the compatibility list completely but we've used it on the version it's on without issue so we're OK having it as an emergency host. Is the only way to add it to turn off EVC so it can join? Once it's off we won't be able to turn it back on at the previous level I assume.

Thanks a bunch!

[larstr]

Hoodsie2018,

EVC mode affects the output of the cpuid command of your VMs return a different cpu than the physical one and hides newer cpu features. Some applications may use this command to determine which cpu features can be used. Each new cpu generation comes with extra commands that some programs may utilize. Most programs do however not care about this, but some cpu hungry programs that  may benefit greatly of such instructions may use them (typically: compilers, video compression, CAD, encryption, ++). Going to a higher EVC mode will unmask some of the newer cpu features and some of your programs may run smoother than before.

1. It's not easy to know what benefits you get when changing the EVC level.

2. In 6.7 you can set EVC mode per VM, but I think the VM needs to be powered off in order to configure it.

3. The third host can be a member of the cluster, but if you give your VMs a higher EVC mode than it supports you will not be able to vmotion VMs to that host. HA to that host may also not be working.

Virtual EVC per VM

Lars

[a_p_]

1. see previous reply
2. VMs need to be power-cycled (power off/power on) in order to get the new CPU features presented. A reboot, or vMotion is not sufficient.
3. a host that doesn't support the CPU features for an EVC enable cluster cannot be added to the cluster. Turing off EVC may allow you to add the host to the cluster, but you won't be able to vMotion VMs (that have been powered on on hosts with newer CPU features) to that host.

Also keep in mind that the VM's virtual hardware version (compatibility mode) is something to consider. Assuming that the new hosts run a newer ESXi version, and the VM's are using using a current virtual hardware version, you will not be able to power on these VMs on an older ESXi version.

André

[itguy81]

Thanks for clarifying that we'd need to actually power it off, and not just reboot. missed that. Can that be scheduled using VUM (power off and/or upgrade hardware version)? most of our VMs are never powered off unless we had some reason to upgrade their hardware version which is rare.

[a_p_]

I didn't try this myself yet, but I think it should work with a scheduled upgrade of the virtual hardware version.

André