Resource Pool Resource Allocation Settings
Resource allocation settings are applied to resource pools. Although similar to virtual machines, their behavior can differ somewhat.
Shares
Shares determine the priority of a resource pool or virtual machine compared to their siblings.
Siblings can be resource pools or virtual machines that exist at the same hierarchical level, i.e.
share the same parent.
Priority is determined by comparing the number of shares to the total amount of shares issued by the object’s parent. For example, a resource pool is created with 4000 CPU shares. If it is the only object, its parent (the cluster) has issued only 4000 CPU shares. Because the resource pool owns all issued shares, it is entitled to all the CPU resources available in the cluster.
In Figure 66, Resource Pool 2 is added to the cluster and is configured with 8000 shares. The cluster issues 8000 more shares, increasing the total shares to 12,000 and diluting the share ratio of Resource Pool 1 from 100% to 33%. In a worst-case scenario, Resource Pool 1 is entitled to 33% of the cluster resources. Worst-case scenario describes the state where all virtual
machines request 100% of the resources within the boundaries of their configured size.
Shares are a part of the dynamic entitlement calculation. During computation of dynamic entitlement, reservation and limits take precedence over shares, but this does not imply that shares are unimportant!
Note
Shares are not simply a weighting system for resources. In the following chapters we explain the working of shares during a worst-case scenario situation: every virtual machine claims 100%
of their configured resources, the system is overcommitted and contention occurs. In real life, this situation (hopefully) does not occur very often. During normal operations, not every virtual machine is active and not every active virtual machine is 100% utilized.
Activity and amount of contention are two elements determining dynamic entitlement of active virtual machines. For ease of presentation, we tried to avoid as many variable elements as possible and used a worst-case scenario situation in each example.
Figure 66: Resource Pool 1 and 2 share ratio
Resource Pool Shares
Because resource pool shares are relative to other resource pools or virtual machines with the same parent resource pool, it is important to understand how vCenter sizes resource pools internally.
The values of CPU and memory shares applied to resource pools are similar to virtual machines.
By default, a resource pool is sized like a virtual machine with 4 vCPUs and 16GB of RAM.
Depending on the selected share level, a predefined amount of shares are issued. Similar to virtual machines, four share levels can be selected. There are three predefined settings: High, Normal or Low, which specify share values with a 4:2:1 ratio, and the Custom setting, which can be used to specify a different relative relationship.
Caution must be taken when placing virtual machines at the same hierarchical level as resource pools, as virtual machines can end up with a higher priority than intended. For example, in vSphere 5, the largest virtual machine can be equipped with 32 vCPUs and 1TB of memory. If a
virtual machine is configured with a High share level, it can own up to 64,000 CPU shares and 20,80,000 memory shares. Figure 67 depicts the share ratio between a resource pool and the virtual machine both configured with a Normal share level.
Figure 67: Shares ratio of RP and a 32 vCPU, 1TB virtual machine
Basic design principle
It is not recommended deploying virtual machines at the same hierarchical level as resource pools.
Sibling Rivalry
As shares determine the priority of the resource pool or virtual machine relative to its siblings, it is important to determine which objects compete for priority.
Figure 68: Sibling level
In the scenario depicted in Figure 68, multiple sibling levels are present. Resource Pool 1 and Resource Pool 2 are child objects of the Cluster and therefore are on the same sibling level.
Resource Pool 3 and VM1 are child objects of Resource Pool 1 and are active on the same sibling level. The VMs of Resource Pool 2 are active on their respective sibling level. VM2 and VM3 are siblings and both compete for resources provided by Resource Pool 3. Their share values can be compared to each other. The share values of VM1 and VM3 cannot be compared with each other because they each have different parent resource pools and don’t have sibling rivalry.
Shares indicate the priority at that particular hierarchical level, but the relative priority of the parent at its level will determine the availability of the total amount of resources.
In the example depicted in Figure 69, the cluster resources are divided between Resource Pool 1 and Resource Pool 2. Resource Pool 1 receives 33% of the cluster resources based on its share value. Resource Pool 1 divides its resources between Resource Pool 3 and VM1. Both child-objects own an equal amount of shares and therefore receive each 50% of the resources of Resource Pool 1. This 50% of Resource Pool 1 resources equals to 16.5% of the cluster
resources. 16.5% resources is the result of 50% of pool of resources that is equal to 33% of the total amount of cluster resources. Resource Pool 3 divides its resources between VM2 and VM3. These child-objects of Resource Pool 3 compete with each other with an unequal amount of shares. In a worst-case scenario situation, VM2 ends up with 67% of Resource Pool 3’s resources that in turn equals 11% of the cluster resources.
Figure 69: Cluster resource distribution
Virtual Machines and Resource Pools as Siblings
Having virtual machines as siblings to resource pools can affect the resource allocation of the subsequent layers. This section illustrates why placing virtual machines as siblings to resource pools is considered to be a misconfiguration. Depicted in Figure 70, VM1 competes for
resources with Resource Pool 3. Based on their share values, each can receive up to 50% of the parent resource pool. The resources Resource Pool 3 obtains need to be divided among its child-objects, contrary to VM1 that can use its allocated resources for its own sake.
In the previous example, two virtual machines are active inside Resource Pool 3 and the
resources are divided between those two virtual machines. When adding more virtual machines to the resource pool, each share value of the virtual machine gets diluted, while the share value
of VM1 remains the same.
Figure 70: Share value dilution
Mixing virtual machines and resource pools at the same hierarchical level may create an
unintended imbalance in the proportional share values at that hierarchical level and affects the resource allocation of subsequent layers.
Share Levels are not Resource Classes
Share levels set at a parent are not inherited by child-objects. When a virtual machine is associated with a resource pool, it will retain its share level. If a virtual machine with a Custom share level is moved to a resource pool, an error is generated if the virtual machine is
configured with a share amount that is too high or low:
The CPU resource shares for VM <name> are much lower than the virtual machines in the resource pool. With its current share setting, the virtual machine will be entitled to 0% of the
CPU resources in the pool. Are you sure you want to do this?
When creating a virtual machine or a resource pool, vCenter assigns the Normal share level by default, independent of the share level of its parent.
In Figure 71, VM1 has 4000 shares, caused by a High share level, whereas Resource Pool 3 is configured with a Normal share level. Although their share levels are different, both Resource Pool 3 and VM1 own 4000 shares each. Both compete with each other based on share
amounts, not based on share level values. The number of shares and ‘share level’ are related but different, the number of shares is important while the ‘share level’ is simply a convenience for generating the values.
Figure 71: Share levels
To summarize: all shares are the same and none are more important than the others: 4000 shares = 4000 shares.