VMware ESXi and vSphere Cluster Management
VMware Virtual SAN Requirements
Learn the historical VMware Virtual SAN prerequisites for vCenter, ESXi hosts, local disks, SSD sizing, dedicated networking, bandwidth, and redundancy.
VMware Virtual SAN, also called VMware VSAN in historical documentation, is a software-defined storage capability that combines eligible local disks from multiple ESXi hosts into a shared datastore. Virtual machines on participating hosts can use this distributed storage without relying on a separate external storage array.
These requirements should be validated before enabling Virtual SAN. The design must account for management components, compute hosts, storage-contributing hosts, local disks, and the dedicated storage network.
What must be planned?
A Virtual SAN deployment has several distinct parts:
- vCenter Server: the centralized VMware management platform used to configure, administer, and monitor the cluster.
- ESXi hosts: physical servers running the VMware hypervisor. They provide compute resources and may also provide local storage.
- Virtual SAN cluster: a vCenter-managed group of ESXi hosts that provides pooled, distributed storage.
- Storage-contributing hosts: ESXi hosts with eligible local SSD and hard-disk devices that add capacity to the datastore.
- Compute-only hosts: ESXi hosts that run virtual machines and consume the shared datastore but do not add local Virtual SAN disks.
- Dedicated Virtual SAN network: a network segment and uplink path used for storage communication between participating hosts.
vCenter Server requirement
vCenter Server is required to configure, manage, and monitor a Virtual SAN cluster. Virtual SAN is administered at the cluster level through vCenter Server; it is not independently configured as a datastore managed by only one ESXi host.
Plan for vCenter availability and reliable connectivity before enabling Virtual SAN. The hosts must be visible in the correct vCenter inventory, organized into the intended cluster, and reachable by the management services used to configure the feature.
ESXi host count and cluster sizing
The historical guidance specifies a minimum of three ESXi hosts and a historical maximum of eight ESXi hosts for a Virtual SAN cluster.
Multiple hosts are necessary because Virtual SAN aggregates storage across servers, places storage objects across hosts, and supports continued operation when a host or path fails. A single host cannot provide the same distributed storage and host-level resilience model.
These limits are tied to the referenced Virtual SAN release. Current releases may have different limits, architectures, or requirements, so verify the deployed version's compatibility documentation before creating or expanding a cluster.
Supported ESXi version
The historical minimum stated for Virtual SAN is ESXi 5.5 or later. Every host in the design must run a compatible ESXi release and use hardware supported by that release.
Do not assume that any mixture of ESXi versions is safe. Mixed-version clusters may be permitted only during carefully planned upgrade transitions, and unsupported combinations can prevent configuration or cause operational problems. Confirm ESXi, vCenter, storage-controller, disk, and network compatibility before implementation.
Dedicated Virtual SAN network
Virtual SAN requires a separate network path for storage traffic. This traffic includes storage-object access, replication, synchronization, and recovery operations between participating hosts.
All cluster members must have consistent connectivity to this network. A common design uses a dedicated VLAN or network segment so Virtual SAN traffic is separated from management, vMotion, and virtual-machine traffic. Isolation reduces contention and makes troubleshooting easier, although the physical switching and routing design must still provide the required connectivity.
Bandwidth and latency planning
The historical guidance identifies 1 Gbps as usable and recommends 10 GbE for stronger performance. A 10 GbE connection is a 10-gigabit Ethernet link with substantially more throughput for storage operations.
Insufficient bandwidth can increase storage latency and extend rebuilds and synchronization. During a disk or host failure, recovery traffic competes with normal virtual-machine I/O; a congested link can therefore affect both recovery time and workload performance.
Network redundancy
The stated design guidance requires two physical NICs for network fault tolerance. A NIC, or network interface controller, connects an ESXi host to the network.
Redundancy should be considered at multiple levels:
- Use two physical NIC paths for each host's Virtual SAN network.
- Use redundant cables and, where appropriate, separate physical switches.
- Design switch uplinks so one adapter, cable, or switch failure does not isolate a host.
- Keep VLAN, teaming, MTU, and uplink settings consistent across all hosts.
Two NICs do not automatically guarantee end-to-end availability. The physical switches, uplinks, and host configuration must also avoid a single point of failure.
Local storage requirements
Each storage-contributing host in the historical hybrid Virtual SAN model needs at least:
- One SSD, or solid-state drive.
- One magnetic hard disk, commonly called an HDD.
The SSD provides the flash tier used by the storage design, while HDDs provide persistent capacity in the historical hybrid model. The exact role and behavior of these devices depends on the Virtual SAN release and its disk-group architecture, so validate device eligibility rather than relying only on drive type.
These disk requirements apply to hosts that contribute local storage. A host that only consumes the datastore does not necessarily need local Virtual SAN disks.
SSD capacity sizing
The historical requirement is that SSD capacity equal at least 10 percent of total storage capacity. Use the capacity included in the planned Virtual SAN design, not merely the capacity of a single virtual machine.
For a simple calculation:
Minimum SSD capacity = planned total storage capacity × 0.10For example, if a storage-contributing host has 8 TB of planned total local storage capacity:
8 TB × 0.10 = 0.8 TBThat host therefore needs at least 0.8 TB of SSD capacity under the stated historical threshold, subject to the release's disk-group rules and the selected sizing approach. Recalculate the ratio when adding HDD capacity. This 10 percent value is a historical planning threshold, not a substitute for workload-based sizing.
Storage-contributing hosts and compute-only hosts
A host can join the cluster without local disks configured for Virtual SAN. If it has suitable network connectivity, it can run virtual machines whose files reside on the distributed datastore provided by other hosts.
| Host role | Local SSD and HDD required | Contributes datastore capacity | Can run virtual machines | Network participation |
|---|---|---|---|---|
| Storage-contributing ESXi host | Yes, at least one SSD and one HDD in the historical hybrid design | Yes | Yes | Dedicated Virtual SAN connectivity and redundant NIC paths |
| Compute-only ESXi host | No local Virtual SAN disks required | No | Yes, using the shared datastore | Must reach the Virtual SAN network and cluster services |
Compute-only hosts do not increase Virtual SAN capacity or add local disk performance resources. Include them in compute, network, and failure planning, but do not count their unused local disks as storage capacity.
Historical Virtual SAN prerequisite summary
| Requirement area | Historical requirement | Planning rationale | Validation action |
|---|---|---|---|
| Management platform | vCenter Server | Cluster-level configuration, administration, and monitoring | Confirm vCenter availability, connectivity, permissions, and cluster inventory |
| Cluster size | Minimum three hosts; historical maximum eight hosts | Storage aggregation, object availability, and host-failure resilience | Count hosts and check the limit for the target release |
| Hypervisor | ESXi 5.5 or newer | Provides the supported virtualization platform | Verify compatible ESXi, vCenter, and hardware versions |
| Networking | Dedicated Virtual SAN network | Carries replication, synchronization, and storage access traffic | Verify consistent VLAN or network-segment connectivity |
| Bandwidth | 1 Gbps usable; 10 Gbps recommended | Higher throughput improves normal I/O and recovery operations | Check link speed, congestion, and workload demand |
| Network resilience | Two physical NICs | Reduces impact from an adapter, cable, or path failure | Verify redundant NIC, switch, and uplink design |
| Host storage | At least one SSD and one HDD per storage-contributing host | Provides flash and persistent capacity media in the hybrid model | Inventory eligible local devices on each storage host |
| Flash sizing | SSD capacity at least 10 percent of total storage capacity | Provides the historical flash-tier planning baseline | Calculate the ratio after all planned capacity disks are included |
| Compute-only participation | Permitted without local storage | Allows compute expansion without adding datastore capacity | Classify each host explicitly during design |
Network option comparison
| Design characteristic | 1 GbE approach | 10 GbE approach | Operational consideration |
|---|---|---|---|
| Bandwidth | Meets the basic historical guidance | Provides substantially more throughput | Measure workload and recovery requirements rather than choosing by link speed alone |
| Suitability | May suit modest or lower-demand designs | Recommended for stronger performance and heavier traffic | Account for concurrent virtual-machine I/O and rebuild traffic |
| Rebuild and synchronization impact | Can take longer and compete more readily with workload traffic | Usually provides more recovery headroom | Monitor latency and congestion during failure testing |
| Recommended NIC redundancy | Two NIC paths are still required by the stated guidance | Use two NIC paths and redundant switching where possible | Bandwidth and redundancy solve different problems |
Reference deployment examples
Minimum all-storage cluster
A baseline historical design contains three ESXi hosts managed by vCenter Server. Each host contributes at least one SSD and one HDD and has two NICs assigned to the dedicated Virtual SAN network. The network uses 10 GbE uplinks to provide higher throughput and a redundant path design.
This example includes the management, host-count, local-storage, and network elements required for the historical minimum deployment.
Adding a compute-only host
Suppose three storage-contributing hosts already provide the datastore. A fourth ESXi host can join the cluster with no local disks configured for Virtual SAN. It can run virtual machines stored on the distributed datastore, but it does not add storage capacity or local disk performance resources.
Comparing 1 GbE and dual 10 GbE
A dedicated 1 GbE network may satisfy the basic historical requirement. A dual-10-GbE design provides higher throughput and a second physical path, reducing the effect of congestion or a single adapter failure. The choice should consider workload I/O, rebuild traffic, synchronization, latency, and switch redundancy.
Pre-deployment validation checklist
- Confirm that vCenter Server is available, reachable, and managing the intended cluster.
- Verify that the planned ESXi release is supported and that all hosts have compatible versions and hardware.
- Confirm that the cluster meets the applicable host-count limits; the historical baseline is three hosts, with eight as the referenced maximum.
- Inventory local disks on every intended storage-contributing host.
- Confirm at least one eligible SSD and one eligible HDD per storage-contributing host in the historical hybrid design.
- Calculate SSD capacity as at least 10 percent of planned total storage capacity under the historical rule.
- Create or identify a dedicated Virtual SAN VLAN or network segment.
- Verify consistent connectivity among all cluster members.
- Provide the required bandwidth: 1 Gbps is the historical usable baseline, while 10 GbE is recommended.
- Configure two physical NIC paths per host and review switch, cable, and uplink redundancy.
- Classify every host as storage-contributing or compute-only.
- Recheck capacity and fault-tolerance assumptions when one host or one network path is unavailable.
Configuration checklist
- Create or identify the dedicated network segment for Virtual SAN traffic.
- Assign Virtual SAN networking to redundant physical NICs on every participating host.
- Make eligible SSD and hard-disk devices available on each storage-contributing host.
- Confirm the SSD-to-total-storage ratio meets the historical minimum.
- Create or select a supported ESXi cluster in vCenter Server before enabling Virtual SAN.
- Record the intended role of each cluster member as storage-contributing or compute-only.
No specific command-line syntax is required for this planning-focused lesson. Validation is normally performed through vCenter inventory, host hardware information, network configuration, and release-specific compatibility guidance.
Troubleshooting common planning failures
Virtual SAN cannot be managed or enabled
Likely causes include unavailable vCenter Server, unreachable management services, or hosts that are not organized into the correct vCenter-managed cluster.
- Confirm vCenter Server connectivity.
- Verify that all intended hosts appear in the correct cluster inventory.
- Check that the administrator has access to that cluster.
A host cannot contribute storage
The host may lack an eligible SSD or hard disk, may have been intentionally designed as compute-only, or may use an unsupported ESXi version or storage controller.
- Inventory local disks by host.
- Confirm the intended host role.
- Validate ESXi, controller, disk, and hardware compatibility for the target release.
Storage traffic performs poorly or fails after an adapter failure
Common causes include congested shared networking, only one NIC assigned to Virtual SAN, insufficient bandwidth, or inconsistent switch and VLAN settings.
- Verify the dedicated network and consistent VLAN connectivity.
- Confirm two NIC paths for every host.
- Review physical switch and uplink redundancy.
- Assess whether 10 GbE is appropriate for the workload and recovery demand.
The SSD sizing rule is not met
SSD capacity may be below 10 percent of planned total storage, or newly added HDD capacity may have been omitted from the calculation.
SSD percentage = SSD capacity ÷ total planned storage capacity × 100Recalculate using all planned capacity devices, then resize the SSD tier or reduce planned capacity as appropriate.
The cluster has too few or too many hosts
A design with fewer than three hosts does not meet the referenced historical minimum. A design exceeding eight hosts may exceed the historical limit. Count participating ESXi hosts and confirm the applicable limits for the actual Virtual SAN release before deployment or expansion.
Exam-relevant points
- vCenter Server is required for Virtual SAN configuration and management.
- The referenced historical minimum is three ESXi hosts, and the historical maximum is eight.
- The referenced historical minimum ESXi version is 5.5.
- Virtual SAN traffic requires a dedicated network path.
- 1 Gbps is identified as usable historical guidance; 10 GbE is recommended.
- Two physical NICs provide the stated network fault-tolerance design.
- Each storage-contributing host needs at least one SSD and one HDD in the historical hybrid model.
- The historical SSD planning threshold is at least 10 percent of total storage capacity.
- A compute-only host can consume the datastore but does not contribute capacity.