VMware ESXi and vSphere Cluster Management

VMware Virtual SAN (vSAN) Overview

Learn how VMware Virtual SAN pools local ESXi disks into shared clustered storage, including hybrid disk groups, cache, networking, policies, vSphere integration, and setup considerations.

VMware Virtual SAN, commonly abbreviated VSAN and later branded vSAN, is VMware software-defined shared storage for vSphere clusters. It combines disks installed inside multiple ESXi hosts and presents their storage as one distributed datastore.

Instead of requiring a separate traditional storage array, a vSAN cluster uses the compute hosts themselves to provide storage. This design is called hyperconverged infrastructure: compute, virtualization, and storage resources are delivered by the same group of hosts.

What VMware Virtual SAN Provides

A traditional vSphere environment might store virtual machine files on an external Fibre Channel, iSCSI, or NFS array. VSAN provides another model: local disks in participating ESXi hosts are pooled into a VSAN datastore that is accessible to the cluster.

The datastore can contain virtual machine configuration files, virtual disks, snapshots, swap files, and other VM-related storage objects. VSAN distributes these objects across participating hosts according to the storage policy assigned to each virtual machine.

  • Local physical disks are installed in individual ESXi hosts.
  • Disk groups organize cache and capacity devices inside each host.
  • Host contributions expose those disk groups to the VSAN cluster.
  • The VSAN datastore combines contributions from the cluster into one shared storage resource.
  • Distributed storage objects represent VM data and can have components or copies placed on different hosts.

VSAN is not simply a method of presenting one host's local disk to every other host. It is a distributed clustered storage system that uses host-local devices, storage policies, and network communication to provide shared storage.

Hybrid VSAN Architecture

In the early hybrid design, each disk group contains one solid-state drive (SSD) and one or more hard disk drives (HDDs). The SSD provides the cache tier, while the HDDs provide persistent capacity.

  • The cache-tier SSD is used for read caching and write buffering. It must provide suitable performance and write endurance.
  • The capacity-tier HDDs retain the stored data. Their size, speed, and reliability affect usable capacity and workload performance.
  • Each participating host in a hybrid cluster requires an approved cache-tier SSD.
  • Cache and capacity devices have different selection requirements. A large capacity disk is not automatically a suitable cache device.

Later vSAN releases also support all-flash architectures, in which flash devices provide both cache and capacity roles. All-flash vSAN is an important evolution, but it should not be confused with the early hybrid design described here.

Hybrid VSAN Architecture Components

Component             Location              Role                         Key requirement
ESXi host              Cluster member        Supplies compute and storage  Compatible ESXi and hardware
Cache-tier SSD         Inside an ESXi host   Read cache and write buffer   Approved performance/endurance
Capacity-tier HDD      Inside an ESXi host   Persistent storage capacity   Supported capacity device
Disk group             Host-local            Groups one SSD with HDDs      Correct cache/capacity pairing
VSAN network           Between ESXi hosts    Carries storage traffic        Reliable, low-latency connectivity
VSAN datastore         Cluster-wide          Shared VM storage              Sufficient protected capacity
vCenter Server         Management layer      Configures and monitors VSAN  Compatible management platform

Disk Groups

A disk group is a storage grouping within one ESXi host. It consists of one cache device and one or more capacity devices. In the early VSAN generation, a disk group used one SSD and could contain up to seven capacity HDDs. A host could contain up to five disk groups.

These limits and disk-composition rules are version-specific. Do not apply early VSAN limits to a current vSAN release without checking its product documentation.

A host can have multiple disk groups. For example, an administrator might create two disk groups on one host, with each group having its own SSD and several HDDs. Each group contributes its cache device and capacity devices to the cluster-wide datastore.

Storage Layers and Their Relationships

Layer                     Scope             Contains                         Purpose
Physical disk             Device            One SSD or HDD                   Supplies a raw storage device
Disk group                One ESXi host     One cache SSD plus capacity disks Organizes host-local storage
ESXi host contribution    One host          One or more disk groups           Adds resources to the cluster
VSAN cluster datastore    Entire cluster    All eligible host contributions   Presents shared distributed storage
VM storage objects        Virtual machine   Virtual disks, config, snapshots  Stores VM data according to policy

Cluster Membership and Hardware Requirements

ESXi hosts must be members of the same vSphere cluster to contribute storage to that VSAN datastore. A host outside the cluster does not automatically contribute its local disks to the datastore.

Before enabling VSAN, verify the following:

  • All intended hosts use mutually compatible ESXi and vCenter Server versions.
  • Each contributing host has suitable local storage devices and the required cache-tier SSD for the selected architecture.
  • Storage controllers, controller modes, drivers, firmware, SSDs, HDDs, and server models are supported together.
  • The planned number of hosts provides the desired availability and failure tolerance.
  • Raw capacity is sufficient after accounting for protection, snapshots, temporary overhead, rebuilds, and maintenance operations.
  • Network connectivity can support storage traffic without unacceptable latency or congestion.

Use the VMware Compatibility Guide to validate the intended server, controller, drive, driver, and firmware combination for the deployed release. A device that works as a generic ESXi disk is not necessarily supported for VSAN.

Virtual SAN Networking

Participating ESXi hosts exchange VSAN storage traffic over a Virtual SAN network. The transport is a VMkernel adapter, which is an ESXi networking interface used for services such as VSAN, vMotion, and management.

Each host needs a VMkernel adapter with the VSAN traffic service enabled. The adapters must have end-to-end connectivity between all participating hosts. Depending on the supported design and release, this can use appropriate Layer 2 or Layer 3 connectivity.

Storage traffic requires reliable, low-latency connectivity and sufficient bandwidth. Network design should address:

  • Common VLAN reachability or correctly routed connectivity between all VSAN VMkernel interfaces.
  • Consistent MTU settings from the VMkernel adapter through virtual switches, physical switches, and uplinks.
  • Correct physical-switch configuration and working uplinks.
  • Isolation from management, vMotion, and virtual machine traffic when the design requires separate paths or reduced contention.
  • Monitoring for packet loss, errors, congestion, link failures, and unexpected latency.

Network loss can prevent hosts from exchanging storage information, interrupt synchronization, affect object accessibility, and cause cluster-health warnings. A disk design cannot compensate for an unreliable storage network.

Dedicated VSAN Traffic Path

ESXi host 1: VMkernel VSAN adapter ─┐
ESXi host 2: VMkernel VSAN adapter ─┼─ Common VSAN VLAN or storage network
ESXi host 3: VMkernel VSAN adapter ─┘

Management and vMotion paths may use separate logical or physical paths
when required by the network design.

vSphere Integration and Management

VSAN is integrated into ESXi and vSphere rather than being installed as a separate storage software package on every host. vCenter Server is used to configure, enable, monitor, and manage VSAN at the cluster level.

A typical management workflow is:

  1. Create or select a vSphere cluster containing the intended ESXi hosts.
  2. Configure a VMkernel adapter on each host and enable VSAN traffic.
  3. Verify network reachability, VLAN configuration, MTU consistency, and physical uplink status.
  4. Enable Virtual SAN for the cluster through vCenter Server.
  5. Claim one compatible SSD as the cache device and one or more compatible HDDs as capacity devices for each disk group.
  6. Verify the VSAN datastore, host contributions, disk-group state, capacity, and health information.
  7. Assign an appropriate VM storage policy to test virtual machines.

Because the datastore is part of the vSphere cluster, VSAN can work with cluster capabilities such as vMotion, DRS, and HA. vMotion live-migrates a running VM between hosts. DRS helps place and balance workloads. HA restarts affected VMs after a host failure. These features still depend on correct cluster configuration, network access, storage policies, available capacity, and sufficient failure tolerance.

Storage Policies and Object Availability

A storage policy is a rule set that expresses the availability and placement characteristics required by a VM's storage. In VSAN, a VM's data is represented as distributed storage objects, such as virtual disks and their components.

When a policy requires protection against a host failure, VSAN can place components or copies on different hosts. The cluster must have enough hosts, disks, network connectivity, and raw capacity to satisfy that policy.

  • More protection generally consumes more usable capacity.
  • Stronger placement requirements may require additional hosts or fault domains.
  • Protection and layout choices can affect write traffic and performance.
  • A policy cannot provide protection that the cluster's hardware and available capacity cannot support.

For example, a three-host hybrid cluster can assign a VM a policy requiring host-failure protection. That policy consumes more raw capacity than a single unprotected copy and requires the cluster to keep enough resources available for placement and recovery.

Preparing Disks for VSAN

Disk claiming changes a device's role from standalone storage to a VSAN cache or capacity device. A disk allocated to VSAN cannot simultaneously be used for another datastore purpose.

Before claiming disks:

  1. Inventory the disks, datastores, virtual machines, templates, snapshots, and other files using them.
  2. Identify approved SSD and HDD devices and confirm their roles for the selected VSAN version.
  3. Migrate, export, or back up workloads that must be retained.
  4. Evacuate data from any VMFS datastore that uses the target disks.
  5. Unmount and remove the VMFS datastore only after confirming that it is no longer in use.
  6. Claim the released SSD as a cache device and the released HDDs as capacity devices.
  7. Confirm that the new disk group contributes capacity and reports a healthy state.

Preconfiguration Checklist

Check                                      Why it matters                         Validation approach
ESXi and vCenter compatibility             Prevents unsupported management        Check release compatibility
Controller and firmware support             Ensures correct disk presentation      Check Compatibility Guide
Approved SSD and HDD devices                Avoids unsupported or unsuitable media  Validate exact device models
Available disk capacity                     Supports VM data and recovery           Calculate raw and usable capacity
VMkernel VSAN connectivity                  Enables host storage communication      Test every host-to-host path
VMFS data evacuation                        Prevents destructive data loss          Confirm backups or migration
Cluster sizing and failure tolerance        Ensures policy requirements can be met   Model host and device failures

Benefits and Limitations

Benefits

  • Simplified shared storage: The cluster presents one datastore without requiring a separate traditional storage array.
  • Scale-out growth: Capacity and performance can grow by adding hosts, disk groups, or supported devices.
  • vSphere integration: Storage is managed alongside hosts, VMs, vMotion, DRS, and HA through vCenter Server.
  • Policy-based availability: VM storage requirements can be expressed through storage policies.
  • Hyperconverged operation: The same hosts provide compute and storage resources.

Limitations and Design Risks

  • Storage availability depends on host-local disk health and the health of the VSAN network.
  • Unsupported controllers, drives, firmware, or drivers can undermine reliability and performance.
  • Insufficient cache performance or endurance can limit a hybrid cluster.
  • HDD saturation, network congestion, and too many workloads per disk group can reduce performance.
  • Protection requirements reduce usable capacity and may increase write activity.
  • A failed host or disk group can reduce available capacity and trigger resynchronization or rebuild work.
  • Maintenance operations require enough free capacity and failure tolerance to keep objects accessible.

Troubleshooting Common Problems

A Host Cannot Contribute a Disk Group

  • Confirm that a suitable SSD is available for the cache tier.
  • Check whether the selected device is recognized and supported as the intended device type.
  • Verify that the disk is not being used by VMFS, another datastore, or another storage role.
  • Review controller mode, driver, firmware, vCenter alarms, and VSAN health results.

The Datastore Is Inaccessible or Reports Network Health Errors

  • Verify that VSAN traffic is enabled on a VMkernel adapter on every host.
  • Validate host-to-host connectivity across the VSAN network.
  • Compare VLAN, routing, MTU, uplink, and physical-switch settings end to end.
  • Inspect switch ports, virtual-switch status, uplinks, errors, packet loss, and congestion.

Usable Capacity Is Lower Than Expected

  • Compare raw capacity with usable capacity after protection and distributed placement overhead.
  • Verify that all intended disk groups and hosts are contributing successfully.
  • Review the storage policies assigned to VMs.
  • Reserve capacity for rebuilds, resynchronization, snapshots, and maintenance operations.

Virtual Machine Storage Performance Is Poor

  • Review cache-device performance and endurance suitability.
  • Check whether HDD capacity devices are saturated.
  • Examine VSAN network throughput, latency, errors, and congestion.
  • Check for active resynchronization or recovery operations.
  • Compare workload demands with the number and performance of disk groups.

Data Is Missing After VMFS Removal

VSAN does not automatically import data from a previous VMFS datastore. If disks were claimed before workloads were migrated or backed up, restore from a verified backup where available and review the change procedure. The key lesson is that datastore removal and disk claiming can be destructive.

Summary

VMware Virtual SAN pools local disks from ESXi hosts into a distributed, shared VSAN datastore for a vSphere cluster. In the early hybrid model, each disk group uses one SSD for caching and one or more HDDs for persistent capacity, with up to five disk groups per host in that generation.

Successful VSAN design depends on more than disk quantity. Administrators must validate hardware compatibility, create reliable VMkernel storage networking, plan capacity and failure tolerance, evacuate VMFS data before repurposing disks, and assign storage policies that match application requirements. For a related reference, see the VMware Virtual SAN overview.