Page tree
Skip to end of metadata
Go to start of metadata

You can perform various operations on a Node when managing it. For more information, see Managing Nodes

If at any point a Node detects an error in its running, it will automatically place itself into an error state, to prevent any further virtual machines being started on it.

If a node reboots, then it will come back into maintenance mode and will need manually placing back in the pool (by placing back into running mode). This is to prevent faulty hardware that has rebooted becoming live again in the available resource pool.

Flexiant Cloud Orchestrator supports having nodes of different configurations, including different CPUs, RAM, and network configuration. 

The Xen hypervisor is fussy about migrating VMs between nodes with different CPU features. For information about how to mitigate this problem by selectively disabling CPU flags, see CPU Levelling.

To deal with the issues of having heterogenous node configurations, Flexiant Cloud Orchestrator has introduced the following features to ensure the nodes can work together, even within the same cluster:

  • CPU Contention - This allows nodes with different CPU capabilities to be balanced so that they appear to have the same capabilities.
  • RAM Contention - This allows nodes with different RAM capabilities to be balanced so that they appear to have the same capabilities.
  • Node Groups - This allows nodes with different network configurations to obtain the correct configuration when they are PXE booted.


Compute Nodes have two contention settings: CPU and RAM.

RAM Contention should be used with caution. It allows you to 'thin allocate' RAM to virtual machines, only allocating them what they need as they use it. This potentially allows you to over-allocate/contend the RAM resources on a node.

Over allocating RAM resources can overwhelm the contention and cause the Virtual Machines to crash.

CPU Contention

Flexiant Cloud Orchestrator allows you to set different contention levels on different Nodes, which can mean you can balance overall CPU performance between nodes of different capabilities, ensuring smoother performance for users of the platform.

As standard, Flexiant Cloud Orchestrator will allocate virtual machines to nodes so that the ratio of virtual CPU cores used by the VMs to physical CPU cores on the machines evened out across the platform. This ensures even loading of each CPU core. However, it assumes that each CPU core is equally powerful. The CPU contention setting acts a multiplier for the number of physical CPU cores. If a node was added with CPU cores with twice the performance of all other nodes, it should be set to have CPU contention of 2, so in the CPU part of the VM allocation algorithm, the system will assume there is twice as much CPU capacity given the number of CPU nodes. If a very slow node with CPU cores with half the normal speed, it should have its CPU contention set to 0.5.

RAM Contention

Where allowed by the hypervisor, Flexiant Cloud Orchestrator allows you to contend the RAM offered to each virtual machine.  This offers the ability to 'oversell' the RAM. If the RAM contention is set to a number greater than 1, the allocation algorithm will treat the node as having the amount of physical RAM it does have multiplied by that contention ratio. So, if the node has 1GB of RAM and a RAM contention setting of 1.5, it will treat it as having 1.5GB. It will therefore allocate VMs to that node with RAM requirements totalling 1.5GB rather than 1GB. This strategy will succeed so long as VMs either do not use more than an average of 2/3 of their allocated RAM, or successfully page share such that 1/3 of their allocated RAM is shared with other VMs, or a combination of the two. If each of the VMs happens to allocate more RAM than this, VMs will start to fail; therefore you should use this setting with caution.

RAM contention settings greater than one can cause your system to become unreliable. The probability of failure increases as the ratio of the largest VM RAM size to the physical memory increases.

For technical reasons, notwithstanding the RAM contention setting, a node will not be allocated a VM unless there is sufficient physical RAM (ignoring contention) to start the virtual machine.

Node Groups

As Flexiant Cloud Orchestrator PXE boots its nodes, it needs to know about their network configuration before they boot. Node Groups allow you to specify multiple different network configurations for nodes, even within the same cluster. More details are available from Config Groups.

  • No labels