VMware ESXi and vSphere Cluster Management

Understanding the vSAN Datastore in VMware ESXi

Learn how the VMware vSAN datastore pools host-local storage, represents VM files as objects, and uses storage policies for capacity, performance, and resilience.

A vSAN datastore is the shared datastore presented by a vSAN-enabled VMware vSphere cluster. Instead of managing a separate storage datastore for each ESXi host, vSAN combines eligible storage devices from participating hosts into one cluster-wide storage pool.

Virtual machines use this datastore through the familiar vSphere datastore interface. Behind that interface, vSAN stores VM data as distributed objects and places their components across hosts according to storage policies.

What a vSAN Datastore Is

When vSAN is enabled and configured for an eligible cluster, vCenter Server presents a primary vSAN datastore for that cluster. The datastore can contain virtual machine files and other supported vSAN-resident data.

The datastore aggregates capacity contributed by participating ESXi hosts. Administrators do not normally select a particular host disk when creating a VM on vSAN. They select the shared datastore and assign an appropriate storage policy.

Datastore Creation and Cluster Scope

The vSAN datastore is associated with the cluster, not with an individual ESXi host. The normal sequence is:

1. Create or select a vSphere cluster.
2. Enable and configure vSAN at the cluster level.
3. Add eligible ESXi hosts to the cluster and configure their vSAN networking.
4. Claim compatible storage devices or configure disk groups according to the vSAN architecture in use.
5. Verify that vSAN is healthy and that the shared datastore is visible in vCenter Server.

A vSAN cluster has one primary vSAN datastore. Hosts intended to contribute storage must be members of that same cluster. A disk installed in a host does not become part of the vSAN storage pool merely because the host is connected to vCenter Server; the host must participate correctly in the configured vSAN cluster.

This distinction is important:

• Physical view: Each host contains local cache and capacity devices, often arranged into disk groups or another supported architecture.
• Logical view: vSphere sees one shared vSAN datastore backed by the combined cluster resources.

How Capacity Is Contributed and Consumed

Hosts contribute capacity devices to a cluster storage pool. The amount shown as usable datastore capacity is not necessarily the sum of every device's advertised physical capacity.

Capacity has several useful meanings:

• Physical capacity: The raw space provided by the installed devices.
• Usable capacity: Space available for VM data after architecture, metadata, formatting, and other required overheads.
• Consumed capacity: Space currently used by objects, protection copies, snapshots, resynchronization, and system overhead.
• Reserved or slack capacity: Space intentionally kept available for changes, repairs, policy operations, and temporary data movement.

A storage policy can cause a VM to consume substantially more physical capacity than the logical size of its virtual disks. For example, replication stores more than one copy of data. Erasure coding uses data and parity fragments and may provide a different capacity efficiency and host requirement. The exact result depends on the vSAN version, architecture, policy rules, and cluster topology.

Capacity can also change during normal operations:

• Maintenance mode may require evacuation or temporary relocation of components.
• A disk, host, or network failure may trigger rebuilding or resynchronization.
• Snapshots can retain changed blocks and increase storage consumption.
• Thin-provisioned virtual disks can grow as the guest operating system writes data.
• Changing a policy can temporarily require space for new components before old components are removed.

vSAN Object-Based Storage Architecture

vSAN uses an object-based storage model. An object is a logical storage entity representing VM data or metadata. vSAN divides an object into one or more components, then places those components on hosts and storage devices according to the object's policy.

An object is not the same thing as one physical file on one host. A logical object may be implemented by:

• One or more mirrored data components.
• A witness component used to maintain quorum for a mirrored layout.
• Data and parity fragments in an erasure-coded layout.
• Additional components created to satisfy stripe or placement requirements.

Distributed placement separates data from a single host or disk. With an appropriate policy and healthy cluster, this layout can provide availability after a device, host, or fault-domain failure while also distributing I/O across multiple devices.

How Virtual Machine Files Become Objects

A VM stored on vSAN can consume several objects. The datastore browser may show familiar VM files, but the underlying implementation is object-based.

For example, a VM with two VMDKs normally has a VM home namespace object plus a separate object for each virtual disk. It therefore consumes multiple logical objects rather than one single datastore file. A snapshot can add further storage structures and retain changed data for as long as the snapshot exists.

Filesystem and Datastore Presentation

vSAN historically used the term OSFS, meaning Object Store File System, for the layer that exposed distributed vSAN object storage through a datastore-style interface. This terminology describes an architectural presentation layer, not a conventional administrator-created VMFS volume on every vSAN host.

The datastore interface is useful because vSphere workloads can use vSAN in much the same operational way they use other datastore types: administrators can deploy VMs, browse VM files, and select storage policies. The interface hides the need to manually choose a physical disk or host for each VM file.

Keep these concepts separate:

• Datastore presentation: The storage target visible to vSphere administrators and workloads.
• Distributed object storage: The vSAN implementation that places object components across hosts and devices.
• VMFS: VMware Virtual Machine File System, commonly used for conventional VMFS datastores. A vSAN host should not be treated as requiring a separate VMFS volume for each host in order to provide the vSAN datastore.

Storage Policy-Based Management

A single vSAN datastore can support workloads with different service levels. A development VM might need minimal protection, while a production VM might require greater failure tolerance or a particular performance layout. Storage policies express these requirements.

A policy is assigned to a VM, its VM home namespace, or, where supported, an individual virtual disk. vSAN evaluates the policy and creates an object layout that attempts to satisfy the rules.

Common policy dimensions include:

• Failures to tolerate: The number of failures an object should remain available through, subject to available resources.
• Data placement: Rules that separate components across hosts or fault domains.
• Protection method: Mirroring or erasure coding where supported by the architecture and topology.
• Stripe width: A placement or performance-related setting in applicable vSAN architectures.
• Thin provisioning or object space reservation: Rules affecting how logical space is allocated and reserved.

Changing a policy is not merely changing a label. vSAN may create new components, move data, change protection, or release old components. The object can remain in a resynchronization state until the new layout is complete.

Availability and Resilience

Policy-driven replication or erasure coding protects objects against defined failure types. Components are placed across hosts and, when configured, across fault domains. A fault domain is a group of hosts that share a risk boundary, such as a rack.

The selected policy must be feasible for the cluster. vSAN needs enough hosts, storage devices, fault domains, and free capacity to create the required components. A policy that tolerates a particular number of failures may be impossible on a small cluster or while resources are unavailable.

An object can be:

• Compliant: Its current layout meets the assigned policy.
• Noncompliant: The object is accessible or partially accessible, but its layout does not currently meet all policy requirements.
• Inaccessible: Required components cannot be accessed, so some or all data is unavailable.
• Resynchronizing: vSAN is moving or rebuilding data to restore protection or policy compliance.

Free capacity is essential to resilience. After a failure or before host maintenance, vSAN may need space to rebuild or evacuate components. A cluster that has enough space for ordinary workload growth but not enough for a rebuild can leave objects noncompliant or prevent a full evacuation.

Requirements Before Using the Datastore

Before placing production workloads on a vSAN datastore, verify the following:

• The cluster is properly configured for vSAN, with participating ESXi hosts.
• Eligible storage devices have been claimed or organized according to the supported vSAN architecture.
• Hosts have reliable, correctly configured vSAN network connectivity and adequate bandwidth and latency.
• The cluster has enough hosts, devices, and fault domains for the intended storage policies.
• ESXi, vCenter Server, hardware, drivers, firmware, and vSAN architecture requirements are compatible.
• Licensing and other platform prerequisites are satisfied.
• vSAN health checks pass, the datastore is visible, and no unresolved critical configuration issues remain.

Use the compatibility guidance for the specific vSphere and vSAN release. Hardware and firmware combinations that are acceptable for one release may not be supported for another.

Configuring and Managing the Datastore

Enable vSAN at the Cluster Level

In the vSphere Client, configure vSAN from the cluster's vSAN settings. Select the appropriate vSAN architecture, configure networking, and claim or organize storage devices as required. Confirm that every intended host participates in the same cluster and that the datastore becomes visible after configuration completes.

Create and Assign Storage Policies

1. Create a VM storage policy containing vSAN rules such as failure tolerance, placement, protection method, stripe behavior, or space reservation.
2. Validate the policy against the cluster's current host count, fault domains, devices, and free capacity.
3. Assign the policy during VM deployment or through VM storage policy management.
4. Where supported, assign a different policy to an individual VMDK when one disk has different requirements from the rest of the VM.
5. Check policy compliance after assignment and after any topology or policy change.

Inspect Health and Capacity in the vSphere Client

Use the vSphere Client's storage and vSAN views to review:

• Datastore capacity, free space, and capacity breakdown.
• VM and virtual disk storage policy assignments.
• Object health and policy compliance.
• Resynchronization activity and estimated remaining work.
• Host, disk, network, and fault-domain health.
• Slack space available for maintenance, repairs, and growth.

For advanced verification from an ESXi host, use supported vSAN diagnostic commands for the installed release. These tools can help inspect cluster membership, object health, and resynchronization state when graphical management is unavailable. Command names and syntax vary between vSphere versions, so use the documented commands for the specific release rather than copying a command from another environment.

Practical Examples

A New vSAN Cluster Becomes Available

Three or more appropriately configured ESXi hosts contribute storage to a cluster. After vSAN configuration completes, vCenter Server presents one shared vSAN datastore. An administrator creates a VM on that datastore without selecting a particular host disk. The assigned policy determines how the VM's objects are distributed and protected.

One VM Uses Multiple Storage Objects

A VM has two VMDKs. vSAN creates separate virtual disk objects for those disks and a VM home namespace object for configuration and metadata. If the VM receives a snapshot, additional storage structures may retain changed data. The VM therefore consumes multiple objects with potentially separate policy assignments.

Different Service Levels on One Datastore

A development VM and a production VM can use the same vSAN datastore. The development VM can use a policy with lower protection requirements, while the production VM uses a policy with greater failure tolerance. Their objects are placed and protected differently even though both workloads select the same datastore.

A Policy Change Triggers Reconfiguration

An administrator changes a virtual disk from a lower-protection policy to a higher-protection policy. vSAN checks whether the cluster has enough hosts, fault domains, devices, and free capacity. If the change is feasible, vSAN creates or rearranges components and reports resynchronization until the object becomes compliant.

Host Maintenance Planning

Before placing a host into maintenance mode, check free capacity, object health, and policy requirements. Depending on the selected evacuation behavior, vSAN may move or rebuild components to preserve accessibility and compliance. Insufficient capacity can prevent full evacuation or leave objects temporarily noncompliant.

Troubleshooting Common Problems

The vSAN Datastore Does Not Appear

Possible causes include incomplete vSAN enablement, incorrect host membership, unclaimed storage devices, incomplete vSAN network connectivity, or unmet compatibility and licensing prerequisites.

• Review the cluster's vSAN configuration and health status.
• Confirm that intended hosts belong to the same cluster.
• Verify vSAN network reachability between hosts.
• Confirm that eligible capacity devices are available and configured.
• Review vCenter Server alarms and vSAN health findings.

A VM Is Noncompliant

The assigned policy may require more hosts, fault domains, or capacity than the cluster currently provides. A host, disk, or component may also be unavailable, or a recent maintenance operation or policy change may still be resynchronizing.

• Inspect the policy assigned to the VM and each relevant virtual disk.
• Review object compliance details rather than only the datastore summary.
• Check host, device, and network health.
• Check free capacity and active resynchronization tasks.
• Determine whether the policy is feasible for the current topology.

Free Space Drops Faster Than Expected

Protection policies multiply physical consumption. Snapshots may retain changed data, maintenance and resynchronization may require temporary capacity, and thin-provisioned disks may have grown.

• Review the datastore capacity breakdown and largest consumers.
• Identify old or unnecessary snapshots.
• Compare logical VM capacity with policy protection overhead.
• Check for active resynchronization or evacuation operations.
• Keep sufficient slack space for rebuilds and maintenance.

A Policy Cannot Be Applied

The cluster may lack sufficient resources for the requested policy, or its fault-domain topology may not support the selected placement. A temporary host or device failure can also prevent compliant placement.

• Validate policy rules against the number of hosts and fault domains.
• Check available capacity and host health.
• Review detailed placement and compliance messages.
• Restore failed resources or select a policy that the current topology can satisfy.

Key Exam and Operations Notes

• A vSAN datastore is a shared, cluster-wide datastore backed by storage contributed from participating ESXi hosts.
• The datastore is a logical presentation; the underlying storage is distributed across physical devices and hosts.
• vSAN stores VM data as objects made from distributed components.
• Each vSAN-resident VMDK has a corresponding virtual disk object, and the VM home area has a namespace object.
• Storage policies determine object placement, protection, capacity behavior, and applicable performance characteristics.
• Different VMs, and sometimes different VMDKs in one VM, can use different policies on the same datastore.
• Policy changes, failures, and maintenance can trigger resynchronization and temporary capacity consumption.
• Policy compliance depends on current cluster resources and topology, not only on the policy text.
• Always check object health, free capacity, slack space, and resynchronization status before maintenance or major policy changes.

For related administration tasks, continue with vSAN datastore management and architecture topics.