Virtual Overview
The Virtual section covers compute: vCenters, data centers, clusters, ESXi hosts, virtual machines, datastores, and the VMDK files underneath them. It answers three questions that usually live in three different tools. How much headroom is left, where is the waste, and what is it costing.
The object hierarchy
Every report in this section sits somewhere on one containment chain, and most drill-downs follow it: Environment or vCenter scope, then Data Center, then Cluster, then Host, then Virtual Machine, with Datastore and VMDK hanging off the storage side. Knowing which level a report operates at tells you what it can and cannot answer.
Four terms worth learning first
| Term | What it means |
|---|---|
| Capacity Score | A 0 to 100 indicator of balance and utilization health |
| Weeks Left to Capacity | Estimated runway until a constraint is reached |
| Build Capacity | How many more VMs fit given CPU, memory, and disk headroom. It can go negative |
| Capacity Constraint | The resource that runs out first. In most environments it is memory |
Negative build capacity is the one to internalize. It means at least one constraint has already been exceeded, and it should be read as a hard stop on new workload placement rather than a number to average away.
The reports in this section
| Report | What it answers |
|---|---|
| Virtual Summary | Documentation in progress |
| All Units: Clusters | Which clusters are closest to capacity, and what is constraining them |
| All Units: Datastores | Storage hot spots and underused datastores across the estate |
| All Units: Hosts | Which ESXi hosts are overloaded and which are idle |
| All Units: VMs | The full VM inventory, with utilization categories and cost tiers |
| Virtual Environment | Environment and vCenter comparison via cluster cards |
| Health Alerts | What needs attention today, with acknowledgment and escalation |
| Orphaned VMDKs | Virtual disks attached to nothing, and how much they are costing |
| VM Datastore Mapping | What lives on this datastore, and where does this VM store its data |
| Virtual Trends | How the estate has grown, and what that implies about headroom |
| Cluster Plans Summary | Documentation in progress |
| Delta Report | Exactly what changed between two dates, and by how much |
| VM Summary | Everything about one virtual machine, including its cost breakdown |
| Cluster Summary | One cluster’s health, limiting factor, and build capacity |
| Cluster Trends | When a cluster’s headroom started disappearing |
| Cluster Modeling | What happens to runway and cost if you add hosts in a given month |
| ESX Host Summary | One host’s hardware, constraint, cost, and resident VMs |
| VM Right-Sizing | Recommended allocation changes, with an approval workflow |
Portfolio screens versus deep dives
The section splits cleanly in two. Portfolio screens, meaning the All Units views, Virtual Environment, Trends, and Delta, look across everything and are where you decide what deserves attention. Deep dives, meaning VM Summary, Cluster Summary, Cluster Trends, Cluster Modeling, and ESX Host Summary, take a single object as a parameter and are where you build the case for a decision. The normal path is portfolio first, deep dive second.
How data gets here
Collection is agentless. Visual One reads configuration and instrumentation rather than running workload-intensive agents on production systems, so collection is not a performance consideration. Most screens carry a Collection Date selector controlling which snapshot you are reading, which is what makes before-and-after comparison around a maintenance window possible.
Note: Performance fields such as IOPS, latency, and throughput depend on what the underlying device and collector expose. Blank or zero values in those columns usually mean the platform does not report them at that scope, not that the value is genuinely zero.