,

VMware Cloud Foundation 9.0 vs 9.1: What Actually Changed

A plain comparison of VMware Cloud Foundation 9.0 and 9.1: what changed, which features matter (vCenter quick patch, VKS Fast Deploy, vSAN object storage, VCF Management Services), and whether to upgrade.

VCF 9 · Version Comparison

TL;DR · Key Takeaways

  • 9.0 was the architecture shift; 9.1 is an optimisation release, so you do not need to re-architect anything to adopt it.
  • vCenter quick patch changes only the binaries that changed, cutting patch downtime to under a minute and sometimes to zero.
  • VKS Fast Deploy roughly triples Kubernetes deploy and upgrade speed, and a Supervisor can now run up to 500 clusters.
  • vSAN adds native S3-compatible object storage as a tech preview, so block, file and object can share one cluster.
  • Upgrades now run through the new VCF Management Services; upgrade VCF Operations first and clear the prechecks before you start.

If you are already on VMware Cloud Foundation 9.0 and wondering whether 9.1 is worth the change window, here is the honest version. 9.0 was the big rebuild, the release where VCF became one unified platform with VCF Operations at the centre. 9.1 does not redraw that picture. It sharpens it. Faster patching, faster Kubernetes, a bit more storage flexibility, and a smoother way to run upgrades.

So this is not a rip-and-replace. It is the kind of release you take because it removes real day-to-day friction, not because it changes how you think about the platform. Below is what actually moved between the two, what I would care about, and whether it is worth doing now.

Short answer

9.1 is an optimisation release on top of 9.0. Nothing forces a re-architecture. The headline wins are vCenter patching that is close to zero downtime, Kubernetes clusters that deploy and upgrade far quicker, object storage arriving on vSAN, and a cleaner upgrade and lifecycle flow through the new VCF Management Services. If any of those hit a pain point you have today, 9.1 pays for itself. If none do, there is no rush, and you can plan it for a quiet quarter.

9.0 and 9.1 side by side

AreaVCF 9.0VCF 9.1
What it isThe architectural shift to a unified private cloud platformAn optimisation layer on that platform
vCenter patchingStandard patch with a reboot and real downtimeQuick patch: only changed binaries, often under a minute, sometimes zero downtime
vCenter resizeManual resize workflowNew API: one call plus a reboot to scale compute and disk
Kubernetes (VKS)Standard deploy and upgrade timesVKS Fast Deploy: 100-node cluster 37 to 11 min; upgrade 414 to 103 min
Supervisor scaleLower cluster density per SupervisorUp to 500 clusters per Supervisor, lower container cost
vSAN storageBlock and fileAdds native S3-compatible object storage (tech preview) on the same cluster
Lifecycle and upgradeSDDC Manager drivenVCF Management Services (fleet and SDDC lifecycle, software depot) plus an Upgrade Planning Tool
Multi-tenancyTenancy model in placeHundreds of isolated tenants on shared infrastructure
9.0built the unified platform 9.1runs it faster and cheaper
Same platform. 9.1 spends its energy on speed, scale and smoother operations rather than a new architecture.

The new features, by area, and how ready they are

Before deciding, it helps to see the new pieces grouped by what they touch and how production-ready each one is. Some are generally available and safe to lean on. At least one, object storage on vSAN, ships as a technology preview, which means trial it, do not bet production on it yet.

AreaWhat 9.1 gives youStatus
vSpherevCenter quick patch, resize API, VM customization (video card, CPU topology at power-on)GA
Kubernetes (VKS)VKS Fast Deploy, up to 500 clusters per Supervisor, lower container costGA
Storage (vSAN)Native S3-compatible object storage alongside block and fileTech preview
LifecycleVCF Management Services, software depot, Upgrade Planning ToolGA
TenancyHundreds of isolated tenants on shared infrastructureGA

Which changes actually matter

A release note lists everything. In practice only a few of these change your week. Here are the ones I would weigh.

vCenter quick patch and resize

Patching vCenter used to mean a maintenance window and a reboot nobody enjoyed scheduling. Quick patch changes only the binaries that actually changed, so a patch can land in under a minute and sometimes with no downtime at all. If you run a busy vCenter that is painful to take offline, this alone is a reason to look at 9.1. The new resize API is smaller but handy: you scale vCenter compute and disk with one call and a reboot, instead of clicking through a manual workflow.

9.0 patchmaintenance window + reboot9.1 quick patchunder a minute
Quick patch only swaps changed binaries, so a vCenter patch that meant a window now lands in about a minute, sometimes with no downtime.

If you run a single large vCenter that half the business logs into, this is the change you feel most. Patching stops being a scheduled outage and becomes something you can do in a normal maintenance slot without paging anyone. Over a year of patch cycles that adds up to real hours back, and fewer awkward change-approval conversations.

Faster Kubernetes with VKS Fast Deploy

If you run vSphere Kubernetes Service at any scale, this is the standout. A 100-node cluster that took 37 minutes to deploy now takes about 11, and an upgrade that took nearly seven hours drops to under two. VMware also quotes up to 500 clusters per Supervisor and a meaningful cut in container cost. Numbers like those change how often you are willing to rebuild or upgrade clusters, which is usually where the real time goes.

100-node cluster deploy (minutes)9.0379.111Cluster upgrade (minutes)9.04149.1103
VKS Fast Deploy in 9.1: roughly a third of the deploy time and a quarter of the upgrade time versus 9.0, on VMware figures.

Object storage on vSAN

vSAN gains native S3-compatible object storage, so block, file and object can live on the same cluster. It arrives as a technology preview, which means I would trial it, not put production behind it yet. Still, if you have been standing up a separate object store for app teams, this is worth watching, because keeping it on vSAN removes a whole moving part.

The appeal is fewer systems to run. Today an app team that wants S3-style buckets usually means a separate object platform to stand up, patch and secure. Folding block, file and object onto one vSAN cluster means one thing to operate instead of two. I would pilot it now with non-critical data, get a feel for the performance and the management, and have a real opinion ready for when it reaches general availability. Piloting early is cheap; migrating production onto a preview feature is not.

Lifecycle moved: VCF Management Services

This one you cannot ignore, because it is part of the upgrade itself. 9.1 introduces VCF Management Services, a container cluster that hosts the newer lifecycle pieces: fleet lifecycle, SDDC lifecycle and the software depot. You deploy it during the upgrade, and the order matters, VCF Operations goes first. There is also an Upgrade Planning Tool that maps your path before you start. If you take one thing into the change window, take the sequence, because doing it out of order is the classic way an upgrade stalls.

Practically, the order is fixed: VCF Operations upgrades first, then you deploy VCF Management Services and point it at the software depot, then the license appliance and any dependency components like VMware Live Recovery or the NSX Advanced Load Balancer, then SDDC Manager and the management domain, and finally each workload domain in turn with NSX, then vCenter, then ESX. Every stage has a precheck, and every stage assumes the one before it finished cleanly. This is why I treat the sequence as the real deliverable of the planning phase, more than the feature list.

VCF OperationsfirstMgmt Services+ depotDependencieslicense, LR, AviSDDC + mgmtdomainWorkloadNSX/vC/ESX
The upgrade order in 9.1. Each box has its own precheck and assumes the previous stage finished cleanly.
Before you upgrade: run the prechecks, take backups, and confirm your rollback plan. Make sure dependent pieces like VCF Operations and Automation are on their latest release first, since the upgrade expects that. None of the speed wins above matter if the upgrade itself trips on a precheck you could have cleared the day before.

What stays the same from 9.0

This is the reassuring part. 9.1 does not touch the mental model you built for 9.0. The hierarchy is still fleet, then instance, then domain, then cluster. VCF Operations is still the single control point that holds licensing, identity and lifecycle for the fleet. Licensing is still per core and per vSAN TiB, pooled in one license file. Your runbooks, your dashboards, your alert definitions and your capacity policies all carry straight over. If your team has spent the last year getting good at 9.0, none of that knowledge is thrown away.

That continuity is the reason 9.1 is a low-drama upgrade rather than a migration. You are not relearning the platform, you are picking up faster patching, quicker Kubernetes and a smoother lifecycle on top of the same foundation. It also means you can roll it out domain by domain without retraining anyone, which is exactly how I would phase it in a large fleet.

How long the upgrade actually takes

There is no single number, because the time scales with how many domains and hosts you have, but the shape is predictable. You upgrade VCF Operations first, which is a contained job on the management side. You stand up VCF Management Services and the depot once. After that, most of the clock is the per-domain work: NSX, then vCenter, then a rolling ESX upgrade across the hosts, one domain at a time. The ESX rollout is usually the longest stretch, because hosts go into maintenance mode and evacuate workloads in sequence.

Plan it in waves

For anything bigger than a lab, I plan the workload domains as waves across separate change windows rather than one marathon night. Do the management domain and one lower-risk workload domain first, confirm everything is healthy for a few days, then take the rest. vCenter quick patch helps here, because the vCenter step that used to eat a chunk of every window now lands in about a minute. Size each wave to the ESX host count you can drain and patch comfortably inside the window you have, and leave headroom, because a host that will not enter maintenance mode is the classic thing that overruns an upgrade night.

Whatever the total, the prechecks and the planning tool are what make the estimate trustworthy. Run them early, fix what they flag before the window, and the actual upgrade becomes the boring, predictable part. Skip them and the timeline is a guess.

Should you upgrade?

My take: yes, but on your schedule, not in a panic. There is no architectural reason you must move off 9.0, so treat 9.1 as a value decision. If vCenter downtime, slow Kubernetes rebuilds, or the old lifecycle flow are costing you real time, plan it soon. If your 9.0 fleet is quiet and none of the new features solve a problem you actually have, wait for a maintenance window that suits you and go in prepared. Either way, do not skip the prechecks and the planning tool. The upgrade is smoother in 9.1, but smoother is not automatic.

Who benefits most: shops with a busy vCenter that is hard to take down, and anyone running vSphere Kubernetes Service at scale, since those two get the biggest, most obvious wins. Who can wait: a small, stable 9.0 estate with no Kubernetes and no object-storage need, where the upgrade is worth doing eventually but nothing is on fire. Either way the honest sequence is the same, decide on value, then plan it properly with prechecks and the planning tool rather than rushing it because a new version exists.

Common questions

Do I have to upgrade to 9.1?
No. 9.0 stays supported and 9.1 is not a re-architecture, so there is no forced move. Upgrade when a specific 9.1 feature solves a problem you have, or when you want the smoother lifecycle and faster patching. Otherwise plan it for a convenient window.

Can I skip straight from an older release to 9.1?
Supported paths change, so check the current upgrade-paths guidance before you plan. From 9.0.x it is a straightforward upgrade. From older or from vSphere Foundation, the Upgrade Planning Tool maps the route for you, and that is the first thing I would run.

What has to be upgraded first?
VCF Operations. The 9.1 sequence starts there, then VCF Management Services and the depot, then dependencies, then SDDC Manager and the management domain, then each workload domain. Dependent products like Operations and Automation should already be on their latest release before you begin.

Is the vSAN object storage safe for production?
Not yet. It ships as a technology preview in 9.1, so trial it on non-critical data and watch how it behaves. Keep production object workloads where they are until it goes generally available.

Will my 9.0 skills and runbooks still apply?
Yes. The fleet, instance, domain and cluster model is unchanged, VCF Operations is still the control point, and licensing is still per core and per vSAN TiB. You are adding capability, not relearning the platform.

How to do the upgrade

If you decide to go, the step-by-step lives in the VCF 9.1 Upgrade guide: paths, prerequisites, the planning tool, prechecks, the full sequence, and each component in order. For day-2 once you are on 9.1, the VCF 9 Operations guide covers running it well, and the VCF 9 Complete Guide is the wider reference.

References

About The Author


Discover more from Journal of Intelligent Infrastructure – By Dr Pranay Jha

Subscribe to get the latest posts sent to your email.

Leave a Reply

Your email address will not be published. Required fields are marked *

Architect’s Toolkit

About the Author

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

Discover more from Journal of Intelligent Infrastructure - By Dr Pranay Jha

Subscribe now to keep reading and get access to the full archive.

Continue reading