Prerequisites

Confirm the items below before you claim any devices. vSAN ESA expects flash NVMe drives that pass its compatibility check and a cluster that already reports green health. Gather admin access to vCenter, and to SDDC Manager if you plan to add hosts.

Step 1, Review current capacity and headroom

Start by measuring how much usable space remains so you size the expansion correctly.

1. Select the vSAN cluster in vCenter.
2. Click the Monitor tab.
3. Under vSAN, click Capacity.
4. Read the Capacity Overview for used and free space, then check the Usable capacity analysis for your policy.
5. Open VCF Operations and review the capacity dashboards to see how the cluster trends over time.

Size the expansion against a target of free operational slack rather than filling the cluster to the last block. vSAN needs headroom for rebuilds, host maintenance and transient policy changes, so plan to keep a meaningful margin free after growth. If VCF Operations shows a steady climb toward that margin, expand before you cross it rather than waiting for a capacity alarm. Record the current usable figure so you can compare it against the post claim total during verification.

Step 2, Confirm device and hardware compatibility

vSAN ESA only claims devices that meet its compatibility rules, so clear any hardware warnings first.

1. Confirm each new drive is a TLC NVMe device listed on the vSAN ESA compatibility guide.
2. In vCenter, select the cluster and click the Monitor tab.
3. Under vSAN, click Skyline Health.
4. Review the Hardware compatibility checks and resolve any warnings before you add devices.

vSAN ESA enforces stricter device rules than the older architecture, so a drive that worked in a lab OSA cluster may not qualify here. Match the drive model, firmware and controller against the vSAN ESA compatibility list, and confirm the device is a TLC NVMe class drive rather than a QLC or SATA device. Clearing hardware warnings now avoids a failed claim task later, when the device is already installed and harder to swap.

Step 3, Add flash devices to existing hosts

Scale up when hosts have empty drive bays. Install the new NVMe devices following your hardware vendor guidance, then prepare each host so vSAN stays healthy during the physical work.

1. In vCenter, right click the target host and select Maintenance Mode, then Enter Maintenance Mode.
2. Choose Ensure accessibility as the vSAN data migration option.
3. Install the flash devices in the empty bays per your vendor guidance.
4. Right click the host and select Exit Maintenance Mode once the work is done.
5. Wait for the host to rejoin and report green health before moving on.

Many servers support hot plug NVMe, so a physical add may not require a full maintenance window. Even so, entering maintenance mode with Ensure accessibility keeps data available while you work and protects against an accidental removal of the wrong device. Add devices to one host at a time and let each host settle before you touch the next, so the cluster never loses more than one host worth of components at once.

Step 4, Claim the new devices into the storage pool

Newly installed devices sit unused until you claim them. Claiming happens in vCenter Disk Management.

1. Open vCenter and select the vSAN cluster in the inventory tree.
2. Click the Configure tab.
3. Under vSAN, click Disk Management.
4. Click Claim Unused Disks.
5. Group the list by host, then select each new NVMe device you want in the storage pool.
6. Click Create to add the devices to the storage pool.
7. Watch the Recent Tasks pane until the claim task reports Completed.

Where vSAN Managed Disk Claim is enabled, vSAN claims compatible devices for you as they appear, and manual claiming becomes a fallback rather than a routine step. After the claim completes, vSAN begins a background rebalance to spread data across the larger pool. Let that rebalance finish before you measure the final usable figure, because capacity and component counts keep moving until it settles. You can watch rebalance progress under Cluster, Monitor, vSAN, Resyncing Objects.

Step 5, Scale out by adding hosts when bays are full

Scale out when hosts have no free bays or you need more compute alongside storage. Adding a host to a cluster is a domain level operation, so it runs in SDDC Manager rather than vCenter. Follow Part 12, adding ESXi hosts to a cluster for the commission and add host workflow, then return here. With vSAN Managed Disk Claim on, vSAN claims compatible devices on the new host automatically; otherwise claim them in Disk Management as in Step 4. To add an entire cluster to a domain instead, see Part 13, adding a cluster to a workload domain.

Step 6, Turn on space efficiency features

Once the pool is larger, VCF 9.1 space efficiency settings squeeze more usable capacity from the same drives. Compression is improved in this release, and Global Deduplication runs cluster wide as a post processing task with encryption support.

1. Select the vSAN cluster, then click the Configure tab.
2. Under vSAN, click Services.
3. Find the Space Efficiency row and click Edit.
4. Set space efficiency to Compression only or Deduplication and compression as your design requires.
5. Click Apply to save the change and let vSAN process existing data in the background.

Step 7, Let Auto RAID manage resilience

VCF 9.1 defaults vSAN clusters to Auto RAID, the successor to Auto-Policy Management. A single cluster policy adjusts resilience as the host count changes, which removes the need to hand build separate storage policies for each cluster size. As you scale out, vSAN moves the cluster to the layout below without further action from you.

To review the applied policy, open Policies and Profiles from the vCenter menu, then click VM Storage Policies and inspect the vSAN default policy assigned to the cluster. Existing virtual machines keep their assigned policy, and Auto RAID handles the resilience level under it, so you rarely edit per object policies by hand. When a cluster crosses a host count boundary, such as growing from five hosts to six, vSAN moves the layout from RAID 5 to RAID 6 and rebuilds affected objects in the background. Plan such transitions during a quieter window, since the rebuild consumes cluster resources while it runs.

Step 8, Mount remote vSAN capacity instead of adding drives

When a cluster needs more space but you would rather not add local drives, VCF 9.1 lets a cluster mount a remote vSAN datastore from a separate vSAN storage cluster. This release also allows a cluster to mount both vSAN OSA and vSAN ESA datastores at the same time. Use this disaggregated path when compute and storage grow at different rates.

1. Select the client cluster, then click the Configure tab.
2. Under vSAN, click Remote Datastores.
3. Click Mount Remote Datastore.
4. Select the vSAN storage cluster datastore to mount, then confirm the compatibility check passes.
5. Click Finish to mount the remote capacity to the client cluster.

Verify the expansion

Confirm the new capacity is in use and healthy before you consider the task done. Check each of the following.

• In vCenter, open Cluster, Monitor, vSAN, Capacity, and confirm total capacity rose by the expected amount.
• In Disk Management, confirm the new devices show as In use and mounted with green health.
• Run Skyline Health and confirm every vSAN check returns green, including the physical disk checks.
• Confirm the storage pool on a host lists the new devices over SSH:

esxcli vsan storagepool list

Each new NVMe device should appear in the output with a state of mounted and a role that includes both cache and capacity. Give the cluster time to finish any resync before you sign off, and confirm the compression or deduplication savings show in the Capacity view once background processing catches up. A clean Skyline Health run plus a stable, higher usable figure is your signal that the expansion is complete and the cluster is back to a steady state.

Common errors and fixes

Common questions

Whether ESA needs matching drive sizes. vSAN ESA works best with consistent device sizes across hosts, and mixed sizes can leave capacity stranded. Aim for a uniform device size within the storage pool where you can.

How Auto RAID changes existing policies. On upgrade to VCF 9.1, vSAN replaces discrete manual or Auto-Policy Management policies with one cluster policy that adjusts resilience as the host count changes, so you no longer maintain a policy per cluster size.

Whether you must add disks to every host. Adding devices to a single host still adds usable capacity, but balanced growth across hosts gives the cluster more even resilience and rebuild behaviour. Add devices evenly when you can.

How this differs from replacing a failed drive. Expansion adds new capacity to a healthy cluster, while a failed device is a remediation task. For a failed host, follow Part 17 of this series once it is published.

Whether Global Deduplication suits every cluster. Global Deduplication runs cluster wide as a post processing task, so it trades some background work for extra usable space. It fits capacity focused clusters with repetitive data, while latency sensitive clusters may prefer compression only. Test the setting against a representative workload before you commit to it across the fleet.

Where fleet wide capacity trends live. vCenter shows capacity for one cluster, while VCF Operations aggregates capacity and forecasts across every cluster in the fleet. Use VCF Operations to spot which clusters will need expansion next, then return to this task for the cluster you choose to grow.

References

• VMware Cloud Foundation 9.1 Release Notes, vSAN 9.1 New Features
• Auto-RAID in VMware vSAN for VCF 9.1, VCF blog
• Selecting the Best RAID Configuration for a vSAN Storage Cluster, Broadcom TechDocs
• Optimize, Modernize and Protect Your Private Cloud Storage with vSAN in VCF 9.1, VCF blog

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts