VM Datastore Mapping
VM Datastore Mapping answers the two questions that come up during every storage incident: what is on this datastore, and where does this VM actually keep its data. It maps the relationship in both directions and adds the performance indicators where the platform reports them.
What this screen shows
| Field group | What it contains |
|---|---|
| Mapping | Datastore, VM, vCenter, cluster, ESXi host |
| Usage | Days since last modified, % datastore used, overprovision ratio |
| Performance | LUN IOPS, latency, and throughput where available |
The mapping fields carry the full containment chain, not just the two endpoints. That means a datastore problem can be traced to the cluster and host serving it without opening another screen.
When to use it
- Answering what is on this datastore. Filter to the datastore and every dependent VM lists out. Essential before any maintenance on shared storage.
- Answering where does this VM live. Filter to the VM and its storage placement is immediate.
- Datastore balancing and troubleshooting. The usage indicators next to the mapping tell you whether a move is worth making.
Reading the indicators
- Days since last modified. A long-dormant VM on premium storage is a tiering candidate, and often a decommission candidate nobody has raised.
- Overprovision ratio. How much has been promised against what physically exists. Comfortable until every workload grows into its allocation at once.
- IOPS, latency, throughput. Where the collector supports them. Blank or zero means the platform does not report that field at that scope rather than genuinely no activity.
Tip: Run this screen before scheduling datastore maintenance. The dependent VM list is the blast radius, and it is nearly always larger than the person requesting the window expects.
Related screens
All Units: Datastores identifies which datastores to investigate. VM Summary shows the disk configuration from the VM’s side. Snap / Replication Details covers what else is holding capacity on the underlying array.