Information Technology Reference
In-Depth Information
vMotion Is Not a High-Availability Feature
vMotion is a great feature, but it is not a high-availability feature. Yes you can improve uptime by
preventing downtime from planned outages, but vMotion will not provide any protection in the
event of an unplanned host failure. For that functionality, you'll need vSphere High Availability
(HA) and vSphere Fault Tolerance (FT), two features that are discussed in Chapter 7, “Ensuring
High Availability and Business Continuity.”
vMotion is an invaluable tool for virtual administrators. Once you've managed a datacenter
with vMotion, you'll wonder how you managed without it.
Over time, though, you could i nd yourself in a situation where you are without vMotion. As
hardware manufacturers such as Intel and AMD introduce new generations of CPUs, some of
your ESXi hosts may have a newer generation of CPUs than others. Remember that one of the
requirements for vMotion is compatible CPUs. So what happens when you need to refresh some
of your hardware and you have to start using a new generation of CPUs? vSphere addresses this
potential problem with a feature called VMware Enhanced vMotion Compatibility (EVC).
Ensuring vMotion Compatibility
In the section “Examining vMotion Requirements,” we discussed some of the prerequisites
needed to perform a vMotion operation. In particular, I mentioned that vMotion has some fairly
strict CPU requirements. Specii cally, the CPUs must be from the same vendor, must be in the
same family, and must share a common set of CPU instruction sets and features.
In a situation where two physical hosts exist in a cluster and there are CPU differences
between the two hosts, vMotion will fail. This is often referred to as a
vMotion
boundary
. Until
later versions of ESXi 3.
x
and appropriate support from Intel and AMD in their processors, there
was no i x for this issue—it was something that virtual datacenter administrators and architects
simply had to endure.
However, in later versions of VMware Virtual Infrastructure 3.
x
and continuing into VMware
vSphere 4.
x
and 5.
x
, VMware supports hardware extensions from Intel and AMD to help miti-
gate these CPU differences. In fact, vSphere provides two ways to address this issue, either in
part or in whole.
Using Per-Virtual-Machine CPU Masking
vCenter Server offers the ability to create custom CPU masks on a per-VM basis. Although this
can offer a tremendous amount of l exibility in enabling vMotion compatibility, it's also impor-
tant to note that, with one exception, this is
completely
unsupported
by
VMware
.
What is the one exception? On a per-VM basis, you'll i nd a setting that tells the VM to show
or mask the No Execute/Execute Disable (NX/XD) bit in the host CPU, and this specii c instance
of CPU masking is fully supported by VMware. Masking the NX/XD bit from the VM tells the
VM that there's no NX/XD bit present. This is useful if you have two otherwise compatible
hosts with an NX/XD bit mismatch. If the VM doesn't know there's an NX or XD bit on one of
the hosts, it won't care if the target host has or doesn't have that bit if you migrate that VM using
vMotion. The greatest vMotion compatibility is achieved by masking the NX/XD bit. If the NX/
XD bit is exposed to the VM, as shown in Figure 12.9, the BIOS setting for NX/XD must match
on both the source and destination ESXi hosts.
