Clusters

A cluster is one hypervisor machine. The Clusters screen is the register of every machine the module manages: what each one is running, how much of it is sold, whether it is healthy, and how much of it you are willing to sell. Registering a machine for the first time is covered in Adding a Hypervisor Node; this article covers the list and everything on a cluster's own page.

Note: one machine is one cluster. The panel refuses to register a second cluster against the same node, and names the existing one when it does. "Cluster" and "node" mean the same thing throughout these screens.

Opening the page

In the admin sidebar open VPS, then the Clusters tab. The header reads VPS Clusters — KVM hypervisor clusters, virtual machines and takeover imports. Controls in the header let you refresh the page, open a Capacity preview, connect clusters another panel shares with you, and set the Freeze order. To add a cluster, use the Create menu on the tab strip and pick Node — see Adding a Hypervisor Node.

What a cluster owns

Everything on one node belongs to that cluster:

• Its agent. Exactly one, and it cannot be shared with another cluster.
• Its storage pools. Discovered when the panel reads the node's inventory. You choose which of them the node sells from.
• Its bridges. Also discovered; guest interfaces attach to one of them.
• Its virtual machines. A machine lives on exactly one node until it is migrated.
• Its own sell ceiling and reserve. How much of the machine you are prepared to commit, measured against that machine's hardware.

A cluster belongs to at most one group and sits in at most one location.

Cluster statuses

What each cluster status means

Status	Meaning
Provisioning	Registered, but not yet read and not yet holding a valid licence certificate. It accepts no virtual-machine work.
Active	Normal operation.
Maintenance	Flagged by an operator, with an optional reason and expected return. Shown as a banner wherever the node appears.
Unreachable	The agent is offline, so the panel cannot drive the hypervisor. Running machines are unaffected; management resumes when the agent reconnects.
Frozen	The number of registered clusters exceeds what your licence covers. Machines keep running and stay manageable — power actions, console and delete all work — but creating, reconfiguring and adopting are blocked.
Shared	A mirror of a cluster another panel owns. You manage your own machines on it; its hardware, health and settings live on the owner's panel.

Only Active and Maintenance can be set by hand. Provisioning, Frozen and Unreachable are set by the platform.

Separately from status, a node either accepts new machines or is Draining. Draining is not a status — a draining node is still active and fully manageable, it simply receives nothing new.

Freezing, and choosing the order

When registered clusters exceed the licensed count, the surplus is frozen. By default the newest cluster freezes first. You can set an explicit order in VPS Settings under Freeze order: the first cluster listed freezes first, and any cluster you do not list freezes last, newest first. Clusters shared with you by another panel are never listed — the owner's licence decides when they freeze.

The cluster list

Figures and filters

Six tiles above the table summarise every node at once. Their labels on screen are Nodes (by status, with how many are draining), Virtual machines (split into billed and unbilled), Fleet RAM, Fleet storage, Left to sell — memory still sellable under the resolved per-node ceilings, with reserves and multipliers already applied and measured against what is committed to customers rather than live usage — and Needs attention. Below them, a search box matches on name, agent, location, group, tag or note, and three dropdowns filter by status, by group and by placement (Accepting & draining, Accepting new VPS, or Draining).

Columns

Columns in the cluster table

Column	What it shows
Cluster	The node's name, its tags, and a marker if it carries operator notes.
Agent	The agent bound to this node and whether it is online.
Location	The site the machine is in.
Pool	The group it belongs to.
VMs	How many virtual machines are on it, and how many of those are unsold.
Resources	Live utilisation against what is sold, with the time of the last sample. A stale sample is called out.
24h	A small CPU trend. Trends are loaded on request, one read per node, so they are not drawn automatically; a button above the table loads them for the listed nodes.
Status	The status above, plus whether the node is accepting new machines.

Row actions

Each row has a menu: Open node, Refresh inventory, Edit node, Drain or Accept new VPS, Put in maintenance, Re-point agent (only while the node is unreachable or in maintenance) and Decommission. Selecting several rows lets you drain or un-drain them together; mirrors of another panel's hardware are skipped, because they are managed on the owner's panel.

Capacity preview

Capacity preview runs the placement decision without creating anything. Choose a plan or a custom size, and the panel shows which node the next machine would land on, why each other node was refused, and for every candidate how much is already sold, how many cores and how much disk it has, and how many addresses are free. If a plan is chosen, its targeting is applied as well. Use it before you launch a product to be sure the plan can actually be built somewhere.

A cluster's own page

Click a cluster to open it. The header carries its status, its agent, its tags, and one banner for the most serious thing currently true of it — licence, maintenance, frozen, unreachable or shared — with the remaining notices reduced to chips beside the status. Four sections follow.

Virtual Machines

Every machine on this node, with the same table, filters and actions as the module-wide list. Creating a machine, power actions, console, reinstall, migration and deletion are all documented in Virtual Machines. An Auto-refresh switch re-reads the node every 30 seconds while the tab is visible.

This section also carries the Guest network filter control. Machines the module built already carry a filter in their own definition that pins them to their known addresses and blocks address, MAC and ARP spoofing. Machines adopted from another panel do not: they keep whatever rules the old panel installed, and those rules disappear at the next reboot. Preview changes counts how many machines would be filtered and how many have no address the panel knows; Apply filter writes the filter into each machine's saved configuration. Running machines are not restarted or interrupted — the filter starts working at each machine's next power cycle, and the original configuration is saved on the node first. A machine that already carries any filter is left as found unless you tick Replace a filter the VM already has. A machine whose address the panel does not know gets a filter that learns the address instead of enforcing a fixed one: weaker, but still blocking MAC and ARP spoofing.

Health

Hardware readings, sampled by the agent every 5 minutes. You can look at the last 6 hours, 24 hours, 7 days or 30 days.

• CPU — usage, core count and load average. A sustained load above the core count means work is queueing for CPU.
• Memory and swap — used against total.
• Storage — per pool, with free space.
• Sold vs physical — how much memory and how many cores are promised to machines against how much is placeable once the reserve is taken off, plus the memory overcommit ratio. A warning appears when running machines are promised more memory than the node physically has: they only have to touch it for the host to start swapping or killing guests.
• Disk health — per physical disk, its self-test status, power-on hours, remaining write life, temperature and reallocated or pending sectors. A disk reported as failing is called out with an instruction to move machines off the node.
• Host throughput — disk read and write, and network in and out.

Note: some readings depend on what the node's agent reports. Where a counter is not sent, the panel says so plainly rather than showing a zero — the node is healthy, it is simply not sending that figure yet.

Imports

Adopting the machines already running on this node from another virtualisation panel. The whole flow — discovery, the review screen, adoption and removing the old panel — is documented in VPS Panel Migration.

Settings

Everything about this node that you decide.

Fields on a cluster's Settings section

Field	What it does
Name	The node's name across the panel.
Location	The site it is in. This decides which orders can reach it.
Migration pool	The group it belongs to.
Status	Only Active and Maintenance are offered. When you choose maintenance you may record a Reason and an Expected back time; both appear wherever the node is listed.
Tags	Free labels, for example nvme, rack-b, eu-west. They are searchable in the cluster list.
Operator notes	Anything the next person on call needs to know about this machine.
Accept new VPS on this node	Turn off to drain the node.
Server selection	How this node competes for a new machine. Leave it on Inherit from group unless this node needs its own rule.
Max VPS on this node	A hard cap on the number of machines, regardless of resources. Blank means no cap.
Held back for the host	Memory (in MB) and vCPUs subtracted from the physical figure before any multiplier is applied. This is how you express "never sell the last 8 GB" — a multiplier cannot.
How much of this node may be sold	The sell ceiling. See below.
Storage pools this node sells from	Tick the pools customers' disks may be created in, and pick which is the default. See below.

The sell ceiling

Set separately for memory, vCPU and disk. Each has three modes:

• Inherit — use the group's value, or the module-wide default if the group sets none.
• Multiple of node — a multiplier on the hardware. 2 means twice the physical amount.
• Fixed amount — a real figure in the node's own units.

Where both a multiple and a fixed amount apply, the tighter of the two wins. Blank everywhere means no limit. Under each field the panel shows its working — for example the multiplier, the physical amount, the reserve held back, the resulting sellable figure, and how much of it is already sold as a percentage.

A node past its ceiling simply stops receiving new machines. Nothing already running is touched.

Note: a sell ceiling is enforced against one machine's hardware, so it lives on the node. A group cannot express it. Where an older group still carries a multiplier, it is shown read-only on the Groups page with a note pointing here.

Storage pools this node sells from

The node reports its storage pools when its inventory is read; this control decides which of them are used for machines sold on it. With nothing ticked, a machine is built in whichever pool is largest at the time and capacity is measured against that largest pool. With pools ticked, every machine sold on the node — including by a panel you share this hardware with — is built in one of them, and both capacity and the free-space floor count only those pools. You may also nominate which ticked pool is the default. If the node has never been read, the panel says so and asks you to refresh its inventory first.

Common problems

• "Agent does not advertise the libvirt+qemu capabilities" — the virtualisation stack is missing on the machine. Install it and wait for the next check-in.
• "Agent already hosts a VPS cluster" — one node is one cluster. Use another machine's agent, or decommission the existing cluster.
• "Decommissioning is refused while VM records exist" — delete or migrate the machines first; the message says how many are in the way.
• The node is online and idle but orders will not land on it — almost always plan targeting. Check the node has a location and a group, and that the plan targets that group. Run a Capacity preview: it names every reason each node was refused. See Groups.
• "No host sample yet" — the node has never reported. Confirm the agent is online, then refresh the inventory.