VMware ESXi and vSphere Cluster Management

Configure VMware vSAN in a vSphere Cluster

Learn how to plan and configure VMware vSAN: prepare ESXi hosts, build the vSAN VMkernel network, enable vSAN, claim disks, create disk groups, and validate the datastore.

vSAN is VMware software-defined storage that combines eligible local disks from multiple ESXi hosts into one shared, distributed datastore. Virtual machines access this datastore through the vSphere cluster rather than through a single host.

vSAN was previously called Virtual SAN or VSAN. Current VMware documentation generally uses the name vSAN, but older interfaces and materials may use VSAN.

How vSAN Works

An ESXi host is a physical virtualization server. Each participating host contributes local storage devices, while vSAN coordinates those devices across the hosts. The result is a vSAN datastore that is visible to the cluster and can be selected when creating or migrating virtual machines.

vSAN is configured at cluster scope. A cluster is a vCenter grouping of ESXi hosts that forms the management and resource boundary for vSAN. Every participating host must be able to communicate with the other hosts over the vSAN network.

Local datastore: Storage attached to, and normally usable by, one ESXi host.
vSAN datastore: Distributed storage assembled from local devices across the vSAN cluster and presented as shared storage.
vCenter Server: The management platform used to create clusters, enable vSAN, configure storage, and monitor health.

Because vSAN distributes storage across hosts, disk placement, host failures, network availability, and storage policies must be considered together. Enabling the service does not make unavailable or unsuitable disks usable; devices must first be eligible and claimed.

Plan the Deployment Before Enabling vSAN

Required management and host conditions

Use a vCenter-managed ESXi cluster. Hosts should be added to vCenter and placed in the intended cluster before vSAN configuration begins. See Add ESXi Host to vCenter Server Inventory and Create Clusters.
Ensure every participating host has compatible local disks suitable for vSAN.
Identify which devices will be dedicated to vSAN. They must not contain required datastores, boot data, partitions, or other information that must be retained.
Plan capacity, expected growth, and fault domains before claiming disks. A fault domain is a planned failure boundary, such as a rack, that affects how storage availability is designed.
Validate the hardware, storage controller, drives, firmware, drivers, and ESXi/vSAN release against the compatibility guidance for the intended deployment.
Decide whether disk groups will be created automatically or manually.

vSAN Configuration Prerequisites

Requirement	Why It Matters	Validation Method
vCenter-managed cluster	vSAN is enabled and managed at cluster scope.	Confirm the hosts are members of the intended vCenter cluster.
Dedicated VMkernel interface	Provides a defined path for vSAN traffic.	Inspect VMkernel adapters and their enabled services on every host.
Host-to-host vSAN connectivity	Hosts must exchange storage and cluster traffic.	Test reachability between the vSAN VMkernel addresses.
Consistent VLAN and MTU	Inconsistent network settings can cause packet loss or health failures.	Compare port groups, VLANs, MTU values, and switch settings.
Eligible unused disks	Claiming a disk removes it from its previous storage role.	Review device usage, partitions, metadata, and capacity.
Network bandwidth	vSAN continuously exchanges storage-related traffic.	Confirm the planned link speed and physical network capacity.
Redundant NIC paths	Multiple paths reduce the effect of a failed adapter, cable, or switch path.	Review NIC teaming and physical switch redundancy.
Compatible hardware and software	Unsupported controllers, drives, firmware, or drivers can prevent reliable operation.	Check compatibility for the exact vSAN release and hardware configuration.

Build the Dedicated vSAN VMkernel Network

A VMkernel adapter is an ESXi network interface used by host services. For vSAN, create one VMkernel adapter per participating host and enable the vSAN traffic service on that adapter.

Place the adapters on a common network or VLAN with IP connectivity between every vSAN host. A VLAN is a logical network segment that can isolate vSAN traffic from management, virtual-machine, and other host traffic.

Network configuration requirements

Create a dedicated vSAN port group or distributed port group on each host.
Assign a unique IP address to each host's vSAN VMkernel adapter. Use addresses from a subnet reachable by every participating host.
Enable the vSAN traffic service on the appropriate VMkernel adapter.
Use consistent VLAN IDs, MTU values, IP addressing design, uplink assignments, and physical-switch configuration across hosts.
Configure physical switch trunks or access settings so the vSAN VLAN reaches every host as designed.
Apply the selected MTU consistently to the VMkernel adapter, virtual switch or distributed switch, physical NIC path, and switching infrastructure. Jumbo frames are useful only when the entire path supports the same MTU.

A dedicated 1 GbE network can function in a small environment, but 10 GbE or faster networking is generally preferred for vSAN. Design redundant physical NIC paths when availability matters. For example, connect each host's vSAN port group to two physical NICs, use NIC teaming, and connect those NICs through separate resilient switch paths where supported.

Per-host vSAN network pattern
VMkernel adapter: vmk-vsan
Service: vSAN traffic enabled
IP address: unique address on the shared vSAN subnet
VLAN: same planned vSAN VLAN on every host
Uplinks: redundant physical paths where required
MTU: identical end-to-end value

Create the Cluster and Enable vSAN

In vCenter Server, create or select the target ESXi cluster. For cluster creation fundamentals, see Create Clusters.
Confirm that every intended ESXi host is a member of the cluster and is connected in the vCenter inventory.
Verify the vSAN VMkernel adapter, enabled vSAN traffic service, IP address, VLAN, MTU, and uplinks on every host.
Open the cluster configuration workflow and enable the vSAN service.
Select the disk-claiming approach: automatic or manual.
Review the configuration before applying it. Enabling vSAN establishes the basis for the vSAN datastore; storage capacity becomes available as eligible devices are claimed and organized into disk groups.

Do not treat enabling vSAN as a substitute for network validation. A cluster can have the service enabled while still having a broken VLAN, an incorrect MTU, or a host without a usable vSAN path.

Choose a Disk-Claiming Mode

Disk claiming is the process of assigning eligible local disks to vSAN. Claimed devices are dedicated to the vSAN storage configuration.

Mode	How Disks Are Added	Best Use Case	Main Risk or Trade-off
Automatic	Eligible unused local disks are discovered and claimed without selecting each device individually.	Hosts are identically designed and every eligible empty disk is intended for vSAN.	It can claim more disks than intended if unused devices are reserved for another purpose.
Manual	The administrator reviews devices, selects cache and capacity devices, and explicitly creates disk groups.	Hosts contain mixed storage roles or the disk layout requires deliberate control.	It takes longer and requires careful per-host device selection.

Create Disk Groups and Assign Storage

A disk group is the vSAN unit that organizes storage devices on one host. It combines a cache device, which supports vSAN caching or related metadata functions depending on the architecture, with one or more capacity devices, which provide storage capacity to the vSAN datastore.

With manual configuration, repeat the review and disk-group creation process for each intended host:

Open the host's available storage devices in the vSAN configuration workflow.
Review each device's eligibility, model, capacity, current usage, partitions, and metadata.
Confirm that the selected devices are genuinely unused and are not required by a local datastore, boot configuration, or another service.
Select the intended cache device.
Select the intended capacity devices and create the disk group.
Repeat for other hosts and verify that the planned capacity and fault-domain design are represented.
Apply the configuration and wait for vCenter to update device and disk-group status.

Successful disk claiming and disk-group creation contributes the selected capacity to the vSAN datastore. The usable amount may differ from the raw sum of disk sizes because of system overhead, protection requirements, reserved space, and the storage policies used by workloads.

Small Three-Host Example

Create a vCenter cluster containing three ESXi hosts.
On each host, create a VMkernel adapter on the same dedicated vSAN VLAN.
Assign unique addresses from a common IP subnet and enable vSAN traffic.
Attach the vSAN port group to redundant uplinks where available, using separate switch paths when the physical design supports it.
Enable vSAN in the cluster configuration.
Choose manual disk claiming and select only the designated empty local drives on each host.
Create the required disk groups and confirm that all three hosts contribute storage.
Verify that the vSAN datastore appears with the expected approximate capacity and that health checks are clear.

Validate the Configuration

Validation should cover the network, cluster membership, disk groups, datastore, and health state. Where appropriate, create or move a test workload and confirm that it can see the vSAN datastore.

Component	Expected Result	Where to Verify
VMkernel vSAN service	Each participating host has a VMkernel adapter with vSAN traffic enabled.	Host networking and VMkernel adapter configuration in vCenter.
Inter-host network reachability	Every host can communicate with every other host over the vSAN VMkernel network.	vSAN network health checks and host-to-host connectivity tests.
Cluster vSAN status	The service is enabled and all intended hosts are participating.	Cluster vSAN configuration and summary views.
Disk groups	Expected cache and capacity devices are assigned on each host.	Cluster or host vSAN disk-management view.
vSAN datastore	The distributed datastore appears and has the expected capacity range.	vCenter storage inventory and datastore summary.
vSAN health	No unresolved disk, network, compatibility, or cluster alarms remain.	vSAN health monitoring and vCenter alarms.

Confirm all intended hosts remain in the cluster and report the expected storage contribution.
Check that no claimed disk is unexpectedly absent, degraded, or reporting an alarm.
Compare the observed capacity with the planned raw capacity and account for overhead and protection.
Test datastore visibility with a suitable nonproduction workload before relying on the deployment.

Troubleshooting Common Problems

A host cannot participate or reports vSAN network-health failures

Check that vSAN traffic is enabled on the intended VMkernel adapter.
Compare VMkernel addresses, subnet settings, VLAN assignments, and MTU values across hosts.
Review port-group, uplink, trunk, and physical-switch VLAN settings.
Test host-to-host connectivity using the vSAN VMkernel addresses.
Verify that the adapter has a functioning uplink and that a failed NIC or switch path has not removed reachability.

Expected disks are missing or cannot be claimed

Inspect whether the disk is already used by a datastore, boot configuration, or another service.
Check for existing partitions or metadata that prevent the device from being treated as empty.
Confirm the controller presentation, drive type, firmware, driver, and hardware compatibility.
Claim only devices that are genuinely unused and intended for vSAN.

Automatic claiming selected too many disks

Eligible unused disks were probably present when automatic mode was enabled. Review disk membership immediately, determine whether any device was selected unintentionally, and use manual claiming in environments that require explicit per-device control.

The vSAN datastore is missing or smaller than expected

Review whether vSAN is fully enabled on the target cluster.
Check disk-group and device state on every intended host.
Confirm that all intended hosts are connected and contributing capacity.
Look for ineligible, unavailable, or unclaimed devices.
Review vSAN health for network, compatibility, or cluster problems that prevent normal storage contribution.

Exam-Relevant Notes

vSAN aggregates local ESXi storage into a shared distributed datastore; it is not simply a larger host-local datastore.
vSAN configuration is performed at the vCenter cluster level.
Every participating host needs vSAN network connectivity through an appropriately configured VMkernel adapter.
Automatic disk claiming is convenient but unsafe when eligible disks have mixed purposes.
Manual claiming provides explicit control and requires disk-group design.
Never claim a disk until its existing data, datastore role, partitions, and compatibility have been checked.
Network redundancy depends on the complete path: NIC teaming, uplinks, cables, and physical switch redundancy must work together.