VMware ESXi and vSphere Cluster Management

VMware Virtual SAN (vSAN) Overview

Learn how VMware Virtual SAN, or vSAN, pools local ESXi storage into a shared datastore, including hybrid disk groups, networking, requirements, and vSphere integration.

VMware Virtual SAN, now commonly branded as vSAN, is software-defined clustered storage integrated into VMware ESXi. It combines eligible local storage devices from multiple ESXi hosts and presents the combined resources as a shared vSAN datastore.

Unlike a datastore created on one host's local disk, vSAN is designed for a vSphere cluster. The participating hosts contribute storage, communicate over a vSAN network, and collectively provide storage for virtual machine files.

How vSAN Works

An ESXi host is a physical server running the ESXi hypervisor. In a vSAN cluster, each participating host contributes compatible local devices. vSAN organizes those devices into host-local disk groups, then combines the disk groups across the cluster into one shared datastore.

  1. A vCenter Server-managed cluster is created or selected.
  2. Each participating host receives a vSAN-enabled VMkernel adapter.
  3. Compatible local SSD and HDD devices are identified.
  4. The devices are organized into one or more disk groups on each host.
  5. vSAN aggregates the disk groups into a cluster-wide vSAN datastore.
  6. Virtual machines are placed on the vSAN datastore and their objects are distributed according to storage policy and availability requirements.

Although the datastore is shared, the disk groups remain physically associated with their original ESXi hosts. This distinction matters when planning capacity, performance, maintenance, and failure domains.

Historical Hybrid vSAN Architecture

The hybrid configuration introduced with vSphere 5.5 used two storage tiers. An SSD formed the cache tier, while magnetic hard-disk drives formed the capacity tier.

  • Cache tier: The SSD accelerated reads and buffered writes.
  • Capacity tier: HDDs provided persistent storage capacity.

In this original hybrid design, the SSD was not the primary persistent capacity location. The HDD capacity devices stored the persistent data, while the SSD helped improve I/O behavior.

This overview focuses on the historical hybrid architecture. All-flash vSAN uses different device roles and performance behavior, so its design should not be assumed to be identical to hybrid vSAN.

Hybrid vSAN Storage Components and Roles

Component | Location | Role | Persistent Data

SSD cache device | Inside a host disk group | Read caching and write buffering | Not the primary persistent tier in the hybrid design

HDD capacity device | Inside a host disk group | Supplies capacity for the datastore | Yes

Disk group | Local to one ESXi host | Combines one cache device with capacity devices | Its capacity devices provide persistent storage

Cluster-wide vSAN datastore | Shared across the vSAN cluster | Presents aggregated storage to hosts and virtual machines | Yes, through distributed vSAN objects

Disk Groups

A disk group is a local storage unit consisting of one cache-tier SSD and one or more capacity-tier HDDs. The disk group belongs to one ESXi host, even though its capacity contributes to the shared vSAN datastore.

For the historical hybrid layout, one disk group contained one SSD cache device and up to five HDD capacity devices. A host could contain up to five disk groups under the historical limit.

Historical Hybrid Disk-Group Limits

Scope | Maximum or Requirement | Explanation

Disk groups per ESXi host | Up to five | Historical maximum for the host

SSD cache devices per disk group | One | Each disk group requires one cache SSD

HDD capacity devices per disk group | Up to five | These devices provide the hybrid capacity tier

Minimum SSD requirement per participating host | One eligible SSD | Every host participating in a hybrid vSAN cluster needs a cache device

For example, Host A might contain Disk Group 1 with one SSD and four HDDs. It could contain additional disk groups, subject to the applicable release limits. The disk groups remain on Host A, but their usable storage contributes to the cluster's shared datastore.

Disk-group design affects the amount of usable capacity, I/O performance, device utilization, and the way failures are isolated. Do not select devices based only on raw disk capacity; consider cache requirements, protection overhead, maintenance operations, and the storage policy used by virtual machines.

vSAN and ESXi Integration

vSAN functionality is integrated into ESXi. It does not require separate storage software to be installed on every host. vCenter Server provides the central management plane used to configure, monitor, and administer the vSAN cluster.

The resulting vSAN datastore is presented as shared storage to the participating hosts. Virtual machine configuration files, virtual disks, swap files, snapshots, and related VM objects can reside on it. At a conceptual level, vSAN distributes these objects across contributing hosts according to the selected storage policy and availability requirements.

A vSAN datastore is different from a local VMFS datastore. VMFS is a VMware file system commonly created on local or SAN-attached block storage. vSAN instead aggregates host-local devices through the cluster's distributed storage architecture.

vSAN Networking

ESXi hosts exchange vSAN storage traffic over a vSAN network. This traffic uses a VMkernel adapter, which is an ESXi interface assigned to services such as vSAN.

  • Enable the vSAN traffic service on the intended VMkernel adapter on every participating host.
  • Provide reliable host-to-host connectivity across the entire cluster.
  • Use a dedicated or appropriately isolated network for vSAN traffic.
  • Provide adequate bandwidth and low latency for the storage workload.
  • Validate IP addressing, VLAN assignment, physical uplinks, switch configuration, and MTU consistency.

Jumbo frames can be used where appropriate, but the MTU must be configured consistently across the complete network path. A mismatch can cause communication failures that appear to be storage problems.

Relationship to vSphere Cluster Services

vSAN supplies shared storage; other vSphere services perform different functions. Shared storage makes it possible for cluster hosts to access the virtual machine objects needed by these services.

vSAN and vSphere Service Roles

Feature | Primary Role | Relationship to vSAN

vSAN | Provides distributed shared storage | Creates and presents the vSAN datastore

vMotion | Migrates a powered-on VM between hosts | Uses shared access to VM storage while compute execution moves

DRS | Balances VM workloads across hosts | Can place or move workloads while their storage remains available through vSAN

HA | Restarts affected VMs after a host failure | Uses shared vSAN storage to access VM files from another host

vCenter Server | Centrally configures and manages vSphere | Manages the cluster, vSAN settings, health, and datastore

These services are related but not interchangeable. vSAN does not perform workload balancing, vMotion does not provide storage, DRS does not replace HA, and HA does not prevent every host failure.

Conceptual Three-Host Example

Consider a three-host hybrid vSAN cluster:

  • Each host has a VMkernel adapter with vSAN traffic enabled.
  • The adapters connect to a network that provides reliable host-to-host communication.
  • Each host contributes one SSD cache device and several HDD capacity devices.
  • Each host organizes its devices into one or more disk groups.
  • The combined disk groups form one shared vSAN datastore visible to the cluster.
  • Virtual machines placed on that datastore can use vMotion, DRS, and HA according to the cluster's configuration and policies.

The storage is distributed, but it is not independent storage on each host. The cluster coordinates access to the distributed VM objects.

Basic Requirements and Planning

Before enabling hybrid vSAN, validate the complete design rather than only checking whether disks are present.

vSAN Readiness Checklist

Area | Requirement to Validate | Why It Matters

Host cluster management | Use a vCenter-managed ESXi cluster | vCenter provides the configuration and management context

Compatible storage devices and controllers | Confirm support for the intended vSAN release | Unsupported devices can be unavailable or unsafe to use

Cache SSD on each host | Provide at least one eligible SSD per participating hybrid host | The SSD is required to form each hybrid disk group

Capacity HDDs | Provide sufficient compatible HDD capacity devices | HDDs supply persistent hybrid capacity

VMkernel vSAN networking | Configure vSAN traffic on every participating host | Hosts must exchange storage traffic reliably

Existing datastore data | Locate and protect VMFS content before repurposing disks | Clearing devices can cause data loss

Plan for usable capacity, not just raw capacity. Storage policies, metadata, snapshots, swap files, reserved space, failures, and maintenance operations can reduce the capacity available for new virtual machines.

Always check the VMware Compatibility Guide and the requirements for the specific vSphere and vSAN release. Validate the host model, storage controller mode and firmware, SSD model, HDD model, driver versions, and supported configuration.

Configuration Workflow in vCenter Server

  1. Create or select a vCenter-managed ESXi cluster.
  2. Confirm that participating hosts have compatible local SSD and HDD devices.
  3. Create or designate VMkernel adapters and enable vSAN traffic on each host.
  4. Verify vSAN network reachability between all participating hosts.
  5. Enable vSAN for the cluster in the applicable vSphere Client workflow.
  6. Claim eligible cache and capacity devices and create disk groups.
  7. Verify that the vSAN datastore appears and is accessible to the expected hosts.
  8. Review cluster health, capacity, disk-group status, and host participation.

The exact wizard names and available options vary by vSphere release. Use the release-specific workflow rather than assuming that an older interface has the same labels.

For a configuration procedure, see Configure Virtual SAN. For cluster preparation, see Create Clusters and Add ESXi Host to vCenter Server Inventory.

Repurposing Existing VMFS Storage

Disks intended for vSAN may already contain a VMFS datastore. A datastore must not be deleted merely because vSAN is being planned.

  1. Identify the existing VMFS datastore and everything using it.
  2. Check for virtual machines, ISO images, templates, logs, snapshots, and other required files.
  3. Migrate or back up the required content.
  4. Confirm that the datastore is no longer in use.
  5. Delete the VMFS datastore only when the underlying devices are intentionally being prepared for another use.
  6. After the devices are clear and compatible, claim them as cache or capacity devices according to the disk-group design.

Deleting a datastore is an administrative storage operation with data-loss implications. Review Browse VMFS Datastores before removing storage, and use Delete VMFS Datastore only after the data-safety checks are complete.

Troubleshooting vSAN Readiness

A host cannot contribute storage

Likely causes include the absence of an eligible SSD, an unsupported or incorrectly recognized controller or device, or disks already used by VMFS, another datastore, or another disk group.

  • Review device visibility and eligibility in vCenter.
  • Check the compatibility information for the intended vSAN release.
  • Confirm that the disks are not claimed by an existing datastore or storage configuration.

vSAN reports network communication problems

Check whether vSAN traffic is enabled on the intended VMkernel adapter. Also verify host IP configuration, VLAN placement, physical switch and uplink connectivity, and MTU consistency.

  • Confirm the vSAN service on each host's VMkernel adapter.
  • Validate connectivity among every participating host.
  • Compare VLAN and MTU settings across the complete vSAN network path.

An expected disk is unavailable

The disk may belong to a VMFS datastore, contain VM files, or be claimed by another storage service. Identify ownership and content before clearing it, then migrate or protect required data and verify eligibility again.

The vSAN datastore does not appear or cannot be used

Possible causes include vSAN not being enabled at the cluster level, no valid disk groups, or hosts failing to participate because of compatibility or networking issues.

  • Review cluster vSAN status in vCenter.
  • Confirm that disk groups exist and contain the expected cache and capacity devices.
  • Review host membership, health status, device eligibility, and vSAN network status.

Exam-Relevant Notes

  • vSAN is software-defined clustered storage integrated into ESXi.
  • It pools eligible local storage from multiple hosts into a shared vSAN datastore.
  • In historical hybrid vSAN, SSDs provide cache functions and HDDs provide persistent capacity.
  • A hybrid disk group contains one SSD cache device and one or more HDD capacity devices.
  • Every participating hybrid host requires an eligible SSD cache device.
  • Historically, a host supported up to five disk groups, and each hybrid disk group supported up to five HDD capacity devices.
  • vSAN storage traffic uses a VMkernel adapter with vSAN traffic enabled.
  • vSAN, vMotion, DRS, HA, and vCenter Server have different roles.
  • A vSAN datastore is distinct from a local VMFS datastore.
  • Deleting or repurposing VMFS storage requires confirming that no required data remains.