Information Technology Reference
In-Depth Information
Shares Apply Only during Actual Resource Contention
Remember that share allocations come into play only when VMs are fi ghting one another for
a resource—in other words, when an ESXi host is actually unable to satisfy all the requests for a
particular resource. If an ESXi host is running only eight VMs on top of two quad-core processors,
there won't be contention to manage (assuming these VMs have only a single vCPU) and Shares
values won't apply. Be sure to keep this in mind when reviewing the results of Shares allocations
like those displayed in Figure 11.15.
Now that we've introduced you to the Resource Allocation tab, we need to discuss an impor-
tant consideration about the use of resource pools. It's possible to use resource pools as a form
of organization, as you would use folders. Some organizations and administrators have taken to
using resource pools in this way to help keep VMs organized in a specii c fashion. While this is
possible, it's not recommended. The Resource Allocation tab helps show why.
Look at Figure 11.16, which shows the Resource Allocation tab for a cluster of ESXi hosts. In
the root of this cluster are six VMs assigned a total of 7,000 shares. Because each of these VMs
is using the default CPU Shares value (1,000 shares per vCPU), they each get equal access to the
host CPU capacity—in this case, 14 percent per vCPU (the VMs with 2,000 shares and 28-percent
shares have two vCPUs).
Figure 11.16
In the absence of
custom CPU shares,
CPU capacity is
equally allocated to
all VMs.
Now look at Figure 11.17. The only change here is that we've added a resource pool. I did not
change any of the default values for the resource pool. Note that the resource pool has a default
CPU Shares Value of 4,000, and note how the simple addition of this resource pool changes the
default CPU allocation for the individual VMs from 14 percent per vCPU to only 9 percent per
vCPU. The resource pool, on the other hand, now gets 36 percent. If you added a single VM to
the resource pool, that one VM would get 36 percent of the host CPU capacity while other VMs
only received 9 percent (or 18 percent for VMs with two vCPUs).
This unintended change on the resource allocation distribution is why we don't recommend
using resource pools strictly for the purposes of organizing VMs. If you do insist on using
resource pools in this way, be sure to understand the impact of coni guring your environment in
this manner. A better way to organize your environment, and one that won't impact the perfor-
mance, is to use folders or tags within vCenter; for more information, see Chapter 3, “Installing
and Coni guring vCenter Server.”
