lifecycle

VCF 9.1.1 Is Billed as a Maintenance Release. The Networking Documentation Says Otherwise.

The release notes call it maintenance. It also brings an AI assistant you can point at your own model, shared models across teams, six networking changes, and a patch order that will catch you out.

Called a maintenance release. It also brings an AI assistant on your own model, shared models across teams, and a patch order that will catch you out.

If you've come here from the QR code at VMUG Sydney, this is the long version of slide two.

VCF 9.1.1 shipped on 3 September. The release notes describe it in about one sentence: a maintenance release with an updated Bill of Materials, mostly focused on supportability.

I read that and nearly moved on. Then I went through the documentation and the operations announcements that landed the same week, and there's more in here than the summary lets on. Some of it is genuinely new function. One part of it will catch people out in a change window if they treat it like a normal patch.

So here's what's actually in it, roughly in the order I'd care about it.

Before anything else: the patch order

This is the bit I'd want every engineer to read, because it contradicts what people have learned to expect.

The release notes open by saying maintenance releases generally don't affect interoperability and don't need a strict patch order. Then, in the next breath, they say 9.1.1 does, because it comes with a new BoM and has specific dependencies between components.

Fleet lifecycle

Patch the VCF management services fleet lifecycle component first. Nothing else goes before it.

Everything else, in parallel, with four catches

The software depot blocks every other patch while it updates, because the binaries aren't available. Identity broker and Salt RaaS each want their host runtime patched before them. The migration service engine wants VCF Automation done first.

The depot one is worth planning around properly. It isn't just another item on the list, it's a serialising step in the middle of your window. If the tooling happens to schedule it late, everything behind it waits.

The good news in the same release: if you're on 5.2.x or 9.0.x, you can go straight to 9.1.1, starting with VCF Operations 9.1.1. No stop at 9.1.0 on the way. If you've got a 5.2 upgrade on the plan for next year, target 9.1.1 directly and land on the newer BoM with all of the below included. I've written up the wider staged approach here if you're working out the sequence for a larger estate.

Operations and AI

AI Assistant in the VCF Operations console

An optional conversational assistant for Day-2 troubleshooting and diagnostics. What makes it usable in a bank or an insurer is that you can connect it to a model you host yourself, so operational data doesn't have to leave your environment to get an answer. Treat it as an assistant for the person on call, not a replacement for them.

Multi-Tenant Model Sharing is now GA

Until now, if three business units each wanted the same model, you tended to end up running three copies of it, each with its own GPU allocation. One instance can now serve multiple consumers. If you've got GPU capacity sitting reserved and underused, this is where you get some of it back.

OpenTelemetry-based observability for VKS

Containers come and go faster than infrastructure polling can follow, which leaves blind spots when something misbehaves for ninety seconds and then disappears. This brings real-time VKS visibility into the same operations tooling as the rest of the platform rather than a separate product.

There's also an AI gateway supporting 150-plus open-weight and third-party models, which is still in preview. I wouldn't plan around it yet.

One caution on numbers. Broadcom has quoted figures including a 2.6x Kubernetes improvement and a 46% operational cost reduction alongside this release. Those are Broadcom's own internal estimates and they're disclosed as such. Fine to mention with that attribution, not something I'd put in a business case as though it were an independent benchmark.

Networking: the part the release notes undersell

If you run, or considered and rejected, the Distributed VXLAN Connectivity Model, this is the section to read. It's the model that joins NSX to a physical EVPN-VXLAN fabric so virtual workloads and physical endpoints sit in one routing domain.

Between 9.1.0 and 9.1.1 it picked up six capabilities:

Capability

9.1.0

9.1.1

Stateful network services through a Virtual Network Appliance

Not supported

Supported

Avi Load Balancer

Not supported

Supported

EVPN Route Controller high availability

Active/Standby

Active/Active, up to 8 nodes

EVPN-VXLAN Direct Prefix Routing

Not supported

Supported

DHCP relay on VPC public subnets

Not supported

Supported

Host group affinity for route controller and VNA nodes

Not supported

Supported

Four of those were the obvious reasons to rule the model out earlier in the year. Stateful services, Avi, Direct Prefix Routing and DHCP relay are all now there. The active/active route controller matters too, since active/standby effectively capped the control plane at one working node.

Two constraints still apply and they're easy to miss. Layer 2 MAC advertisement isn't supported in the current NSX integration, so this gives you Layer 3 reachability, not Layer 2 extension. And the EVPN gateway has to advertise a default route regardless of whether Direct Prefix Routing is on. That second one is a physical fabric requirement, so it's a conversation with the network team before the design is fixed.

What you get for it is the ability to run multi-rack Layer 3 cluster designs without needing an external VLAN stretched across the Distributed Transit Gateways. Clean rack isolation without the old trade-off. For GPU estates, where power and cooling are already dictating rack boundaries, that's a real simplification.

Platform engineering

GitOps with Argo CD is now a native service in VCF Automation, available to Org users, in Tech Preview. The design constraint that matters: one Argo CD instance per hosting namespace, able to sync across multiple vSphere Namespaces and VKS clusters, but only within the same region. Multi-region estates need more than one instance by construction. I went through what that means for namespace layout in this post.

Native object storage is also still Tech Preview. No committed GA date from Broadcom on either.

Eleven management packs, same day

Eleven VCF management packs reached GA at 9.1.1.0 on the same day as the platform release. Five are databases: SQL Server, Oracle, PostgreSQL, MySQL and MongoDB. The reason they all shipped together is that log management is now converged into VCF Operations, so every pack was rebuilt to carry log content as well as metrics.

Watch the licensing on these. Application and database packs need VCF or VCF Edge. They aren't included with vSphere Foundation. Full breakdown over here.

Bill of Materials, the lines people pin

Core components all move to 9.1.1.0. The ones that version separately and tend to end up hard-coded in design documents:

VMware Tools 13.5.0, Remote Console 13.1.1
VKS 3.7.0+v1.36, VKS Add-ons 3.7.0+20260618
vSphere Kubernetes releases 1.34.2+vmware.2-vkr.2
Harbor 2.15.2, Contour 1.33.5, ArgoCD 1.2.0, External DNS 0.21.0

If your HLD pins versions, the Kubernetes release is the line most likely to matter to application teams.

If you only do three things

Read the patch order before you book the window, and put the software depot somewhere deliberate in the sequence. If you're on 5.2.x, retarget the upgrade at 9.1.1. And if the Distributed VXLAN model was ruled out earlier this year, get the network team to look at that table again, because the reasons may have gone.

Everything else can be picked up when it becomes relevant to you.