VMware Cloud Foundation 9.1: A Field Engineer’s Read

Can KarahaliloğluLeave a comment

Broadcom released VMware Cloud Foundation 9.1 on May 5, 2026. The official messaging is all about AI. Ignore that for now. Here is what actually changed and what it means if you run these environments for a living.

First — What Is VCF?

VCF bundles vSphere, vSAN, NSX, and lifecycle management into one platform. You manage compute, storage, and networking together. One upgrade process. One support call. One control plane.

If you run standalone vSphere today, VCF is the same infrastructure — with automation and operational structure on top. It is not a replacement for your skills. It is a framework for running them at scale.

What Changed in 9.1 — Feature by Feature

Scale: 5,000 Hosts Per Instance

VCF 9.0 supported 2,500 ESX hosts per management domain. 9.1 doubles that to 5,000.

If you split environments purely because of that limit, you can now consolidate. Fewer management domains means fewer upgrade cycles, fewer failure domains to track, and less operational overhead.

Most environments will never hit 5,000 hosts. But for those who do — this matters a lot.

Faster Upgrades: Parallel Cluster Operations

Cluster upgrades now run in parallel. Broadcom claims 4x faster upgrade times.

In practice: large environments used to upgrade clusters one by one. That stretched maintenance windows significantly. Parallel operations reduce that. How much depends on your environment size and cluster count.

The Fleet Update Service handles this. It also improves upgrade readiness checks — meaning it catches problems before the upgrade starts, not during.

Live Patching: Up to 80% of Patches Without Downtime

This is the one that matters most for operations teams.

Live patching now covers up to 80% of patch use cases without host evacuation. No maintenance window. No change request. No 2am window.

The remaining 20% still requires the traditional approach. But for the majority of security patches — especially critical CVEs — you can now apply without disrupting running workloads.

Test this in your environment before relying on it for production. The 80% number is Broadcom’s figure. Your specific patch mix may vary.

Encrypted vMotion with Hardware Offload

Encrypted vMotion has always had a CPU cost. In some environments it was bad enough that teams disabled it or avoided it entirely.

9.1 offloads the encryption to hardware — Intel QuickAssist Technology. Broadcom claims approximately 70% CPU reduction during migrations.

This means you can enable encrypted vMotion without hurting application performance during migrations. Hosts return to steady state faster after a migration completes.

If you have Intel QAT hardware in your hosts, this works. Check your hardware compatibility before planning around it.

NVMe Memory Tiering

Hot memory pages stay in DRAM. Cold pages move to NVMe. The platform manages this automatically.

The result: higher VM density on the same physical hosts. Broadcom claims up to 40% lower server costs through better consolidation.

Real world caveat: the savings depend heavily on your workload memory access patterns. Workloads with predictable hot/cold patterns benefit most. Random-access workloads will see less benefit.

9.1 improves on the 9.0 implementation. It adds native software mirroring and simplifies deployment. If you tried memory tiering in 9.0 and had issues, it is worth revisiting.

vSAN Deduplication and Compression — Always On

Global deduplication and compression now run continuously in the background. This includes encrypted environments — a limitation in previous releases.

Broadcom claims up to 39% lower storage TCO. As with all TCO numbers, treat this as a best-case figure. Environments with diverse workloads and already-compressed data will see less.

The operational benefit beyond cost: storage capacity growth becomes more predictable. You are not buying capacity for peak usage. You are buying for effective usage after deduplication.

vSAN Replication: Any Source to vSAN Target

Previously, vSAN replication required a vSAN source. Now it accepts VMFS, NFS, or vSAN as a source and replicates to a vSAN target.

This is useful during storage refresh projects and environment consolidations. You no longer need to migrate storage type before enabling replication. One less prerequisite in already complex migration plans.

Continuous Compliance — Advanced Cyber Compliance (ACC)

ACC continuously checks VCF components against security baselines. It detects drift and remediates automatically. Supported baselines include VCF security guidelines and PCI DSS.

For teams that currently run quarterly compliance checks manually — this changes the workflow. Audit readiness becomes an ongoing state rather than a periodic exercise.

Be careful with automatic remediation in production. Understand what it will change before enabling it. Review the remediation policies before you turn it on.

vDefend Extended to Kubernetes

Distributed IDS/IPS now covers Kubernetes workloads running on VKS — not just VMs. 9 Tbps inspection capacity per instance. 5x more application IDs than previous versions.

If you run containers alongside VMs on VCF, you previously had a security gap between the two. That gap is now closed at the platform level.

Ransomware Recovery with CrowdStrike Falcon Support

VCF 9.1 adds isolated recovery environments and integrates CrowdStrike Falcon Endpoint Security for ransomware recovery scenarios.

The recovery environment is on-premises. This matters for organizations with data sovereignty requirements — no data leaves the environment during recovery, and no bandwidth fees for restoring large datasets from a public cloud recovery service.

Kubernetes — VKS at 500 Clusters Per Supervisor

vSphere Kubernetes Service now supports up to 500 clusters per Supervisor. Kubernetes 1.35 support. Multi-NIC support for worker nodes. 70% faster deployments and 75% shorter upgrade windows compared to preview versions.

For most infrastructure teams, Kubernetes management is someone else’s problem. But if your platform team owns VKS, these numbers are significant for scale planning.

Transition and Upgrade — The Practical Part

You Run vSphere 8.0 Update 3 or Higher — Good News

You now have two options to get into VCF 9.1 without rebuilding.

Converge to VCF Management Domain — using the VCF Installer, bring your existing vCenter/ESX environment into a VCF 9.1 management domain. No downtime. No data migration. Your workloads keep running.

Import as VCF Workload Domain — using VCF Operations, import your existing environment as a workload domain. VCF manages it for lifecycle purposes. Your older vSphere environment keeps running under VCF’s management umbrella without an immediate upgrade.

Both paths preserve existing infrastructure. Neither requires a migration of applications or data. This is a significant change from earlier adoption paths.

Official reference: VCF 9.x Release Notes — Broadcom Tech Docs

You Run VCF 5.x

You need to go through VCF 9.0 first. There is no direct jump from 5.x to 9.1. Plan accordingly — this is a two-stage upgrade, and 9.0 has its own prerequisites and readiness checks.

You Run VCF 9.0.x

Standard in-place upgrade via VCF Operations lifecycle management. Start with the upgrade readiness checks. The 9.1 compatibility matrix on the Broadcom support portal is your first stop.

Licensing — One Thing That Will Catch People Out

VCF uses two license keys now. That part is simple. The part that is not simple:

License usage must be confirmed in VCF Operations every 180 days.

In connected mode, submission is automatic. But confirmation still requires a manual step in the console. Miss the deadline and hosts disconnect from vCenter. New workloads cannot start. Existing workloads are not stopped — but your environment effectively freezes for new deployments until you confirm.

This will catch someone out during a busy period. Set a recurring calendar reminder at 150 days. Do not rely on the system to remind you sufficiently in advance.

On the AI Features

Every VCF 9.1 blog post leads with AI. Here is the honest version.

If you are building private AI inference infrastructure today — GPU workloads, model hosting, agentic applications — VCF 9.1 has relevant capabilities. Native object storage, AMD/NVIDIA GPU support, NVIDIA ConnectX-7 and BlueField-3 integration, Avi Load Balancer for inference endpoints.

If you are not — the AI features are interesting for future roadmap planning. They are not the reason to upgrade now.

The reasons to upgrade now are: live patching, parallel cluster upgrades, encrypted vMotion offload, and the converge/import paths for existing vSphere environments. Those are operational improvements that affect every environment regardless of workload type.

Numbers That Matter

What VCF 9.0 VCF 9.1 Note
Max ESX hosts 2,500 5,000 Per management domain
Cluster upgrade speed Sequential 4× faster Parallel operations
Live patching Limited 80% of use cases Broadcom figure — test in your env
Encrypted vMotion CPU High ~70% lower Requires Intel QAT hardware
Server cost reduction — Up to 40% Memory tiering — workload dependent
Storage TCO reduction — Up to 39% Dedup/compression — data dependent
Kubernetes clusters — 500 per Supervisor VKS
VKS upgrade window — 75% shorter vs preview versions
License deadline 180 days 180 days Set a reminder at 150 days

Reference Links

Running VCF in production? Hit something in 9.1 that is not in the release notes? Leave a comment.

Leave a comment