VMware ESXi and vSphere Cluster Management

VMware Virtual SAN Requirements

Learn the vCenter, ESXi, host, storage, networking, compatibility, and capacity requirements for planning a VMware vSAN deployment.

VMware Virtual SAN, now commonly called vSAN, is a distributed storage platform that aggregates eligible local disks from multiple ESXi hosts into a shared datastore. Virtual machines can use that datastore as shared storage while data is distributed across the cluster.

Successful deployment requires more than a few disks in each server. Plan and validate four requirement groups: management, compute and cluster membership, storage, and networking. Always check the vSAN release, vSphere interoperability guidance, and the VMware Compatibility Guide that apply to your environment. Older release limits and hardware rules must not be assumed to apply to newer versions.

How vSAN deployment is organized

A vSAN cluster is a group of ESXi hosts configured to provide distributed vSAN storage. A host may contribute local disks, compute resources, or both. vSAN places and protects virtual-machine data across participating hosts according to storage policies and the capabilities of the cluster.

vSAN is configured at the cluster level. It is not independently enabled and managed as a shared datastore on unrelated standalone ESXi hosts. The usual workflow is to install or make available vCenter Server, create a cluster, add compatible ESXi hosts, configure their networking and disks, and then enable vSAN through vCenter.

vCenter Server requirement

vCenter Server is the centralized VMware management platform used to create, configure, monitor, and manage a vSAN cluster. It provides the cluster inventory and management context needed for vSAN configuration, health monitoring, host coordination, and datastore administration.

Before deployment, verify that vCenter is available and that the intended ESXi hosts are added to the correct cluster. For background, see installing vCenter Server and adding an ESXi host to vCenter inventory.

ESXi host count and cluster membership

The referenced deployment baseline uses at least three ESXi hosts for standard vSAN availability. Multiple hosts are important because vSAN distributes data and its replicas or erasure-coded components across hosts. A single host cannot provide the same host-level resilience.

The historical planning limit for the referenced environment is up to eight ESXi hosts. Treat that number as release-specific historical guidance, not a universal current limit. Supported cluster-scale limits depend on the vSAN version and edition, so verify the current documentation before designing a production cluster.

Every host intended to join the cluster must have compatible software, network connectivity, and configuration. A host can be storage-contributing or compute-only, but it must still be a supported member of the vSAN cluster.

ESXi software and hardware compatibility

The baseline stated for the historical deployment context is ESXi 5.5 or later. Hosts in the same cluster must use compatible ESXi versions. In a current deployment, do not select a version solely because it meets that old baseline.

Validate the complete combination of:

ESXi and vCenter Server versions
Storage controllers and controller modes
SSDs, hard disks, and other storage devices
NIC models, drivers, and firmware
Server firmware and vendor-supported configurations

Use the VMware Compatibility Guide and applicable interoperability guidance before production use. Disk-count compliance alone does not make a controller, disk, driver, or firmware combination supported.

Dedicated vSAN network

vSAN storage traffic requires a dedicated network path or a dedicated network configuration. On each participating ESXi host, configure a VMkernel adapter for vSAN traffic. A VMkernel adapter is an ESXi network interface used for host services such as vSAN communication.

Design the network so that all participating hosts have consistent, reliable, host-to-host reachability. Use the intended VLAN or physically separate network, document the VLAN and switch configuration, and prevent unrelated traffic from congesting the vSAN path. Low latency and sufficient bandwidth are important because reads, writes, resynchronization, and health operations use the vSAN network.

The vSAN VMkernel configuration should be present and functional on every host that participates in vSAN. Test reachability and failover before enabling the datastore.

Bandwidth and network redundancy

1 GbE is identified as usable for the referenced deployment. It may be functional for suitable workloads, but it provides less headroom for intensive storage traffic, resynchronization, and growth. 10 GbE is the preferred speed for improved performance and reduced congestion risk.

The recommended design uses two physical NICs for vSAN connectivity where available. Redundant uplinks reduce the effect of a failed NIC, cable, switch port, or switch path. Redundancy is useful only when the cabling, VLANs, switch configuration, teaming, and failover behavior are also correct.

Network characteristic	Usable baseline	Preferred design	Availability and performance effect
Bandwidth	1 GbE	10 GbE	Higher bandwidth provides more room for workload traffic and resynchronization.
Physical NIC count	One functioning path	Two physical NICs per host	Two uplinks reduce the impact of a single adapter or physical-path failure.
Traffic separation	Explicitly configured vSAN traffic path	Dedicated or carefully isolated VLAN and switching design	Isolation limits congestion and improves troubleshooting.

Local storage device requirements

Each storage-contributing host needs eligible local storage. In the referenced hybrid configuration, the baseline is at least:

One supported SSD per storage-contributing host
One supported hard disk or other supported capacity disk per storage-contributing host

In that historical hybrid design, the SSD supplies the flash or cache component and the hard disk supplies capacity. The devices must be connected through a supported controller and must appear as eligible for vSAN use. Confirm device model, controller mode, firmware, driver, and disk ownership before claiming the devices.

Modern vSAN releases can support additional storage architectures and requirements. Therefore, use the stated SSD-plus-hard-disk layout as the referenced baseline, then verify the exact disk-group and device rules for the selected release.

Flash capacity sizing

The referenced design requires SSD capacity of at least 10 percent of total planned raw storage capacity. The basic calculation is:

Minimum SSD capacity = planned raw capacity × 0.10

For example, if planned raw capacity is 30 TB:

30 TB × 0.10 = 3 TB minimum SSD capacity

This is a baseline calculation, not a complete performance design. Review workload characteristics, resiliency overhead, expected growth, resynchronization behavior, usable capacity after policies, and version-specific sizing guidance. Make sure the SSD capacity is distributed appropriately among the storage-contributing hosts and disk groups.

Storage-contributing and compute-only hosts

A vSAN cluster does not require every host to supply local disks. A storage-contributing host has eligible local disks claimed by vSAN. It adds compute resources, local storage capacity, and potential disk performance to the cluster.

A compute-only host is an ESXi host that runs virtual machines and consumes the shared vSAN datastore but does not supply local vSAN storage. It can increase available CPU and memory without increasing vSAN capacity or disk performance.

Host role	Contributes local disks	Runs virtual machines	Adds storage capacity	Example use
Storage-contributing host	Yes	Yes	Yes	Add a compatible ESXi server with an SSD and capacity disks to expand compute and vSAN resources.
Compute-only host	No	Yes	No	Add compute capacity while using the existing shared vSAN datastore.

Compute-only expansion is useful when CPU or memory is needed but additional storage is not. However, it does not replace a storage-contributing host when the design needs more capacity, cache, or disk throughput.

vSAN requirement checklist

Requirement area	Baseline requirement	Recommended approach	Reason for requirement
Management platform	vCenter Server	Use a supported vCenter and manage hosts in one intended cluster	vCenter provides vSAN configuration, monitoring, and cluster management.
Host count	Three hosts for the referenced standard availability design	Confirm the current release limit and resilience design	Multiple hosts allow distributed placement and resilience.
ESXi version	ESXi 5.5 or later in the historical context	Use mutually compatible, currently supported ESXi and vCenter versions	Compatibility is required for cluster operation and supportability.
vSAN network	Dedicated or explicitly configured vSAN path with VMkernel networking	Use an isolated VLAN or dedicated network with tested reachability	Storage traffic needs predictable connectivity and low latency.
Network speed	1 GbE usable in the referenced requirements	Prefer 10 GbE	More bandwidth improves performance headroom and resynchronization.
NIC redundancy	One working path can function	Use two physical NICs per host	Redundancy limits the effect of a single physical failure.
Per-host storage devices	At least one SSD and one capacity hard disk on each storage-contributing host	Use supported devices and controllers	Provides the flash and capacity components of the referenced hybrid layout.
SSD capacity ratio	At least 10 percent of planned raw capacity	Include workload, resilience, growth, and release-specific sizing	Flash capacity affects caching and storage behavior.
Hardware compatibility	Supported disks, controllers, NICs, drivers, and firmware	Check the VMware Compatibility Guide before deployment	Unsupported combinations can prevent disk use or invalidate support.
Compute-only hosts	Permitted without local vSAN disks	Use only when extra compute, not storage, is required	Compute-only hosts add CPU and memory but no vSAN capacity or disk performance.

Configuration sequence before enabling vSAN

Confirm that vCenter Server is available and that its version is compatible with the planned ESXi release.
Create the vSAN cluster in vCenter and add the intended compatible ESXi hosts.
Classify each host as storage-contributing or compute-only.
Create or identify a VMkernel adapter for vSAN traffic on every participating host.
Place the adapters on the intended dedicated network or VLAN and verify host-to-host reachability.
Assign the planned physical uplinks, preferably two NICs per host, and document teaming and failover behavior.
On each storage-contributing host, verify one eligible SSD and the required capacity disks.
Validate controller, disk, NIC, driver, and firmware support against the VMware Compatibility Guide.
Calculate SSD capacity using the 10 percent baseline, then review workload and resiliency sizing.
Claim eligible disks and enable or configure vSAN through vCenter.

Planned raw capacity: 30 TB
Minimum flash baseline: 30 TB × 0.10 = 3 TB
Network baseline: 1 GbE usable
Preferred network: 10 GbE with two physical NICs per host

Troubleshooting common prerequisite failures

vSAN cannot be enabled or managed

Likely causes include unavailable vCenter Server, incorrect cluster membership, or incompatible host software. Confirm vCenter connectivity, verify that all hosts are in the intended cluster, and compare ESXi and vCenter versions with current interoperability guidance. Review communication between vCenter Server and ESXi if management connectivity is uncertain.

A host cannot contribute disks

Check that the host has an eligible SSD and capacity disk. Then verify controller, disk, driver, and firmware support in the VMware Compatibility Guide. Also check whether the disk is already in use, claimed by another service, or otherwise ineligible. Having the correct number of disks does not prove that the configuration is supported.

vSAN performance is poor or the network is congested

Measure link speed and utilization, confirm that vSAN traffic is separated from congested traffic, and test end-to-end reachability. Recalculate flash capacity and review workload sizing if the flash tier is undersized. A functional 1 GbE network may still be inadequate for a demanding workload; 10 GbE is the preferred design.

Connectivity is lost after an uplink failure

Confirm that two physical NICs are assigned as intended and that both links, cables, switch ports, VLANs, and teaming settings are correct. Test failover rather than assuming that two installed NICs automatically provide redundancy.

An added compute host does not increase datastore capacity

The host is probably compute-only and has no local disks claimed by vSAN. Confirm its host role and disk-contribution status. Add supported local storage only if the design requires additional vSAN capacity or disk performance.

Exam-relevant notes

vSAN is managed through vCenter Server and configured at the cluster level.
The referenced standard availability baseline uses three ESXi hosts.
The referenced historical environment identifies up to eight hosts; current scale limits are release-specific.
ESXi 5.5 or later is the stated historical software baseline, not a current production recommendation.
vSAN traffic uses a VMkernel adapter and requires a dedicated or explicitly isolated network path.
1 GbE is usable in the referenced requirements; 10 GbE is preferred.
Two physical NICs provide recommended network fault tolerance.
The referenced hybrid layout uses at least one SSD and one capacity hard disk per storage-contributing host.
The stated flash baseline is 10 percent of planned raw capacity.
A compute-only host adds compute resources but not local vSAN capacity or disk performance.
Always validate the entire hardware and software combination with the VMware Compatibility Guide.