Creating and Configuring Resource Pools

A root resource pool is associated with each ComputeResource and with each ClusterComputeResource.

You can create a hierarchy of resource pools by calling the ResourcePool.CreateResourcePool method passing in a ResourceConfig method as an argument. The ResourceConfig.cpuAllocation and ResourceConfig.memoryAllocation properties point to a ResourceAllocationInfo object that allows you to specify the information.

■	reservation – Amount of CPU or memory that is guaranteed available to the resource pool. Reserved resources are not wasted if they are not used. If the utilization is less than the reservation, the resources can be utilized by other resource pools or running virtual machines.

■

expandableReservation – 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. See Understanding Expandable Reservation. This property is ignored for virtual machines.

■

limit – Upper limit for CPU or memory resources assigned to this resource pool. The virtual machine or resource pool does not exceed this limit, even if resources are available. This property is typically used to ensure consistent performance. Set this property to -1 to indicate no fixed upper limit on resource usage.

■	shares – Relative metric for allocating memory or processing capacity among multiple resource pools. The SharesInfo data object has two properties, level and shares, that allow you to specify resource allocation.

■	level – Choose high, low, or normal to map to a predetermined set of numeric values for shares. See the API Reference Guide for the numbers for CPU, memory, and disk shares. Set this property to custom to specify an explicit number of shares instead.

■	shares – Allows you to specify the number of shares you want to allocate to the resource pool. The allocation is divided evenly between resource pools with the same level.

Calling the ResourcePool.UpdateConfig or ResourcePool.UpdateChildResourceConfiguration method allows you to change the configuration.

Understanding Expandable Reservation

Expandable reservations are best illustrated with examples.

Expandable Reservation Example 1

Assume an administrator manages pool P, and defines two child resource pools, S1 and S2, for two different users (or groups).

The administrator knows that users want to power on virtual machines with reservations, but does not know how much each user will reserve. Making the reservations for S1 and S2 expandable allows the administrator to more flexibly share and inherit the common reservation for pool P.

Without expandable reservations, the administrator needs to explicitly allocate S1 and S2 a specific amount. Such specific allocations can be inflexible, especially in deep resource pool hierarchies and can complicate setting reservations in the resource pool hierarchy.

Expandable reservations cause a loss of strict isolation; that is, S1 can start using all of P's reservation, so that no memory or CPU is directly available to S2.

Expandable Reservation Example 2

Assume the following scenario (shown in Admission Control with Expandable Resource Pools, Scenario 1):

■	Parent pool RP-MOM has a reservation of 6GHz and one running virtual machine VM-M1 that reserves 1GHz.

■	You create a child resource pool RP-KID with a reservation of 2GHz and with Expandable Reservation selected.

■	You add two virtual machines, VM-K1 and VM-K2, with reservations of 2GHz each to the child resource pool and try to power them on.

■	VM-K1 can reserve the resources directly from RP-KID (which has 2GHz).

■	No local resources are available for VM-K2, so it borrows resources from the parent resource pool, RP-MOM. RP-MOM has 6GHz minus 1GHz (reserved by the virtual machine) minus 2GHz (reserved by RP-KID), which leaves 3GHz unreserved. With 3GHz available, you can power on the 2GHz virtual machine.

Admission Control with Expandable Resource Pools, Scenario 1

Now, consider another scenario with VM-M1 and VM-M2, shown in Admission Control with Expandable Resource Pools, Scenario 2.

■	Power on two virtual machines in RP-MOM with a total reservation of 3GHz.

■	You can still power on VM-K1 in RP-KID because 2GHz are available locally.

■

When you try to power on VM-K2, RP-KID has no unreserved CPU capacity so it checks its parent. RP-MOM has only 1GHz of unreserved capacity available (5GHz of RP-MOM are already in use—3GHz reserved by the local virtual machines and 2GHz reserved by RP-KID). As a result, you cannot power on VM-K2, which requires a 2GHz reservation.

Admission Control with Expandable Resource Pools, Scenario 2

Deleting Child Resource Pools

The ResourcePool.DestroyChildren method recursively deletes all the child resource pools of a resource pool. The operation takes a single parameter, a reference to the parent ResourcePool managed object. Any virtual machines associated with the child resource pool are reassigned to the parent resource pool.

Moving Resource Pools or Virtual Machines Into a Resource Pool

You can move a resource pool and its children within a resource pool hierarchy.

The ResourcePool.MoveIntoResourcePool method lets you move virtual machines, virtual applications, or resource pool hierarchies into a new resource pool. You call the method with an array of ResourcePool or VirtualMachine managed object references that you want to move. The whole resource pool hierarchy, including child resource pools and virtual machines, is moved when you move a resource pool.

Minimum available resources of the immediate children must always be less than or equal to the resources of the immediate parent. The root resource pool cannot be moved.