VCF 9.1 is Out. What Does This Mean to You?

VCF 9.1 dropped yesterday and the timing is excellent. Broadcom released the preview of their Private Cloud Outlook 2026 alongside the announcement, and the headline numbers are hard to miss. That’s a directional shift in how enterprises think about production AI. It also lines up with what customers I work with have been saying privately for the past year. The economics of public cloud inference don’t pencil out at the volumes they’re now hitting.

Let me walk through what 9.1 actually changes in real planning conversations. The release explicitly tackles three challenges every customer I work with is wrestling with at the same time. That’s the right framing, and 9.1 is the first VCF release that takes a real swing at all three at once.

There’s a lot to dig into across the 9.1 release. The six capabilities I want to focus on here are the ones that sharpen what an architect can plan for in 2026, and they line up exactly with what the agentic enterprise platform layer needs to sit on in production. That’s why 9.1 reads as a stepping stone.

Below is the practical version. Six scenarios. For each one: the situation, the 9.1 capability that addresses it, and what you actually do with it. If your environment looks like one of these, you have a real plan to go build this quarter.

// USE CASE 01Your fleet is out of memory headroom

Almost every infrastructure lead I’ve sat with this year arrives with the same problem. The host fleet was sized in 2022. Workload memory demand has crept up by thirty to fifty percent since. The refresh cycle should have started six months ago, but capex is tight and the AI program wants every spare dollar for GPU.

What 9.1 brings

• NVMe memory tiering Hot pages stay in DRAM. Cold pages move transparently to high-speed NVMe.
• Higher effective memory per host Consolidation ratios go up. The host fleet stretches further on the iron you already have.
• Dynamic enable, no reboot 9.0 needed a maintenance window to turn this on. 9.1 flips it on running hosts.

What to do with it

Pilot it on a non-critical cluster first. Measure the real reduction in memory pressure and the impact on tail latency for your most demanding workload. Once you have numbers from your environment, walk into your next planning cycle with a concrete capex deferral story for the CFO. For a 600-host fleet, the difference between needing a refresh now and needing it in eighteen months is the kind of capex deferral that makes room for the AI program without sacrificing other workloads.

One caution. Tiering shifts pressure onto NVMe write endurance and can amplify tail latency on memory-sensitive workloads if the working set is misjudged. I would not turn this on under a transactional database tier without testing first.

// USE CASE 02You’re planning AI capacity around GPU count

Every AI capacity conversation I’ve been in this year starts and ends with GPU count. How many H100s, when, which generation, which vendor. Fair questions, but they’re only half the conversation. Agentic workloads spend most of their wall-clock time on CPU, not GPU. Decision orchestration, tool calls, retrieval, evaluation steps. All of that runs on CPU. Size a platform around GPU alone and you’ll hit a CPU bottleneck before the GPUs are saturated.

What 9.1 brings

• Mixed compute management CPU and GPU treated as equally first-class on a unified VCF substrate.
• Workload-aware scheduling Placement based on what workloads actually need: CPU cycles, GPU cycles, memory bandwidth, NUMA topology.
• AI observability Time to first token, token throughput, and GPU utilization across multiple accelerator types. You can see where time is going.
• Open accelerator ecosystem AMD, Intel, and NVIDIA in the same domain instead of running parallel stacks.

What to do with it

Build a small mixed-workload pilot. One inference path on GPU, one agentic workflow on CPU, both running under VCF Operations observability. Measure where the agent loop actually spends its time. Most architects discover the inference call is fast and the orchestration around it is what’s eating wall-clock. Bring those numbers to your next AI capacity discussion and use them to push back on a GPU-only sizing model. You’ll size more accurately and spend less.

// USE CASE 03Coordinating across the SDN overlay and physical fabric

This one is more technical than dramatic, but it’s a real source of operational complexity in any large environment. The NSX overlay and the physical fabric have historically used different protocols and different management tooling. Even with strong teams on both sides, every cross-domain change carries coordination overhead, and cross-domain incidents take longer to triage than single-domain ones.

What 9.1 brings

• EVPN-VXLAN interoperability NSX overlay and the physical fabric finally share a routing language. Arista, Cisco, SONiC.
• Distributed Transit Gateways Connect VPCs straight from ESXi hosts using a VLAN ID. No edge cluster required.
• Cleaner legacy migration path The long tail of VLAN-bound apps gets a smoother path forward.

What to do with it

Pick one fabric segment and stand it up on EVPN-VXLAN. Measure change-window duration and incident triage time before and after. Once you have those numbers from your own environment, you have a credible operating-model story to bring to leadership. Removing protocol mismatch between layers is the kind of fix that compounds across every change cycle.

// USE CASE 04You’ve been asked to host AI agents

The mandate has come down. The business wants agents. Customer service, internal IT, treasury workflow, take your pick. You’ve been asked to host them, and your Kubernetes estate is, charitably, not ready. The current VKS deployment is small, the lifecycle process is artisanal, and the security architecture review for service mesh has been on the backlog for a year.

What 9.1 brings

• VKS at fleet scale 500 Kubernetes clusters per Supervisor.
• Faster lifecycle Seventy percent faster deployments. Seventy-five percent shorter upgrade windows.
• Embedded Istio service mesh mTLS and L7 routing without any application change.
• IPFIX flow data Container traffic in VCF Operations alongside VM traffic.
• Container-as-a-Service path A simpler on-ramp for teams not ready for full Kubernetes.
• Tanzu Platform Agent Foundations The agent runtime story sitting one layer up.

This is also where 9.1 connects to the agentic enterprise platform stack I’ve written about previously. That stack is the architecture for hosting autonomous agents in production. It assumes a substrate that scales Kubernetes like a fleet, that ships an opinionated mesh by default, and that gives you observable flows across both VMs and containers. 9.1 is where that substrate finally lines up. Without it, the agentic platform is theory. With it, you can start building.

What to do with it

Build a small VKS cluster for your first agent workload and use it to prove the lifecycle. Measure how long a deploy takes, how an upgrade behaves, what the IPFIX visibility actually looks like in your operations console. The whole agentic-platform story only holds if VKS can be run like a fleet rather than a science project. With 9.1, it’s possible. The rest is execution in your fleet.

// USE CASE 05Your auditors keep finding the same drift

The annual audit comes around. The same drift findings come up. Configuration changes that bypassed the change process. Patches that didn’t land on every host. Compliance posture that was good at last quarter’s snapshot but isn’t now. Your team spends six weeks closing findings and the cycle starts again. For regulated environments under MAS, BNM, or HKMA expectations, repeated drift findings cross from annoying into actual audit exposure.

What 9.1 brings

• Continuous compliance enforcement Built-in drift detection alerts on unauthorized changes in real time, not at audit time.
• Enhanced live patching ESXi and vCenter security patches in partial maintenance mode, with workloads still online.

What to do with it

Take your top twenty audit controls and translate them into runtime policies. Let the platform watch them every minute instead of every quarter. The mechanism is only as good as the policies you author, so this is real work, but it’s the kind of work that compounds. Six months in, your audit prep is a generated report, not a six-week project.

// USE CASE 06Your AI agents need a data tier you control

Situation

The agent program is real. It needs a vector store for retrieval, a Postgres or two for state, and somewhere a SQL Server is still anchoring a system of record. The default path was managed services in public cloud, and the bills are landing harder than anyone modelled. The CISO has questions about embeddings and training data leaving the perimeter that nobody has a clean answer for, and the program has stalled twice in security review.

What 9.1 brings

• PostgreSQL with pgvector Vector embeddings for RAG, semantic search, and agent memory, running inside VCF as a managed service.
• Microsoft SQL Server 2022, GA Full lifecycle automation, Always-On availability groups, sub-30-second failover. No specialised SQL DBA needed for the routine.
• MySQL with fast cloning Space-efficient clones in seconds. Test environments stop being the bottleneck.
• Unified self-service catalog VMs, Kubernetes, and databases through the same VCF Automation APIs. Terraform and GitOps work end-to-end.
• FIPS 140-2 for PostgreSQL and MySQL A clean answer for the CISO on data sovereignty and cryptographic posture. Embeddings stay inside the perimeter.

What to do with it

Pick one AI workload that needs retrieval. Stand up Postgres with pgvector under DSM, point a small RAG pilot at it, and instrument the cost and latency from end to end. Compare that against the public cloud DBaaS bill for the same workload at the same scale. The gap is the business case. Once it’s proven on one workload, the conversation shifts from can we run our own database tier to which databases come home next, which is a different planning problem entirely.