Information Technology Reference
In-Depth Information
VMs by the ESXi host, two are assigned to VM1, and one is assigned to VM2. The diagram
earlier in Figure 11.6 helps graphically reinforce how shares are allocated based on percent-
age of the total number of shares assigned to all VMs.
Scenario 6
The ESXi host has three equally busy VMs running (each requesting maximum
CPU capabilities with CPU afi nity set to the same core). The shares are set as follows: VM1 is
set to 2,000 CPU shares, and VM2 and VM3 are set to the default 1,000 CPU shares. Will the
Shares values have any effect in this scenario? Yes. In this case, VM1 has double the number
of shares that VM2 and VM3 have assigned. This means that for every two clock cycles that
VM1 is assigned by the host, VM2 and VM3 are each assigned a single clock cycle. Stated
another way, out of every four clock cycles assigned to VMs by the ESXi host, two cycles are
assigned to VM1, one is assigned to VM2, and one is assigned to VM3. You can see that this
has effectively watered down VM1's CPU capabilities.
Scenario 7
The ESXi host has three VMs running. VM1 is idle while VM2 and VM3 are
equally busy (each requesting maximum CPU capabilities, and all three VMs are set with
the same CPU afi nity). The shares are set as follows: VM1 is set to 2,000 CPU shares, and
VM2 and VM3 are set to the default 1,000 CPU shares. Will the Shares values have any effect
in this scenario? Yes. But in this case VM1 is idle, which means it isn't requesting any CPU
cycles. This means that VM1's Shares value is not considered when apportioning the host
CPU to the active VMs. In this case, VM2 and VM3 would equally share the host CPU cycles
because their shares are set to an equal value.
Avoid CPU Affinity Settings
You should avoid the CPU a nity setting at all costs. Even if a VM is confi gured to use a single
CPU (for example, CPU1), it does not guarantee that it will be the only VM accessing that CPU,
unless every other VM is confi gured not to use that CPU. At this point, vMotion capability will be
unavailable for every VM. In short, don't do it. It's not worth losing vMotion. Use shares, limits,
and reservations as an alternative.
Given these scenarios, if you were to extrapolate to an eight-core host with 30 or so VMs, it
would be difi cult to set Shares values on a VM-by-VM basis and to predict how the system will
respond. The question then becomes, “Are shares a useful tool?” The answer is yes, but in large
enterprise environments, you need to examine resource pools and the ability to set share param-
eters along with reservations and limits on collections of VMs. We'll introduce resource pools in
the section “Using Resource Pools.” First, though, we'll summarize the behavior of reservations,
limits, and shares when used to control CPU allocation and usage.
Summarizing How Reservations, Limits, and Shares Work with CPUs
The following list includes some key behaviors and facts surrounding the use of reservations,
limits, and shares, when applied to controlling or modifying CPU usage:
Reservations set on CPU cycles provide guaranteed processing power for VMs. Unlike
memory, reserved CPU cycles can and will be used by ESXi to service other requests when
needed. As with memory, the ESXi host must have enough real, physical CPU capacity to
◆
