Brief Introduction

Compute hosts (aka hypervisors) can be grouped to different host pools. This allows separation of hosts with different purpose and configuration. Virtual Machines designated to a particular pool will stay in the pool throughout its lifetime. Only admin users have the capability to move Virtual Machines between pools. Host pools are grouped by their storage cluster. Virtual Machines can only be moved between pools that are using the same storage cluster.

Host pools are designed to separate physical hosts that still share common network.

Possible Use Cases

Selling different CPU types for different prices, user can choose between standard Intel (cheaper) or performance AMD (more expensive) CPU when creating a Virtual Machine.

Selling hosts with different resource overcommit with different prices, user can choose between standard cluster with CPU overcommit or “dedicated” cluster where the number of vCPUs running on a host never exceeds the actual number of CPU threads the host has.

Easier management of hosts with different CPU features.

Selling block storage from clusters with different performance for different prices.

Keeping good players in a hidden pool on hosts where no other user can create resources.

Keeping bad players in a hidden pool on hosts where they don’t bother other users.

Host Pool Concepts

Storage pool corresponds to a Ceph cluster. There can be multiple Ceph clusters in one location. A compute host can only be configured to one storage pool/Ceph cluster.

Host pool is a group of similar hosts (hypervisors). When starting a Virtual Machine, a host is chosen from the VM’s designated host pool. CPU type, CPU and RAM allocation coefficients and the storage pool are defined on host pool level. To end-user, host pool is shown as server class when creating a new VM.

Pool Management

Every location has at least 1 host pool and storage pool defined by default. Host pools are local to a location, they cannot span across multiple locations. All hypervisors must be assigned to some host pool.

Host pool properties, shown on Host pools admin view :

Name of the host pool and UUID for filtering in hosts table

Name can be seen by end-user

Description about host pool purpose

Can be seen by end-user

CPU model – this is QEMU / KVM CPU model configuration that applies to all hosts in that pool.
The CPU model configuration in QEMU/KVM refers to the settings that define the virtual CPU that is presented to the guest operating system running inside a virtual machine. Selecting a CPU model that closely matches the hardware of the physical host machine can help ensure compatibility with device drivers and system libraries.
It is vital to configure a CPU model that is supported by all hosts in that pool. The platform expects virtual machine live migrate to be possible between all hosts in a particular pool. A common baseline between host CPUs must be configured if hosts with different CPUs are present in one pool.

Virtual CPU coefficient – CPU overcommit factor for virtual CPUs. The number of available vCPUs on a host is calculated by the number of physical threads on that host times the host pool CPU overcommit factor. E.g., for a host that has 24 physical threads in a host pool that has 2.5 CPU coef., the number of vCPUs available for virtual machines will be
24 physical threads * 2.5 = 60 virtual CPUs

Virtual Memory coefficient – Defines how much physical memory is reserved for allocation to virtual machines. The recommended value 0.8 means that 80% is reserved for VMs and the other 20% is reserved for management overhead. E.g., for a host that has 140 GB of RAM in a host pool that has 0.8 Mem coef., the amount of RAM available for virtual machines will be
140 GB * 0.8 = 112

Default Pool for VMs – new VMs that are created will have this as their designated pool by default. The default applies to both API and, if pool (server class) selection is visible to the user, also to the default selection in Create VM view.

Pool is visible – A visible pool is presented to the end user in Create VM view as a selectable Server class option. The Default Pool for VMs will be auto-selected. By default host pools are not visible.

Hosts – shows number of hosts assigned to that host pool. Clicking on the number will open Hosts table view, showing only hosts from that pool.

Default pool for hosts – useful when adding new hosts to a location, new hosts will self-register to the selected pool.

Storage pool name and UUID – all hosts in this pool must all have this storage cluster configured in their OS configuration. Different host pools can share a storage pool. Storage pool name is not visible to end-user.

Action buttons for host pools –

Edit (similar to Create view)
Storage pool can only be changed if there are no hosts in that host pool currently. When a storage pool is selected for a host pool, only hosts with the same storage pool can be added to the host pool.

Delete –

Host pool must not contain any hosts

No Virtual Machine must have this pool as its designated pool

Host Pools and Virtual Machines

All Virtual Machines have a designated host pool. When Starting a VM, a host is chosen from the VM’s designated pool only. If the pool does not have a host with enough resources available, the VM can not be started.

If no host pools have “visible” flag set then all newly created Virtual Machines will have the Default pool for VMs as their designated pool.

Visible host pools are presented to the user when creating a Virtual Machine as Server class option, in which case the selected class/pool will be the designated host pool for that VM.

End user is not allowed to change the designated host pool for an existing Virtual Machine. If such need arises it must be handled by platform admin.

Admins can change VM’s designated pool in VM details view. Do note that for a running VM, changing the designated pool does not cause the VM to switch hosts automatically.

VM disks are bound to the storage cluster that they were created in. This means that new designated pool selection is limited to host pools that have the same storage pool configured as the current designated pool. VMs cannot be migrated to another storage cluster.

After changing the designated pool, one of two actions should follow:

Manual Migrate of VM to a host in the designated pool. The platform will do a best effort of live migrating the VM. This will move the VM to a new host in the new pool, provided that the CPU model that was configured for the VM at the time of Start in the old pool is compatible with the new host in the new pool.

Use platform Stop and Start to have the VM running on a host from the designated pool. It is not enough to do reboot from inside the VM, this will keep the VM running on the same host as it was before, so Current pool will not be changed.
Admin can either Stop and Start from UI (or via API) by themselves, or ask the user to do so at a time most appropriate for their service.

Pricing for Different Server Classes

It is possible to set different prices for CPU, RAM and disk/block storage depending on the Server class (host pool). In the Prices configuration view, clicking on Add button (1) will open a dialog with dropdown (2) from where either a location or a host pool in that location can be chosen. Locations or host pools that already have a price list are not selectable in the dropdown.

Although the host pool specific price list will only apply to CPU, RAM and disk, it is advisable to define prices for all resources, copying them from the location specific or the global default price list. This will make it easier for users to read and understand price lists.

Running Virtual Machines are priced by their Current pool, so if the designated pool is changed, but the VM is not Stopped and Started or Migrated, it will be still priced by their current pool. This in accordance with user VM details view, where Server class will show Current pool for running VMs, no matter what their designated pool is.