Utilizing vSphere features, resource controls for VM priority

Solution providers can show customers the value of virtualization by configuring vSphere features and resource controls to prioritize VMs and give them proper access to resources.

After you implement virtualization for your customers it is important to define the priorities for their virtual machines (VMs). If you do not, your customers may find that their critical applications now run slower than before. Setting up resource controls can be a valuable service that VARs can offer their customers. The value can be two-fold: it helps to define customer priorities so that mission-critical VMs get access to the resources they need to run their workloads, and it allows VARs to show their customers the benefits of virtualization.

Here we will learn the resource control features in vSphere and how solutions providers can use them to set up a virtualized infrastructure that works for their customers.

Virtual Machine Resource Controls
Let's start with the four resources that can be regulated in vSphere at the VM level: CPU, memory, disk I/O and network I/O. When setting resource controls at this level, only CPU, memory, disk can be set. Both CPU and memory use the same three resource allocation controls that work in a similar fashion called shares, limits and reservations:

Shares are used to assign an importance to VMs and resource pools to control the amount of resources (CPU, memory or disk) to which each VM is entitled. Using shares to assign a general priority for resource usage to VMs means that you don't have to set specific reservations and limits for those VMs. So, a VM that has more shares then another VM is entitled to more resources. Shares can be set to Low (1000), Normal (default to 2000), High (4000) and Custom for each VM. Each setting has a numeric value associated with it that is used as a weight.

Shares can also be used for disk, but the share value does not apply. You can also set a limit on the amount of disk IOPS that a VM can use. When a VM is assigned a share level, it is entitled to a certain amount of resources, but the VM is not prevented from having more resources if they are available. Resource entitlements from shares come into play only when the host's CPU resources become constrained because they are designed to prioritize resources for certain VMs.

Shares do not guarantee a fixed amount of resources for VMs. They provide priority access only to available resources. They are easier to use than reservations and limits because they are more flexible and are not set to a fixed amount of resources.

Limits specify the maximum amount of host CPU and memory resources that a VM can use. Limits are set in the unit of the specific resource: CPU reservations are set in megahertz and memory reservations are set in megabytes. VMs are set to use unlimited host resources by default, but this term is misleading because a VM can never use more CPU or memory than it has been assigned.

Setting a CPU limit on a VM will always limit it to the amount set regardless of the amount of resources available. Setting a limit on memory will only regulate the amount of physical host memory that at VM can use. Once that limit is reached, the VM will instead use its virtual swap (vswp) file for memory.

Limits are useful to ensure that non-critical VMs do not hog host resources. The drawback is that they are in effect at all times, regardless of host resource availability. Also, because they define fixed resource amounts, limits can be more difficult to manage than shares.

Reservations are used to guarantee a certain amount of host CPU or memory resources to a VM. When you set a reservation on a VM, the host will ensure that the VM always gets that amount of resources if it needs it.

Reservations are also set in the unit of the specific resource but are set to 0 for all VMs by default. Because reservations set a certain amount of resources, a VM will not be allowed to power on if the host does not have enough resources to guarantee a reservation. Therefore if you set a 4 GB memory reservation on a host, and it only had 2 GB of physical memory free, you would be unable to power on the VM.

Because they are based on fixed resource amounts, reservations can also be more difficult to manage than shares, but they do guarantee resources for critical VMs.

A nice side benefit to reservations is that they reduce the size of the vswp file that is created when a VM is powered on. The size of a VMs vswp file is dictated by the amount of memory assigned to a VM minus the amount of the memory reservation. So a VM with 8 GB of memory and a 5 GB memory reservation would have only a 3 GB vswp file created in its home directory. This is because an amount of physical memory is reserved for the VM, and there will never be the need to use the virtual disk file for the amount reserved. This can help save disk space on your host datastores.

Shares, reservations and limits can be used together on a single VM. But, in general, shares are the most flexible and easiest way to control the amount of resources a VM has access to. Because shares are dynamic, they can be less restrictive when host resources are plentiful. But when host resources become constrained, they will prioritize access to resources to help ensure critical VMs get the resources they need.

Using Resource Pools
The concept of resource pools works just like setting shares, limits and reservations on individual VMs but on a broader scale. Resource pools can be created on standalone hosts, on clusters and on other resource pools. Resource pools allow you to split a host or cluster's CPU and memory resources into pools that can be assigned to VMs. By default, every standalone host and DRS cluster has an invisible root resource pool containing all the resources of the host or cluster.

You can optionally create child resource pools to split the host or cluster's resource into separate pools. Child resource pools own part of the parent's resources and can contain additional child resource pools to form a resource hierarchy. Resource pools can contain additional resource pools, and VMs and are referred to as siblings if they are at the same level.

Image 1: See how an ESX host is sectioned off into resource pools.

When you create resource pools, you allocate CPU and memory to them using shares, limits and reservations. Reservations in resource pools can be set to be expandable so they can draw more resources from the parent pool if they are available.

If a resource pool is set to not be expandable, then it is unable to draw additional resources from the parent even if they are available.

You cannot create a resource pool on an individual host if it is a member of a DRS-enabled cluster. Once you create a resource pool, you can move VMs into it, and they will share the resources assigned to the pool. If a VM has individual resource settings, they will still be honored when it is moved to a resource pool, but the pool settings may affect the resource entitlements.

Resource pools are a great way to segregate a cluster's resources to limit the amount of resources a group of VMs can use. If resources are available, the VM will be powered on.

About the expert
Eric Siebert is a 25-year IT veteran whose primary focus is VMware virtualization and Windows Server administration. He is one of the 300 vExperts named by VMware Inc. for 2009. He is the author of the book
VI3 Implementation and Administration and a frequent TechTarget contributor. In addition, he maintains vSphere-land.com, a VMware information site.

Dig Deeper on Server virtualization technology and services