When working with virtualization environments, especially VMware vSphere, storage design can sometimes be confusing. Terms like SAN, HCI, vCenter, Nutanix, Fiber Channel, RAID, multipathing, and storage controllers are often used together, but they do not all mean the same thing.
This post explains these concepts in a beginner-friendly way.
What Is Hyperconverged Infrastructure?
Hyperconverged Infrastructure, usually called HCI, is an infrastructure design where compute, storage, networking, and virtualization are combined into the same server cluster.
In a traditional virtualization environment, you may have:
ESXi Hosts ---> FC/iSCSI Network ---> SAN Storage
The ESXi hosts run the virtual machines, but the VM disks are stored on a separate SAN.
In a hyperconverged environment, the servers themselves contain the disks, and the HCI software combines the disks from all servers into one distributed storage pool.
Example:
Node 1: CPU + RAM + Disks
Node 2: CPU + RAM + Disks
Node 3: CPU + RAM + Disks
All disks are combined into one shared storage pool
So instead of using an external SAN, the cluster uses the local disks inside the hosts.
Does HCI Use More Disk Space?
Yes, usually it does.
In HCI, VM data is commonly copied or distributed across multiple nodes to protect against failure.
For example, if you create a VM with a 100 GB disk:
100 GB VM disk
With two-way mirroring, it may consume approximately:
100 GB primary copy
+ 100 GB second copy
= 200 GB physical storage
This extra space is used for resiliency.
If one node fails, the VM data still exists on another node.
Common protection methods include:
| Protection Method | Approximate Physical Usage |
|---|---|
| 2-way mirror | 100 GB VM ≈ 200 GB physical |
| 3-way mirror | 100 GB VM ≈ 300 GB physical |
| Erasure coding/parity | More space-efficient, but more complex |
So when sizing HCI storage, never calculate only raw capacity.
For example, this is not enough:
3 nodes × 10 TB = 30 TB usable
Instead, calculate:
Raw capacity
- protection overhead
- reserved free space
- snapshots
- metadata
= safe usable capacity
Nutanix with ESXi and vCenter: Why Use Both?
One common point of confusion is seeing a Nutanix cluster running VMware ESXi with a VCSA VM.
The question is:
If vCenter already exists, why is Nutanix used?
The answer is simple:
vCenter manages VMware. Nutanix provides the hyperconverged storage platform.
They are not doing the same job.
Role of Each Component
ESXi
ESXi is the hypervisor. It runs the virtual machines.
Physical Server → ESXi → VMs
vCenter / VCSA
VCSA stands for vCenter Server Appliance.
It manages the VMware environment, including:
- ESXi hosts
- Clusters
- VMs
- vMotion
- HA
- DRS
- Templates
- Permissions
But VCSA is not the storage system.
Nutanix
Nutanix provides the HCI storage layer.
Each Nutanix node runs a special VM called a CVM, or Controller VM.
The CVMs work together to combine local disks from all nodes into shared distributed storage.
Example:
vCenter / VCSA
|
| manages
|
ESXi Host 1 ESXi Host 2 ESXi Host 3
| | |
CVM 1 CVM 2 CVM 3
| | |
Local disks Local disks Local disks
\ | /
Nutanix Distributed Storage
So in a VMware-on-Nutanix environment:
vCenter manages VMware
Nutanix manages distributed storage
ESXi runs the VMs
CVMs provide the storage layer
Traditional SAN vs HCI
In a traditional SAN design:
ESXi Hosts ---> FC/iSCSI Network ---> SAN Storage
In an HCI design:
ESXi Hosts ---> Local disks combined by HCI software
A simple comparison:
| Area | Traditional SAN | HCI |
|---|---|---|
| Storage location | Separate SAN | Inside the servers |
| Scaling | Add SAN shelves/controllers | Add HCI nodes |
| Complexity | Usually higher | Usually simpler |
| External SAN required | Yes | Usually no |
| VM mobility | Uses shared SAN datastore | Uses distributed HCI storage |
| Example products | EMC, NetApp, HPE 3PAR | Nutanix, VMware vSAN, Azure Stack HCI |
How SAN High Availability Works
SAN high availability is not achieved by one feature only. It is built using several layers.
A good SAN HA design usually includes:
Dual storage controllers
+ RAID protection
+ redundant FC/iSCSI switches
+ multiple host paths
+ multipathing software
+ redundant power
+ backup and replication
1. Dual Storage Controllers / SPs
Enterprise SANs usually have two controllers.
In EMC systems, these are often called:
SP A
SP B
SP means Storage Processor.
If one SP fails, the other SP can continue serving storage.
Example:
ESXi Host
|
|---- Path to SP A
|
|---- Path to SP B
This protects against controller failure.
2. RAID Protection
RAID protects against disk failure.
Common RAID types include:
| RAID Type | Protection |
|---|---|
| RAID 1 | Mirror between disks |
| RAID 5 | Can usually survive one disk failure |
| RAID 6 | Can usually survive two disk failures |
| RAID 10 | Mirroring + striping, good performance and protection |
RAID is important, but RAID alone is not full HA.
RAID does not protect against:
- Storage controller failure
- SAN switch failure
- Power failure
- Site disaster
- Accidental deletion
- Ransomware
3. Redundant FC or iSCSI Switches
A good SAN design does not use only one switch.
Usually there are two separate fabrics:
Fabric A → FC Switch 1
Fabric B → FC Switch 2
Each ESXi host should have one HBA path to Fabric A and another HBA path to Fabric B.
Example:
ESXi Host HBA 1 ---> FC Switch 1 ---> SAN SP A
ESXi Host HBA 2 ---> FC Switch 2 ---> SAN SP B
This protects against switch, cable, HBA, or path failure.
4. Multipathing
When an ESXi host has multiple paths to the same SAN LUN, the host must understand that these are multiple paths to the same storage.
This is handled by multipathing.
Examples:
| Platform | Multipathing Technology |
|---|---|
| VMware ESXi | Native Multipathing Plugin / NMP |
| Windows Server | MPIO |
| Linux | DM-Multipath |
Without multipathing, the host may not fail over correctly if one path goes down.
5. Redundant Power and Hardware
A proper SAN design also includes:
- Dual power supplies
- Dual power feeds
- UPS protection
- Redundant fans
- Redundant shelf controllers
- Redundant SAS paths to disk shelves
High availability is not only about software. Physical hardware redundancy is also important.
6. Replication and Backup
SAN HA is not the same as disaster recovery.
If the whole SAN fails, RAID and dual SPs may not help.
For bigger failures, you need replication to another SAN or another site.
Example:
Primary SAN ---> Secondary SAN
Replication can be:
| Type | Meaning |
|---|---|
| Synchronous | Writes are committed to both sides before success is returned |
| Asynchronous | Writes are copied later with some delay |
However, replication is still not a replacement for backup.
If a VM is deleted or encrypted by ransomware, replication may replicate the bad data too.
You still need proper backup software such as:
- Veeam
- Commvault
- Rubrik
- Dell PowerProtect
- Azure Backup
How to Document SAN Physical Connections
Documenting SAN cabling can be difficult, especially when cables are not labeled or are tied together.
The safest approach is:
Do not start by physically tracing every cable. Start from the logical information.
For Fiber Channel SAN, the best information comes from:
vSphere host HBA WWPNs
+ FC switch login table
+ SAN storage port WWNs
Then you can create an accurate physical map.
Fiber Channel Path Structure
A Fiber Channel path usually looks like this:
ESXi Host HBA port
↓
FC switch port
↓
SAN storage SP port
To document this correctly, you need to identify:
- ESXi host HBA WWPN
- FC switch port where that WWPN is logged in
- SAN storage port WWPN
- FC switch port where the SAN WWPN is logged in
Step 1: Get ESXi HBA WWPNs
In vCenter:
Host > Configure > Storage Adapters
Look for Fiber Channel adapters such as:
vmhba3
vmhba4
Each Fiber Channel adapter has WWN information.
Usually, you will see two values:
Node WWN
Port WWN
For switch mapping, the important one is usually the Port WWN, because that is what appears on the FC switch.
You can also get this from ESXi CLI:
esxcli storage san fc list
Step 2: Check the FC Switch
On a Brocade FC switch, use:
switchshow
This shows each switch port and the WWPN logged into it.
Example:
Port 14 = 10:00:00:90:fa:a9:2d:6e
This means the device with that WWPN is physically connected to switch port 14.
You can also search for a specific WWPN:
nodefind 10:00:00:90:fa:a9:2d:6e
On Cisco MDS switches, similar information can be found using:
show flogi database
Step 3: Match ESXi WWPN to Switch Port
Once you have the ESXi HBA WWPN and the switch output, you can build a table like this:
| Host | HBA | Port WWN | FC Switch | Switch Port |
|---|---|---|---|---|
| ESXi-01 | vmhba3 | 10:00:00:90:xx:xx:xx:01 | FC-SW01 | 14 |
| ESXi-01 | vmhba4 | 10:00:00:90:xx:xx:xx:02 | FC-SW02 | 14 |
This tells you exactly where the ESXi host is connected.
Step 4: Get SAN Storage Port WWNs
In EMC Unisphere, storage port WWNs can usually be found under:
Settings > Network > Settings for Block > Ports
For EMC systems, the WWN field may show two WWNs together.
Example:
50:06:01:60:B6:E0:25:2C:50:06:01:62:36:E0:25:2C
This is usually:
Node WWN: 50:06:01:60:B6:E0:25:2C
Port WWN: 50:06:01:62:36:E0:25:2C
The FC switch normally shows the Port WWN, which is the second WWN.
Step 5: Match SAN WWPN to Switch Port
After identifying the storage port WWN, search for it in the FC switch output.
Example:
SAN SP A Port 2 WWPN = 50:06:01:62:36:E0:25:2C
If switchshow shows that WWPN on port 0, then your mapping is:
SAN SP A Port 2 ---> FC Switch Port 0
Why “Paths” in vCenter Does Not Equal Cables
In vCenter, a Fiber Channel adapter may show multiple paths.
For example:
vmhba3 = 8 paths
This does not mean there are 8 physical cables.
One physical HBA cable can see multiple SAN target ports and multiple LUN paths.
So:
8 paths ≠ 8 cables
It usually means:
One HBA can see multiple storage paths
Troubleshooting Old FC Switch Web Interfaces
Many older FC switches have web interfaces that do not work properly in modern browsers.
You may see issues like:
- Blank page
- Flickering page
- Java errors
- Page opens then closes
- Old TLS/cipher problems
This is common with older Brocade, Dell, or EMC-branded FC switches.
The better approach is to use CLI.
For Brocade:
switchshow
To find a WWPN:
nodefind <WWPN>
To check port details:
portshow <port-number>
CLI is usually faster, more reliable, and more useful for documentation.
Recommended SAN Documentation Table
Before creating a diagram, create a table like this:
| Device Type | Device Name | Adapter/SP Port | WWPN | FC Switch | Switch Port | Status |
|---|---|---|---|---|---|---|
| ESXi Host | ESXi-01 | vmhba3 | WWPN | FC-SW01 | 14 | Online |
| ESXi Host | ESXi-01 | vmhba4 | WWPN | FC-SW02 | 14 | Online |
| Storage | SAN-01 | SP A Port 2 | WWPN | FC-SW01 | 0 | Online |
| Storage | SAN-01 | SP B Port 3 | WWPN | FC-SW02 | 4 | Online |
After this table is complete, drawing the SAN diagram becomes much easier.
Best Practice: Label Cables After Mapping
If the SAN cables are not labeled, avoid unplugging or tracing them during production hours.
Instead:
- Collect ESXi HBA WWPNs.
- Collect FC switch login information.
- Collect storage port WWNs.
- Match everything logically.
- Build the documentation table.
- Physically verify unclear ports only.
- Label both ends of the cables.
Recommended cable labels:
ESXi-01 vmhba3 ↔ FC-SW01 Port 14
ESXi-01 vmhba4 ↔ FC-SW02 Port 14
SAN-01 SP A-2 ↔ FC-SW01 Port 0
SAN-01 SP B-3 ↔ FC-SW02 Port 4
This makes future troubleshooting much easier.
Final Summary
Hyperconverged infrastructure and traditional SAN storage solve similar problems in different ways.
In a traditional SAN environment:
ESXi hosts use external shared storage
In an HCI environment:
ESXi or another hypervisor uses distributed storage from the local disks inside the nodes
vCenter manages VMware, but it does not provide the storage layer. In a Nutanix environment running ESXi, Nutanix provides the distributed storage, while vCenter manages the VMware hosts and VMs.
For SAN high availability, you need multiple layers:
Dual controllers
+ RAID
+ redundant FC switches
+ multiple host HBAs
+ multipathing
+ redundant power
+ backup and replication
For SAN physical documentation, do not start by tracing cables manually. Use WWPNs from vSphere, FC switch login tables, and SAN storage port information to build the map logically.
This approach is safer, faster, and more accurate.