10 Exciting Enhancements in VMware Cloud Foundation 9.1.1

This has been an exciting week as VMware Explore 2026 takes place in Las Vegas, where I have been meeting with customers and partners while delivering several technical breakout sessions and workshops. To coincide with the event, we have also announced the general availability of VMware Cloud Foundation (VCF) 9.1.1, the first maintenance release for VCF 9.1! 🥳

Note: While there is no defined patch sequence for maintenance and EPs, there is a special exception that you should be aware specifically for VCF 9.1.1 release which will have a couple of specific sequence that must be followed (pre-checks already built into the release). These exceptions will be removed in a future maintenance release, but just something to be aware of

• Fleet LCM must be patched to 9.1.1 before updating other VCF components to 9.1.1
• VCFMS must be updated to 9.1.1 before updating Identity broker, Salt Master/RaaS component to 9.1.1
• VCF Automation (VCFA) must be updated to 9.1.1 before updating VCD Migrator component to 9.1.1

As a maintenance release, it includes all cumulative bug fixes and security updates from previous Express Patches (EPs), along with platform stability improvements and enhancements that simplify the journey to VCF 9.1.

While there are many improvements in this release, here are ten that I think are worth highlighting.

1. Support for Back-in-Time Upgrades

There were several vSphere and VMware Cloud Foundation (VCF) releases published after VCF 9.1 that were considered back-in-time releases, preventing a direct upgrade path to VCF 9.1. With VCF 9.1.1, all of these back-in-time releases now have a supported upgrade path 🥳

2. Support for Latest VCF Component Versions with VCF Download Tool (VCFT)

With more frequent VCF Component Express Patch (EP) releases, it can quickly become challenging to identify the latest versions across all the components required for a new VCF installation or upgrade. While the VCF Download Tool (VCFDT) makes it easy to look up the latest version for an individual component, determining the latest versions across the entire VCF software stack has been less straightforward.

With VCFDT 9.1.1, a new --latest flag makes this much simpler by automatically filtering the required VCF components to their latest Express Patch versions for both installation and upgrade workflows.

Here is the command to list the latest VCF 9.1.0 binaries that is required just for the initial installation:

vcf-download-tool binaries list --depot-download-token-file=/Users/lamw/vcf_download_token.txt --vcf-version=9.1.0 --sku=VCF --type=INSTALL --automated-install --latest

Here is the command to download the latest VCF 9.1.0 binaries that is required just for the initial installation:

vcf-download-tool binaries download --depot-download-token-file=/Users/lamw/vcf_download_token.txt --depot-store=/Volumes/Storage/Software/VCF-LATEST --vcf-version=9.1.0 --sku=VCF --type=INSTALL --automated-install --latest

3. Support for OCI-based binaries & vSphere Supervisor, VKS & VKR Images with VCF Download Tool (VCFT)

The unified VCF Software Depot provides a single repository that hosts all the binaries used by a VCF deployment, including OVAs, ZIP files, PAKs, and OCI-based artifacts. The VCFDT is the primary tool for interacting with the online VCF Software Depot to download content and create an offline VCF Software Depot. However, one limitation was that it could not handle OCI-based artifacts, including vSphere Kubernetes Releases (VKR).

With VCF 9.1.1, VCFDT has been enhanced with a new artifacts command that simplifies downloading vSphere Supervisor Services, including vSphere Kubernetes Service (VKS), and most importantly, vSphere Kubernetes Releases (VKRs). The new command allows you to choose exactly which VKRs to download, instead of the previous experience where subscribing to the online VKR Content Library made all VKR releases available for deployment with no simple way for platform operators to control which releases were consumed.

A new category filter has also been introduced as part of the artifacts sub-command which will allow users to quickly filter by the specific type of binary you wish to view and/or download:

• SUPERVISOR - vSphere Supervisor Control Plane Updates
• VKS - vSphere Kubernetes Service Updates
• SUPERVISOR_SERVICE - vSphere Supervisor Service Updates
• VCF_CLI - VCF Consumption CLI and plugins
• VCF_SERVICE - VCF Services provided by VCF Automation
• DSM - Data Service Manager Updates

Here is the command to list VKR releases:

vcf-download-tool artifacts list --depot-download-activation-code-file=/Users/lamw/vcf_activation_code.txt --sku=VCF --vcf-version=9.1.0 --component=VKR

Here is the command to download a specific VKR releases:

vcf-download-tool artifacts download --depot-download-activation-code-file=/Users/lamw/vcf_activation_code.txt --sku=VCF --vcf-version=9.1.0 --component=VKR --depot-store=/Volumes/Storage/Software/VKR --component-version=1.36.1+vmware.4-vkr.5

4. Reduced Footprint for VCF Management Services (VCFMS)

When VCF Management Services (VCFMS) was introduced in VCF 9.1.0, its virtual machine sizing was optimized to accommodate the largest optional Day-N service. This reduced the likelihood of requiring a rollout to a larger VM size as additional services were enabled. However, for environments that did not deploy these optional Day-N services, some VCFMS virtual machines could be larger than necessary.

With VCF 9.1.1, VCFMS sizing has been optimized for the initial Day-0 deployment. In addition, individual VCFMS components have been further right-sized to ensure that each service reserves only the resources it requires, improving overall resource utilization. For example, a Simple (non-HA) deployment, you will now have one less VCFMS Worker Node (12 vCPU / 24GB memory).

For users with an existing VCF 9.1 deployment upgrading to VCF 9.1.1, the current VCFMS sizing will remain unchanged. With that said, users can still take advantage of the reduced VCFMS footprint by running a post-upgrade right-sizing script after all VCFMS components have been upgraded to 9.1.1.

5. Support for Small HA deployment of VCF Management Services (VCFMS) in VCF Installer

While VCF 9.1.0 supported a Small VCFMS deployment, it was only available with the Simple (non-HA) deployment model. As a result, users requiring high availability for the VCFMS Control Plane Nodes had to deploy the next larger VCFMS size, trading additional resource consumption for increased availability.

With VCF 9.1.1, VCF Management Services (VCFMS) now supports a new Small HA deployment option, allowing users to achieve high availability without increasing the resource footprint beyond the smallest deployment size.

For those interested in using this capability through the VCF Installer JSON API, use small_ha as the deployment size value within the vspClusterSpec that defines your VCF Management Services (VCFMS) configuration.

If you decide to deploy VCF Fleet using the Small non-HA option, you can also scale to Small HA as a Day-N operation using the VCF Operations UI under Build > Lifecycle > VCF Management > Components > VCF Services Runtime and then select Action > Scale.

6. Support for HTTP & Custom URL for Offline Depot in VCF Installer UI

Initially introduced in VMware Cloud Foundation (VCF) 9.1.0, the VCF Installer API allowed users to configure a VCF Offline Depot using an HTTP endpoint, including support for a custom URL path. Starting with VCF 9.1.1, this same capability is now available directly in the VCF Installer UI, allowing environments that do not require HTTPS and/or use a custom Offline Depot URL to be configured without needing to invoke the VCF Installer API.

7. Support for non-vSAN ESA HCL Disks in VCF Installer UI

For lab/PoC deployments, access to vSAN ESA-certified NVMe devices may not always be practical. By default, the VCF Installer only allows certified NVMe devices to be used with vSAN ESA. Previously, this behavior could be overridden by adding a configuration setting to the VCF Installer. Starting with VCF 9.1.1, support for non-certified NVMe devices with vSAN ESA is now built directly into the VCF Installer, eliminating the need for this manual configuration.

Disclaimer: Only NVMe devices listed on the Broadcom Compatibility Guide (BCG) are supported for production VVF and VCF environments running vSAN ESA.

For those interested in using this capability through the VCF Installer JSON API, a new skipHclAutoDiskClaim property has been added under vsanSpec. Setting this property to true enables the same behavior used by the VCF Installer UI.

"datastoreSpec": {
    "vsanSpec": {
        "vsanDedup": false,
        "failuresToTolerate": 1,
        "esaConfig": {
            "enabled": true,
            "skipHclAutoDiskClaim": true
        },
        "datastoreName": "vsanDatastore",
        "encryptionConfig": {
            "dataInTransitConfig": {
                "enable": false
            }
        }
    }
}

8. Support for Single ESX Host deployment in VCF Installer UI

For hardware-constrained lab/PoC environments, meeting the minimum ESX host requirement may not always be possible. Although a workaround has been available since VCF 5.x using a configuration setting override, the VCF Installer UI still enforces the minimum host count, preventing deployments even when the override was configured. As a result, users had to rely on the Cloud Builder or VCF Installer JSON API to complete the deployment.

Starting with VCF 9.1.1, the VCF Installer UI now honors the configuration override, allowing these deployments to be completed directly through the UI. This significantly simplifies the experience for new users getting started with VCF in lab and PoC environments.

Disclaimer: Only the official minimal ESX host configuration is supported for production VVF and VCF deployments.

9. Support for non-vSAN ESA HCL Disks in Host Commissioning Workflow

When adding a new VCF Workload Domain or expanding an existing one that uses vSAN ESA, an additional configuration override was previously required to commission ESX hosts with non-certified NVMe devices. Continuing the usability improvements introduced in VCF 9.1.1, users can now perform ESX host commissioning directly from either the vCenter Server or SDDC Manager UI without requiring the additional override.

Before adding a commissioned ESX host with non-certified NVMe devices to a vSAN ESA cluster, ensure that the vSAN Managed Disk Claim feature has been disabled. By default, this feature automatically claims certified NVMe devices for use with vSAN ESA. Because non-certified devices require manual handling, the operation will otherwise be blocked.

Disclaimer: Only NVMe devices listed on the Broadcom Compatibility Guide (BCG) are supported for production VVF and VCF environments running vSAN ESA.

10. Support for VLAN Backed VPC without Overlay Tunnel Endpoint (TEP)

With the introduction of Distributed Transit Gateway (DTGW), a Distributed Virtual Portgroup (DVPG) that is VLAN-backed is all that is required to start consuming Virtual Private Cloud (VPC), users still needed to configure an additional network for the Overlay network that would be used for the Tunnel Endpoint (TEP) between your ESX hosts. With VCF 9.1.1, there is now an additional option for DTGW that is VLAN-backed without requiring a TEP network to be configured on each ESX hosts, thus reducing the configurations required to start playing with VPCs!

Note: While this new VLAN-backed VPC deployment is fully compatible with vSphere Kubernetes Service (VKS) and VCF Automation (VCFA), it does have some limitations. These include the lack of VPC Private Subnets, SNAT/DNAT/VPN services, and support for non-IP protocols (for example, VRRP and Multicast).