AI has fundamentally changed the software industry through its ability to discover software vulnerabilities at an unprecedented pace. This has driven software vendors to adopt faster release cadences, making more frequent software updates the new industry norm.
VMware Cloud Foundation (VCF) is no exception. With the unified versioning introduced in VCF 9, several release types are available to deliver updates, each serving a specific purpose.
The following diagram summarizes the VCF unified versioning model, showing whether each release type is synchronized across the VCF software stack or delivered independently, along with its installation method.
Rather than bundling security fixes into the next scheduled maintenance release, Express Patches allow them to be delivered as soon as they are available. Unlike upgrades, which must be applied in a specific order, Express Patches can be applied in any order, reducing some of the overhead in rolling out the fixes.
As a result of this faster release cadence, product fixes can also be delivered much sooner, rather than waiting for the next maintenance or minor release.
For long-time VMware users, this is one of the most significant benefits of the faster release cadence. Historically, even after a product issue had been resolved by engineering, customers often had to wait months before the fix became available in a scheduled release.
As of this blog post's publication, three Express Patch (EP) releases (9.1.0.0100, 9.1.0.0200, and 9.1.0.0300) have been published for various VCF 9.1.0 components.
| VCF Component | 9.1.0.0100 | 9.1.0.0200 | 9.1.0.0300 |
|---|---|---|---|
| ESX | ✅ | ||
| vCenter | ✅ | ||
| vSAN | ✅ | ||
| NSX | ✅ | ||
| SDDC Manager | ✅ | ✅ | ✅ |
| VCF Operations | ✅ | ✅ | ✅ |
| VCF Automation | ✅ |
As you can see from the table above, not all VCF components have an applicable EP and users are encourage to review the release notes for each applicable component to determine its applicability within their environment.
Depending on the EP, VCF Operations can include several other components including VCF Management Services (VCFMS) service components as shown in the table below.
| VCF Management Services Components | 9.1.0.0100 | 9.1.0.0200 | 9.1.0.0300 |
|---|---|---|---|
| Fleet Lifecycle | ✅ | ✅ | |
| SDDC Lifecycle | ✅ | ✅ | ✅ |
| Log Management | ✅ | ||
| Realtime Metrics | ✅ | ||
| Salt Master | ✅ | ||
| Salt RaaS | ✅ |
Express Patch Sequencing
With VCF Management Services (VCFMS) being a brand new component, you might wonder whether there is a specific order in which Express Patches must be applied. There is not. Each VCFMS service is patched independently, so Express Patches can be applied in any order. Another important point is that EPs are independent and do not need to be applied in sequential order (e.g. 0100 before 0200).
Note: When applying VCF Maintenance Releases, there is a patch sequence for VCF Management Components and VCF Core Components
With that said, if you plan to apply an EP that contains fixes for Fleet Lifecycle, you should consider applying that first since that is what drives the actual patch and upgrade for the VCF Fleet components.
To view the latest available patches from your VCF Software Depot (Online or Offline), first synchronize the VCF metadata. Log in to VCF Operations, navigate to Build > Lifecycle > VCF Management > Upgrade, and click Sync in the upper-right corner.
To choose a specific a EP for a given VCF Management Component, you need to click on the Change Target Version button and then select Customize from the drop down menu.
Express Patch Specific Offline Depot
A common misconception is that multiple VCF Offline Software Depots are needed to support different VCF releases, including recent EPs. In fact, when you connect to the VCF Online Software Depot, it is a single repository serving ALL VCF releases (major, minor, maintenance and express patches). The VCF manifest determines which versions are available for deployment, assuming the required binaries have already been downloaded.
While you can absolutely create version-specific offline depots using the VCF Download Tool (see my recent VCFDT cheatsheet for some tips), it adds unnecessary overhead. For organizations that need to maintain specific bill of materials (BOM) parity across development/pre-production and production environments, I recommend using the VCF Installer's JSON API for new Fleet or Instance deployments. This allows specific component versions to be defined directly in the JSON deployment manifest, providing both deployment consistency and a version controlled deployment configuration.
Lastly, if you deploy interactively using the VCF Installer UI, it automatically uses the VCF manifest to populate each component with the latest supported version, ensuring you are always deploying the most up-to-date version of the component.
The same behavior applies after your VCF 9.1 Fleet has been deployed. During Day-N operations, such as creating additional VCF Instances or Workload Domains, or enabling additional VCF Services, both Fleet LCM and SDDC Manager use the VCF manifest to automatically deploy the latest supported version of the required components.
Thanks for the comment!