VMware ESXi and vSphere Cluster Management

Understanding the VMware vSAN Datastore

Learn how the VMware vSAN datastore pools host-local storage, represents VM data as objects, distributes protection components, and uses storage policies for different service levels.

The vSAN datastore is the shared storage layer created when vSAN is enabled on an eligible vSphere cluster. Instead of mounting a separate SAN or NAS system, vSAN combines storage devices contributed by participating ESXi hosts and presents the result as one datastore to the cluster.

Virtual machines can use this datastore as a common location. vSAN then decides how each virtual machine component is distributed and protected according to its assigned storage policy.

What the vSAN Datastore Provides

Enabling vSAN at cluster level creates one shared vSAN datastore for that cluster. The datastore aggregates eligible capacity from the participating ESXi hosts. A VM registered in the cluster can store its home data, virtual disks, snapshots, and other supported components on that shared datastore.

This differs from a host-local datastore. A local VMFS datastore normally uses storage visible to one host, while a separately mounted SAN or NAS datastore is provided by an external storage system. vSAN uses storage devices inside the ESXi hosts, but presents their pooled capacity through a cluster-wide datastore.

Storage model: Host-local devices from multiple ESXi hosts → vSAN storage pool → one shared vSAN datastore → policy-controlled VM objects.

Access scope: Hosts participating in the vSAN cluster can access the datastore when their vSAN networking, storage configuration, and cluster health permit it.

Important terminology

• vSAN cluster: A group of ESXi hosts participating in the same vSAN storage system.
• vSAN datastore: The shared datastore automatically made available to a vSAN-enabled cluster and backed by pooled host-local storage.
• Storage policy-based management: The vSphere mechanism for assigning storage requirements through policies instead of selecting separate physical datastores.

For background on vSphere inventory and ESXi administration, see the VMware ESXi online course and the ESXi overview.

How Cluster-Wide Storage Consumption Works

Each participating host contributes eligible storage devices to the vSAN storage pool. Depending on the vSAN architecture and version, this can involve disk groups, storage pools, cache devices, capacity devices, or other supported configurations. The devices must be claimed or assigned to vSAN before their capacity is available to the datastore.

The displayed usable capacity is not simply the sum of every device's raw size. Capacity planning must account for:

• Raw capacity contributed by hosts and devices.
• Reserved capacity and operational headroom.
• Mirroring, erasure coding, or other protection overhead.
• Snapshots, thin-provisioning growth, and swap-related consumption.
• Temporary space needed for repairs, policy changes, evacuations, and resynchronization.
• Filesystem, metadata, checksum, and other vSAN operational overhead.

Datastore capacity and accessibility also depend on cluster membership, device availability, vSAN network connectivity, and overall health. A failed host or disk may reduce available capacity even when the remaining raw devices still appear healthy. A network partition can prevent hosts from communicating with object components and may affect whether objects retain quorum.

The vSAN Object-Based Storage Model

vSAN stores VM data as objects. An object is a vSAN-managed logical representation of a VM component whose data and protection pieces are placed across the cluster. A virtual machine is therefore not treated as one indivisible storage unit.

Common object types include:

• A VM home or namespace object, representing the VM's home area and associated configuration or metadata content.
• A VMDK object for each individual virtual disk.
• Snapshot-related objects or delta components.
• Swap-related data where applicable.
• Other VM components supported by the vSphere and vSAN versions in use.

A VM with two virtual disks normally has at least two separate VMDK objects, in addition to its VM home object. Each object can have its own placement and protection characteristics when policy assignment permits it.

VM files, namespaces, and virtual disks

The VM home or namespace object represents the virtual machine's home area. It contains configuration and metadata files such as the VM configuration and related descriptive information. The data held by a VMDK is represented independently as a VMDK object rather than being treated as ordinary data inside the VM home object.

This separation enables vSAN to apply placement and policy rules at a useful granularity. For example, an operating-system disk can use one policy while a database disk uses another, even though both disks belong to the same VM and reside on the same vSAN datastore.

VM component: VM configuration and metadata. Typical object: VM home or namespace object. Purpose: VM identity, configuration, and home content. Policy scope: VM home policy.

VM component: Operating-system VMDK. Typical object: VMDK object. Purpose: Operating-system data. Policy scope: Individual virtual-disk policy.

VM component: Database VMDK. Typical object: VMDK object. Purpose: Database data. Policy scope: Individual virtual-disk policy.

VM component: Snapshot data. Typical object: Snapshot-related object or components. Purpose: Changed blocks associated with a snapshot. Policy scope: Usually derived from the relevant VM or disk policy.

VM component: VM swap data where applicable. Typical object: Swap-related object. Purpose: Guest memory swap storage. Policy scope: vSAN and VM configuration dependent.

Distributed Placement, Components, and Availability

Each object is made from one or more components. A component is a physical placement unit that forms part of an object, such as a replica, data fragment, parity fragment, or witness.

vSAN distributes object data and protection components across hosts and storage devices according to the assigned policy. The layout may use:

• Mirroring: Maintaining separate replicas of data.
• Erasure coding: Splitting data into data and parity fragments to provide protection with a different capacity trade-off.
• Witness components: Small metadata components used to establish quorum for certain protected layouts.

A witness is not a complete data replica. It helps determine which components form the authoritative, available object layout. vSAN attempts to avoid placing required protection components in the same failure domain when enough hosts and fault domains exist.

A fault domain is a grouping of hosts intended to represent a common failure boundary, such as a rack. Fault-domain-aware placement helps prevent one rack-level failure from removing all required components. The actual layout depends on the policy, vSAN architecture, number of hosts, fault domains, and available capacity.

Failure implications

• Host failure: Objects with sufficient protection may remain accessible, while affected objects can become reduced or noncompliant until they are repaired.
• Disk or device failure: Components on the failed device become absent or degraded and may require rebuilding elsewhere.
• Network failure: Lost vSAN VMkernel connectivity can isolate components, reduce quorum, or disrupt datastore and VM access.
• Fault-domain failure: Protection is effective only when components were placed across suitable failure boundaries.

After a failure, vSAN may begin resynchronization, the process of rebuilding or rebalancing object components after a failure, policy change, capacity change, or maintenance activity.

Storage Policy-Based Management

One vSAN datastore can serve workloads with different service levels. A storage policy is a ruleset that specifies the availability, placement, and service characteristics required for VM storage objects.

Common policy rules include:

• Failures to tolerate: The number of failures an object should withstand while remaining available, subject to cluster resources and design.
• Failure tolerance method: The protection approach, such as mirroring or erasure coding.
• Stripe width: The number of stripes used for a component layout where supported and relevant to the vSAN version.
• IOPS limit: A per-object input/output operations limit where this rule is available and appropriate.
• Object space reservation: The percentage of logical object space reserved rather than thinly allocated, where supported.
• Checksum and data services: Data-integrity and service options supported by the vSAN version and selected architecture.

Policies can be assigned to the VM home object and to individual virtual disks. Thus, a VM may have a general policy for its home data, a standard policy for its operating-system disk, and a higher-protection or higher-performance policy for its database disk.

Workload: Development VM. Availability: Low or moderate. Performance/capacity: Favor efficient capacity use. Suggested characteristics: Low protection overhead, subject to organizational requirements.

Workload: General production VM. Availability: Tolerate one host or fault-domain failure. Performance/capacity: Balanced protection and capacity. Suggested characteristics: One failure to tolerate with a supported protection method.

Workload: Database disk. Availability: High availability and predictable performance. Performance/capacity: Consider stripe width, IOPS limits, reservation, and protection overhead. Suggested characteristics: A policy designed specifically for the database workload.

Policy compliance versus accessibility

Accessibility answers whether the object can currently be read and written. Policy compliance answers whether the object's current layout satisfies its assigned policy.

An object can remain accessible but be noncompliant after a host or disk failure. For example, a mirrored object may continue serving I/O from one surviving replica while waiting for a replacement component. Conversely, an object may have a policy that appears appropriate but still be inaccessible if the required quorum or data components cannot be reached.

Protection and Capacity Trade-Offs

Protection increases the physical capacity and host resources required to store a logical object. Consider a 100 GB virtual disk:

Protection approach: No additional protection. Conceptual layout: One data layout. Capacity overhead: Lowest protection overhead, but little or no failure tolerance. Cluster considerations: Suitable only when the design and workload accept the risk.

Protection approach: Mirroring. Conceptual layout: Multiple complete data replicas. Capacity overhead: Approximately one additional logical copy for a two-way mirror, plus operational overhead. Cluster considerations: Requires suitable host or fault-domain separation.

Protection approach: Erasure coding. Conceptual layout: Data and parity fragments. Capacity overhead: Often more capacity-efficient than full mirroring for eligible layouts, but requires additional fragments and suitable resources. Cluster considerations: Requires enough hosts or fault domains and support from the selected architecture.

Protection approach: Witness-supported layout. Conceptual layout: Data or replica components plus a small witness component. Capacity overhead: Witness uses little space compared with data components, but it is essential to quorum. Cluster considerations: The witness must be placed separately when the design requires separation.

These are conceptual comparisons rather than exact sizing formulas. The vSAN version, object size, policy rules, data services, and cluster architecture determine the actual physical consumption.

Prerequisites and Requirements

Before relying on a vSAN datastore, verify the following:

• A properly configured vSAN cluster with compatible ESXi hosts.
• Supported storage devices and controllers, with correct firmware and driver combinations.
• A vSAN VMkernel network configured on every participating host.
• Reliable, appropriately designed connectivity between hosts, including consistent VLAN, MTU, routing, and physical network settings where applicable.
• Enough hosts and fault domains for the selected availability architecture and policy.
• Verified licensing and entitlement for the required vSAN features.
• Version and compatibility checks across vCenter Server, ESXi, controllers, devices, and policy features.
• Enough claimed capacity and operational headroom for normal growth, repairs, maintenance, and resynchronization.
• Successful vSAN health checks before production workloads are placed on the datastore.

At cluster level in vSphere Client, the configuration workflow generally includes enabling vSAN, selecting supported deployment and architecture options, claiming eligible devices, configuring the vSAN VMkernel network on every host, and validating health.

Practical Configuration Workflow

Enable and configure vSAN

1. Prepare the cluster and confirm host, device, controller, network, licensing, and version compatibility.
2. Configure a vSAN VMkernel adapter on each participating ESXi host and verify host-to-host connectivity.
3. Enable vSAN for the selected cluster in vSphere Client.
4. Select the vSAN architecture and deployment options supported by the environment.
5. Claim or assign eligible storage devices for each host.
6. Review the generated vSAN datastore and run cluster health checks.
7. Resolve configuration warnings before placing production workloads on the datastore.

Create and apply a VM storage policy

1. Create a VM storage policy with vSAN-specific availability and performance rules.
2. Confirm that the policy is compatible with the target vSAN datastore.
3. Assign the policy to the VM home object and, when needed, to individual virtual disks.
4. Review compliance at both VM and disk level.
5. Monitor resynchronization after applying or changing the policy.

For access and administrative delegation, review assigning permissions and the ESXi access control system.

Managing the Datastore in vSphere Client

Administrators normally inspect the vSAN datastore and its objects through vSphere Client rather than directly manipulating an underlying storage filesystem. Useful views include:

• Cluster and datastore capacity, free space, and usage trends.
• vSAN health, configuration consistency, network status, and device status.
• VM storage policy assignment and compliance.
• Object health, component placement, absent or degraded components, and resynchronization activity.
• Pending repairs, rebalance operations, and capacity-related warnings.

OSFS is a historical term associated with the object-store filesystem layer used in early Virtual SAN explanations. Administrators normally manage vSAN through the vSAN datastore, vSphere Client, storage policies, health views, and supported object-inspection tools rather than treating OSFS as a conventional host-local filesystem.

Changes that trigger data movement

• Adding hosts or capacity: Increases available resources and may cause rebalancing or enable previously impossible policy layouts.
• Removing a host: Can require evacuation and rebuilding of components, and may reduce policy capability if resources are not replaced.
• Maintenance mode: The selected evacuation option determines whether data is fully evacuated, temporarily inaccessible, or left in place. The choice must match the planned work and availability requirements.
• Replacing failed devices: Can initiate component rebuilding and resynchronization.
• Changing a policy: May create, delete, or relocate components until the object satisfies the new policy.

Before maintenance, confirm sufficient free capacity for evacuation or rebuild operations. Verify that affected objects remain accessible and compliant, or document the expected period of reduced availability.

Datastore Health States and Administrative Meaning

State or condition: Healthy and compliant. Meaning: Components are available and objects satisfy their policies. Likely impact: Normal operation. Administrator action: Continue monitoring capacity and health.

Accessible but noncompliant. Meaning: The object can serve I/O, but one or more required policy components are absent, degraded, or incorrectly placed. Likely impact: Reduced protection until repair. Administrator action: Check failures and resynchronization, then restore compliance.

Resynchronizing. Meaning: vSAN is rebuilding or rebalancing object components. Likely impact: Extra capacity and device/network activity; protection may be temporarily reduced. Administrator action: Monitor progress and avoid exhausting free capacity.

Inaccessible. Meaning: Required data or quorum cannot currently be reached. Likely impact: VM or datastore I/O disruption. Administrator action: Restore hosts, disks, network paths, or quorum and investigate object health.

Low capacity. Meaning: Free space or operational headroom is approaching a critical threshold. Likely impact: Growth, evacuation, policy changes, and rebuilds may fail. Administrator action: Remove unnecessary consumption or expand supported vSAN capacity.

Troubleshooting Common Problems

A storage policy is incompatible with the vSAN datastore

Likely causes include insufficient hosts, fault domains, free capacity, or unsupported protection methods. Review the policy compatibility details, host count, fault-domain configuration, claimed capacity, and available free space. Confirm that the rules match the vSAN version and architecture.

Resolve the issue by adjusting the policy or adding the resources required to satisfy it. After assignment, check compliance and monitor any resynchronization.

An object is noncompliant after a host or disk failure

A component may be absent or degraded, or there may not be enough capacity or eligible hosts to rebuild it. Review object health and resynchronization status. Identify failed hosts, disks, and network paths, then check whether available capacity can support the policy.

Restore failed infrastructure or replace failed devices, add resources when necessary, allow resynchronization to complete, and verify the final object state.

The datastore has low available capacity

VM growth, snapshots, protection overhead, resynchronization, reserved space, or a recent policy change may be consuming capacity. Identify the largest consumers by VM, object type, and snapshot use. Review pending resynchronization and active capacity alarms.

Remove unnecessary data or snapshots where appropriate, expand vSAN capacity with supported devices or hosts, and avoid aggressive policy changes until sufficient operational headroom is restored.

Access is disrupted after a network issue

Check vSAN VMkernel connectivity, VLAN consistency, MTU settings, physical network status, and host configuration. Determine whether hosts are partitioned and whether affected objects retain quorum.

Restore consistent and redundant vSAN network connectivity, correct mismatched settings, verify object accessibility, and wait for required resynchronization.

Worked Examples

One VM with two disks and different requirements

Suppose a VM has a 60 GB operating-system disk and a 500 GB database disk. Both can remain on the same vSAN datastore. Assign a standard availability policy to the operating-system disk and a higher-performance or higher-protection policy to the database disk. The separate VMDK objects allow vSAN to apply those requirements independently; a second datastore is not required.

VM object inventory

A VM with a home directory, two VMDKs, and a snapshot consumes multiple vSAN objects: one VM home or namespace object, two VMDK objects, and snapshot-related objects or components. Each object can have a distributed component layout rather than existing as one undivided file set on one host.

Host failure with a protected object

Assume a VM disk uses a policy designed to tolerate one host failure and the cluster has enough eligible resources for that layout. If one host becomes unavailable, the surviving components can continue serving the object. The object may temporarily be accessible but noncompliant. vSAN then resynchronizes replacement components when suitable capacity and connectivity are available.

Changing a policy

Changing a disk from a no-failure-tolerance policy to a policy tolerating one failure requires vSAN to create and place additional protection components. During this operation, the object may be resynchronizing. It becomes compliant only after the new layout is successfully created and placed according to the policy.

Exam-Relevant Notes

• Enabling vSAN creates a shared cluster datastore backed by host-contributed storage.
• A vSAN VM is composed of multiple objects, not one indivisible object.
• Each VMDK is represented independently, so different disks can use different policies.
• Replicas, erasure-coded fragments, and witnesses are components of an object layout.
• Witnesses provide quorum metadata; they are not full data copies.
• Failures to tolerate describes the desired failure resilience, but the cluster must have enough hosts, fault domains, and capacity to implement it.
• An object can be accessible while noncompliant during a failure or resynchronization.
• Policy changes, maintenance, failures, and capacity expansion can trigger resynchronization or rebalancing.
• Free capacity must include headroom for growth, repairs, evacuations, and temporary component creation.
• Administrators normally manage vSAN through vSphere Client, storage policies, health views, and supported object tools rather than direct filesystem operations.

Summary

The VMware vSAN datastore presents pooled host-local storage as one shared datastore for a vSAN cluster. Behind that simple datastore view, vSAN represents VM home data, virtual disks, snapshots, swap-related data, and other components as separate objects. It distributes each object's components across hosts and storage devices according to storage policy requirements and available fault domains.

This object and policy model lets different workloads share one datastore while receiving different availability, performance, capacity, and data-service characteristics. Successful operation depends on compatible hosts and devices, reliable vSAN networking, sufficient capacity, appropriate policies, and continuous monitoring of object health, compliance, and resynchronization.