Information Technology Reference
In-Depth Information
also add signii cant overhead, which would limit the performance of the virtualization platform
by adding more computational overhead.
So, how many CPUs should a VM have? A VM that replaces a physical DHCP server that
runs at less than 10 percent CPU utilization at its busiest point in the day surely does not need
more than one virtual CPU. As a matter of fact, if you give this VM two virtual CPUs (vCPUs),
then you might limit the scalability of the entire host. Here's why.
The VMkernel simultaneously schedules CPU cycles for multi-vCPU VMs. This means that
when a dual-vCPU VM places a request for CPU cycles, the request goes into a queue for the
host to process, and the host has to wait until there are at least two cores or hyperthreads
(if hyperthreading is enabled) with concurrent idle cycles to schedule that VM. A relaxed
co - scheduling algorithm provides a bit of l exibility in allowing the cores to be scheduled on a
slightly skewed basis, but even so, it can be more difi cult for the hypervisor to i nd open time
slots on at least two cores. This occurs even if the VM needs only a few clock cycles to do some
menial task that could be done with a single processor. Here's an example: Have you ever been
stuck behind a truck with a wide load that takes up more than one lane? Normally trafi c could
l ow around this slow-moving vehicle, but now trafi c is held up because two lanes are occupied.
On the other hand, if a VM needs two vCPUs because of the load it will be processing on a
constant basis, then it makes sense to assign two vCPUs to that VM—but only if the host has
four or more CPU cores total. If your ESX host is an older-generation dual-processor single-core
system, then assigning a VM two vCPUs will mean that the VM owns all of the CPU processing
power on that host every time it gets CPU cycles. You will i nd that the overall performance of
the host and any other VMs will be less than stellar. Of course, in today's market of multicore
CPUs, this particular consideration is less signii cant than it was in previous hardware genera-
tions, but it is something to keep in mind.
One (CPU) for All—at Least to Begin With
Every VM should be created with only a single virtual CPU so as not to create unnecessary con-
tention for physical processor time. Only when a VM's performance level dictates the need for an
additional CPU should one be allocated. Remember that multi-CPU VMs should be created only on
ESXi hosts that have more cores than the number of virtual CPUs being assigned to the VM. Create
a dual-vCPU VM only on a host with two or more cores, a quad-vCPU VM only on a host with four
or more cores, and an eight-vCPU VM only on a host with eight or more cores.
Default CPU Allocation
Like the memory settings discussed previously, the Shares, Reservation, and Limit settings can
be coni gured for CPU capacity as well.
When a new VM is created with a single vCPU, the total maximum CPU cycles for that VM
equals the clock speed of the host system's core. In other words, if you create a new VM, it can
see through the “hole in the system board,” and it sees whatever the core is in terms of clock
cycles per second—an ESXi host with 3 GHz CPUs in it will allow the VM to see one 3 GHz core.
Figure 11.7 shows the default settings for CPU Reservation, Limits, and Shares.
 
Search WWH ::




Custom Search