VPS Overview

The VPS module turns your own KVM hypervisor machines into sellable virtual servers. You register each physical machine with the panel, group the machines that may hand work to one another, describe the virtual-machine sizes you want to sell, attach one of those sizes to a product, and from then on a paid order builds a real virtual machine on your hardware without anyone touching a hypervisor by hand. The same screens also manage machines you did not sell — anything you build for yourself or adopted from another panel appears alongside them.

How the pieces fit together

Six things make up the module. Reading them in this order is the fastest way to understand every other screen.

The building blocks of the VPS module

Piece	What it is
Cluster	One physical hypervisor machine. The panel calls a registered machine a cluster, and the words "cluster" and "node" are used interchangeably across the screens. One machine is one cluster — there is no such thing as a cluster containing several machines.
Agent	The small program the panel installs on that machine. It is the only thing that ever talks to the hypervisor: the panel writes an instruction, the agent collects it over an outbound connection and carries it out. A machine with no agent cannot be managed.
Group	A named set of clusters. A group decides which machine a new virtual server lands on, and it is the boundary inside which a running machine can be moved live from one node to another. A cluster belongs to at most one group.
Storage pool	A place on one node where disks are created — a volume group, a directory of disk image files, or a storage dataset. Each node reports the pools it has when the panel reads its inventory, and you choose on the node itself which of them you sell from.
Plan	The size of virtual machine you sell: how many cores, how much memory, how many and how large the disks, how many addresses, which operating systems it offers, and which locations, groups or nodes may host it. A plan is edited on the product that sells it.
Virtual machine	One running guest, built from a plan on a cluster. It may be linked to a billing service (a customer pays for it) or unlinked (you built it for yourself, or it came in from another panel).

Addresses come from IPAM. You may reserve part of your address space for virtual machines and point that space at particular nodes or groups, so a physical server can never be handed an address you were keeping for a virtual one.

Opening the module

In the admin sidebar, open VPS. The entry appears only when the VPS module is switched on for your company and your role grants VPS access. If you do not see it, check Settings → the features list, and ask an administrator about the View VPS Clusters and Edit VPS Clusters permissions.

Note: the VPS module depends on the Locations module. If Locations is switched off, VPS is unavailable no matter how it is set.

The tab strip

Every screen in the module carries the same row of seven tabs across the top, so you can move between them from anywhere — including from a cluster or a virtual machine you have opened.

• Overview — the module dashboard: health, capacity and everything that needs attention.
• Clusters — the list of registered hypervisor machines. See Clusters.
• All VPS — every virtual machine on every cluster. See Virtual Machines.
• Groups — placement and live-migration groups. See Groups.
• Game Hosting — the game-server section of the same module. See Game Hosting Overview.
• Jobs — every instruction the panel has sent to an agent. See Agent Jobs.
• Settings — module-wide behaviour. See VPS Settings.

That is the whole strip. There is no Nodes tab — a node is a cluster, and it is managed on Clusters. There is no Plans tab either — a plan is edited on the product that sells it, and an old link to one lands on Products.

To the right of the tabs sits a Create menu, available on every page of the module. The first two entries — VPS and Game server — open the new-order form filtered to products of that kind, because a customer's server is a service with an invoice and a billing cycle behind it. Below a divider, Node opens the add-cluster form and Group opens the add-group form.

The tab you are on and, on the cluster and virtual-machine screens, the section you have opened are both part of the address in your browser — so a link to one node's health or to one machine's graphs can be pasted straight into a ticket.

The Overview tab

The first screen of the module answers "is anything wrong, and how much room is left". Its heading on screen reads VPS Fleet, with the subtitle Hypervisor health, capacity and virtual machines across every cluster.

Needs attention

A panel at the top lists conditions the module has detected, each marked Critical, Warning or Info, with a link to the affected node or machine. When there is nothing to report it reads Everything looks healthy. The conditions include a disk reporting itself as failing or running low on write life, host memory pressure, memory sold beyond the physical amount, a storage pool filling up, a node that has stopped sending samples, an agent that is offline, a cluster that is frozen or unreachable, failed agent jobs in the last 24 hours, machines in an error state, machines that exist in the panel but not on their hypervisor, adopted machines that are not linked to any service (so nobody is billed for them), and snapshots that are old or stuck.

The thresholds behind most of these are yours to set — see VPS Settings.

Figures and charts

Tiles across the page show the number of clusters, the number of virtual machines (and how many of them are linked to a service), CPU, memory and storage in use against what is sold, current bandwidth, and agent job counts for the last 24 hours. A Capacity headroom tile estimates how many more machines of your average size would fit, and names the resource that runs out first.

Note: capacity figures are measured against what is committed to machines, not against live usage. A stopped machine still holds its memory and its disk.

Below the tiles, a chart labelled Fleet load plots CPU and memory usage and inbound/outbound throughput over the last 24 hours or 7 days, and a Node utilisation table lists every node with its load, what is sold on it and its machine count, sorted by whichever resource is under most pressure. Agents send a host sample every 5 minutes; a break in a chart line is a missing sample, not idle time. An Auto switch refreshes the page every minute and pauses while the browser tab is in the background.

Licence

A chip on the same screen shows how many clusters your licence covers and how many are registered. If you register more clusters than your licence covers, the surplus is frozen. Freezing is not an outage: a frozen cluster keeps every virtual machine running and manageable — power actions, console and delete all still work — and only creating, reconfiguring and adopting machines are refused on it. You choose which clusters freeze first in VPS Settings. Extend the cluster allowance from your License page.

Selling VPS end to end

The path from bare hardware to a customer with a running server has five steps.

1. Register the machine. Add it under Clusters, either by giving the panel SSH details so it installs the agent for you, or by picking an agent you have already installed. See Adding a Hypervisor Node.
2. Put it in a group. A node with no group is invisible to any plan that targets groups. If you did not name one when registering, the panel puts the node in its location's group and creates that group the first time it is needed. See Groups.
3. Create the product and its plan. Add a product in a VPS category under Products. Its VPS Configuration section holds the plan — sizes, disks, addresses, operating systems — plus the placement rules for that product. See VPS Plans.
4. Check where it can be sold. The plan's targeting must admit at least one online node in each location you offer. This is the most common configuration mistake in the module; the worked example is in Groups.
5. Take the order. The customer picks the plan, an operating system, a location and optionally a hostname on the order page, and pays.

What happens between payment and a running machine

Once the order is paid, the platform chooses a node, allocates addresses, and sends a build instruction to that node's agent:

• Candidate nodes are narrowed to those that are active with an online agent in the service's location, then to those the plan's targeting admits, then to those with room under their own sell ceiling. Frozen and draining nodes are never chosen. If the product is pinned to one cluster, that cluster is used or the build is refused.
• Addresses are reserved in IPAM for the machine — as many as the plan's IP count, plus anything the order added.
• The operating system is resolved: the customer's choice at checkout wins, then the product's forced image, then the plan's default.
• The agent creates the disks, seeds them from the chosen image, writes the first-boot configuration (hostname, addresses, resolvers, root password, any SSH keys, and the plan's install script if it has one) and starts the machine.
• When the agent confirms the build, the plan's resource ceilings are applied to the new machine, the service is activated, and the credentials letter goes out.

Warning: the service is only marked active when the agent confirms the build. A machine still building shows as Creating, and its order stays open. Never treat an accepted job as a finished build.

What the customer receives

The customer gets the usual service welcome message, carrying the hostname the machine was built with, its primary address and the root login and password. On their service page in the client portal they see the machine's specification, every address allocated to it, live usage, and the controls you have allowed: power buttons, the console, operating-system reinstall, root-password reset and snapshots are each switched on or off for the whole module in VPS Settings. See Managing Your Services.

Machines you did not sell

A virtual machine does not have to belong to a customer. Machines you create yourself, and machines adopted from a panel you migrated away from, sit in the same lists with no service attached — the panel marks them Unsold and warns about them on the Overview tab, because nobody is being charged for them. You can link one to a billing service at any time from the machine's Settings section, and unlink it again; linking and unlinking is bookkeeping only and never touches the running machine.

Importing an estate from another panel is covered in VPS Panel Migration.

Sharing hardware with another panel

Two FluxBilling panels can share hypervisors: one panel owns the hardware and its agents, and grants a linked panel the right to create and manage its own machines on named clusters. On the borrowing panel those clusters appear as read-only mirrors — the machines are managed normally, but node health, inventory refresh, imports and cluster settings all live on the owner's panel, and the owner's licence covers the hardware. Links between panels are set up under Panel Links.

What the module does not do

These are out of scope. Plan around them rather than expecting them to appear.

• KVM guests only. Container-style virtualisation is not supported. Guests are full virtual machines.
• No scheduled or off-node backups. There are snapshots, which live on the same node's storage as the machine they protect. They are not backups, there is no schedule, no retention policy and no copy anywhere else.
• No automatic failover. If a node dies, its machines are down until it comes back. Live migration exists but is started by an operator, node by node, and only between members of the same group.
• No live migration between groups, locations or panels.
• No per-machine firewall rules. The module attaches an anti-spoofing filter that pins a machine to its own addresses and blocks MAC and ARP spoofing. It is not a configurable firewall.
• Bandwidth figures are informational. Traffic is measured and displayed, and a plan can record a monthly transfer allowance, but nothing throttles, suspends or bills on it. Only the per-machine rate ceilings are enforced, and only on machines where they have been applied.
• No shared-storage or clustered-storage back ends. Disks live on the node's own storage.
• Termination is immediate and final. When a service is terminated the machine is destroyed and its disk is wiped at once. There is no retention window and no undo.
• Automatic start after a node reboot is recorded, not applied. The setting on a machine is a note of your intent for the next operator; the panel does not write it to the hypervisor.
• No file-level access to a guest. The panel can power, console, reinstall and reset a password; it cannot browse or edit files inside a machine.