Groups

A group is a named set of hypervisor nodes. It decides which node a new virtual server lands on, it is the boundary inside which a running machine can be moved from one node to another without stopping it, and it is what a plan usually targets when you sell capacity in a particular place. Groups cost nothing — your licence counts clusters, not groups.

Note: some parts of the panel still call a group a migration pool, and a plan's targeting field is labelled Migration pools. It is the same object.

Opening the page

Open VPS in the admin sidebar, then the Groups tab. Each group is a card rather than a table row, because a group is a small policy plus a set of machines and you need to see both at once. To add one, open the Create menu on the module's tab strip and pick Group — that is the only place the add form is opened from.

What a group decides

The page states this at the top, and every item on the list is enforced somewhere in the module:

The six things a group governs

Concern	What the group does
A named set of hypervisors	A name, an optional location, and the nodes ticked into it. A node belongs to at most one group; a mirror of another panel's hardware belongs to none.
The live-migration boundary	A machine only moves between nodes of the same group, and only once their access keys have been meshed.
Server selection	Which member takes the next machine. Resolved as module-wide default → group → node, with the node value winning.
Plan targeting	A plan pinned to a group is only ever placed on that group's members — the way a "Germany" plan stays in Germany without naming individual machines.
IP scoping	Address space reserved for virtual servers can be pointed at a group rather than at single nodes, so adding a node to the group also gives it that space.
Not how much may be sold	A sell ceiling is measured against one machine's hardware, so it lives on the node — Clusters → the node → Settings. A group cannot express it.

Creating and editing a group

1. Open the Create menu on the tab strip and pick Group.
2. Enter a Name.
3. Pick a Location, or leave it as None.
4. Choose a Server selection strategy, or leave it on Use the global default — the panel shows what that default currently is.
5. Save.

The available strategies are None (first available), Most available RAM, Most available disk, Most available cores, Most available IPv4, Least number of VPS and Least system load. The module-wide default is set in VPS Settings, and any individual node can override its group.

The form deliberately carries no sell ceiling. If an older group still stores overselling multipliers, the card shows them read-only with a line saying where the limit lives now — on each node. Saving the group leaves those stored values untouched.

Choosing the members

Click Members on a group card. The ticked hypervisors are the group. Unticking one removes it; ticking one that already sits in another group moves it, and the picker says which group it is coming from. Mirrors of another panel's hardware are listed but cannot be ticked — they have no agent of yours, so they cannot join a group.

The panel confirms what changed — how many nodes were added and removed.

Warning: a group with no members places nothing and migrates nothing. The page also warns you when nodes belong to no group at all, and names them: those nodes place by the module-wide defaults and cannot move to anything.

The key mesh

Moving a running machine from one node to another needs each node in the group to trust the others' access keys. The panel maintains that automatically: meshing runs after a node joins a group, and retries within minutes once every member's agent is online. The card shows Mesh current or Mesh stale, and when it last ran.

Changing membership makes the mesh stale, and live migration inside the group is refused until it runs again — the panel checks the mesh before it starts a migration, so the refusal lands on you rather than on a customer's machine. Mesh SSH keys on the card re-runs it on demand; it takes about a minute and reports per-node results. A group needs at least two nodes before there is anything to mesh.

Re-pointing a node's agent also makes the mesh stale, because the replacement machine's key is not in it.

Deleting a group

Deleting keeps the nodes — they simply leave the group. The confirmation tells you how many nodes will fall back to the module-wide placement defaults, and that live migration between them stops being possible. Delete a group only when you have somewhere else for its nodes to go.

Groups that came from somewhere else

• Imported groups. Migrating an estate from another virtualisation panel creates one group per source group. The card says where it came from and what it was called there. A later re-import re-applies that panel's strategy and membership; your own name for the group is kept.
• Inherited groups. When another FluxBilling panel shares hardware with you, its groups appear here marked as owned by that panel. They are read-only: editing, deleting and meshing all belong to the panel that owns the machines.

Storage pools and IP pools — not the same thing

The word "pool" appears in three places in this module and means three different things. Keeping them apart saves a lot of confusion:

• A group (sometimes labelled "migration pool") is a set of machines, described above.
• A storage pool is a place on one node where disks are created — a volume group, a directory of disk image files, or a storage dataset. Nodes report the pools they have when their inventory is read; you choose which of them the node sells from on the node's own Settings section, and which is its default. See Clusters.
• An IP pool is address space in IPAM. Any subnet or single address can be marked Virtual Server, which reserves it for this module — a marked address is never handed to a physical server, a rack device or an IP transit allocation. Marked space then carries a scope: pick the clusters and groups allowed to draw from it, or pick nothing, which means any node may. Scoping to a group is usually what you want, because adding a node to that group then gives it the space automatically.

Note: a node from which marked space is reachable allocates only from marked space — it never falls back to the general pool. If you mark nothing at all, nothing changes: addresses are drawn as before. You can also require every virtual server address to come from marked space company-wide, from VPS Settings.

The mistake that costs you sales

This is the single most common configuration error in the module, and it produces a confusing symptom: a machine that is powered on, online and completely idle, while orders for it fail.

The cause is always the same. A plan targets a group, not a node. A plan's targeting is an allowlist: if it names any groups at all, only nodes in those groups may host it. A node that belongs to no group, or to a group the plan does not name, is excluded — even when it is the only machine in that location.

Worked example

You have three nodes in Frankfurt in a group called DE-Frankfurt, and every plan targets that group. You install a fourth machine in Vienna, register it, give it the location "Vienna", and forget to put it in a group.

1. The storefront still offers Vienna, because the location exists and has an online machine in it.
2. A customer orders and pays.
3. Placement narrows candidates to active nodes with an online agent in Vienna — one machine — then applies the plan's targeting, which names only DE-Frankfurt. The candidate list is now empty.
4. The build is refused with No active VPS cluster with an online agent in the service's location, about a machine that is online and doing nothing.

How to avoid it

• Always give a node a location when you register it. With a location set, the panel puts the node in that location's group automatically, creating that group the first time it is needed. A node with no location gets no group.
• Then add the group to the plans that should sell there. Joining a group is not the same as being sold: a plan still has to target the group. New locations stay unsold until you price them, which is deliberate.
• Prove it before you launch. Open Clusters → Capacity preview, choose the plan, and confirm at least one node in the new location can take it. The preview names every reason each node was refused, including outside the targeting of plan.
• Watch the group card. Each one shows how many plans place only there, and the page warns about nodes that belong to no group.

Tip: the same trap applies to a plan that targets individual clusters. If you replace a machine and register the new one, any plan that named the old cluster by name will not use the replacement. Targeting a group instead of individual machines avoids this entirely.

Where to go next

• VPS Plans — where targeting is set.
• Clusters — per-node settings, including the sell ceiling and storage pools.
• Virtual Machines — moving a running machine between nodes of a group.