Eric Sloof

The claim that the homelab is “not VMware anymore” and that containers are replacing VMs is too simplistic. What is changing is what people use a full virtual machine for. A DNS filter, password manager, media server, or monitoring tool usually does not need to boot its own complete Linux installation. For those services, a container is often the rational choice: it has less overhead, deploys faster, and is easier to manage as code.

That does not make a container a universal replacement for a VM. They are different layers. A VM virtualizes a complete computer with its own kernel. A container generally shares the host kernel and packages the application together with its dependencies. That makes containers lighter, but their isolation boundary is typically weaker, and they cannot simply run a different operating system or kernel.

So the practical conclusion is not: get rid of virtualization. It is: stop deploying a VM when all you need is to run one application.

Why Containers Dominate Self-Hosted Services

Most homelab services consist of one application, its configuration, and a database or other persistent data. Think Pi-hole, Vaultwarden, Plex, Grafana, or a small monitoring stack. Docker Compose fits that pattern well. It defines services, networks, and volumes in one YAML file, then manages the complete stack as a unit.

That delivers three immediate benefits. You do not need to patch a full guest OS for every small service. You can make deployment reproducible by keeping the Compose definition in Git. And moving, upgrading, or rolling back a service becomes much more controlled.

Do not turn this into a religion, though. A container image is not automatically secure, manageable, or persistent. You still need to update images, manage secrets, back up volumes, and restrict network access. Anyone who thinks docker compose up -d is a management strategy is merely building a less visible pile of mess.

What People Are Actually Deploying

For a small homelab, a regular Linux host running Docker Compose is often the most logical route. Install Debian or Ubuntu Server on bare metal or a mini PC, define services in Compose, and keep the configuration under version control. There is no extra hypervisor layer if you do not need one. This is particularly strong for a modest number of stable, self-hosted applications.

A second, widely used pattern is Proxmox VE as the foundation. Not because every service should become a VM, but because a single host can manage both VMs and Linux Containers. Proxmox uses LXC for containers, with cgroup resource controls and integration with networking, storage, firewalling, and high-availability features. That is useful when you also need test machines, a Windows VM, a firewall lab, or a complete directory environment alongside containers.

Proxmox can now use OCI images to create containers. That sounds like “Docker directly in Proxmox,” but the nuance matters: Proxmox still labels OCI application-container support as a technology preview, and it translates those images to the existing LXC stack underneath. It is interesting to test, but it is not a reason to abandon Docker Compose and a mature Linux guest overnight.

If you want to run containers inside Proxmox, a small Linux VM with Docker or Podman is often a clean boundary. The VM provides a clear isolation layer and lets you back up or move the container host as one object. For use cases requiring maximum isolation and live migration, Proxmox itself recommends nesting containers inside a QEMU VM. Running Docker nested inside an LXC container can work, but it adds exceptions around privileges, kernel capabilities, and troubleshooting. Only choose it if you understand exactly why you want that complexity.

k3s Is Not a Mandatory Destination

Kubernetes often enters the discussion as soon as a homelab has more than one node. k3s lowers the entry barrier: it is a fully compliant, lightweight Kubernetes distribution with few external dependencies, delivered as a single binary or minimal container image. It also bundles components such as a container runtime, CoreDNS, ingress, and basic storage services.

That makes k3s excellent for people learning Kubernetes, GitOps, ingress, persistent volumes, scheduling, and failure scenarios. It is not, however, a rational upgrade for a single NUC running five household services. In that case, you replace one simple Compose file with a larger control plane, more concepts, and a much larger failure surface. That is not modernization; it is overengineering.

Use k3s when Kubernetes itself is the learning goal, when you genuinely want multiple nodes, or when you want to practice platform engineering. Use Docker Compose when you mainly want to run applications. That distinction prevents a lot of unnecessary homelab architecture.

VMware Is Not Gone — and Neither Are VMs

The idea that VMware no longer has a place in the homelab partly comes from the uncertainty around Broadcom, licensing, and product changes. But the statement that “the free ESXi version no longer exists” is currently false. Broadcom once again offers ESXi 8.0 Update 3e as a free hypervisor for basic virtualization and explicitly lists home labs as a target use case. The edition has real limitations: no vCenter management, vMotion, DRS, HA, VADP-based backups, or official support.

For a VMware, NSX, or VCF lab, that distinction is fundamental. If you want to learn vCenter, nested ESXi, vSAN, NSX, Avi, or lifecycle management realistically, you need VMs and usually a mature virtualization layer. Containers are not an alternative to that. A Kubernetes cluster on mini PCs teaches you nothing about the vSphere control plane or the NSX data plane.

VMs also retain a clear role outside the VMware world. Choose a VM when you need another kernel or operating system, need a stronger isolation boundary, want to test an appliance, or deliberately want to contain faults inside a guest environment. A Windows server, firewall appliance, nested hypervisor, and malware or patch-testing environment are not natural container workloads.

Snapshots Are Not Backups

A repeated claim is that containers always give you fast, almost free snapshots and backups. That is misleading. Snapshot behavior depends on the filesystem, storage backend, volumes, and the amount of data that changes after the snapshot. Persistent databases and bind mounts may not even receive the same protection as the container image.

A snapshot helps you roll back quickly. A backup protects you from deletion, corruption, ransomware, hardware loss, and a failure in the snapshot chain. Keep your Compose or Quadlet definitions in Git, back up persistent volumes through a proven restore procedure, and test that restore. Anything below that is wishful thinking.

Choose the Layer That Matches the Objective

Do not start by asking which tool is popular right now. Start by asking what your homelab must prove or deliver.

• Are you primarily running a limited set of self-hosted services? Choose a minimal Linux host with Docker Compose or Podman.
• Are you combining applications with several operating systems, appliances, and test VMs? Choose a hypervisor such as Proxmox VE, and reserve VMs for workloads that actually need them.
• Are you learning VMware Cloud Foundation, NSX, or Avi? Keep a vSphere-oriented lab. Proxmox is not a substitute in that case; at most, it is supporting infrastructure.
• Are you learning Kubernetes or platform engineering? Build a small k3s cluster, but accept that the platform itself is then the objective — not merely running a few containers.

The best homelabs are hybrid. Containers take over repetitive application work. VMs provide compatibility, isolation, and a realistic infrastructure lab. Anyone who dismisses either one as obsolete is confusing a deployment model with a complete architecture.

References

Microsoft Learn — Containers vs. virtual machines

Docker Docs — Docker Compose

Proxmox VE Wiki — Linux Container

K3s Documentation — What is K3s?

Broadcom Knowledge Base — VMware ESXi 8.0 Update 3e now available as a Free Hypervisor

Version 3 of the VMware Cloud Foundation 9.1.1 Fleet Latency Diagram is now available in the Broadcom VMware Ports and Protocols portal.

This is not a new VCF feature. It is a practical architecture reference for anyone designing, reviewing, or operating a VCF fleet across more than one site. The diagram maps the logical relationships between a primary and secondary VCF instance, VCF Operations, VCF Automation, management services, vCenter, SDDC Manager, NSX, and workload domains — including the latency limits that apply to the relevant paths.

The message is simple: do not treat every connection in a VCF design as if it has the same latency requirement. Fleet-level paths can allow up to 300 ms where indicated, but tighter limits apply to several management and control-plane interactions. The diagram also highlights limits for vCenter-to-SDDC Manager, NSX, vSphere Supervisor, long-distance vMotion, and vCenter Linking, as well as the minimum bandwidth callout for Edge deployments.

Most importantly, 300 ms is a supportability limit for specific paths — not a design target. A multi-site VCF design should still be engineered with margin and validated end to end for latency, packet loss, jitter, MTU, DNS, NTP, bandwidth, security controls, and failure behaviour.

Not every application needs Kubernetes. But in VCF 9.1, “not Kubernetes” does not automatically mean “Nomad.”

VMware Cloud Foundation (VCF) 9.1 gives infrastructure teams several ways to run modern applications. VMware vSphere Kubernetes Service (VKS) is the natural choice when the application and its operators expect Kubernetes. But what if your estate consists of a few containerized services, Java processes, scheduled batch jobs and perhaps a GPU-backed inference service? Running a Kubernetes platform for every one of those workloads may be unnecessary.

HashiCorp Nomad is worth examining here. Its control plane schedules work onto existing machines; task drivers can run containers as well as non-containerized applications. It does not need an external database to maintain its own cluster state. The important question is not whether Nomad can run on VCF—it can run in Linux VMs like other software—but whether adding a separately operated scheduler brings enough value to justify its integration and support costs.

First, the comparison has three options—not two

VKS is VCF’s Kubernetes path. It provides declarative lifecycle management for Kubernetes clusters through the vSphere Supervisor, with platform integration for VM-based nodes, networking and persistent storage. VCF 9.1 also improves VKS deployment and scale. If your teams depend on Kubernetes APIs, Helm charts, operators and the broader cloud-native ecosystem, this is the obvious starting point.

VCF Container Service is the option an honest Nomad comparison cannot ignore. It lets users deploy container workloads as VM-backed vSphere Pods without managing a separate workload Kubernetes cluster. It is exposed through VCF consumption interfaces, but it still uses the Supervisor under the hood: “no cluster to manage” does not mean “no Kubernetes-derived platform components.” For a small number of OCI container applications, evaluate this built-in service before adding another orchestrator.

Nomad on VCF is a different architectural choice: install Nomad servers and clients in guest VMs, then own that workload platform yourself. Its strongest argument is not that it runs containers—both VMware options do—but that one scheduler can also handle non-containerized services and batch jobs. You gain a flexible application scheduler while taking on its upgrades, access control, recovery, integrations and support model.

A sensible reference design

Start in a VCF workload domain, not on ESX directly. Provision three Nomad server VMs across separate vSphere host/failure domains, following HashiCorp’s production reference architecture for an odd-numbered Raft quorum. Add a pool of Linux client VMs for ordinary jobs; create a separate client pool only if workloads need distinct hardware, security boundaries or GPUs. Place these VMs on appropriate vSphere storage and networks, and design vSphere DRS/HA placement alongside Nomad’s own allocation placement. vSphere HA restarts VMs; Nomad reschedules application allocations when capacity is available. Neither replaces an application-level data-recovery design.

The control boundary is clean:

• VCF/vSphere/VCF Automation or an appropriate Terraform provider: provision and lifecycle-manage VM capacity, storage policy and networks.
• Nomad: register clients, place jobs, enforce resource requests and constraints, run updates, and reschedule failed allocations when capacity exists.
• Optional services: use Nomad’s basic native discovery for a small pilot; assess Consul for more demanding service discovery, and Vault if your secrets requirements justify it. Neither is required for Nomad’s own Raft state.

This is a reference design, not a claim of a supported, out-of-the-box Nomad integration with VCF 9.1.

Where the integration gets interesting—and uncertain

VM lifecycle. VCF Automation and vSphere tooling can provision Linux VMs; guest-init tooling can install and configure Nomad. The join-and-drain workflow, safe removal of clients, image patching, and capacity feedback must be designed and tested by your team. Drain a Nomad client and verify allocation migration before deleting its VM. Do not assume VCF Automation natively autoscales Nomad clients, or that a particular Terraform provider supports generic VM provisioning on your exact VCF build.

Networking and security. Put Nomad VMs on appropriately segmented NSX-backed networks and enforce VM-level policy with NSX/vDefend where licensed and configured. Nomad supports its own CNI-based bridge networking, but that fact alone does not make NSX a validated Nomad CNI, nor does VM-level distributed firewalling automatically produce per-allocation microsegmentation. Decide how ingress, service discovery, east-west policy and DNS will actually work.

Storage. A client VM’s virtual disks can live on vSAN as ordinary VM storage. That is a different proposition from dynamic application volumes. Nomad supports CSI, but the VMware vSphere CSI driver is designed and documented for Kubernetes. Do not promise Nomad-to-vSphere CSI compatibility or official vendor support without an end-to-end test and a confirmed support statement. Start a pilot with stateless services; add stateful placement and backup requirements only when the storage path is clear.

GPUs and private AI. Nomad has a device-plugin framework and an NVIDIA device plugin, tested by HashiCorp with its Docker driver. That makes GPU-aware scheduling an interesting experiment for inference or batch jobs in GPU-enabled guest VMs. The guest must actually see usable GPU devices, with a supported VCF 9.1 GPU access mode, NVIDIA hardware, guest driver and container-runtime combination. Verify that matrix and measure GPU utilization; a Nomad job requesting a GPU does not validate the underlying virtualization stack.

Operations. VCF Operations can observe the infrastructure, while Nomad exposes its own workload telemetry. Bringing the two views together is an observability project, not a built-in Nomad management pack. Budget for ACLs, TLS, audit, upgrades, backups of Nomad state, monitoring and incident ownership. A small scheduler binary does not eliminate the platform work around it.

A focused proof of concept

I would not begin with CSI or production AI. I would run a short pilot in this order:

1. Provision three Nomad server VMs and at least three Linux clients; document placement, quorum, networking and VM backup/restore assumptions.
2. Deploy one stateless container service and one non-containerized or batch job; compare the deployment workflow with VKS and VCF Container Service for the same use case.
3. Fail a client VM and then one Nomad server. Measure application recovery, surviving quorum, vSphere HA behavior and the operational steps—not just whether a green dashboard returns.
4. Apply NSX policy at the VM boundary, test reachability and service discovery, and document any gaps in per-workload segmentation.
5. Only then test persistent storage and GPU clients as separate experiments, recording exact versions and vendor support positions before drawing conclusions.

Use observable criteria: deployment effort, day-2 patching, failure recovery, storage and network behavior, policy fit, team skills and total platform ownership. “Nomad uses fewer control-plane components” is a design fact; “therefore it is cheaper or better on VCF” is a hypothesis until measured.

My take

If your applications are already Kubernetes-native, use VKS. If you simply need to run a limited set of containers without operating workload clusters, examine VCF Container Service first. If you have a genuine mix of containers, native applications and batch work—and need a continuously running scheduler across a pool of VMs—Nomad is a credible alternative workload layer on VCF 9.1.

That is the right claim: an alternative workload layer, not a VKS replacement and not a VMware-supported native integration by default. VCF supplies the virtual infrastructure; Nomad can schedule applications on top of it. The value of the combination will be decided by the PoC, particularly at the networking, persistent-storage and GPU boundaries.

Further reading

• VCF 9.1 release notes and feature summary
• VKS architecture and integration with the Supervisor
• VCF Container Service technical overview
• Nomad production reference architecture
• Nomad service discovery options
• Nomad Community Edition licensing and support

VMware Cloud Foundation 9.1 changes the upgrade discussion in an important way. Moving forward no longer has to mean deploying every element of the full private-cloud stack in one operation. An organization can modernize its vSphere and operations layer first, converge existing infrastructure into VCF, or upgrade an established VCF environment through lifecycle management.

That flexibility is useful, but it does not make sequencing optional. VCF 9.1 provides more routes to the destination while imposing clear rules on the order in which components must move. Choosing the wrong workflow can create licensing failures, missing binaries or blocked lifecycle operations. Broadcom therefore describes the component sequence as mandatory, not advisory.

The practical message is simple: do not wait for a perfect full-stack design before starting. Select a supported path for the environment you have today, reserve the required management resources and follow the prescribed sequence.

This article covers the VCF 9.1 family. Always check the current release notes before execution because maintenance releases can add dependencies or change the applicable build numbers.

VCF 9.1 distinguishes deployment, convergence and upgrade

The first planning decision is to identify the operation correctly. Broadcom documents three primary ways to build a VCF 9.1 environment.

These are not interchangeable words. A standalone vSphere estate is converged into VCF. An existing VCF instance is upgraded. A new environment is deployed. This distinction determines the tooling, prerequisites and component order.

The supported route depends on the components already present

VCF 9.1 supports several starting states, but the presence of NSX is the main dividing line. A vSphere-only environment can take an incremental route. Once NSX is part of the source environment, the VCF Installer conversion workflow becomes mandatory.

The critical point is that VCF 9.1 is not a single upgrade path. It is a decision tree based on the source architecture.

Path 1: Modernize vSphere first without deploying the full VCF stack

A vSphere 8.x environment can move to vCenter Server 9.1, ESX 9.1 and VCF Operations 9.1 before the organization is ready for a complete VCF deployment. This is the shortest route to newer vSphere capabilities such as VMware vSphere Kubernetes Service, NVMe memory tiering and the current vSAN platform.

Where Aria Operations 8.18.x is already present, upgrade it in place to VCF Operations 9.1. Where it is absent, install VCF Operations first. The license server is then deployed through the VCF Operations workflow, followed by the vCenter and host upgrades. Broadcom explicitly supports this route for customers that want vSphere 9.1 but are not yet ready to deploy the complete VCF 9.1 stack.

This approach is strategically useful because it separates immediate infrastructure modernization from a larger private-cloud transformation. It also prevents architecture workshops from becoming an excuse to postpone necessary platform updates.

Path 2: Converge an existing vSphere environment into VCF 9.1

A vSphere 8 environment can become the management-domain foundation for a VCF 9.1 instance. Depending on the source, the convergence workflow can include an existing vCenter Server, ESXi hosts, vSAN, Aria Operations, Aria Suite Lifecycle and Aria Automation components.

For a vSphere-only source, the broad sequence is:

1.Install or upgrade to VCF Operations 9.1.

2.Upgrade vCenter Server and the hosts to the required 9.1 versions.

3.Deploy VCF Installer and download the required binaries.

4.Run the conversion workflow to establish the VCF 9.1 environment.

5.Apply the VCF Operations entitlement through the centralized license service.

The target architecture adds the VCF management layer around the reused infrastructure. That target can include VCF Automation, VCF Operations, SDDC Manager, vCenter, ESX and NSX at version 9.1.

This is not a cosmetic registration exercise. The conversion introduces management services, lifecycle control, identity integration, licensing and potentially new NSX and automation components. Treat it as an architecture change with an upgrade component, not as a simple product update.

Path 3: Converge vSphere plus NSX through VCF Installer

An environment containing vSphere 8.x and NSX 4.x must use the VCF Installer convergence workflow. Broadcom's guidance is unambiguous: when NSX is present, there is no supported path based on upgrading the components independently.

The high-level order shown for this route is:

1.Deploy VCF Installer.

2.Download the required VCF binaries.

3.Convert/import the existing vSphere and NSX environment into VCF 9.1.

4.License VCF Operations.

5.Upgrade NSX.

6.Upgrade vSphere.

VCF 9.1 broadens what can be carried through this process. Existing NSX Federation deployments remain supported, while 9.1 adds conversion/import support for environments with NSX bare-metal Edge nodes. The release also adds transition support for vCenter High Availability and Day-0 deployment of the VMware Identity Broker.

These additions remove several design conditions that previously forced customers into manual remediation or delayed adoption. They do not remove the need for compatibility validation. Firmware, server hardware, network interface cards, storage controllers and third-party integrations still need to match the target vSphere and VCF support matrices.

Path 4: Upgrade VCF 5.2.x or 9.0.x through lifecycle management

Existing VCF 5.2.x and 9.0.x deployments use the lifecycle path rather than VCF Installer conversion. Both source versions can move to the VCF 9.1 target architecture. The first major step is VCF Operations.

If Aria Operations is already deployed, upgrade it to VCF Operations 9.1. If it is absent, install VCF Operations 9.1 first. The remaining management-domain sequence is then:

1.Upgrade SDDC Manager.

2.Download the VCF 9.1 binaries.

3.Deploy VCF Management Services.

4.Upgrade NSX in the management cluster.

5.Upgrade vSphere in the management cluster.

6.Upgrade the workload domains.

7.Deploy or enable the required Automation, Logs and Networks services.

Workload domains can follow later as a Day-N operation, but the management-domain order is controlled. Do not improvise by upgrading whatever component has the most convenient maintenance window.

VCF 9.0 customers also need to account for architectural consolidation. The standalone Fleet Management Appliance is removed in 9.1. Its lifecycle functions move into VCF Management Services as Fleet Lifecycle and SDDC Lifecycle services. The external VMware Identity Broker architecture from 9.0 is also consolidated into VCF Management Services.

Licensing changes at the same time. VCF 9.1 moves from individual product license keys to a keyless subscription entitlement backed by a centralized VCF License Server. The license server is mandatory and needs forward and reverse DNS records.

Lifecycle management is substantially more granular

The new pathways are only part of the story. VCF 9.1 also reduces the operational cost of staying current after the transition.

Component-version visibility is centralized in VCF Operations. Administrators can compare current and target versions for SDDC Manager, NSX, vCenter Server and ESX hosts from one lifecycle view. Additional domain components, including VMware HCX, can also be handled through this model.

Host selection is more precise. Instead of treating every cluster upgrade as an indivisible operation, administrators can select specific hosts. This helps when a host fails a pre-check, when capacity limits require staged maintenance or when a problematic server would otherwise block the complete cluster.

NSX Edge sequencing is decoupled. VCF 9.1 provides more control over whether host or Edge upgrades run first. That flexibility makes it easier to align the network data plane with application and capacity constraints. NSX Manager upgrades are also designed to reduce management-plane interruption to a sub-second interval according to the VCF 9.1 training material.

vCenter maintenance becomes less disruptive. Reduced Downtime Upgrade deploys a new appliance, synchronizes data while the existing vCenter remains active and limits the outage to the final switchover. During that upgrade, VCF 9.1 can select the deployment size, adjust storage sizing and allow a manual switchover. Quick Patch provides a faster path for compatible fixes and can minimize or avoid service interruption. It is not universal: administrators must confirm in the release notes whether a specific patch supports the quick-patch mechanism.

The result is not “zero maintenance.” The result is smaller failure domains, shorter control-plane interruptions and more freedom to stage work around actual capacity.

Management Services change the infrastructure prerequisites

The move to VCF 9.1 introduces a common runtime for lifecycle and operational services. This is mandatory for VCF and optional for vSphere Foundation. The minimum management-services pool contains 12 IP addresses. Broadcom recommends allowing expansion to 30 addresses for high availability and future scale-out. The ranges must be on the management network and do not have to be contiguous.

The internal VCF Services Runtime network uses 198.18.0.0/15 by default. If that range overlaps with an existing management network, the deployment specification must use one of the supported alternatives before installation.

The overall IP and DNS plan must also include Fleet Services, Instance Services, the License Server, the Identity Broker, SDDC Manager and the VCF Operations Cloud Proxy. A full VCF Automation deployment requires additional addresses. This is exactly the kind of detail that turns into a failed deployment when it is left until the implementation window.

VCF 9.1 can deploy VCF Operations and VCF Automation on a custom distributed virtual port group or NSX segment. Their deployment can also be deferred during the initial planning phase and completed later. This supports a phased design, but “deferred” must not be confused with “unnecessary.”

Dual-stack support still contains IPv4 islands

VCF 9.1 supports dual-stack deployment for selected traffic types, but it does not support an IPv6-only software stack. All dual-stack component names must resolve to both IPv4 and IPv6. External services such as DNS and NTP must support IPv4 or dual-stack operation.

Several components remain IPv4-only, including VCF Automation, the License Server and the NSX overlay. There is also no automatic fallback when the preferred IPv6 path fails, so manual intervention may be required. In other words, dual stack is a deployment option; it is not the elimination of IPv4.

Constraints that can invalidate an otherwise sound plan

Enhanced Linked Mode requires special attention. In a vSphere-only environment, every vCenter in the Enhanced Linked Mode ring must first move to 9.1 before the ring can be broken using the newer non-disruptive method. In a vSphere-plus-NSX environment, the vCenter must be separated from the ring while it is still on vSphere 8.x, before the VCF conversion.

VxRail support is equally specific. An existing VCF 5.2-on-VxRail deployment can upgrade to VCF 9.1 with Dell assistance. That support statement does not authorize conversion of a standalone vSphere-on-VxRail environment into VCF.

VCF 9.1 can also create a workload domain management plane without immediately adding a vSphere cluster. This is useful for staged deployments, but it comes with a hard lifecycle restriction: the domain cannot be patched or upgraded while it has no cluster. Any other domain sharing that NSX Manager is blocked from patching and upgrading as well. This design should therefore be temporary and deliberate.

A practical pre-upgrade checklist

Before opening a change window, validate the following:

• Classify the operation correctly as a deployment, convergence or upgrade.
• Inventory vCenter Server, ESXi or ESX hosts, vSAN, NSX, Aria Operations, Aria Automation, Aria Suite Lifecycle, Identity Manager, Log Insight and Operations for Networks.
• Confirm the exact source builds, not only the marketing version.
• Validate hardware, firmware, drivers, third-party integrations and target interoperability.
• Use the VCF Upgrade Planning Tool to generate a path for the actual starting state.
• Reserve all management IP addresses and create forward and reverse DNS records before deployment.
• Check for overlap with the VCF Services Runtime network.
• Resolve the Enhanced Linked Mode design before starting a vSphere-plus-NSX conversion.
• Decide whether VCF Operations and VCF Automation will be deployed immediately or deferred.
• Run pre-checks early enough to remediate failed hosts without blocking the maintenance window.
• Read the release notes for the exact target maintenance release and apply every stated dependency.

Conclusion

VCF 9.1 makes platform adoption more practical because it supports incremental modernization as well as full-stack convergence. A vSphere-only customer can move to the 9.1 compute and operations layer first. A vSphere-plus-NSX customer can reuse the existing environment through VCF Installer. Existing VCF 5.2.x and 9.0.x deployments can move forward through lifecycle management.

The flexibility is real, but so are the constraints. NSX changes the available path. Enhanced Linked Mode changes the preparation. VCF Management Services change the IP plan. The centralized license service changes entitlement handling. The component sequence remains mandatory.

The right strategy is therefore not to ask, “How do we upgrade everything?” Start with a more precise question: “What is our exact starting state, and which supported VCF 9.1 workflow matches it?” Once that answer is correct, the rest becomes an engineering exercise instead of a recovery exercise.

References

[1] Upgrade Sequence and Related Issues for VMware Cloud Foundation and vSphere Foundation 9.1

[2] VMware Cloud Foundation 9.1.1.0 Release Notes

[3] Paths to Building 9.1.x Environments

[4] Modernizing the Private Cloud: Why VCF 9.1 Lifecycle Management Is a Game Changer

[5] VCF Upgrade Planning Tool

VMware by Broadcom has signalled that it intends to refresh vSphere Standard for smaller deployments. That part is credible. The claim that a generally available “vSphere 9 Standard” already exists for customers up to 128 logical CPUs is not. As of 8 September 2026, it is a future product direction backed by executive comments, not a released SKU, published licensing programme, or contractual entitlement.

That distinction matters. Organisations should not purchase VMware Cloud Foundation (VCF) merely because someone assumes it is the only future path for a small estate. Equally, they should not make renewal, architecture, or migration decisions on the assumption that a 128-core vSphere Standard offer is available today. Both conclusions get ahead of the evidence.

The short answer

At VMware Explore 2026, Paul Turner, Chief Product Officer of VMware by Broadcom’s Cloud Foundation Division, told The Register that VMware had corrected the sales incentives that pushed customers toward VCF and had sometimes put too much emphasis on VCF. The report says that VMware will soon release an updated vSphere Standard. Ram Velaga, President of Broadcom’s Infrastructure Software Group, positioned the offer for organisations operating around 128 cores. Turner indicated that further details, including the route to market, were expected around VMware Explore Germany in mid-October.

That is a meaningful signal. It is also incomplete. VMware has not publicly documented a release date, product version, price, minimum commitment, feature matrix, channel availability, support model, or licence metric for this prospective refreshed offer. In particular, it has not stated that 128 cores is a hard ceiling, a licence bundle size, or a purchasing threshold.

First correction: it is “around 128 cores,” not “128 lCPU”

The reported wording is around 128 cores. It does not say 128 logical CPUs, 128 vCPUs, or 128 licensed processor threads. These are materially different quantities.

This is not pedantry. A licensing decision based on a logical-CPU count when the vendor is discussing cores is an avoidable error. Until VMware publishes the SKU and ordering guide, call this a market-positioning signal, not a licence rule.

What is actually confirmed

The evidence supports a narrow but important conclusion: VMware by Broadcom is re-engaging with the smaller virtualisation market and plans an updated vSphere Standard. The Register directly attributed the statements to Turner and Velaga. Techzine independently reported the same interview outcome and likewise described a new vSphere Standard as forthcoming, with more details expected at VMware Explore Germany.

The current official VMware vSphere page also lists vSphere Standard as a standalone subscription choice and positions it as “basic server virtualization for development and testing environments.” This confirms that Standard remains a product identity in VMware’s portfolio. It does not, however, identify a vSphere 9 Standard edition or reveal commercial terms.

“We corrected this,” Turner told The Register when discussing incentives that drove sales teams to VCF. He added that VMware had sometimes had “too big a focus on VCF.”

For smaller customers, that change in commercial posture is potentially more significant than any single technical feature. It recognises that basic virtualisation and a full private-cloud stack are different buying decisions.

What is not confirmed—and why that matters

VMware’s own current vSphere 9.1 FAQ is unambiguous: standalone vSphere Standard and vSphere Enterprise Plus are limited to vSphere 8 Update 3 and earlier. It states that vSphere 9.0 and 9.1 features are available only through VMware vSphere Foundation (VVF) 9.0/9.1 and VMware Cloud Foundation (VCF) 9.0/9.1. The official version-comparison document repeats the same position.

The implication is straightforward. A refresh has been signalled, but the authoritative public documentation still says that there is no standalone vSphere Standard for vSphere 9.1. Until that documentation changes and an orderable SKU exists, “vSphere 9 Standard is back” is a premature headline.

Where VVF and VCF fit while we wait

Today’s documented vSphere 9 path remains VVF or VCF. Broadcom’s 2024 portfolio announcement established VCF and VVF as its flagship subscription offers. VVF targets the traditional vSphere estate with broader operational and Kubernetes capabilities, while VCF is the complete private-cloud stack. The current VCF 9.1 licensing documentation describes term subscriptions and primary licences for VCF and VVF, with VCF capacity expressed in cores.

This means the immediate decision should remain technical and commercial, not emotional. Choose VCF where you genuinely need the integrated private-cloud platform, including the fuller stack and its lifecycle model. Choose VVF where the vSphere 9 feature set and included operational capabilities fit the estate, but the full VCF platform is not justified. Retain or renew vSphere Standard 8 Update 3, where available and appropriate, only with a clear support and lifecycle plan. A prospective vSphere Standard refresh is a reason to delay an irreversible platform decision when the timing permits; it is not a reason to ignore current support dates, procurement lead times, or business risk.

What smaller customers should do now

First, ask your Broadcom representative or authorised partner for a written statement of the currently orderable option for your estate. Verbal positioning is not a quote. Request the exact SKU, version eligibility, subscription capacity, minimum purchase, included support, renewal conditions, and regional availability.

Second, count the estate correctly. Record physical sockets, physical cores, logical CPUs, vCPUs, vSAN capacity, and the required availability and security services separately. Do not collapse those values into a single “CPU” number. That bad habit produces bad licensing comparisons.

Third, create a decision gate around VMware Explore Germany. The reported announcement window makes it a rational checkpoint for customers with renewal flexibility. If your renewal occurs before clear terms are published, price the documented options—VVF and VCF—alongside the cost and risk of a short renewal or bridge strategy. Do not assume a future Standard SKU will be backdated or automatically available to every existing customer.

Finally, demand a feature comparison before accepting the word “Standard” as an answer. The eventual value will depend on the precise vSphere 9 features included, whether memory tiering lands in the edition, lifecycle tooling, support coverage, and the economics relative to VVF. The product name alone does not resolve any of that.

Bottom line

The rumour has a solid factual basis: VMware by Broadcom has signalled an updated vSphere Standard aimed at environments of around 128 cores, and it has acknowledged that sales incentives over-favoured VCF. That is good news for smaller vSphere customers.

But the precise claim needs discipline. There is no public evidence that vSphere 9 Standard is generally available today, that 128 is a licence boundary, or that the threshold is 128 logical CPUs. Current official documentation still limits standalone Standard to vSphere 8 Update 3 and earlier.

So the rational position is neither “nothing has changed” nor “VCF is dead for small customers.” It is this: a credible lower-end option is coming, but it is not a product you can safely architect or procure against until VMware publishes the SKU-level facts.

References

[1] VMware swings its focus back to low-end server virt, promises vSphere Standard upgrade

[2] vSphere with VCF 9.1 General FAQ

[3] VMware vSphere Version Comparison

[4] VMware vSphere

[5] Licensing Overview for VMware Cloud Foundation 9.1

[6] VMware End Of Availability of Perpetual Licensing and SaaS Services

[7] VMware subtly promises a return to vSphere Standard