VMware Cloud Foundation 9.0 was the platform reset.
It moved VCF beyond the idea of an integrated VMware software stack and toward a more complete private cloud operating model. Unified operations, governed self-service, VPC networking, Kubernetes, cost visibility, infrastructure automation, and API-driven consumption became central parts of the platform rather than adjacent capabilities.
VMware Cloud Foundation 9.1 takes a different step.
It does not replace the model established by the previous release. It operationalizes it. The platform becomes denser, more scalable, more programmable, easier to patch, and more tightly integrated around shared management services.
That distinction matters.
VCF 9.0 became generally available on June 17, 2025. VCF 9.1 reached general availability on May 12, 2026. Although the version number suggests an incremental release, the management architecture and operating-model implications are significant enough that infrastructure teams should not treat the move as a routine point upgrade. [R1] [R2]
TL;DR
VCF 9.0 established the modern private cloud model. It introduced the unified operational and consumption experience, VCF Automation, VPC-based networking, VKS integration, NVMe memory tiering, stronger cost governance, and a more API-driven platform.
VCF 9.1 makes that model more practical at production scale.
The most important changes are:
- A new VCF Management Services architecture
- Replacement of the standalone Fleet Management Appliance
- Consolidation of identity, lifecycle, logging, depot, and related services
- A mandatory centralized VCF License Server
- Support for larger fleets and more parallel lifecycle operations
- More usable and resilient NVMe memory tiering
- Generally available vSAN global deduplication
- Greater VKS scale and a new managed Container Service
- More capable tenant networking and security
- Faster, less disruptive patching
- Broader API and automation coverage
- Tighter integration between compliance, protection, and recovery
The practical takeaway is straightforward:
VCF 9.0 defined the platform. VCF 9.1 turns it into a more mature operating model.
Scope and assumptions
This comparison examines VMware Cloud Foundation as a complete private cloud platform. It is not limited to the differences between individual vSphere releases.
The analysis assumes:
- The organization is evaluating a greenfield deployment or an upgrade from a supported VCF 9.0.x environment.
- VCF Operations and VCF Automation are part of the intended platform model.
- The environment may run traditional virtual machines, Kubernetes workloads, containerized applications, or AI workloads.
- Vendor-reported performance and efficiency figures are directional until validated against the organization’s own hardware and applications.
- Advanced cyber compliance, security integrations, disaster recovery services, and some ecosystem capabilities may require additional entitlement, configuration, or supporting products.
- Hardware compatibility, interoperability, and upgrade requirements will be checked against the current Broadcom documentation before implementation.
Why this comparison matters
It would be easy to read the release names and conclude that VCF 9.1 is simply a refined VCF 9.0.
That interpretation misses the architectural change.
VCF 9.0 created a private cloud control and consumption model around VCF Operations and VCF Automation. However, several fleet-level capabilities still relied on dedicated appliances and separately managed services.
VCF 9.1 begins consolidating those capabilities into VCF Management Services, a shared runtime for lifecycle, identity, software distribution, logging, and operational functions. It also introduces a centralized license server and a different lifecycle sequence for the management layer. [R3]
The result is not simply a shorter inventory of virtual appliances.
It is a change in where platform responsibilities live, who should own them, how they are protected, and how upgrades should be coordinated.
The platform shift at a glance
The first diagram shows the management-model transition. This is a logical view rather than an exact deployment topology.
What matters is that VCF 9.1 replaces several separately operated management components with services running on a common platform layer.
VCF Management Services does not eliminate instance-level management boundaries. SDDC Manager, vCenter, NSX, management domains, and workload domains still retain meaningful scope and lifecycle responsibilities.
The change is that shared platform capabilities are becoming more explicitly centralized.
Side-by-side comparison
| Decision area | VCF 9.0 baseline | VCF 9.1 change | Why it matters |
|---|---|---|---|
| Private cloud model | Unified operations and consumption become central to VCF | The model is extended with consolidated shared management services | Moves VCF closer to a consistent platform operating model |
| Fleet management | Standalone Fleet Management Appliance | Fleet Lifecycle and SDDC Lifecycle run in VCF Management Services | Changes upgrade workflows, ownership, backup, and troubleshooting |
| Identity and logging | External identity broker appliances and separately operated logging components | Identity and log-management capabilities move into the management-services architecture | Reduces product silos but increases the importance of the shared services layer |
| Licensing | File-based licensing workflows and capacity aggregation | Centralized VCF License Server becomes mandatory | Licensing becomes a platform dependency that requires DNS and operational planning |
| Platform scale | Lower fleet and lifecycle concurrency limits | Up to 5,000 ESXi hosts and parallel lifecycle operations across as many as 256 clusters | Makes centralized operations more realistic for large enterprises and providers |
| Memory efficiency | NVMe memory tiering introduced with more configuration and hardware dependencies | Software NVMe mirroring, simpler configuration, improved observability, and broader VM support | Makes memory tiering easier to evaluate and operationalize |
| Storage efficiency | Global deduplication announced but required an RPQ at general availability | Global deduplication becomes generally available with enhanced compression | Makes data reduction a mainstream design option rather than an exception workflow |
| Storage resilience | Native snapshots and vSAN-to-vSAN replication foundation | Broader replication, recovery scheduling, and vSAN for Recovery improvements | Brings protection and recovery closer to normal storage operations |
| Modern applications | VM Service and VKS form the main application-consumption paths | Greater VKS scale, Container Service, Fast Deploy, and application-stack capture | Gives platform teams more runtime choices without building separate platforms |
| Networking | VPC-ready networking and self-service foundations | More transit options, tenant security, distributed connectivity, and VLAN integration | Reduces the number of self-service requests that still become network tickets |
| Security lifecycle | Live patching and centralized security visibility | TPM-aware live patching, vCenter Quick Patch, and stronger platform security integration | Shortens vulnerability remediation while reducing application disruption |
| Automation | OpenAPI, SDK, Terraform, and PowerCLI consolidation begins | Broader service coverage and more consistent API behavior across the platform | Makes platform-wide automation more realistic and less product-specific |
The original release established the operating model
VCF 9.0 was important because it changed the center of gravity.
Historically, many VMware environments were operated as a collection of products:
- vCenter for compute operations
- NSX Manager for networking
- SDDC Manager for stack lifecycle
- Aria products for monitoring, automation, logging, and cost
- Separate portals or scripts for application consumption
VCF 9.0 began presenting these capabilities as parts of one private cloud platform.
VCF Operations became the operational home for building, managing, monitoring, securing, and optimizing the environment. VCF Automation provided the consumption layer for virtual machines, Kubernetes clusters, networks, policies, and reusable services. VPC networking created a more cloud-like tenant boundary, while APIs and infrastructure-as-code integrations enabled a more programmable platform. [R1]
That was the architectural reset.
Without that reset, the changes in VCF 9.1 would look like a collection of product enhancements. With the VCF 9.0 model in place, the newer release can instead be understood as an effort to remove the remaining operational seams.
The management layer changed the most
The introduction of VCF Management Services is the most consequential architectural change in the newer release.
VCF Management Services provides a shared runtime for capabilities that previously depended on individual appliances or more fragmented service boundaries. Fleet Lifecycle, SDDC Lifecycle, identity, log management, the software depot, and real-time data services become part of this management-services architecture. [R3]
During an upgrade from VCF 9.0:
- The standalone Fleet Management Appliance is replaced.
- Fleet data is transferred into the new lifecycle services.
- The earlier Fleet Management Appliance is powered down for decommissioning.
- External VMware Identity Broker appliances are migrated into the new services architecture.
- A centralized VCF License Server is introduced.
- Management Services must be established before the remaining core upgrade proceeds through the documented sequence.
This is important for three reasons.
First, backup and recovery planning must now account for shared services that influence a much larger portion of the private cloud.
Second, team ownership must move away from appliance names and toward service scopes. Saying that one team owns “the Aria appliance” or “the lifecycle appliance” is no longer sufficient. Someone must own fleet lifecycle, software distribution, licensing, identity, logging, certificates, and service-runtime availability as coordinated platform functions.
Third, a failure or configuration error in a shared management layer can affect more workflows than a failure in a narrowly scoped tool.
Consolidation can simplify operations, but only when responsibility is equally consolidated.
Scale and lifecycle moved into a different class
VCF 9.1 increases the supported management scale to as many as 5,000 ESXi hosts within a single VCF instance, which Broadcom describes as double the previous release.
Parallel upgrade capacity also increases fourfold, supporting lifecycle operations across as many as 256 clusters concurrently. [R4]
Those numbers are not relevant only to the largest service providers.
They represent a change in the lifecycle model.
In a large private cloud, the limiting factor is rarely whether an individual host can be patched. The limiting factor is whether hundreds of clusters can be assessed, staged, remediated, validated, and returned to service inside approved change windows.
Greater lifecycle concurrency helps reduce the time between:
- A security update becoming available
- The update being approved
- Content being distributed
- Clusters entering remediation
- The entire fleet reaching the desired state
VCF 9.1 also adds capabilities such as vSphere Elastic Provisioning, which can automate discovery, imaging, and configuration as hosts are introduced or repurposed.
The operational implication is significant: adding capacity becomes more like a platform workflow and less like a sequence of one-host-at-a-time administration tasks.
Memory tiering became easier to operationalize
NVMe memory tiering was one of the most interesting infrastructure-efficiency capabilities introduced with VCF 9.0.
The concept is straightforward. Frequently accessed memory pages remain in DRAM, while colder pages are placed on a local NVMe tier. Virtual machines consume logical memory without needing application-level awareness of where each page resides.
The challenge in the original implementation was not the concept. It was operational confidence.
VCF 9.1 addresses several of those concerns:
- Software-based NVMe mirroring reduces dependency on hardware RAID or Intel VROC.
- vSphere Configuration Profiles simplify configuration.
- NVMe partitions can be created as part of the workflow.
- Enabling the capability no longer requires a host reboot, although maintenance mode is still required.
- vCenter provides improved host, cluster, tier, device-health, bandwidth, and latency visibility.
- VCF Operations adds a dedicated dashboard and what-if analysis.
- More VM profiles can run on hosts where tiering is enabled.
- Nested virtualization is supported with the feature. [R5]
Broadcom reports performance improvements over the earlier implementation, including gains in its HammerDB database testing and lower CPU use in customized VMmark tests. Those figures should be treated as vendor test results rather than guaranteed production outcomes.
The more important improvement is manageability.
A feature that can increase effective memory but cannot be confidently monitored, modeled, or protected will struggle to get through an enterprise design review. Software mirroring, health visibility, and what-if analysis give infrastructure teams a more defensible path to adoption.
Memory tiering still requires workload validation. Latency-sensitive databases, large-memory applications, failure behavior, device endurance, and operational replacement procedures should all be tested before broad rollout.
Storage efficiency and recovery matured
VCF 9.0 introduced global vSAN deduplication, but the capability required an RPQ at the original general-availability milestone.
In VCF 9.1, global deduplication becomes generally available. Enhanced compression, including support for encrypted environments, expands the storage-efficiency story further. [R1] [R6]
This changes the design conversation.
Data reduction is no longer something that must be treated as a special exception for selected environments. It can be evaluated as part of normal vSAN capacity planning.
The newer release also introduces or improves:
- System-managed Auto-RAID policy behavior
- More useful effective-capacity reporting
- Cross-storage replication into vSAN targets
- Grandfather-father-son snapshot scheduling
- vSAN for Recovery workflows
- Greater persistent-volume scale
- More flexible use of vSAN Express Storage Architecture and Original Storage Architecture resources
Auto-RAID is particularly interesting from an operational perspective. Rather than forcing an administrator to manually redesign policy every time the cluster size changes, the system can select an appropriate resilience and erasure-coding posture based on available hosts.
That does not remove the need for storage architecture.
It changes where some of the repetitive policy logic is executed.
Data-reduction results will still vary dramatically by workload. Database encryption, guest-level compression, media files, already deduplicated backup data, and application-level storage patterns can all reduce the practical benefit. Capacity models should therefore use observed data rather than headline ratios.
Application delivery became more platform-like
VCF 9.0 established a unified model for virtual machines and Kubernetes through VM Service, the vSphere Supervisor, VKS, namespaces, and VCF Automation.
VCF 9.1 expands the model in three directions.
The first is scale.
VKS can support as many as 500 workload clusters per control plane. Broadcom also reports significantly faster cluster provisioning and upgrade workflows, along with multi-network support, more intelligent node-pool placement, multiple clusters per zone, automated secret injection, and more granular access control. [R7]
The second is runtime choice.
VCF Automation adds Container Service alongside VM Service and VKS. Container Service allows teams to deploy and lifecycle OCI-compatible container images without requiring every application to own a full Kubernetes cluster.
The service can handle container configuration, storage, secrets, load balancing, replicas, sidecars, and runtime parameters. It can also generate Kubernetes YAML from the configuration created in the interface. [R8] [R11]
Container Service should not be interpreted as a replacement for VKS.
It is a lower-friction option for teams that need to run containerized applications but do not require direct ownership of the complete Kubernetes control plane, API surface, or ecosystem. VKS remains the appropriate choice when teams need full Kubernetes behavior, extensive cluster-level customization, or established cloud-native tooling.
The third direction is repeatability.
Fast Deploy accelerates VM and VKS provisioning, while App Stack Formation can capture a running application topology—including virtual machines, networking, and disks—and turn it into a reusable blueprint.
That makes the transition from an individually assembled environment to a governed platform service considerably shorter.
Networking self-service became more practical
VCF 9.0 made VPC-based networking a central part of the private cloud consumption model.
VCF 9.1 fills in several of the practical gaps that can cause an apparently self-service platform to fall back into manual network tickets.
Enhancements include:
- Multiple external connections and transit gateways per tenant
- Tenant-managed VPN and Gateway Firewall capabilities
- Organization-level shared subnets
- VLAN extensions for direct Layer Two connectivity
- Distributed Transit Gateways
- Direct connectivity between VPCs and existing VLAN-backed environments
- More automated inter-VPC connectivity and microsegmentation
- Additional options for multi-network VKS clusters [R8]
The Distributed Transit Gateway pattern is particularly useful for brownfield environments. It can connect VPC workloads to existing VLAN environments through ESXi hosts without requiring every use case to introduce an NSX Edge cluster and dynamic routing.
That does not make network architecture disappear.
It gives architects another translation mechanism between the cloud-style VPC model and the VLAN-backed environments that most enterprises still operate.
The important design question becomes:
Which network functions should be delegated to tenants, and which must remain centrally governed?
Without that decision, self-service networking can create policy sprawl just as easily as it can reduce ticket volume.
Security and recovery moved closer to continuous operations
VCF 9.0 included the foundation for live patching and centralized security visibility.
VCF 9.1 extends the patching architecture across the management, control, and data planes.
ESXi Live Patch now supports TPM-enabled hosts. vCenter Quick Patch provides a faster path for applicable security and minor fixes. Rolling and reduced-downtime mechanisms continue to protect availability across vCenter, NSX, Supervisor, VKS, and the ESXi data plane. [R9]
This matters because security response is increasingly constrained by operational disruption.
When every infrastructure patch requires:
- A large evacuation window
- Application-owner approval
- Host reboots
- Extended validation
- Multiple product-specific workflows
the organization is more likely to defer remediation.
Faster and less disruptive mechanisms do not eliminate change control, but they remove some of the technical reasons for delay.
Recovery also becomes more closely integrated with the platform. vSAN for Recovery, native replication, snapshot scheduling, isolated recovery environments, and security-tool integrations can support more coordinated ransomware and disaster-recovery workflows.
VMware Advanced Cyber Compliance extends this model with continuous posture monitoring, desired-state remediation, and integrated cyber-recovery capabilities. Those functions should be evaluated separately from base-platform capabilities because they may require additional licensing, integrations, or operational services. [R9]
The real improvement is not a new dashboard.
It is the opportunity to manage patch posture, configuration drift, compliance evidence, restore-point validation, and recovery readiness as related operational disciplines.
Programmability became less fragmented
VCF 9.0 began consolidating infrastructure automation around OpenAPI specifications, unified SDKs, Terraform, and PowerCLI.
VCF 9.1 broadens the coverage.
The unified SDK expands to cover additional components, including NSX, VCF Operations, log management, network operations, Fleet Lifecycle, and SDDC Lifecycle. New and updated APIs expose real-time metrics, vCenter utilization, federated inventory access, and more efficient inventory queries. [R10]
PowerCLI and Terraform coverage also continues to grow, including newer VPC, transit-gateway, span, connectivity-policy, and platform-management workflows.
This is important because a private cloud cannot be considered programmable when every subsystem requires a different client library, authentication model, object structure, and error-handling pattern.
VCF 9.1 does not eliminate all component boundaries. It does, however, provide a more consistent platform contract.
Teams moving to the newer release should still test:
- API changes and deprecations
- Authentication and certificate handling
- Pagination and filtering behavior
- Existing PowerCLI scripts
- Terraform provider versions
- Custom integrations
- Monitoring and ticketing connectors
- Automation that targets the former Fleet Management Appliance
The value of an API-first platform is only realized when the organization treats automation compatibility as part of upgrade testing.
Private AI gained more production controls
For organizations using VCF Private AI Services, the newer release adds more operational depth around model, accelerator, and data-service consumption.
Enhancements include broader GPU support, improved model and GPU observability, additional DirectPath and GPUDirect capabilities, CPU-based inference options, and Model Context Protocol integration with policy and governance controls. [R12]
These capabilities can be important for AI platforms that need data locality, private model hosting, resource governance, and shared infrastructure operations.
They should not, however, obscure the larger reason to evaluate the release.
The management-services architecture, lifecycle scale, storage efficiency, application delivery, and security improvements affect a much broader part of the enterprise than AI alone.
The upgrade decision is an operating-model decision
The following diagram shows a more useful decision process than simply asking whether the newer version contains desirable features.
The key gate is operational readiness.
The decision is not whether VCF 9.1 is objectively better.
It is whether the organization can absorb the technical and operational changes while achieving a meaningful outcome.
What each audience should care about
| Audience | Most important change | Operational implication |
|---|---|---|
| Enterprise architects | VCF Management Services and larger shared-service boundaries | Revisit topology, availability, identity, dependency, and ownership models |
| Infrastructure operators | Parallel lifecycle, Elastic Provisioning, Quick Patch, and improved observability | Redesign maintenance workflows around desired state and fleet scope |
| Storage architects | Global deduplication, enhanced compression, Auto-RAID, and recovery integration | Rebuild capacity and protection models using observed workload data |
| Platform engineers | Greater VKS scale, Container Service, Fast Deploy, and application-stack capture | Create clearer service tiers for VMs, containers, and Kubernetes |
| Network teams | Distributed connectivity, tenant networking, and policy-driven VPC communication | Decide which services can be delegated without weakening governance |
| Security teams | Faster patching, centralized posture visibility, and integrated recovery | Align vulnerability, compliance, and recovery processes |
| Automation teams | Broader SDK, API, PowerCLI, and Terraform coverage | Replace product-specific scripts with platform-oriented workflows where practical |
| Technical leaders | Better infrastructure density and less operational fragmentation | Measure value through cost per workload, lifecycle time, risk, and service delivery |
Upgrade planning implications
An upgrade from VCF 9.0.x to VCF 9.1 should begin with platform readiness rather than package download.
The management-services prerequisites are concrete.
Broadcom documents a minimum requirement of 12 management-network IP addresses for the initial VCF Management Services deployment. Additional ranges can be added later, with the documented design allowing as many as 30 addresses as services expand.
The internal services network also uses a dedicated range by default. That range must not overlap with the management network or other routed infrastructure. Alternative internal ranges can be selected through the deployment specification when required. [R3]
The centralized license server requires working forward and reverse DNS records. That makes DNS readiness a hard platform dependency rather than a cleanup item.
A practical readiness review should cover the following areas.
Platform services
- VCF Operations health and upgrade readiness
- SDDC Manager inventory and lifecycle state
- Fleet Management Appliance status
- VMware Identity Broker placement
- Existing logging architecture
- Software-depot connectivity
- Cloud Proxy and collector dependencies
- License status and consumption data
Network and identity
- Forward and reverse DNS
- NTP consistency
- Management IP capacity
- Internal-network overlap
- Firewall paths
- Proxy requirements
- Identity-provider integration
- Service-account ownership
- Certificate subject alternative names and expiration
Protection and recovery
- Current configuration backups
- Management-plane restore procedures
- Validated recovery credentials
- External backup-product interoperability
- Recovery time and recovery point expectations
- Rollback decision points
- Support escalation paths
Automation and integrations
- PowerCLI and API dependencies
- Terraform provider versions
- Monitoring integrations
- Ticketing and event workflows
- Custom dashboards
- Identity automation
- Certificate automation
- Network and security orchestration
- Scripts targeting decommissioned appliances
Operating model
- Fleet-level service owner
- Instance-level owner
- Workload-domain owner
- Licensing owner
- Identity owner
- Logging owner
- Security and compliance owner
- Change authority
- Post-upgrade validation owner
The documented upgrade sequence must be followed for the management components. Workload domains can then be upgraded as controlled Day-N activities, allowing the organization to separate the management-plane transition from the remediation of every workload domain. [R3]
Where staying on the earlier release can still be reasonable
Not every VCF 9.0 environment needs to move immediately.
A controlled period on the earlier release can be reasonable when:
- The platform is stable and current on required patches.
- None of the newer capabilities solves an immediate business or operational problem.
- Hardware or third-party integrations have not completed validation.
- The management-services prerequisites are not ready.
- The organization is inside a major application freeze.
- Backup, recovery, automation, or monitoring integrations still require testing.
- The operational teams have not agreed on post-upgrade ownership.
That is not an argument for indefinite delay.
It is an argument for sequencing the upgrade around readiness instead of calendar pressure.
Remaining on VCF 9.0 should be an explicit, reviewed decision with a defined exit condition—not the accidental result of unclear ownership.
Decision guidance
For a greenfield private cloud, VCF 9.1 should normally be the default design target unless a documented compatibility, hardware, or application constraint requires another version.
For an existing VCF 9.0 environment, the business case is strongest when one or more of the following are true:
- The organization needs a more scalable fleet model.
- Upgrade windows are constrained by cluster count.
- DRAM cost or memory-bound workloads are limiting consolidation.
- vSAN capacity efficiency is becoming a material concern.
- The platform team needs greater Kubernetes scale.
- Application teams need simpler container consumption.
- Networking tickets are blocking self-service.
- Security patching takes too long.
- Compliance evidence is fragmented.
- Recovery workflows need stronger platform integration.
- Automation is constrained by product-specific APIs.
- The organization is ready to consolidate management ownership.
For a smaller, stable environment, the immediate scale benefits may be less important. Management consolidation, patching, storage efficiency, observability, and security can still justify the move, but the upgrade should be scheduled when the operating model and dependencies are ready.
Conclusion
VMware Cloud Foundation 9.0 and 9.1 are not competing platform strategies.
They are two stages of the same strategy.
VCF 9.0 established the modern private cloud operating model. It unified infrastructure operations, consumption, automation, VPC networking, Kubernetes, cost governance, and programmable access around a common platform direction.
VCF 9.1 makes that direction more viable at production scale.
The most important change is not an individual storage, compute, Kubernetes, or security feature. It is the consolidation of shared platform capabilities into VCF Management Services, accompanied by a new licensing dependency, greater lifecycle scale, stronger resource economics, more complete application delivery, and tighter security and recovery integration.
For architects, the release changes boundaries.
For operators, it changes lifecycle and troubleshooting.
For platform teams, it expands the service catalog.
For security teams, it shortens the path between finding risk and remediating it.
For leadership, it creates a more credible path toward operating private cloud as a platform rather than maintaining VMware as a collection of products.
The right question is therefore not:
Is VCF 9.1 better than VCF 9.0?
The better question is:
Is the organization prepared to operate the more consolidated, automated, and service-oriented private cloud that VCF 9.1 introduces?
Treat the transition as an operating-model cutover, not a patch window.
External reference links
[R1] What’s New in VMware Cloud Foundation 9.0
https://blogs.vmware.com/cloud-foundation/2025/06/17/whats-new-in-vmware-cloud-foundation-9-0/
[R2] VCF 9.1 Is Available: Explore the New Features in Hands-on Labs
https://blogs.vmware.com/cloud-foundation/2026/05/12/vcf-9-1-is-available-explore-the-new-features-in-hands-on-labs/
[R3] Upgrade Sequence and Related Issues for VMware Cloud Foundation
https://knowledge.broadcom.com/external/article/440630/upgrade-sequence-and-related-issues-for.html
[R4] Scale, Simplify, and Secure Your Private Cloud Operations with VCF 9.1
https://blogs.vmware.com/cloud-foundation/2026/05/05/scale-simplify-and-secure-your-private-cloud-operations-with-vcf-9-1/
[R5] Advanced Memory Tiering Enhancements in VMware Cloud Foundation 9.1
https://blogs.vmware.com/cloud-foundation/2026/05/07/advanced-memory-tiering-enhancements-in-vmware-cloud-foundation-9-1/
[R6] Optimize, Modernize, and Protect Your Private Cloud with vSAN in VCF 9.1
https://blogs.vmware.com/cloud-foundation/2026/05/05/announcing_vsan_in_vcf_9-1/
[R7] Deploy Modern Apps Faster with VKS on VCF 9.1
https://blogs.vmware.com/cloud-foundation/2026/05/05/deploy-modern-apps-faster-scale-smarter-and-lower-your-tco-with-vks-on-vcf-9-1/
[R8] Accelerate, Streamline, and Control Your Self-Service Private Cloud with VCF 9.1
https://blogs.vmware.com/cloud-foundation/2026/05/05/accelerate-streamline-and-control-your-self-service-private-cloud-with-vcf-9-1/
[R9] Faster Security Patching with Fewer Disruptions in VCF 9.1
https://blogs.vmware.com/cloud-foundation/2026/06/30/security-patching-in-vcf-9/
[R9] Continuous Compliance, Integrated Cyber Recovery, and Enhanced Platform Security
https://blogs.vmware.com/cloud-foundation/2026/05/05/continuous-compliance-integrated-cyber-recovery-and-enhanced-platform-security-for-vcf-9-1/
[R10] Programmable Infrastructure with VCF 9.1
https://blogs.vmware.com/cloud-foundation/2026/05/25/unlocking-the-full-potential-of-programmable-infrastructure-with-vmware-cloud-foundation-9-1-new-features-and-capabilities/
[R11] From Container Image to Production: Container Service in VCF 9.1
https://blogs.vmware.com/cloud-foundation/2026/06/30/from-container-image-to-production-container-service-in-vmware-cloud-foundation-9-1/
[R12] Streamline, Simplify, and Protect Your AI Workloads with VCF 9.1
https://blogs.vmware.com/cloud-foundation/2026/05/05/streamline-simplify-and-protect-all-your-ai-workloads-with-vcf-9-1/
VMware vSphere Foundation and VMware Cloud Foundation share the same infrastructure DNA. Both are built around vSphere. Both can run enterprise virtual...