Compute clusters

The screen answers one question: if a host dies tonight, does anything stop? The answer is the memory allocated to the cluster's guests, against the physical memory that remains once the largest host is gone.

The table is sorted by utilization after failure, descending, on arrival — so the worst cluster is the first row without anyone touching a control. A cluster with no failover verdict sorts last, not first: "we cannot say" is not "it is fine", and it is certainly not "it is the worst".

How utilization after failure is computed

Committed guest memory, divided by the cluster's physical memory minus its N largest hosts. The default is N+1 — one host — and it is editable in settings: an organization planning N+2 sets 2, and one that keeps no reservation at all sets 0.

• A single-host cluster gets no percentage. There is nothing to subtract, and the screen prints the reason instead of a number.
• Host overhead ships at zero. The hypervisor itself consumes memory and the system cannot know how much; while the value is zero the screens carry the sentence "host overhead not taken into account". An administrator who knows the figure for their own environment enters it, and the sentence disappears.
• A guest whose host is not in the inventory is still counted in the totals and reported separately in the header, rather than dropped silently.

The table columns

Column	What it says
Cluster	The cluster name. Clicking opens the cluster record
What binds	The resource closest to its threshold — memory, the rack's circuit or rack units
Hosts · Guests · Consolidation ratio	The cluster's composition
Committed memory · Memory utilization	What is allocated to guests, and the same figure against physical memory
Utilization after failure	The screen's headline metric
Failover margin	How much memory is left free after the failure, in GB
More machines	The margin divided by the cluster's average guest size — how many more machines fit
vCPU:pCPU ratio	Shown, never colored
Out of warranty	The share of the cluster's physical memory sitting on hardware whose warranty has expired
Site · Platform · Racks · Systems	Placement

The vCPU:pCPU ratio is plain text everywhere in the product, never a colored badge, with the organization's own planning target shown beside it as a reference. The vendor's own guidance states that there is no accepted ratio and that thinking in ratio terms causes operational problems; a red badge on a given ratio repeats a convention the vendor has published as wrong.

The cluster record

Clicking a row opens the cluster record. It is the only URL in the product that describes a cluster, and the rows on the virtualization screen open it too.

Tab	What is in it
Overview	The capacity bar (committed · reserved for redundancy · free), cluster composition, hardware risk, the systems it carries and the racks its hosts sit in
Hosts	Host, rack, model, cores, memory, guests, warranty and status. Clicking opens the host record
Guests	Machine, system, criticality, host, vCPU, memory, disk and environment
Maintenance windows	Cluster collisions and evacuation checks — the tab this module exists for
Trend	The daily series, once there are enough days

The virtualization screen and this one are not the same screen: the first answers what do we run, on what version, and until when is it supported, and this one answers is there headroom if a host falls, and can a host be evacuated. There is not one capacity metric on the virtualization screen.

The evacuation check before a window

To patch a hypervisor host, its machines have to be moved to the rest of the cluster first. The check is the same arithmetic as utilization after failure, aimed at a specific host on a specific date rather than at the worst case — which is what turns a capacity number into a pre-flight check on a change that is already scheduled.

The check is scoped to the cluster and never to the site. Two hosts can share a site, a rack and a hall and belong to different clusters, in which case neither can take the other's guests.

The same check runs inside the scheduling wizard, at the date and time step, and in the event editor:

• It never blocks a save.
• It does not render at all when no selected server is a hypervisor host — which is most windows.
• An answer that is not known renders as "Unknown" in the quiet tone. A server not in the inventory, a host with no cluster and missing physical placement data each return a reason, not an error.
• A window with more than twelve servers does not run a check per host; it says so instead.

Cluster collisions

Two hosts of the same cluster in overlapping windows are an N-2 event: the cluster runs on fewer hosts while the update is in flight, and if a third host falls there is no plan. The ordinary collision engine cannot see this — it matches on linked systems, and all hypervisor hosts belong to the same system, so it would equally warn about two different clusters at two different sites. The failure domain is the cluster, not the system name.