Virtualization

The screen answers one question: what do we run, on what version, and until when is it supported. The question of how much headroom is left after a host failure is answered on a different screen — Compute clusters, under Capacity management — and the two screens point at each other in words.

Screen	The question it answers
Virtualization	What is installed, on what version, which plane manages it, and when support ends
Compute clusters (Capacity management)	Does the cluster have headroom after a host failure, and can a given host be evacuated

There is not one capacity metric on this screen. No memory commitment, no allocation ratio, no failover headroom, no power draw. Those analytics belong to Capacity management and sit behind a separate permission; repeating them here would both give away a licensed metric and turn this into a second copy of the other screen.

The columns

Column	What it says
Cluster name	The cluster's identity, and its record key
Platform	VMware ESXi, Microsoft Hyper-V… — as the hosts report it
Version	The platform version, as the hosts report it
Support ends	The recorded date; turns red once it has passed
Management plane	The name of the management-plane record that runs the cluster
Site	Where the hosts sit
Status	The five status values shared across infrastructure
Hosts	How many hosts are in the cluster
Guests	How many virtual machines run on them
HA policy	The admission-control policy, in the management plane's own words
DRS mode	The automatic balancing mode, in the management plane's own words
Owning team	Who is responsible for the cluster

The last three columns — HA policy, DRS mode and Owning team — are not in the default set. They are added through the column picker, and they are always in the export.

The HA policy and the DRS mode are text, not yes/no. Both are settings with several values — an admission-control policy is N+1, slotPolicy, a percentage or Disabled, and a DRS mode is whatever the management plane writes, fullyAutomated for instance — and folding them into a boolean would throw away exactly the half a patching team needs: HA being on says nothing about whether it will admit the guests of the host you are about to reboot.

The values are written as the management plane writes them. Disabled is the exception: that is the product's reading rather than a platform token, so it alone is translated.

A mixed cluster stays mixed

When a cluster's hosts report two platforms or two versions, the column shows both, comma-separated — it does not pick the more common one. A cluster running two versions is precisely the finding a patching team is looking for, not noise worth smoothing over.

Where the rows come from

Half the columns are derived from the server inventory: which hosts are in the cluster, how many guests are on them, which platform and version they report, and which site they are at. Those columns are read-only for everyone, administrators included, because they are a reflection of an inventory another team owns.

What no inventory knows — the support end date, the management plane, the HA and DRS settings, the owning team — is recorded on the card.

The management plane is a peer of the cluster, not its parent: one plane holds many clusters. It has no screen of its own; it renders inside the cluster card and as a node on the connection map.