VCF 9.1 was released last week and created quite a buzz in the VMware community worldwide. If VCF 9.0 was the architectural reset, 9.1 is the optimization layer — the release where the new constructs introduced in 9.0 get hardened, scaled, and made operationally practical.

Over the coming posts, we’ll build a full VCF 9.1 environment from scratch in a home lab, making deliberate architectural choices at every step and explaining why—not just how. I’ll cover the management domain build, workload domain deployment, NSX design decisions, vSAN ESA configuration, VKS (vSphere Kubernetes Service), VCFA automation, and lifecycle management.

Let’s start with the foundation: what changed in 9.1, what the high-level design looks like, and the practices that distinguish production-grade thinking from home lab shortcuts.

VCF Management Services: A Unified Control Plane Runtime

The headline architectural change in 9.1 is the introduction of VCF Management Services—a common runtime that unifies the platform’s lifecycle and operational capabilities. Previously, components like VCF Operations and VCF Automation ran as largely independent services. 9.1 collapses these into a shared infrastructure layer, which simplifies upgrades, reduces footprint, and makes the operational surface more predictable.

For architects, the implication is important: the management domain is no longer just a “landing zone for vCenter and NSX.” It is now the active control plane for the entire fleet’s operational stack.

vSphere Kubernetes Service (VKS) at Scale

VKS receives a significant capacity and performance upgrade in 9.1. The re-engineered supervisor architecture now supports up to 500 clusters per supervisor and doubles host capacity to 5,000, while increasing parallel upgrade throughput from 64 to 256 clusters simultaneously. Provisioning speed improves by up to 70% through the use of linked clone technology — the same mechanism now extends to First Class Disks (FCDs), enabling fast-path provisioning of container storage volumes.

For architects evaluating VKS for enterprise Kubernetes platform strategies, these numbers materially change the conversation. A single VCF instance can now plausibly host a very large-scale container platform without the multi-supervisor sharding workarounds required in earlier releases.

VM Fast-Deploy

Linked clone technology isn’t limited to Kubernetes. VCF 9.1 brings VM Fast-Deploy, extending rapid provisioning to standard VM workloads. This is a material operational improvement for VDI-style environments and developer platforms where VM spin-up time directly impacts user experience and automation pipeline latency.

Simplified Container-as-a-Service (CaaS)

A new self-service namespace provisioning model allows developers to consume containers without requiring full Kubernetes cluster management. Namespace constructs — including registry, ingress, quotas, and identity — are inherited directly from VCF constructs. The design intent is to give platform teams a “lite” container offering that doesn’t require standing up a full VKS cluster per team.

For architects, this is a tenant model question as much as a feature question. The design decision is whether to offer CaaS namespaces as a self-service tier beneath VKS clusters or to gate all container consumption through VKS.

Native Object Storage (Tech Preview)

VCF 9.1 introduces self-service S3-compatible object storage as a tech preview. Developers can provision, consume, and manage object storage with the same workflows used for block and file—all while IT retains policy guardrails. This is the first signal that Broadcom intends VCF to compete directly with hyperscaler IaaS consumption models on storage service breadth.

NVMe Memory Tiering Improvements

First introduced in VCF 9.0, NVMe memory tiering matures further in 9.1. ESXi’s tiering engine intelligently moves cold and very-cold memory pages from DRAM to NVMe SSDs, increasing effective VM density per host. The new memory mirroring for NVMe-tier redundancy adds availability guarantees to tiered memory—previously a concern for architects evaluating memory tiering for stateful workloads.

The economics are significant: Broadcom reports potential server cost reduction of up to 42% and storage TCO reduction of up to 39% when combining NVMe tiering with vSAN ESA deduplication.

Live Patching for ESX on TPM-Enabled Hosts

ESX 9.1 extends Quick Boot (live patching without a full power cycle) to hosts running confidential VMs with TPM. Previously, TPM attestation requirements forced a full hardware reinitialization cycle during patching, making maintenance windows significantly longer for security-hardened hosts. This change materially reduces patching overhead in regulated environments.

Hardware-Accelerated vMotion (Intel QAT)

VCF 9.1 introduces offload of encrypted vMotion operations to Intel QuickAssist Technology (QAT). Encryption for vMotion data is moved from software (consuming vCPU cycles) to dedicated QAT hardware, returning those CPU cycles to the workloads. For dense hosts with frequent vMotion activity—DRS-driven rebalancing, host evacuation, and maintenance mode—this is a measurable performance improvement.

New Release Cadence

Starting with VCF 9.x, Broadcom moved to a 6+1 support model (6 years of general support and an optional 1-year extension) with four minor releases per major version (9.0, 9.1, 9.2, and 9.3). Minor releases target 27 months of support each. For home lab architects, this means 9.1 is a stable, long-lived target worth building real institutional familiarity with. You can read more about this announcement here

To learn more about these capabilities, see the VCF 9.1: Discover What’s New page. To read the VCF 9.1 official blogs from Broadcom, click here

That’s it for this post. I hope you enjoyed reading it. Feel free to share it on social media if it’s worth sharing.