VMware ESXi and vSphere Cluster Management

Configure VMware vSAN in a vSphere Cluster

Learn how to plan, configure, claim storage, validate, and operate VMware vSAN in a vSphere cluster.

VMware vSAN is distributed storage technology that aggregates local storage devices from multiple ESXi hosts into a shared datastore. Instead of connecting each host to a separate external storage array, vSAN presents storage contributed by the hosts as the vSAN datastore.

This lesson covers planning, network preparation, cluster configuration, disk claiming, validation, and post-configuration operations. Exact menus and storage workflows vary by vSphere and vSAN release, so use the procedures supported by the version installed in your environment.

Understand vSAN architecture

An ESXi host is the hypervisor server that runs virtual machines and can contribute local disks to vSAN. A vSphere cluster is a logical collection of ESXi hosts managed together by vCenter Server. vSAN is configured at the cluster level, not as an isolated datastore on one host.

After participating hosts contribute compatible local devices, vSAN combines those devices into a distributed storage pool and presents a shared vSAN datastore. Virtual machine files are stored as distributed objects across the hosts. A storage policy determines how those objects should be placed and protected, including availability and performance requirements.

All participating hosts must be able to communicate over a vSAN-enabled VMkernel adapter. A VMkernel adapter is an ESXi interface used by host services such as management, vMotion, and vSAN traffic. vSAN traffic includes storage data, metadata, health information, and resynchronization operations.

The relationship can be summarized as follows:

ESXi hosts: run virtual machines and contribute local storage and network resources.
vSphere cluster: groups the hosts and provides the configuration scope for vSAN.
vSAN datastore: presents the pooled local storage as shared storage to the cluster.
Virtual machines: consume storage from the vSAN datastore.
Storage policies: define the protection and performance rules applied to VM storage objects.

Plan prerequisites and compatibility

Before enabling vSAN, confirm that the design is supported and that the cluster has enough resources for both normal operation and failures.

Requirement — Why It Matters — Validation Method — Planning Notes

vCenter-managed ESXi hosts — vSAN is configured through vCenter Server at the cluster level — Confirm every host is visible and managed by the same vCenter inventory — Keep hosts on compatible vSphere and vSAN versions.

Supported server, controller, drive, driver, and firmware combinations — Unsupported components can cause claiming failures, instability, or poor performance — Review the VMware Compatibility Guide or an approved hardware list — Check storage controllers, disks, drivers, firmware, and network adapters together.

vSAN VMkernel connectivity — Hosts exchange storage and resynchronization traffic through these interfaces — Test every host-to-host vSAN path — Verify VLAN, IP, routing, MTU, and service settings.

Network bandwidth and redundancy — vSAN is sensitive to latency, congestion, and path failures — Check uplinks, switch configuration, and failover behavior — Use redundant physical paths and plan traffic separation or quality of service.

Eligible local storage — vSAN can claim only suitable visible devices — Review device ownership, partitions, controller mode, and eligibility — Reserve boot, diagnostic, and other non-vSAN devices.

Cluster capacity and failure tolerance — Policies, maintenance, repairs, and failures require spare capacity and enough hosts — Model raw and usable capacity and policy requirements — Include resilience overhead, operational reserve, and maintenance capacity.

Check hardware and software support

Confirm that participating hosts are compatible with the selected vSAN version and are managed by vCenter Server. Review the VMware Compatibility Guide or your organization's approved hardware list for:

Server models and firmware versions.
Storage controllers and their operating modes.
SSDs, HDDs, NVMe devices, and other storage media.
ESXi drivers and controller firmware.
Network adapters, drivers, and supported speeds.

Uniform host hardware is a best practice. Matching host models, storage layouts, controller settings, and network adapters make capacity planning and troubleshooting more predictable. Mixed hardware can be supported in some designs, but every combination must be verified and its performance and capacity differences understood.

Plan cluster size and failure tolerance

Plan a supported cluster size based on the vSAN release, the desired storage policy, and the failure domains in the design. The number of hosts must be sufficient for the selected failures to tolerate setting, maintenance operations, and recovery after a host or device failure.

Failures to tolerate is a storage-policy setting that determines how many failures a VM storage object can tolerate. A policy requiring more replicas or a larger protection layout consumes more capacity and may require additional hosts. Do not calculate usable capacity from raw disk capacity alone.

Reserve capacity for repairs, resynchronization, rebalancing, host maintenance, and unexpected failures. A datastore that is technically full enough to store current VMs may still be unable to repair or rebuild objects safely.

Review local storage roles

Verify that every participating host has suitable local storage. In traditional vSAN disk-group architectures, devices are organized into a cache tier and a capacity tier. The cache tier accelerates writes and, in hybrid configurations, also provides read caching. The capacity tier provides persistent storage for vSAN data.

A disk group traditionally contains one cache device and one or more capacity devices. A disk-group failure can affect all capacity devices associated with that group, so disk-group design matters for both performance and failure impact.

All-flash and hybrid configurations differ conceptually. Hybrid designs use flash for cache and may use magnetic disks for capacity. All-flash designs use flash-class devices for both roles. Newer vSAN architectures may use different storage-pool or device-management models, so do not assume that every release uses identical disk-group behavior.

Design the vSAN network

Create a dedicated VMkernel adapter for vSAN traffic on every participating ESXi host. The adapter can use a distributed or standard virtual switch and an appropriate port group. Enable the vSAN traffic service on that adapter.

The vSAN VMkernel interfaces must have supported Layer 2 or Layer 3 connectivity to one another. Use a consistent network design across hosts, including:

VLAN assignment.
IP addressing and subnet design.
Gateway and routing configuration where routed connectivity is used.
MTU settings across the complete path when larger frames are part of the design.
Physical switch, port group, uplink, and NIC teaming settings.

1 GbE may function in limited or older designs, but 10 GbE or faster networking is the recommended baseline for production deployments. Select speed based on host count, device performance, workload, resynchronization requirements, and the amount of traffic sharing the uplinks.

Use NIC redundancy and redundant physical switches where supported. A single uplink, switch, or adapter should not be the only path for vSAN traffic. If vSAN shares uplinks with management, vMotion, or virtual-machine traffic, plan bandwidth separation or quality of service. Storage synchronization should not be allowed to starve critical management or VM traffic.

Validate VMkernel connectivity before enabling vSAN or claiming storage. Network problems discovered after storage is populated can cause unavailable objects, slow resynchronization, and policy noncompliance.

Example: dedicated vSAN VMkernel network

Create a vSAN VLAN or another supported routed network.
Create a port group on the selected standard or distributed switch.
Create one VMkernel adapter on each ESXi host.
Assign addresses from the planned network and enable the vSAN service.
Configure consistent MTU, VLAN, uplink, and routing settings.
Verify that each vSAN VMkernel interface can reach every other participating host.

vmkping -I vmkX <peer-vsan-vmkernel-ip>

Replace vmkX and the destination address with values from the environment. Test from each host to the other hosts, not only from one host to one peer.

Create or prepare the vSphere cluster

In vCenter Server, create a vSphere cluster or select an existing cluster intended for vSAN.
Add the compatible ESXi hosts that will contribute storage.
Plan related cluster services, including vSphere HA, DRS, and admission control.
Confirm that hosts have consistent network, storage-controller, device, and firmware configuration.
Open the cluster configuration workflow and enable vSAN.

vSphere HA can restart VMs after host failures, while DRS can help balance VM placement. Admission control reserves capacity for HA recovery. These services should be planned together with vSAN policies and usable capacity rather than enabled without considering their resource requirements.

Choose a disk-claiming method

Automatic disk claiming detects eligible unused local disks and claims them for vSAN. It is convenient when every eligible disk on every participating host is dedicated to vSAN and the intended layout is simple.

Manual disk claiming lets the administrator explicitly choose devices and create storage groupings or select devices according to the vSAN architecture. It is safer when hosts contain disks reserved for ESXi boot, diagnostics, another datastore, future expansion, or another service.

Method — How Devices Are Selected — Best Use Case — Risk or Limitation

Automatic disk claiming — Eligible unused disks are selected by the configuration workflow — Use when all eligible empty disks are dedicated to vSAN — It can consume disks intended for another purpose, so inventory must be reviewed first.

Manual disk claiming — The administrator selects eligible devices explicitly — Use when storage roles, disk groups, or reserved devices require precise control — It requires more planning and increases the chance of an incomplete or unbalanced layout if selections are inconsistent.

Configure devices and disk groups

For a traditional disk-group layout, select an appropriate cache device and one or more capacity devices for each group on each host. Check device endurance, performance, capacity, compatibility, and failure impact before creating the group.

Review the devices detected as eligible on every host.
Choose the cache device according to the supported architecture and hardware design.
Choose capacity devices that provide the intended capacity and performance.
Create disk groups manually when precise placement is required.
Confirm that only approved devices are added to the vSAN datastore.

Keep the storage layout reasonably consistent across hosts. A host with fewer devices or substantially different device performance can become a capacity, performance, or resilience constraint.

In architectures that do not use traditional disk groups, follow the release-specific workflow for creating a vSAN storage pool or claiming devices. The principles remain the same: verify eligibility, preserve devices needed for other functions, and ensure that the resulting layout supports the intended policies.

Create and verify the vSAN datastore

After storage is successfully claimed, vSAN creates and presents a shared datastore to the participating hosts. Verify the result in vCenter Server before deploying production workloads.

Area — What to Check — Expected Result

VMkernel network — vSAN service, VLAN, IP, MTU, routing, uplinks, and host-to-host tests — Every host has a working vSAN path to every other host.

Host membership — Cluster membership and vSAN participation — All intended hosts are contributing or are intentionally configured for their role.

Storage devices — Device visibility, eligibility, ownership, and health — Intended devices are claimed and unintended devices remain untouched.

Disk groups or storage pool layout — Cache and capacity roles or release-specific storage organization — The layout is complete, supported, and consistent with the design.

vSAN Health — Network, physical storage, configuration, and cluster checks — Health checks show no unresolved critical findings.

Datastore availability — Datastore visibility from each host and reported capacity — The shared vSAN datastore is visible and usable from the cluster.

Test VM policy compliance — VM placement, policy assignment, and compliance state — A test VM is accessible and compliant with its assigned policy.

Use vSAN Health to assess network paths, physical storage, configuration consistency, cluster state, hardware alerts, and other conditions. Usable capacity is lower than raw capacity because of resilience policies, metadata and system overhead, filesystem or object overhead, and the operational reserve needed for repairs and resynchronization.

Useful ESXi validation commands

esxcli vsan network list

Lists VMkernel adapters with vSAN traffic enabled.

esxcli vsan storage list

Shows local devices recognized and claimed by vSAN.

esxcli vsan cluster get

Displays local host membership and cluster information.

vmkping -I vmkX <peer-vsan-vmkernel-ip>

Tests connectivity from a specified vSAN VMkernel interface to another host's vSAN VMkernel address.

Exact commands, output, and supported workflows vary by vSphere and vSAN release. Use version-specific product documentation and test commands with appropriate privileges.

Plan availability and daily operations

Storage policies control VM object availability and performance. The failures-to-tolerate rule determines how many failures an object can withstand, but the policy is achievable only when the cluster has enough hosts, capacity, failure-domain separation, and healthy network paths.

Plan for the operational impact of:

Placing a host into maintenance mode.
Replacing a failed disk or disk group.
Repairing or rebuilding objects after a host failure.
Resynchronization after a failure, maintenance event, or policy change.
Temporary network outages between vSAN hosts.
Capacity rebalancing and future workload growth.

Resynchronization is the process of restoring compliant object components after a failure, maintenance event, or configuration change. Monitor active resynchronization activity because it consumes storage and network resources. Avoid operating close to full capacity, where repairs may be delayed or impossible.

Monitor vSAN Health, capacity utilization, object compliance, resynchronization activity, device health, controller alerts, NIC status, and physical-switch alarms. Establish alert thresholds and an operational procedure for failures before placing the cluster into production.

Use the vSAN datastore

Create or migrate a virtual machine and select the vSAN datastore as its storage location.
Assign a storage policy that matches the VM's availability and performance requirements.
Review the VM's policy-compliance state after deployment.
Run a basic application or guest operating system test.
Confirm that the VM remains accessible while reviewing health and object-placement information.

Do not select a policy solely because it offers the highest protection. Match protection to business requirements and confirm that the cluster has sufficient capacity and hosts to satisfy the policy during normal operation and maintenance.

Troubleshoot common configuration problems

Host does not join or communicate properly

Likely causes include an incorrect vSAN service assignment, inconsistent VLAN or IP settings, routing or MTU problems, a blocked firewall path, an incorrect port group, or a failed uplink.

Review vSAN VMkernel adapters on every host.
Use vmkping between every pair of vSAN VMkernel addresses.
Check vSAN Health network findings.
Inspect physical NIC status, switch ports, VLAN configuration, and uplink failover.

Expected disks are not eligible

A device may contain a partition or datastore, be claimed by another service, be invisible to ESXi, or use an unsupported controller, firmware, driver, or disk model.

Review device visibility and current ownership.
Check the approved hardware and compatibility information.
Verify controller mode, driver, and firmware versions.
Confirm that only intended empty devices are selected.

Datastore is unavailable or has reduced capacity

Check whether all intended hosts contributed storage successfully and whether disk groups or devices are missing or failed. Review capacity consumption, object compliance, resynchronization activity, and vSAN Health. Confirm that the selected storage policy is achievable with the available host count and capacity.

VM is noncompliant with its storage policy

Noncompliance can result from insufficient hosts or free capacity, an unavailable host or device, a failed network path, or pending resynchronization.

Review policy compliance and object placement information.
Check vSAN Health and active resynchronization.
Assess available capacity and host availability.
Change the policy only after confirming that the new requirement is supported by the cluster.

Three-host production example

Prepare three compatible ESXi hosts managed by one vCenter Server instance.
Configure a vSAN-enabled VMkernel adapter on each host using the same reachable vSAN network.
Provide redundant high-speed physical uplinks where the network design supports them.
Create a vSphere cluster and add the three hosts.
Enable vSAN and select manual disk claiming.
Add only approved local devices, creating disk groups when required by the selected architecture.
Run vSAN Health checks and confirm host contribution and datastore creation.
Deploy a test VM with an appropriate storage policy.
Verify datastore access and policy compliance before migrating production workloads.

Exam-relevant notes

vSAN is enabled at the vSphere cluster level.
Every participating host requires a VMkernel adapter with the vSAN traffic service enabled.
Automatic claiming is convenient but can consume eligible disks unintentionally.
Manual claiming provides explicit control over devices and storage groupings.
A traditional disk group contains one cache device and one or more capacity devices.
Failures-to-tolerate is controlled by the VM storage policy and requires enough hosts and capacity.
Raw capacity is not the same as usable capacity.
vSAN Health should be reviewed after configuration and continuously during operation.
Network connectivity should be validated before storage is claimed.

For a related reference within this course, see Configure VMware vSAN in a vSphere Cluster.