Architecting a vSphere Compute Platform : Resource Balancing and Transparent Maintenance : 9.2 Enhanced vMotion Compatibility
   
9.2 Enhanced vMotion Compatibility
Enhanced vMotion Compatibility (EVC) addresses the challenge that each generation of processor hardware presents through improvement with new functionalities. EVC makes sure that all host servers, where slight variations in processor generation exist, offer the same CPU instruction sets to virtual machines, safeguarding vSphere vMotion compatibility among the mixed processors.
EVC employs a baseline across the CPU instruction sets and this baseline enables a set of functionalities supported by all processors found in the cluster, defining a common level for all processors.
Figure 33. Enhanced vMotion Compatibility
 
The ESXi hypervisor works directly with Intel VT Flex Migration and AMD-V Extended Migration processors and technologies to show only the common instruction sets and hide those that would create vSphere vMotion compatibility problems. For further information on which baseline and instruction sets are masked, see the VMware Knowledge base article Enhanced vMotion Compatibility (EVC) processor support (1003212) at http://kb.vmware.com/kb/1003212.
Note, however, that EVC only supports the use of a single vendor’s processors within the cluster (Intel or AMD), and the NX/XD functionality must be activated in the server hardware’s BIOS.
The CPU is the most restrictive component when it comes to vSphere vMotion. Enabling EVC permits the masking of some differences, offering more compatibility between servers with different generations of processors. When employed, EVC does not hinder performance and does not affect the number of processor cores or the size of the CPU cache. The only possibility of degraded performance is where certain processor instructions, such as SSE 4.2 for instance, have been masked and therefore not used.
The design decision on whether or not to enable EVC will depend on a number of questions that you will need to address:
Do you intend to mix hardware in the cluster? 
Do you think there is a high possibility of adding newer hardware to your cluster?
If cross vCenter vSphere vMotion or long-distance vSphere vMotion forms part of a design or service offering, do you know what hardware types and processer generations exist at the other target data centers?
If the answer to any of these questions is yes, the general advice is to enable EVC on all clusters. Doing so makes adding hosts easier and saves having to split the cluster in the future if you have the foresight to enable it from the outset.
In a world where the cluster is no longer the boundary for live migration, and vSphere vMotion can occur across not only different vCenter Server instances, but also geographically dispersed physical data centers, EVC takes on a new meaning.
In the past, enabling EVC has often been overlooked by service providers and VMware enterprise customers because all nodes within the cluster housed an identical processor type, and was as such deemed unnecessary. However, with the introduction of cross vCenter vSphere vMotion and long-distance vSphere vMotion, where the local data center cluster is no longer the limiting factor for performing a vMotion operation, enabling EVC at the outset of a design is a logical step.