Shared VMDK Expansion on vSAN in VCF 9.1 Retiring the Last Outage Window for Clustered Applications

Clustered applications Windows Server Failover Clustering foremost among them have always been the awkward tenants of virtual infrastructure. They need shared disks; shared disks came with an operational caveat list. The caveat that hurt most in production: growing a shared VMDK meant coordinating an application outage. VCF 9.1 removes it shared VMDKs used by clustered applications on vSAN can now be expanded online.

Why This Mattered More Than It Sounds

• Database clusters grow that’s what they do. The inability to grow their shared storage online forced a recurring choice between painful outage negotiations and wasteful up-front over-provisioning.

• The over-provisioning workaround directly fought the vSAN ESA efficiency story capacity was burned to avoid change windows, undermining the dedup and compression economics the platform was delivering everywhere else.

• Every growth event was a cross-team negotiation: application owner, DBA, infrastructure, and change management coordinating an outage for what is, everywhere else in the estate, a routine online operation.

The Design Conversation Changes

For architects carrying legacy WSFC estates through VCF migrations, the target-state conversation shifts. The shared-disk constraint list the section of every migration assessment that catalogued what clustered workloads couldn’t do on the target platform just got shorter. Shared storage for clustered applications can now be right-sized at migration and grown on demand, the same as everything else.

This composes with the broader vSAN 9.1 storage story: global deduplication at cluster scope, the Effective Capacity view for honest capacity reporting, Auto-RAID policy selection, and persistent volume scale of 25,000 per Supervisor. The pattern across the release is consistent workload classes that required special handling keep moving into standard operations, and every such move simplifies the operational model.

Operational Guidance

Revisit the over-provisioned clustered estates first. Clusters that were sized with years of headroom to avoid expansion outages are now carrying reclaimable capacity the Effective Capacity view will show exactly how much. Right-sizing those volumes and returning the capacity to the pool is a concrete, quantifiable win from the upgrade, and it’s the kind of number that makes the 9.1 business case retrospective look good.

Update the clustered application runbooks at the same time: the storage growth procedure loses its outage coordination section, and the DBA team’s capacity request lead time shortens accordingly. Small operational documents, but they encode the constraint leave them stale and the organisation keeps behaving as if the constraint still exists.

The Architect’s Takeaway

Shared VMDK online expansion is a narrow feature with a wide beneficiary base nearly every enterprise estate carries clustered database workloads, and all of them have paid the outage-or-overprovision tax. VCF 9.1 retires it. Shorten the constraint list in your migration assessments, reclaim the defensive over-provisioning, and let clustered applications finally be ordinary tenants.

Sources

• Broadcom Expand Shared VMDKs with Clustered Applications in VMware vSAN for VCF 9.1

• Broadcom Optimize, Modernize and Protect Your Private Cloud Storage with vSAN in VCF 9.1

• Broadcom Simplifying Storage with the New Effective Capacity View in vSAN for VCF 9.1

• Broadcom Announcing VCF 9.1: Modern Private Cloud Built for Efficiency and Resilience