Information Technology Reference
In-Depth Information
per second, regardless of what the host has available. Keep in mind that a VM with one single-
core virtual CPU hosted on a 3 GHz, quad-processor ESXi host will see only a single 3 GHz core
as its maximum, but as administrator you could alter the limit to prevent the VM from using the
maximum core speed. For instance, you could set a 500 MHz limit on that DHCP server so that
when it re-indexes the DHCP database, it won't try to take all of the 3 GHz on the processor that
it can see. The CPU limit lets you throttle the VM with less processing power than is available
on a core on the physical host. Not every VM needs to have access to the entire processing capa-
bility of the physical processor core.
The key drawback to using a CPU Limit setting is its performance impact on the guest OS
and the applications running in that VM. The Limit setting is a true limit; the VM won't be
scheduled to run on a physical CPU core more than the limit specii es, even if there are plenty of
CPU cycles available. It's important, therefore, to understand the CPU processing needs of your
VMs before arbitrarily setting CPU limits or you could i nd yourself signii cantly impacting
performance.
Increasing Contention in the Face of Growth
One of the most common problems administrators can encounter occurs when several VMs without
limits are deployed on a new virtualized environment. h e users get accustomed to stellar perfor-
mance levels early in the environment life cycle, but as more VMs are deployed and start to compete
for CPU cycles, the relative performance of the fi rst VMs deployed will degrade.
One approach to this issue is to set a reservation of approximately 10 to 20 percent of a single
core's clock rate and add approximately 20 percent to that value for a limit on the VM. For example,
with 3 GHz CPUs in the host, each VM would start with a 300 MHz reservation and a 350 MHz
limit. h is would ensure that the VM performs similarly on both a lightly loaded ESXi host and a
more heavily loaded ESXi host. Consider setting these values on the VM that you use to create a
template because these values will pass to any new VMs that were deployed from that template.
Note that this is only a starting point. It is possible to limit a VM that really does need more CPU
capabilities, and you should always actively monitor the VMs to determine whether they are using
all of the CPU you are providing them.
If the numbers seem low, feel free to increase them as needed. h e important concept is setting
appropriate expectations for VM performance based on your knowledge of the workloads running
in those VMs and the anticipated levels of performance.
Using CPU Shares
VMware vSphere's shares model, which lets you prioritize access to resources when resource
contention occurs, behaves similarly for both memory and CPU. The shares for CPU will deter-
mine how much CPU is provided to a VM in the face of contention with other VMs needing
CPU activity. All VMs, by default, start with an equal number of shares, which means that if
VMs compete for CPU cycles on an ESXi host, each one gets serviced with equal priority. Keep
in mind that this share value affects only those CPU cycles that are greater than the reservation
