Broadcom announced VMware Cloud Foundation 9.1 on May 5, 2026. It’s not GA yet, but the scope of the announcement is large enough that it’s going to come up in conversations immediately.
Instead of piecing together multiple blog posts, this is a direct look at what actually changed — and where it matters.
Bigger environments, moving faster
At a high level, VCF 9.1 pushes both scale and speed.
Environments now scale up to 5,000 hosts, with Kubernetes persistent volumes increasing to 25,000 per Supervisor and 50,000 per vCenter. At the same time, cluster deployment drops to roughly 10–11 minutes, down from the 30–40 minute range.
Those numbers matter less on their own than they do together.
When environments get larger and provisioning becomes faster, the operating model changes. Workloads don’t arrive gradually — they appear in volume, often in parallel, and may not exist long enough for manual processes to catch up.
From a data protection standpoint, that’s where gaps start to show up.
Veeam perspective:
Protection has to be enforced at creation time, not applied after the fact. Veeam operates at that control point — applying policy at the workload level across VMs and Kubernetes as they are deployed.
vSAN is expanding its role in recovery
A significant portion of the 9.1 changes sit in vSAN, particularly around recovery.
Key additions include:
- Multi-source replication (no longer limited to vSAN-to-vSAN)
- GFS-style snapshot scheduling with up to 200 snapshots per VM
- Purpose-built Cyber Recovery ReadyNodes
- More consistent snapshot and recovery behavior across VM types
There are also efficiency improvements, with compression and deduplication changes tied to claims of up to ~39% lower TCOcompared to traditional external arrays.
The direction is clear: more recovery capability is being handled within the platform itself.
Those capabilities, however, remain tied to the same infrastructure stack — the same storage layer, control plane, and operational boundary.
Veeam perspective:
vSAN is expanding recovery inside the platform. Veeam operates outside of that boundary — where backup data, retention, and recovery orchestration are independent of the VCF control plane.
That separation defines the difference between platform recovery and independent recovery.
Networking is becoming more distributed
Networking changes in 9.1 are less visible, but they affect how environments behave.
With EVPN-VXLAN integration into physical fabrics and reduced reliance on centralized edge nodes, connectivity becomes more distributed across the environment. That shifts where and how traffic flows.
In practice, that impacts:
- Backup and replication paths
- Proxy placement
- Tenant isolation and access patterns
It’s not inherently more complex, but it does invalidate some assumptions that designs have historically relied on.
Veeam perspective:
As traffic patterns distribute, backup design becomes more topology-aware. Veeam’s role is to maintain predictable data movement regardless of where workloads are placed or how connectivity is structured.
Automation is reducing the time between request and deployment
The automation changes in 9.1 continue a trend toward faster, more repeatable infrastructure.
Cluster deployment times drop to ~11 minutes. Upgrades are reduced from hours to under two. Application stacks can be captured and redeployed through blueprints. More of this is handled through the platform without requiring CLI-driven workflows.
The important shift is not the tooling — it’s the time compression.
When workloads move from request to running in minutes, any process that relies on follow-up actions becomes unreliable.
Veeam perspective:
Protection has to be integrated into the provisioning workflow. Veeam operates at that layer — ensuring workloads are protected as part of deployment, not as a separate step.
Security improvements focus on the platform layer
There are meaningful security changes in this release.
User-Level Monitor (ULM) moves the VM monitor out of kernel space, reducing the hypervisor attack surface. Additional capabilities like hypervisor-level EDR, file integrity monitoring, and faster patching cycles further harden the platform.
These changes reduce the likelihood of compromise at the infrastructure layer.
They do not change how backup data is exposed, accessed, or protected.
Veeam perspective:
Platform hardening reduces risk, but backup data operates under a separate control model. Veeam focuses on securing that layer — through immutability, access control, and isolation independent of the platform.
The clean room model is more clearly defined
One of the more visible additions in 9.1 is the on-premises clean room capability delivered through Advanced Cyber Compliance (ACC).
It’s important to distinguish what is included:
- Base VCF includes expanded recovery capabilities through vSAN (snapshots, replication, recovery workflows)
- ACC (add-on) introduces the clean room model
The clean room is implemented as a dedicated, isolated workload domain:
- vSAN ESA storage
- NSX-based isolation with staged controls
- Separate DNS, NTP, and supporting services
- Dedicated replication network paths
The recovery workflow follows a defined sequence:
- Replicate workloads into the isolated domain
- Power on in isolation
- Analyze and scan (including EDR integrations such as CrowdStrike Falcon)
- Validate system behavior
- Restore to production
This formalizes recovery validation within the platform.
It also introduces additional requirements — separate infrastructure, additional licensing (ACC), and operational overhead.
Veeam perspective:
The clean room validates workloads inside the platform using platform-native replication and storage.
Veeam provides recovery points that are stored and managed outside of that system, with independent retention, immutability, and recovery workflows.
These operate in different layers of the recovery process.
Compliance is moving toward continuous validation
Compliance in 9.1 shifts toward continuous monitoring and drift detection across both infrastructure and workloads.
There is also a stronger emphasis on demonstrating recoverability — not just meeting configuration baselines.
This reflects how environments actually behave: systems change continuously, and point-in-time validation doesn’t capture that.
Veeam perspective:
Recoverability becomes part of compliance. Veeam addresses that requirement by validating restore points, enforcing immutability, and ensuring recovery can be performed independently of the production environment.
Where this leaves things
A few patterns are clear:
- Environments are larger (5,000 hosts, tens of thousands of volumes)
- Workloads are deployed faster (~11-minute cluster deployment)
- More recovery capability is handled within the platform
- The clean room model is now part of the architecture (via ACC)
- Security and compliance are moving toward continuous validation
These changes affect how environments are designed and operated.
Veeam perspective:
As more capability moves into the platform, the boundary between platform recovery and independent recovery becomes more defined.
Veeam operates as the independent layer — separate from the infrastructure it protects.
What to watch next
This is still based on announcement-level detail, and some aspects will evolve as the release moves toward GA.
There are a few areas we haven’t gone deep on yet — including how some of these capabilities are packaged, how they behave in real-world deployments, and where components like VCF Automation (VCF-A) fit as things mature.
Stay tuned as more information is released. I’ll break down those areas in more detail once we have something concrete to work from.
For now, this should give you a clear view of where things are headed and how to start framing the conversation.