Information Technology Reference
In-Depth Information
set for the VM, and the share value applies only when the ESXi host has more requests for CPU
cycles than it has CPU cycles to allocate. In other words, the VM is granted access to its reserva-
tion cycles regardless of what else is happening on the host, but if the VM needs more—and
there's competition—then the share values come into play. If there is no CPU contention on
the host and it has enough CPU cycles to go around, the CPU Shares value won't affect CPU
allocation.
Several conditions have to be met for shares to even be considered for allocating CPU cycles.
The best way to determine this is to consider several scenarios. For the scenarios we'll cover,
assume the following details about the environment:
The ESXi host includes dual, single-core, 3 GHz CPUs.
◆
The ESXi host has one or more VMs.
◆
Scenario 1
The ESXi host has a single VM running. The shares are set at the defaults for
any running VMs. Will the Shares value have any effect in this scenario? No. There's no com-
petition between VMs for CPU time.
Scenario 2
The ESXi host has two idle VMs running. The shares are set at the defaults for
the running VMs. Will the Shares values have any effect in this scenario? No. There's no com-
petition between VMs for CPU time because both are idle.
Scenario 3
The ESXi host has two equally busy VMs running (both requesting maximum
CPU capacity). The shares are set at the defaults for the running VMs. Will the Shares values
have any effect in this scenario? No. Again, there's no competition between VMs for CPU
time, this time because each VM is serviced by a different core in the host.
Scenario 4
To force contention, both VMs are coni gured to use the same CPU by setting
the CPU afi nity. The ESXi host has two equally busy VMs running (both requesting maxi-
mum CPU capacity). This ensures contention between the VMs. The shares are set at the
defaults for the running VMs. Will the Shares values have any effect in this scenario? Yes! But
in this case, because all VMs have equal Shares values, each VM has equal access to the host's
CPU queue, so you do see any effects from the Shares values.
CPU Affinity Not Available with Fully Automated Clusters
If you are using a VSphere Distributed Resource Scheduler-enabled cluster confi gured in fully
automated mode, CPU a nity cannot be set for VMs in that cluster. You must confi gure the cluster
for manual / partially automated mode or set the virtual machine automation mode to manual /
partly automated in order to use CPU a nity.
Scenario 5
The ESXi host has two equally busy VMs running (both requesting maximum
CPU capacity 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 is set to the default 1,000 CPU shares. Will the Shares val-
ues have any effect in this scenario? Yes. In this case, VM1 has double the number of shares
that VM2 has. This means that for every clock cycle that VM2 is assigned by the host, VM1
is assigned two clock cycles. Stated another way, out of every three clock cycles assigned to
