vMotion requirements impact workload mobility between PowerStore X and VxRail with vSAN in the ways outlined here.
Processors must come from the same vendor class
vMotion requires that the processors of the source and target host be of the same vendor. Source and target hosts must either both AMD or both Intel.
As PowerStore X is equipped with Intel processors, this means that it is not possible to vMotion to or from a VxRail cluster consisting of nodes with AMD processors like the E665, P675, or future AMD powered VxRail nodes. In this situation, only a cold migration, with the VM powered off, not suspended, can be performed.
If the desire for workload mobility requires that the VM be moved without disruption or interruption, and the PowerStore X uses Intel processors, so too must the VxRail cluster.
Processors must have the same CPU feature set or EVC baseline
Modern processors have evolved to include complex instruction sets that improve speed and performance of the applications using them. Each new processor generation brings with it additional instructions sets. Near the end of the vMotion process a VM is briefly paused from running on the processor in the source host, and then quickly resumed on the processor in the destination host. Therefore, the source and destination host processors must be able to provide the same instruction set. This requires that the destination host processor must be of the same generation or a later generation as the source host processor. But as vMotion can and will occur in either direction, the source and destination host processors must be or appear to be of the same generation.
As previously mentioned, vMotion is a mature VMware feature. VMware has taken into consideration that customers purchase hardware over time, and will end up with a mix of processor generations or server hardware.
vSphere has a feature called Enhanced vMotion Capability (EVC) mode. This setting is used to mask from the VM processor instruction sets, giving the OS and applications the appearance that VM is running on an older processor. This enables the VM to be vMotioned between processors of different generation in advance. EVC can be set at the cluster level or on individual VMs.
EVC settings for VxRail with HCI and PowerStore X
The vSphere cluster created by PowerStore X does not have EVC set, and setting EVC requires entering maintenance mode on the PowerStore X vSphere cluster. However, VxRail does enable EVC at the cluster level, setting it to Haswell, providing customer with the option of adding any VxRail nodes with earlier generations of Intel processors to a VxRail cluster, or to raise the EVC setting to a level meeting their requirements.
The cluster-wide EVC setting can be enabled or lowered, but only if all VMs are powered off, meaning it cannot be enabled on the PowerStore X vSphere cluster. However, the EVC setting can be raised at any time, so to enable workload mobility between the PowerStore X vSphere cluster and the VxRail with HCI vSphere cluster, the EVC setting on the VxRail with HCI cluster needs to be raised from the VxRail default of Haswell to reflect the processors in the PowerStore X.
This setting will enable all VMs to be vMotioned to and from both vSphere clusters. Alternatively, if VxRail cluster EVC baseline has already been raised to a level above the processors in the PowerStore X, to enable VMs on the VxRail with HCI vSphere cluster to take advantage of features in the later processors, then per VM, EVC must be used.
Per VM, EVC is similar to the cluster-wide EVC setting, but applies only to that individual VM. It would need to be enabled and set to reflect the processors in the PowerStore X, on any VM that workload mobility between the clusters is desired. To enable or change per VM EVC, the VM must be powered off.
vMotion and its derivates are a mature vSphere feature set, and their requirements have been documented in VMware material, including the following VMware sources:
Note: This VMware material is recommended reading as this section does not cover all vMotion requirements.
