Hosts Overview
Purpose: Storage seen from the host’s side rather than the array’s. Which hosts are attached to which arrays, how their LUNs are provisioned, what performance they are getting, and what would happen if you moved them somewhere else.
How this differs from the Storage section
Storage reports from the array outward: pools, volumes, capacity, and efficiency per device. Hosts reports from the consumer inward: what each server sees, what it is attached to, and how it performs.
That difference matters when troubleshooting. An array reporting healthy capacity and low latency can still be serving one host badly, and only a host-side view finds it. It also matters for migration, because the unit you move is a host and its LUNs, not a pool.
The reports in this section
| Report | What it answers |
|---|---|
| Enterprise Host Summary | How the host estate is provisioned, and which hosts have latency or IOPS problems |
| Host and Device Capacity Modeling | What happens to performance and capacity if a host moves to a different array |
| Host LUNs | Every LUN presented to every host, with per-LUN capacity and performance |
Common actions
The normal path runs summary to detail to decision. Enterprise Host Summary finds the hosts worth looking at, Host LUNs shows exactly which LUN is responsible, and Capacity Modeling tests whether relocating the workload would fix it.
Tips
This section carries host names, array names, fully-qualified domain names, and world wide names. A WWN plus a hostname is enough to identify a specific SAN endpoint, so redact both before sharing anything from these screens.
Related screens
All Units is the array-side equivalent inventory. Switches covers the fabric between host and array, which is where a latency problem that neither side explains usually lives. ESX Host Summary covers hypervisor hosts specifically.