TL;DR

VMware Cloud Foundation 9.1.1 became generally available on September 3, 2026. The release is best understood as a boundary-management update: it changes how tenants share AI models, how operators interact with diagnostics, how quickly VKS telemetry reaches VCF Operations, how identity and certificate state is evaluated across the fleet, and how NSX connects to a physical EVPN-VXLAN fabric.

The practical takeaways are:

• Multi-tenant model sharing can reduce duplicate model deployments and GPU waste, but it also creates a shared runtime dependency that must be governed as a common service.
• The optional AI Assistant places conversational diagnostics inside VCF Operations, but architects still need to define the model endpoint, diagnostic-data boundary, retention policy, and human approval model.
• Two-second OpenTelemetry metric streaming for VKS can expose short-lived failures that five-minute polling misses, while increasing the importance of cardinality, retention, ingestion capacity, and alert ownership.
• Dynamic Active Directory and OpenLDAP lookups, broader password workflows, and expanded certificate lifecycle coverage move more security operations into the fleet-management plane.
• EVPN improvements create a more direct east-west VXLAN path between VCF transit gateways and physical leaf switches, while adding NAT, NSX Load Balancing, Avi Load Balancing, and DHCP relay to distributed EVPN connectivity.
• A compact two-node high-availability management option lowers the infrastructure entry point, but it does not remove common-mode failure, backup, DNS, identity, network, or recovery design requirements.
• The new VCF Automation self-service GitOps integration and native vSAN S3-compatible object storage remain technology previews. They belong in evaluation plans, not committed production requirements.

Introduction

A release can be generally available while some of the capabilities discussed around it are optional, topology-dependent, separately configured, or still in technology preview. That distinction sounds obvious until a feature announcement is copied into an architecture requirement, a sizing workbook, or a project commitment without its release status attached.

VCF 9.1.1 makes that risk particularly visible because it spans several teams at once. Private AI teams see model sharing. Platform engineers see native GitOps direction. Kubernetes operators see two-second telemetry. Security teams see dynamic directory lookups and wider certificate management. Network architects see a more direct EVPN data path. Infrastructure leaders see a smaller management footprint.

The common thread is not simply that VCF gained more features. The common thread is that more shared services are being pulled into an integrated private-cloud operating model.

That is why VCF 9.1.1 should be read as an architecture change record, not just a maintenance download. The important questions are where the control boundary moved, which dependencies became shared, what evidence is available on Day 2, and which capabilities are mature enough to appear in a production design.

Scope, Terminology, and Assumptions

This article uses VMware Cloud Foundation 9.1.1, released on September 3, 2026, as its product baseline. It focuses on the architecture and operating-model implications of the release rather than attempting to reproduce the complete bill of materials (BOM), upgrade sequence, resolved issues, or known-issues register.

The following guardrails apply:

• Generally available release means the VCF 9.1.1 release can be consumed under Broadcom’s published support and lifecycle framework. It does not mean every optional service is deployed, configured, licensed, entitled, or valid for every topology.
• Optional capability means the feature may be production-capable but still requires explicit architecture, configuration, capacity, security, and operating decisions.
• Technology preview means the capability should be evaluated separately from production requirements, service-level commitments, and replacement plans.
• Announced capability should not become a production dependency until the exact component version, entitlement, documentation, support status, and installed bill of materials have been confirmed.
• The current release notes, component release notes, compatibility guidance, and environment-specific prechecks remain the source of truth for an upgrade runbook.

The article assumes the reader already understands the major VCF 9.1 components, including vSphere, vSAN, NSX, VCF Automation, VCF Operations, VCF Management Services, and VMware vSphere Kubernetes Service.

VCF 9.1.1 Is a Boundary-Management Release

The most useful way to interpret the release is to look at the boundaries it changes.

Boundary	VCF 9.1.1 change	Architectural consequence
Tenant to shared AI service	Multi-tenant model sharing	Fewer duplicate model runtimes, but a larger shared dependency and governance surface
Operator to diagnostic context	Optional AI Assistant in VCF Operations	Faster investigation, but new questions about model trust, data handling, and human validation
Kubernetes event to operations platform	Two-second OpenTelemetry metric streaming	Better visibility into transient behavior, with higher ingestion and observability-design demands
User to platform authorization	Real-time directory lookup at login	Current group membership can drive access, while directory availability and session behavior become more important
Certificate owner to fleet	Expanded certificate lifecycle management	Broader central visibility and automation, with a larger potential change blast radius
NSX overlay to physical fabric	Direct VXLAN tunnels and expanded EVPN services	A more direct east-west path and a tighter operating contract between virtual and physical networking teams
Management capability to infrastructure footprint	Compact two-node HA option	Lower resource requirements, but no reduction in the need for resilient dependencies and recovery evidence
Product direction to production commitment	Argo CD and vSAN S3 previews	Useful architectural signals that must remain outside committed production scope

The release therefore moves VCF further away from a collection of adjacent products and toward an integrated control system. That can reduce tool fragmentation, but it also makes the management plane more consequential. When a smaller set of shared management services becomes responsible for identity, certificates, telemetry, diagnostics, configuration, and lifecycle coordination, their availability and governance become platform-level concerns.

The Release Boundary at a Glance

The diagram below separates three planning lanes. The middle lane matters because optional does not mean preview. An optional production capability can still require substantial design work before it is safe to enable.

The release label belongs at the top of the tree. Capability status belongs on every branch below it. That small discipline prevents an architecture board from approving a preview, an optional integration, and a core platform update as though they carried the same support and operational meaning.

Multi-Tenant Model Sharing Consolidates Cost and Risk

Broadcom’s VCF 9.1.1 announcement presents multi-tenant model sharing as a way for separate tenants or lines of business to consume shared models while maintaining private data boundaries. The economic logic is strong. A platform team should not need to load and operate an identical model runtime for every business unit when the model itself is common and the tenant-specific context can remain isolated.

The resulting architecture is not simply shared AI. It is a shared service with separated request, data, policy, and evidence paths.

The shared runtime creates several advantages:

• Model binaries and runtime infrastructure can be reused.
• GPU or accelerator capacity can be allocated more efficiently.
• Model patching and version governance can be centralized.
• Platform teams can expose a consistent service rather than many bespoke stacks.

It also creates a common failure and control domain. A model-runtime outage can affect multiple tenants. A bad model update can change behavior across several business units. A quota error can allow one tenant to consume disproportionate capacity. A telemetry design that mixes tenant context can weaken the isolation the architecture was intended to preserve.

Architects should require explicit answers for identity, request routing, namespace isolation, retrieval data, prompt and response logging, model version promotion, rate limits, token accounting, accelerator scheduling, noisy-neighbor controls, incident containment, and tenant-specific evidence.

There is also an availability nuance worth preserving. Broadcom’s general-availability announcement presents multi-tenant model sharing as part of VCF 9.1.1, while a separate VMware AI Factory announcement uses future-oriented wording for the Model Runtime enhancement. The safe planning position is to validate the exact Private AI Services component release, entitlement, documented configuration path, and support status before making it a production dependency.

The right architecture statement is therefore not, “VCF 9.1.1 eliminates duplicate AI infrastructure.” It is, “VCF 9.1.1 introduces a shared-model pattern that may reduce duplication when tenant isolation, capacity governance, and component availability are proven.”

The AI Assistant Moves Diagnostics Into the Operations Plane

VCF 9.1.1 introduces an optional conversational AI interface in VCF Operations. Broadcom describes use cases that include correlating health alerts, configuration, and logs; investigating vSphere and VCF management-service issues; analyzing patterns such as repeated vMotion failures; and helping administrators build management packs for adjacent infrastructure.

The feature is locally configured in VCF Operations, with supported model choices described as models running through Private AI Services or a private Google Gemini instance. That flexibility is useful, but local configuration should not be confused with a complete data-sovereignty guarantee. The actual boundary depends on where the selected model runs, what diagnostic context is supplied, how prompts and responses are retained, and which identities can access the interaction history.

The architecture should preserve a governed diagnostic loop:

The model should not become the source of truth simply because it can summarize several sources quickly. VCF Operations data, component state, supported runbooks, and human accountability still govern the decision.

Before enabling the assistant, architects should define:

• Which logs, alerts, configuration objects, topology relationships, and support data may be sent to the model.
• Whether sensitive hostnames, tenant identifiers, IP addresses, ticket content, secrets, or regulated data can appear in prompts.
• Which model versions are approved and how a model change is reviewed.
• How prompts, responses, generated management-pack content, and user feedback are retained and audited.
• Whether generated integrations require code review, test environments, signing, and promotion controls.
• What happens when the model endpoint is unavailable, slow, or produces conflicting advice.
• Which roles may use the assistant and whether access differs for operators, tenant administrators, and support personnel.
• Where human approval is mandatory before any remediation or configuration change.

The feature can shorten the path from symptom to hypothesis. It does not remove the need for evidence, change control, rollback, or operator judgment.

Two-Second VKS Telemetry Changes the Observability Contract

Traditional infrastructure polling works reasonably well for long-lived virtual machines and slowly changing capacity signals. It is much weaker for containers that can start, spike, fail, and disappear between collection intervals.

VCF 9.1.1 addresses that gap by adding real-time, two-second metric streaming for VKS clusters using OpenTelemetry. The release also describes automated multi-cluster collection and the ability to import existing Grafana dashboards into VCF Operations.

The immediate benefit is visibility into behavior that a five-minute interval can miss:

• Short-lived pods that terminate before the next poll.
• Rapid memory or CPU spikes.
• Brief network saturation.
• Transient scheduling pressure.
• Fast control-plane or node-health changes.
• Performance events that correlate with logs but disappear from coarse metric history.

The operational contract also changes. Faster collection means the observability platform must be designed for more samples, more labels, more objects, and more frequent state changes. A two-second stream across many clusters can improve detection while also increasing ingestion, storage, network, query, and alert-processing load.

Architects should validate five areas.

Collection Scope

Decide which clusters, namespaces, workloads, nodes, and metric families require the two-second path. Not every signal has the same operational value, and collecting everything at maximum frequency can increase cost without improving decisions.

Cardinality and Retention

Kubernetes labels are useful until uncontrolled combinations create a cardinality problem. Define allowed dimensions, retention tiers, aggregation rules, and the conditions under which raw high-frequency data is downsampled.

Service-Level Correlation

Infrastructure metrics can show that a node, network path, or storage layer changed. They do not automatically prove the user-visible effect. Application traces, request metrics, error rates, and service-level indicators still need to connect the infrastructure event to the service outcome.

Alert Ownership

A faster signal that no team owns becomes faster noise. Each alert should have a severity, an accountable team, a runbook, suppression logic, escalation, and a measurable recovery or validation action.

Collector and Platform Failure

The monitoring path itself needs health indicators. Teams should be able to distinguish a healthy cluster with a failed collector from a failed cluster with a healthy collector. Time synchronization, buffering, backpressure, and data-loss behavior should be tested rather than assumed.

The VKS 3.7 Add-on Management Framework also deserves attention because observability, networking, security, and storage add-ons create a Day-2 support problem. Clear ownership and lifecycle responsibility for each add-on matter as much as installation. An integrated framework is valuable when it makes support boundaries explicit rather than merely making deployment easier.

Dynamic Identity and Certificate Management Tighten the Fleet Boundary

VCF 9.1.1 expands real-time identity handling by allowing Active Directory and OpenLDAP users and groups to be queried on demand. Group membership is evaluated at login, reducing dependence on pre-provisioned user objects and making temporary group-based access easier to reflect at authentication time.

That is a meaningful improvement, but it does not solve every access-lifecycle problem. Architects still need to define session duration, token lifetime, reauthentication, emergency revocation, directory outage behavior, nested-group handling, break-glass accounts, and audit evidence. A user removed from a group should not be assumed to lose an already active session instantly unless the session and token design proves it.

The release also expands centralized password and certificate operations. VCF Operations can surface credential freshness across more components and extend certificate lifecycle coverage to systems such as NSX Edges, vSphere Supervisors, License Servers, cloud proxies, and VCF Operations for networks collectors. Broadcom also describes expiration tracking, renewal-failure alerts, third-party certificate-authority integration, and support for non-TLS certificates.

This creates a stronger fleet-level control model:

Centralization reduces console hopping, but it also increases the impact of a bad workflow. Certificate replacement should be staged by dependency group, with trust stores, service endpoints, adapters, load balancers, API clients, automation credentials, and rollback artifacts validated before broad execution.

A practical certificate runbook should include:

• Complete inventory of leaf, intermediate, root, service, signing, and non-TLS certificates.
• Dependency mapping for every consumer and trust store.
• Renewal and replacement authority by component.
• Backup or export of the current certificate and configuration state.
• A canary component or limited-scope change.
• Service, API, adapter, collector, and authentication validation after replacement.
• Explicit rollback criteria and tested recovery steps.
• Evidence that monitoring and alerting resumed after the change.

VCF 9.1.1 also adds VMware Salt for VCF Component APIs, exposing a broad set of configuration settings through native Salt constructs. This can support configuration-as-code and drift control, but only when templates, approvals, secrets, version compatibility, change evidence, and rollback are governed as production automation.

EVPN Improvements Change the Physical and Virtual Fabric Relationship

VCF 9.1.1 introduces a more direct east-west VXLAN data path between VCF transit gateways and physical leaf switches. It also makes NAT, NSX Load Balancing, Avi Load Balancing, and DHCP relay available for the distributed EVPN connectivity model.

The simplified target path looks like this:

The architectural value is not merely fewer hops. The change creates a tighter relationship between NSX logical networking and the physical EVPN fabric. That can improve path efficiency and make distributed services more useful, but it also requires a stronger operating contract between the teams that own the VCF transit layer and the teams that own the leaf-spine fabric.

The design review should cover:

• BGP and EVPN control-plane ownership.
• Tenant VPC, VRF, route-target, and address-plan boundaries.
• VXLAN Network Identifier allocation and collision prevention.
• End-to-end MTU and encapsulation overhead.
• Equal-cost path behavior and route convergence.
• North-south and east-west service insertion.
• NAT state and load-balancer failover behavior.
• DHCP relay reachability and failure handling.
• Route leaking, default routes, and shared-service access.
• Telemetry correlation across NSX and the physical fabric.
• Upgrade sequencing and compatibility between virtual and physical control planes.
• Failure isolation when a leaf, link, transit gateway, or control-plane session is lost.

A direct tunnel does not eliminate the physical fabric as a dependency. It makes that dependency more explicit. Troubleshooting should therefore begin with a shared path model rather than separate virtual-network and physical-network tickets.

Before production use, test same-leaf and cross-leaf east-west traffic, tenant isolation, route convergence, MTU, NAT, both load-balancing options used in the design, DHCP relay, link or leaf failure, transit-gateway failure, and end-to-end flow visibility. The acceptance criteria should describe the user-visible outcome, not only whether the BGP session returned to Established.

The Compact Management Footprint Lowers Entry Cost, Not Design Responsibility

Broadcom describes a new compact form factor for VCF 9.1.1 that can reduce required CPU and memory by up to 40 percent and includes a two-node high-availability setup. The release also states that the streamlined architecture can allow existing brownfield vCenter instances to be imported without network port-group reconfiguration.

This can materially change the feasibility of smaller private-cloud deployments. It may reduce the management-resource tax for constrained environments, regional deployments, or organizations that do not need the larger management profile.

The phrase two-node high availability still needs architectural interpretation. Two management nodes can protect against some individual-node failures, but the service remains dependent on placement, storage, networking, load balancing, DNS, time, directory services, certificate services, backups, and the failure domains that contain both nodes.

Architects should ask:

• Are the two nodes separated across hosts, racks, power domains, and network paths where the supported design permits it?
• Which state is replicated, and how is consistency maintained during a partial failure?
• What external services can cause both nodes to become unavailable at the same time?
• How are backup, restore, rebuild, and disaster-recovery procedures tested?
• What happens during patching, certificate replacement, or a failed scale operation?
• Does the smaller profile have enough headroom for telemetry growth, additional VCF instances, more integrations, and operational history?
• Which brownfield assumptions must be true before avoiding port-group reconfiguration?

A smaller footprint should reduce infrastructure consumption. It should not reduce validation depth.

Technology Previews Need Their Own Planning Lane

VCF 9.1.1 includes two strategically important previews: the new VCF Automation GitOps service based on Argo CD and native S3-compatible object storage in vSAN.

Both are strong indicators of platform direction. Neither should be flattened into the same production commitment as the generally available release capabilities.

The Argo CD Distinction Matters

The release introduces a VCF Automation service that allows organization users to self-service Argo CD instances, integrates VCF Automation OIDC authentication, supports provider management across regions, and can attach vSphere Namespaces and VKS clusters as targets. That new organization-facing integration is a technology preview.

Broadcom separately clarifies that the core Argo CD Supervisor service deployed through vCenter, available since VCF 9.0.1, remains supported for production. The preview applies to the new VCF Automation organization-user self-service experience, not to every use of Argo CD on VCF.

That distinction should appear explicitly in design documents:

Capability	Planning treatment
Core Argo CD Supervisor service through vCenter	Evaluate under its current supported production documentation
VCF Automation organization self-service GitOps integration	Technology-preview evaluation, separate from production commitments

A preview pilot can still be valuable. Test identity mapping, namespace scoping, cross-region provider management, target attachment, repository trust, secrets, promotion, drift, failure recovery, and the upgrade lifecycle. Preserve a supported GitOps path that does not depend on the preview.

Native vSAN S3 Is an Architectural Signal

Native S3-compatible object storage in vSAN points toward a unified block, file, and object-storage model under VCF Automation and the vSphere Supervisor. It is especially relevant to Kubernetes and AI workloads that expect object APIs, tenant quotas, and programmatic bucket consumption.

The capability remains a technology preview. It should therefore be used to answer architecture questions, not to make a production replacement promise.

A useful evaluation should test:

• S3 API compatibility required by actual applications.
• Tenant and bucket isolation.
• Quotas and administrative delegation.
• Encryption and key ownership.
• Backup, restore, replication, and deletion behavior.
• Performance under representative object sizes and access patterns.
• Monitoring, auditing, lifecycle policies, and failure recovery.
• Data portability back to the current object-storage platform.

The fallback should remain visible. A preview that cannot be removed without redesigning the application is no longer a low-risk preview.

Decision Criteria for Production Adoption

The release should move into production because it improves a defined service or control objective, not simply because it is the newest available build.

Decision domain	Question	Evidence required
Release baseline	Is the exact VCF and component bill of materials supported for this environment?	Current release notes, component versions, compatibility checks, known-issue review
AI model sharing	Can tenant data, requests, logs, quotas, and failures remain isolated around a shared runtime?	Tested identity, namespace, network, storage, audit, capacity, and recovery controls
AI Assistant	Is the selected model endpoint approved for the diagnostic context it receives?	Data-flow diagram, model approval, role mapping, retention policy, human-validation workflow
VKS observability	Can the platform sustain two-second telemetry without uncontrolled cost or noise?	Ingestion test, cardinality limits, retention model, collector-health monitoring, alert ownership
Identity	Does current directory membership produce the intended access behavior throughout the session lifecycle?	Login, removal, revocation, outage, break-glass, and audit tests
Certificates	Can certificates be replaced without breaking trust across dependent services?	Dependency map, canary change, rollback test, post-change service validation
EVPN	Does the direct path preserve isolation, convergence, services, and troubleshooting evidence?	End-to-end traffic, failure, MTU, route, NAT, load-balancing, DHCP, and telemetry tests
Compact management	Does the smaller topology meet availability, capacity, and recovery objectives?	Failure-domain review, load test, backup and restore evidence, dependency-resilience test
Technology previews	Can the preview be evaluated without entering the production critical path?	Isolated scope, fallback design, data portability, exit criteria, no committed SLO dependency

A successful architecture review should produce decisions, owners, and evidence for each row. A feature checklist is not enough.

A Practical Adoption Sequence

Establish the Release Baseline

Record the exact VCF 9.1.1 bill of materials, installed component versions, supported upgrade path, entitlement, hardware compatibility, and known issues. Use the release notes and component documentation, not the announcement page, as the runbook baseline.

Separate the Capability Lanes

Mark every proposed capability as core GA, optional and configured, topology-dependent, or technology preview. Preserve that label in requirements, architecture diagrams, test plans, budgets, and change records.

Build Architecture Deltas

Document what changes from the current state. The delta should include management resources, identity flows, certificate ownership, telemetry volume, model endpoints, tenant boundaries, NSX-to-fabric control relationships, firewall rules, DNS, load balancing, backup, and recovery.

Validate Shared Dependencies First

Test the services that can affect many tenants or domains at once. Shared model runtimes, directories, certificate authorities, collectors, VCF Operations, transit gateways, physical leafs, and management-plane storage deserve priority because their blast radius is larger than that of an isolated workload.

Pilot with Measurable Exit Criteria

Use a limited tenant, VKS cluster, management scope, or EVPN segment. Define pass criteria before the pilot begins, including availability, latency, isolation, telemetry completeness, certificate trust, access revocation, failover, recovery, and operator effort.

Promote Only Proven Capabilities

Move a capability into production requirements only after its status, support boundary, topology, capacity, security controls, operational ownership, and recovery evidence are complete. Keep previews in a separate roadmap lane until their release status and support model change.

Conclusion

VMware Cloud Foundation 9.1.1 is a meaningful release because it advances several shared control planes at once. Multi-tenant AI-model consumption, conversational diagnostics, high-frequency VKS telemetry, dynamic identity, centralized certificate operations, distributed EVPN connectivity, and a smaller management footprint all move VCF toward a more integrated private-cloud operating model.

That integration creates value when it reduces duplicate infrastructure, shortens diagnosis, exposes transient behavior, keeps access current, simplifies certificate operations, improves network paths, and makes smaller deployments practical. It also concentrates responsibility. Shared model runtimes, management services, identity systems, certificate workflows, telemetry pipelines, and transit gateways become common dependencies whose failure or misconfiguration can affect many consumers.

The release therefore should not be adopted as a flat list of features. Architects should separate generally available capabilities from optional integrations and technology previews, then attach assumptions, owners, tests, and recovery evidence to each one.

The most important question is not whether VCF 9.1.1 is available. It is whether the organization can prove that each capability is supported, correctly bounded, observable, recoverable, and operationally owned in the topology it intends to run.

External References

• Broadcom TechDocs: VMware Cloud Foundation 9.1.1.0 Release Notes
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/vmware-cloud-foundation-9-1-1-0-release-notes.html
• Broadcom TechDocs: Distributed VXLAN Connectivity Model for Version 9.1.1
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/workload-connectivity-designs/oliver.html
• VMware Cloud Foundation Blog: Announcing General Availability of VMware Cloud Foundation 9.1.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/09/03/announcing-general-availability-of-vmware-cloud-foundation-9-1-1/
• VMware Cloud Foundation Blog: New AI and Kubernetes Private Cloud Operations Capabilities in VMware Cloud Foundation 9.1.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/09/03/new-ai-and-kubernetes-private-cloud-operations-capabilities-in-vmware-cloud-foundation-9-1-1/
• VMware Cloud Foundation Blog: From Bottleneck to Breakthrough: Centralizing GitOps at Enterprise Scale with VCF 9.1.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/09/03/from-bottleneck-to-breakthrough-centralizing-gitops-at-enterprise-scale-with-vcf-9-1-1/
• VMware Cloud Foundation Blog: Native S3 Compatible Object Storage in VMware vSAN for VCF 9.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/13/native-s3-compatible-object-storage-in-vmware-vsan-for-vcf-9-1/
• VMware Cloud Foundation Blog: Explore 2026: VMware AI Factory and other new AI innovations in VCF
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/09/03/explore-2026-vmware-ai-factory-and-other-new-ai-innovations-in-vcf/

The post VMware Cloud Foundation 9.1.1 Is GA: What Changes for AI, VKS, Identity, and EVPN appeared first on Digital Thought Disruption.