Skip to content

Resource Pools

A resource pool groups VMs in one cluster and gives them shared CPU and memory rules. Use one to keep a noisy workload from starving the rest, to give production more CPU than test when hosts are busy, or to cap how much CPU a group can take.

Resource pools are admin-only.

What a pool controls

Setting Effect
CPU shares Low (50), Normal (100), High (200) or Custom (1–10000). Shares only matter when a host's CPU is busy: the pool's VMs together get CPU time in proportion to the pool's shares. A VM outside any pool counts as Normal.
CPU limit, in vCPUs per host The most CPU the pool's VMs on one host can use together. 2.5 means two and a half host CPUs. Blank means no limit.
Memory reservation, % of each VM's memory Memory set aside for each VM in the pool. A host won't take a VM from the pool if the memory reserved on it would be more than the host has, whether the VM is being deployed there, moved there or put into the pool.

Create a pool

  1. Click the cluster in the inventory tree and open its Summary.
  2. Resource Pools → New pool.
  3. Fill in the name and the three settings above. Save.

The console applies the pool to every host in the cluster and says which hosts confirmed. If a host didn't, the toast names it. Check that host and save again.

Put VMs in a pool

  • New VM: in the deploy dialog's Source & Placement step, pick the Resource Pool. With a host or a cluster's Automatic placement chosen, the list shows that cluster's pools. With plain Automatic it shows every pool, and the VM is placed in the chosen pool's cluster. The VM starts in the pool, so its rules apply from first boot. The review step shows the pool.
  • Existing VM: its Configure tab → Resource Pool → pick one (or none) → Apply.

On a running VM, the memory reservation counts straight away, but CPU shares and the CPU limit take effect the next time the VM is powered off and started. A restart from inside the guest isn't enough.

Moves, clones and HA

  • A VM stays in its pool through live and cold migration, load balancing and HA restart.
  • A clone joins its source's pool.
  • A VM in a pool can't be migrated to a host in another cluster.

Delete a pool

Resource Pools → Delete on the pool. Move its VMs out first: a pool with VMs in it can't be deleted. Deleting a cluster deletes its pools.

When a pool is deleted, its CPU settings are removed from the cluster's hosts. A host where a VM is still running under the old settings (a VM that left the pool but hasn't been powered off and on since) keeps them until that VM restarts. The audit line and the toast name those hosts. The settings left behind have no effect on other VMs.

Every pool change, and every VM moved in or out of a pool, is recorded in the audit log.

Placement rules in the deploy dialog

The Placement Rules section of the same deploy step also takes:

  • Affinity Group: the VM's group for affinity rules, HA and the load balancer.
  • Required Host Labels: automatic placement only considers hosts with every label listed.
  • Preferred Host Labels: hosts with these labels are preferred when several fit.

1.3.0-rc3.1 and earlier

Before 1.3.0-rc4 these three fields only fed the placement preview. They weren't sent with the deploy, so the labels didn't affect where the VM landed and the VM didn't keep its affinity group. Set the group on affected VMs from their right-click menu.

See also