In this article, we’ll dive deeper into the topic of vSphere resource management by covering the basics of resource management configuration. To cover this topic, we’ll discuss allocation settings, shares, reservations, limits, which allocation method to use, and admission control.
Again, why is it that you would need to configure resource allocation in vSphere? It’s not something that is required in all cases. However, if you already know that you have instances where there are greater resources demanded than are available, you already know you need to configure resource allocation. Additionally, with your goal of virtualization consolidation being to push resource utilization up (maximizing your hardware investment) then you already know that you are taking the chance of maxing out your hardware (at some point) and the safe choice to make is to configure resource allocation. Let’s find out how.
One of the first, of three, ways to configure resource allocation in vSphere is to use reservations. A reservation is used to allocate a minimum amount of resources that will be available to a virtual machine or resource pool. With a reservation, even when a server is heavily loaded, the virtual machine (or resource pool) will receive the resources that were reserved. You could reserve either CPU or virtual memory resources. Reservations default to zero. Reservations should be used sparingly as you are giving up some of your over commitment benefits offered by vSphere. CPU and memory reservations are configured separately and work differently. With memory reservations, the full amount of the memory is reserved and cannot be used by any other virtual machines. With CPU reservations, the amount of CPU Mhz are reserved but they CAN be used by other virtual machines until needed.
Memory reservations on a VM are configured on the virtual machine’s settings in the form of MB or GB and can be configured all the way up to the maximum amount of memory on the physical host.
CPU reservations are configured in the same place, on the virtual machine settings, under CPU.
Reservations on resource pools work slightly differently so let’s talk about resource pools now.
Resource pools are a pool of resources, allocated to the virtual machines contained inside. Resource pools offer a number of different benefits:
You can create a hierarchy where you have child resource pools
Delegation can be performed such that other admins can administer the child resource pools that you create
Separation of resource administration from the hardware
Allows you to manage resources for groups of virtual machines instead of individually
For example, say that you had a group of file transfer servers that periodically spiked in utilization running on the same cluster (or even an individual host) along with a critical web server that is used by the whole company. You don’t want the file servers to slow down the critical web server. Resource pools are the answer.
With resource pools, you could create one resource pool for the file servers and another resource pool for the web server (and future web servers). The resources allocated to the web server resource pool would be significant enough to ensure that the web server always has the resources that it needs.
Here’s another example, thanks to VMware.com. In this more complex example, the host’s resources have been allocated to two separate resource pools.
To create a resource pool, just right-click on a host or cluster, click All vCenter Actions, and then New Resource Pool.
From here, you give the new resource pool a name and configure the CPU and memory configuration. Resource pools could contain reservations as well as shares and limits (which we’ll talk about later).
What is different about resource pool reservations is that the reservations can be “expandable”. In a resource pool
with an expandable reservation, the reservation on a resource pool can expand beyond the specified value, if the parent resource pool has unreserved resources. A non-expandable reservation is called a fixed reservation.
Once you create your resource pools (parent and child), you’ll need to move your virtual machines into it (usually as easy as drag and drop).
Another common form of resource allocation in vSphere is “shares”. Shares allow an administrator to specify the importance of a virtual machine or resource pool in the virtual infrastructure. For example, the tier-1 ERP application and database server would receive a “high” share setting where the print server would receive a “low” setting.
By default, there are 3 share settings-
High = 2000 shares per vCPU and/or 20 shares per MB of configured memory
Medium = 1000 shares per vCPU and/or 10 shares per MB of configured memory
Low = 500 shares per vCPU and/or 5 shares per MB of configured memory
You can also create your own custom share settings.
Here’s what it would look like to configure the CPU share settings on a new resource pool.
It’s also possible to configure storage shares when using storage I/O control (or SIOC).
In my opinion, shares are the best way to ensure that your most critical virtual machines (and their applications) get the resources that they need.
Another way to configure resource allocations in vSphere is to use limits. Limits are used to limit the amount of CPU, memory, or storage I/O that a virtual machine (or resource pool) consumes. Where reservations and shares are used to ensure that virtual machines get the resources they need, limits are used to prevent virtual machines from using too many resources. By default, there are no “limits” on a virtual machine. An important point about memory limits is that, when a virtual machine’s memory is unlimited, the limit is the amount of configured virtual machine memory.
With your choices being resource pools, reservations, shares, and limits, which of these should you be using? Limitations are rarely recommended unless you have misbehaving applications (and in that case, you need to fix your application). Reservations should be used for certain applications or for specific resource pools.
In my opinion, it’s resource pools and shares (together) that are the best option. For a fantastic post on resource pools, see Chris Wahl’s post – Understanding Resource Pools in VMware vSphere.
Thus, a cluster with multiple resource pools and child resource pools might look like this:
What about admission control? Admission control is a vSphere feature that prevents you from powering on a virtual machine for which you don’t have the necessary resources required to meet a reservation (or at least provide for the VM overhead that’s required for all virtual machines).
When you are using vSphere high availability (HA) then you have vSphere HA admission control to take into account. With HA admission control, you not only need to provide resources to power on virtual machines with reservations but also the resources necessary to provide for virtual machines, should you have a physical server failure (or to support the HA admission control policy that you specify).