Eric Sloof

Yesterday evening Broadcom published a portfolio update, and the press dutifully covered the headline items: a new low-end vSphere tier, native disaster recovery coming to VCF, a private AI quickstart, two new Advanced Services. All of that is real and worth understanding.

But at the very bottom of the post, below the vSphere Express feature list, sits a single sentence that gives European VMware customers something no other region got: a year. Two years, depending on how you count.

"Furthermore, for customers in countries in the European Economic Area, vSphere Standard version 8 and vSphere Enterprise Plus version 8 will remain available for sale until October 31, 2027, and will have Extended Support included in any active subscriptions to those offerings until the earlier of the applicable subscription end date or October 31, 2028."

That is the most consequential thing published yesterday for anyone running VMware in the Netherlands, and almost no coverage led with it. So let us do exactly that, because the dates carry more nuance than they appear to, and the nuance decides what you should do in the next sixty days.

Two dates, and one condition that is easy to miss

Read the sentence again and separate it into its three parts, because they do different things.

Part one: sale continues until 31 October 2027. vSphere Standard 8 and vSphere Enterprise Plus 8 remain purchasable in the EEA for another twelve months. Not version 9 — version 8. That distinction matters enormously and I will come back to it.

Part two: Extended Support is included in any active subscription to those offerings. You do not pay extra for it during this window.

Part three, and this is where people will get caught: until the earlier of the applicable subscription end date or 31 October 2028. The word "earlier" is doing the work. The support runway to October 2028 is not automatic; it is bounded by your own subscription term. If you hold a subscription that expires in March 2028, your Extended Support ends in March 2028, not October 2028. To actually use the full window you need an active subscription running through October 2028, which means the question that matters is not "how long is support" but "what term length will Broadcom sell me in 2027, and at what price."

Nobody has published that yet. It is the first thing to ask.

A second gap worth naming: Broadcom has not described what "Extended Support" entails for these specific SKUs — whether it matches mainstream support in response times and severity coverage, or whether it is the reduced scope that the term usually implies elsewhere in the industry. Do not assume. Ask for the support policy document in writing, because "we have support until 2028" and "we have the support we had in 2026" are different claims.

And one geographical detail: this covers countries in the European Economic Area. That is the EU plus Iceland, Liechtenstein and Norway. It is not the UK, and it is not Switzerland. Any organisation with a footprint split across Amsterdam and London now has two different lifecycle calendars for the same product.

What the extra year does not give you

This is the part that will be misread most often, so it deserves its own section.

The extension is on version 8 SKUs. vSphere Standard and Enterprise Plus were consolidated around vSphere 8 Update 3; standalone vSphere 9 is not sold on those editions. So the extra year buys you time on vSphere 8, with support, at a per-core subscription price you already understand. It does not buy you vSphere 9 features — distributed switch improvements, vCenter Quick Patch, the vSphere 9 security work, TPM 2.0 and vTPM 2.0 enhancements.

If your reason for looking at vSphere Express was "we need to get to vSphere 9 without buying the full private cloud stack," the EEA extension does not solve that. Express remains the only low-end route to vSphere 9. What the extension changes is the urgency, not the destination.

Put more bluntly: you now have until October 2027 to decide, and until October 2028 to keep running what you have. What you do not have is a path to version 9 on Standard. Anyone who reads this announcement as "Standard is fine again" has misread it. Standard is tolerated for another two years, in one region, at version 8.

Why the EEA specifically

There is no technical reason for a regional carve-out. There is a competitive one, and it is not subtle.

The European small and mid-market segment is precisely where the alternatives gained the most ground after the 2023 licensing changes. Proxmox VE, Hyper-V, Nutanix and HPE's VM Essentials all built momentum in organisations running between 20 and 300 cores, and European buyers were among the most vocal about leaving. A one-year, region-specific extension that keeps a per-core, expandable product on sale in exactly that market is a retention move. It keeps the door open for customers who were about to walk through a different one.

That is worth understanding for what it is, because it tells you how to treat it. A regional exception granted under competitive pressure is a negotiating window, not a product strategy. It exists because enough customers in your region were leaving. The leverage that created it is still in your hands until October 2027, and it disappears the moment the deadline passes.

What this does to the Express decision

Two weeks ago, the arithmetic was simple and slightly brutal. vSphere Standard was reported to be at end of sale. If you were under 128 cores and wanted to stay on VMware, vSphere Express was effectively your only option: a fixed package you cannot grow into, on a twelve-month term, with DRS and vSAN reportedly excluded and a list price of 9,600 USD for cores you may not run.

The extension changes that comparison completely, and in your favour.

For an estate under 128 cores, waiting is now a rational strategy rather than a gamble. You can keep buying Standard per core, at a price you already know, for another year — and if you use 64 cores, you pay for 64 cores instead of 128. Express only wins on economics when you are genuinely near the ceiling, and only if you need version 9.

For an estate between 128 and 500 cores, the extension is more valuable still, because Express was never available to you. You now have a documented bridge to October 2027 during which the real decision — VVF, VCF, or leaving — can be made on evidence rather than under deadline pressure.

Four questions to ask this month

What term will you sell me, and at what price, if I want support running to October 2028? The "earlier of" clause makes this the whole game. A one-year renewal in 2027 gets you to 2028; a renewal that ends in June 2028 does not get you to October.

What exactly does Extended Support include for these SKUs? Response times, severity definitions, security patching commitment, and whether it is the same support you have today.

Does the extension apply to entitlements I already hold, or only to new purchases? The sentence says "any active subscriptions to those offerings," which reads as inclusive, but confirm it against your contract rather than a blog post.

What happens on 1 November 2027? There is no stated bridge from Standard 8 to anything. Assume there will be a conversion path and assume nothing about its price.

If you are outside the EEA — the UK, Switzerland, or anywhere else — the answer to all four is different, and the Express conversation is still the urgent one it was last week. That asymmetry is worth flagging to any group that sets VMware policy globally: the same announcement produced two different deadlines depending on where the datacentre sits.

Meanwhile, the rest of the announcement

The EEA extension is the story for Europe, but the rest of the portfolio did move, and briefly:

vSphere Express is available now in all regions: vSphere 9 based, up to 128 cores across all environments per customer, including vMotion with improved migration performance, HA, Distributed Switch, vCenter Quick Patch, and TPM 2.0 with vTPM 2.0. No price is published; partner listings indicate 9,600 USD for the package.

Disaster recovery becomes native in VCF and VVF, planned for Q1 of Broadcom's fiscal 2027 — a quarter that began on 2 November 2026. Orchestration across thousands of workloads, moving out of a separately purchased product and into the core entitlement. This is a licensing change disguised as a feature, and it is the second most important item published yesterday.

VPC policy-based connectivity and infrastructure configuration compliance are also planned as native VCF capabilities in the same window, the second monitoring VCF component settings against PCI and the VCF Security Baseline with drift detection and remediation.

Private AI: multi-tenant model sharing is already in VCF 9.1.1; AI Infrastructure Quickstart and vSAN native S3-compatible object storage are planned for Q1.

Advanced Services: VMware HyperArmor is planned for Q1; VMware Live Recovery and VMware Compliance and Configuration Management were added to the catalog yesterday.

One caveat that applies to all of it: Broadcom describes the next VCF release as currently estimated for Q1 FY27. September press reporting put the next feature release around May 2027 instead. Both cannot be right, and no version number has been confirmed anywhere. Treat Q1 as an intention.

The short version

Broadcom gave European customers a year to keep buying vSphere Standard 8 and a year of support on the other side of it, ending 31 October 2028 — subject to your own subscription term. It did not give you version 9 on Standard, and it did not make Express unnecessary.

What it did was remove the deadline. If you were about to sign a fixed 128-core package this month because you believed Standard was gone, stop and recalculate. You have a per-core, expandable option for another twelve months in the EEA, and the leverage that produced this exception is still yours to use.

That window closes on 31 October 2027 whether or not you have made a decision by then. The only mistake available here is to let it close without one.

References

• Broadcom / VMware Cloud Foundation Blog, "Broadcom Updates VMware Portfolio to Protect and Accelerate Private AI Cloud Deployments", Prashanth Shenoy, 4 November 2026: https://blogs.vmware.com/cloud-foundation/2026/11/04/broadcom-vcf-portfolio-updates/
• Broadcom TechDocs, vSphere Express: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-1/vsphere-express.html
• Network World, "Broadcom expands VMware Cloud Foundation with AI, security, and recovery capabilities", 4 November 2026: https://www.networkworld.com/article/4244653/broadcom-expands-vmware-cloud-foundation-with-ai-security-and-recovery-capabilities.html
• SiliconANGLE, "VMware gets simpler AI deployment and low-cost version for basic private clouds", 4 November 2026: https://siliconangle.com/2026/11/04/vmware-gets-simpler-ai-deployment-and-low-cost-version-for-basic-private-clouds/
• SDxCentral, "Broadcom's VMware vSphere gains 'essential' tier, VCF set for more updates", 4 November 2026: https://www.sdxcentral.com/news/broadcoms-vmware-vsphere-gains-essential-tier-vcf-set-for-more-updates/

For two years Broadcom's message to smaller VMware customers was essentially that there was no product for them. That changed this week. vSphere Express is now documented, orderable through partners, and priced. It is also considerably more constrained than the headline suggests, and the constraints are the part worth understanding before anyone signs.

Start with the honest status of the launch, because it differs from a typical product introduction. Broadcom has published the documentation for vSphere Express in the vSphere 9.1 library, and the page was last updated on 2 November 2026. There is no launch blog post and no press release accompanying it — the same pattern as several recent VMware announcements, where documentation and partner price lists land first and marketing follows later, if at all. The commercial detail below therefore comes from two places: Broadcom's own documentation, which is authoritative but incomplete on features, and partner datasheets and listings, which are consistent with each other but are not Broadcom-published material.

That distinction matters, because the documentation page for vSphere Express ends its feature section with a single sentence: "consult your sales representative." Broadcom has chosen not to publish the feature list. Everything in the included and excluded table below comes from partner material, which is why you should get it confirmed on paper as part of any order.

The package, in one paragraph

vSphere Express is a fixed bundle of 128 CPU cores on a twelve-month subscription. You cannot buy more, you cannot buy less, you cannot expand it, and each end customer may hold exactly one package. The SKU is VCF-VSP-EXP. The US list price published in partner material is 9,600 USD for the package, which is 75 USD per core per year — but only if you actually run all 128 cores. German resellers are quoting 9,631.77 EUR excluding VAT, with the explicit caveat that Broadcom must approve the order.

What you get is essentially vSphere Standard plus the distributed switch, plus the vSphere 9 additions. What you lose, compared to anything above it, is the entire resource-management and hardware-acceleration layer.

Two of those exclusions deserve emphasis. No DRS means no automatic load balancing across hosts and no automated maintenance-mode evacuation based on cluster-wide placement logic. That is not a cosmetic gap; it changes how you operate the platform, because vMotion becomes a decision you make rather than a policy the cluster enforces. No vSAN means no hyperconverged design at all. Express is a package for external storage — SAN or NFS — and anyone who built a small vSAN cluster on vSphere Standard needs to check what their storage design becomes on Express before they assume they can move.

The absence of GPU and vGPU support also closes a door that matters more in 2026 than it would have two years ago. And no memory tiering removes the feature that would have offset exactly the cost pressure that makes small estates painful to run.

The 128-core ceiling is the product, not a limit on it

A fixed package is a floor, and how much of a floor depends entirely on your core count. At the full 128 cores, 9,600 USD is 75 USD per core. At 96 cores — a very common shape: three dual-socket hosts with 16 cores per socket — you pay 100 USD per core. At 64 cores it is 150 USD. At 32 cores it is 300.

So the question "is Express cheaper than vSphere Standard was?" has no general answer. It has an arithmetic answer per estate, and the number that decides it is your billable core count after the 16-cores-per-CPU minimum is applied. If you are running 120 cores, Express is roughly break-even against the per-core economics you had before. If you are running 48, you are paying for 80 cores you do not own.

Two structural consequences follow. First, the package cannot grow. If there is any realistic chance your estate crosses 128 cores during the term — a new project, an acquisition, a host refresh that adds capacity — you are buying a product you will have to leave, and the exit is the thing to price before you enter. Second, the term is twelve months, which means you are back at the table every year. Reseller material describes Express explicitly as a transition offering and states that migration to vSphere Foundation is the intended path after those twelve months. Read that as the vendor's own positioning: this is an on-ramp, not a destination.

Eligibility is decided by Broadcom, and you cannot apply

This is the part that will generate the most frustration, so be precise with customers about it.

New customers qualify — defined as organisations that have never purchased VMware products, or have not purchased any in the last three years. That is straightforward.

Existing customers need Broadcom's authorisation. According to partner briefings, Broadcom has already determined which existing customers are eligible, that list is fixed, and there is no application process. Partners expect to receive visibility of that list in mid-November. Broadcom can also decline an order after the fact if the end customer turns out not to be eligible.

Practically, that means anyone currently running vSphere Standard and hoping Express is their continuity path cannot assume it. If the Standard and Enterprise Plus end-of-sale dates at the end of October 2026 are real — and partner listings treat them as settled — then an existing Standard customer between now and mid-November is in limbo, holding a subscription that is no longer sold and waiting to find out whether the replacement is available to them at all.

The operational surprise: two extra appliances to license three hosts

Here is the detail that will catch people who only read the price.

Broadcom's documentation lists four mandatory components for a vSphere Express environment: ESX, vCenter, VCF Operations, and a license server. Only vSphere Replication, VMware Tools and VMware Remote Console are optional.

VCF Operations is required solely for licence management in this edition; its management features are not part of what you bought. But it is not a checkbox in a portal. It is an appliance you deploy, size, patch, back up, certificate-manage and monitor, alongside the license server appliance, alongside vCenter. A three-host, 96-core estate that previously ran one vCenter now runs three management virtual machines, and needs somewhere to put them.

The documented build sequence for a new environment is manual, one component at a time:

1. Deploy the ESX hosts.
2. Deploy vCenter.
3. Deploy VCF Operations.
4. Deploy the license server.
5. Optionally deploy vSphere Replication (Protection and Recovery).
6. Optionally install VMware Tools.
7. Optionally install VMware Remote Console.

There is no unified installer path here. That is defensible for a package aimed at small environments — small environments are exactly where a manual, comprehensible build is tolerable — but it is a real change in effort for anyone comparing Express against a hyperconverged appliance that arrives as one image.

Licensing mechanics worth knowing before you order

The restrictions on Express licensing are documented and unusually specific:

• 128 cores maximum per customer, enforced per site ID. The VCF Business Services console blocks any allocation that would exceed it.
• Default licence only. You cannot split the licence into smaller units, and you cannot share it across sites.
• VCF Operations is used only for licensing. No add-on capabilities, and no add-on licences are available for Express at all.
• Version 9 or later only. Version 8 licence keys are not available for Express.

That last point is more significant than it looks. It means Express is a route to vSphere 9 for small estates that would otherwise be stuck: standalone Standard and Enterprise Plus are vSphere 8 Update 3 era products, so a small customer wanting vSphere 9 features has, in practice, to take Express, VVF, or VCF.

The licence workflow itself follows the same infrastructure as VCF and VVF: you buy a subscription, a default primary licence appears in the VCF Business Services console, you add the licence to VCF Operations and the license server, and you assign it to assets from VCF Operations. Familiar if you already run VCF 9. Unfamiliar, and slightly absurd, if your entire estate is three hosts.

The migration paths are the strategic point

Three documented paths exist, and they are the most interesting thing about the release.

Upgrade from vSphere 8. Minimum versions are vCenter 8.0 and ESXi 8.0, with Aria Operations 8.18.6 and vSphere Replication 9.0.2.2 if those are in place. The upgrade order is not the order most people would guess: vSphere Replication first, then Aria Operations, then the license server, then vCenter, then ESX hosts, then the distributed switches, then VMware Tools, then VM compatibility. Getting that sequence wrong on a live environment is the kind of thing that turns a weekend change into a week.

Converge to VCF. An existing Express estate can be used as the building blocks for a full VCF deployment, using the standard converge procedure for vCenter, ESX hosts and Aria Operations.

Extend to vSphere Foundation. Apply the VVF licence and, optionally, deploy VCF Management Services.

That third path is the one Broadcom is clearly designing for, and it reframes the product. Express is not a small-estate product line Broadcom intends to sustain. It is a landing zone that keeps a customer inside the VMware ecosystem at a price they will accept, on a twelve-month leash, with a documented and engineered path upward. Whether you find that cynical or pragmatic probably depends on whether you were one of the customers who spent the last two years evaluating Proxmox.

Who should actually take it

Take it if all of the following are true: you are at or under 128 billable cores; you are a new customer or you are on Broadcom's existing-customer list; you do not use DRS, vSAN, GPU or SR-IOV today and have no plan to; you have external shared storage; and you accept a twelve-month term with an annual renewal conversation.

Do not take it if any of these apply. You are between 128 and roughly 500 cores, in which case Express cannot cover you and your realistic options are VVF or VCF — this is the group with the least room to manoeuvre and the most urgent need to start procurement early. You depend on DRS for availability or maintenance workflows. You run vSAN. You need GPU capacity for AI or VDI workloads. Or you need the estate to grow on a predictable curve.

And be clear-eyed about the comparison set. For a 64-core estate, the honest alternatives in late 2026 are Proxmox VE, Hyper-V, Nutanix, HPE VM Essentials, or public cloud — and Express at 9,600 USD for a package you can use half of is not obviously the strongest of those on price. What Express still has is the operational maturity of the platform your team already knows, and for a lot of organisations that is worth real money.

What to confirm in writing

Five things, before anything is signed:

1. Your billable core count, computed per CPU with the 16-core minimum applied. If the answer is 130, Express is unavailable unless you retire hardware.
2. Eligibility, confirmed by Broadcom through your partner rather than assumed. Do not plan around a mid-November list you have not seen.
3. The published feature list, in writing, since Broadcom's documentation defers to a sales representative. Get DRS, vSAN, GPU, memory tiering and live patching confirmed as excluded rather than discovering it later.
4. The renewal price and the VVF migration price, asked for now. A one-year term with an engineered exit is only a good deal if you know what the exit costs.
5. The appliance overhead, including where VCF Operations and the license server will live, and who patches them.

Verdict

vSphere Express is a genuine reversal of direction, not a marketing gesture: Broadcom has admitted that its sales motion pushed VCF at customers who needed a hypervisor, and this is the correction. The price is real, the documentation exists, and partners can transact it.

But the design choices are revealing. A fixed package you cannot expand, a one-year term, eligibility Broadcom controls unilaterally and can revoke after the order, the removal of precisely the resource-management and memory features that make small estates economical, and a mandatory two-appliance licensing stack for an environment of three hosts — this is a product engineered to be a doorway rather than a room. That is not automatically bad. A doorway is what a lot of stranded vSphere Standard customers needed. It does mean you should walk through it knowing where it leads, and what it costs to walk back out.

VCF 9.1.1.0 went generally available on 3 September 2026 as a maintenance release with an updated bill of materials. In Broadcom's cadence that label means something specific: no new architecture, no renumbering of the platform, and a path designed to be taken by customers already running VCF 9.1. It does not mean the release is empty, and anyone who plans an upgrade this quarter should look past the label.

The technical content behind 9.1.1 runs across seven tracks: NSX networking, Kubernetes with VKS and Supervisor services, VCF Operations, VCF Automation, VMware Data Services Manager, Private AI, and Protection and Recovery. Read end to end, a clear pattern emerges. Very little here is invented from scratch. Most of it completes promises made in 9.1 — and a meaningful part of it is gated, either behind an explicit opt-in, a tech preview label, or an early-access program.

That gating is the most important thing to understand before you plan anything. Below is what actually changed, and where the fine print sits.

Networking: finishing what VNAs started

VCF 9.1 introduced Virtual Network Appliances (VNAs) as the vehicle for centralized services in a Distributed Tier-0 Gateway (DTGW) design. The gap in that first release was the external connection type: VNAs were validated for VLAN-backed external connections, not for EVPN/VXLAN.

9.1.1 closes that gap. VNAs are now validated with EVPN/VXLAN external connections, which means the centralized service set — Avi Load Balancer for L4, NAT and SNAT including default outbound NAT, and DHCP relay — becomes usable in EVPN designs. That matters practically, because EVPN/VXLAN is what many enterprise fabrics standardize on, and it is the connection type that makes VKS and VCF Automation deployments realistic at scale.

There is a deployment trap worth flagging. Because the feature introduces data plane changes, it does not work across an environment that mixes VCF 9.1 and 9.1.1 hosts. Broadcom therefore does not enable it automatically: you have to opt in through an API call. If you run a fleet upgrade in waves, finish the hosts before you touch that API.

DHCP relay on VNAs is the second networking item, and it is more interesting than it sounds. In 9.1, DHCP relay was supported on CTGW deployments only. With 9.1.1 it works with DTGW plus VNAs, configured through the VPC service profile with north-south services enabled. The relay converts broadcast DHCP requests into unicast toward the DHCP server, and you can configure up to eight servers as targets — which is the sort of number that tells you Broadcom expects this to be used for real IPAM offload rather than as a lab feature.

The benefit is architectural: subnet-level IP address management can be delegated to an external DHCP server, inside or outside the VCF environment, and you can choose per subnet. One subnet can use a DHCP relay while another keeps using the built-in DHCP server. If you have an existing IPAM practice, a service management platform, or a network team that owns address allocation, this removes a recurring objection to putting workloads on VCF.

Active/active route controllers. In 9.1, the EVPN route controller ran active/standby, and failing over from an active controller caused a data plane outage. 9.1.1 supports up to eight active/active route controllers, each running an independent BGP session to the EVPN gateway, with BFD available to retire a failed controller quickly. When a controller fails, its advertised routes are removed from both the EVPN gateways and the ESX hosts, while the other active controllers hold duplicates of the same entries. The result is a hitless failure — and, just as usefully, you no longer need to stretch a VLAN across the physical network between route controllers.

Direct prefix routing is the item that will generate the most design discussion. Historically the route controller collapsed everything advertised by the EVPN gateway into default routes pointing back at that gateway, which guaranteed all VCF traffic traversed the only device with a complete view of both virtual and physical workloads. Now the EVPN gateway can advertise next-hops other than itself for specific prefixes, and the route controller installs those specific routes directly into the ESX hosts. Selected workloads then tunnel straight to the destination VTEP, bypassing the border gateway.

The performance argument is sound: lower latency and higher throughput for virtual-to-physical traffic across the data center fabric, with no hairpinning. The operational argument deserves equal weight. This capability is only as good as your BGP configuration in the physical network, it requires deliberate capacity planning on the NSX control plane as routes are pushed to many hosts, and it has to stay within the hardware limits of your switch ASICs. Broadcom has not yet published exact scale numbers for this. Treat it as a targeted optimization for specific flows, not a global default.

VLAN-backed VPCs deserve a paragraph of their own because they are easy to misread. This is a fallback deployment model that lets you stand up a workload domain for VCF Automation or VKS without a TEP network and without requiring an MTU above 1500. It preserves the VPC model and APIs, which is genuinely valuable for future migration into a fully virtualized network.

It also comes with hard limits: public subnets only, no private subnets, no NAT, no network isolation between VPCs, IP unicast traffic only. Subnets have no virtual Layer 2, so anything depending on broadcast, multicast or non-IP traffic — VRRP-style high availability being the obvious example — will not work. VNAs are supported for load balancing only. Broadcom's own positioning calls this a solution of last resort, and that framing is correct. Offer it when organizational or political constraints make NSX overlay deployment impossible, not as a shortcut to avoid learning the network stack.

Kubernetes: security, patching, and a real add-on framework

The VKS work in 9.1.1 is the most coherent part of the release, because it addresses three separate problems that platform teams hit in sequence.

Immutable node OS. VKS cluster node OS binaries can now be locked down, moving /usr to read-only system binaries, restricting /opt to configured binaries, and mounting other partitions as non-executable. Combined with the existing UEFI Secure Boot chain that verifies Photon OS before loading it, this blocks workloads and unauthorized processes from modifying critical operating system directories — a meaningful barrier against privilege escalation and persistence.

Note the constraints. It is supported on Photon 5 only, it is not enabled by default (a cloud admin must turn it on), and Ubuntu and RHEL node images are not covered. Broadcom describes this as phase one of a capability that will extend toward stricter immutability and, eventually, node replacement.

OS patching decoupled from Kubernetes versions. This is the fix for a genuine operational deadlock. Historically, OS security patches arrived bundled in a Kubernetes patch version, which meant a critical CVE fix waited on planning and a maintenance window large enough for a cluster upgrade. With 9.1.1 you can build a node image with the OS patch applied — via Image Baker, from Photon 5, Ubuntu 22.04 or 24.04, RHEL 9, or Windows Server 2022 — and roll it out with rolling node replacement, leaving the Kubernetes version untouched. For regulated environments with weekly or bi-weekly patching obligations, that closes a compliance gap without turning every CVE into a change project.

The add-on framework. The old Core and Standard packaging names are replaced by four tiers that are defined by who supports what:

For platform teams the practical value is a single lifecycle mechanism across all four tiers, with a documented boundary for who takes the call. The Helm Controller add-on is the most consequential item here: it lets standard, unmodified Helm charts be packaged as first-class VKS add-ons with install, update, rollback, drift detection and reconciliation handled declaratively instead of through imperative CLI work. That lowers the cost of onboarding ISV software for Broadcom and for partners — and it removes an argument that has kept a lot of tooling off VKS.

Alongside it, three named add-ons are worth knowing:

• Gatekeeper arrives as a Product-tier add-on with sane defaults and the exclusions for system and VKS namespaces that people historically forgot to configure by hand, which is exactly how clusters ended up non-functional. It provides Rego-based admission control, audit and drift detection, and mutation, and it is air-gap ready.
• Headlamp is the first Ecosystem-tier package: a Kubernetes UI with live node shell and pod debugging, plugin support, and automatic detection of other VKS add-ons.
• Cilium extends to L7 proxy visibility (latency, HTTP status codes) and Gateway API for north-south and east-west connectivity — an eBPF-native alternative to Istio for the ingress path.

One smaller item closes a long-standing friction point: validated Ubuntu images from Canonical are now consumable directly in VM Service through subscribed content libraries, once the provider allows the subscription. That arrived in a 9.1 express patch rather than in 9.1.1 itself, but it is the sort of thing that removes the "build your own image first" step from every VM demo.

VCF Operations: less dashboarding, more lifecycle control

Operations is where 9.1.1 delivers the most volume, and the theme is consolidation. Several capabilities that used to be separate tools, or separate manual procedures, now live in one console.

OpenTelemetry-based VKS observability adds a platform extension that instruments VKS clusters and pulls metrics, logs, events and traces into VCF Operations. The prerequisites matter: Real-Time Metrics must be enabled as part of Day-N operations first, then the Platform Observability extension. After that, onboarding a cluster is a matter of running a generated command with the OpenTelemetry agent, and the cluster appears on the Platform Services page within seconds. From there you get cluster overviews with node, pod, container and workload counts, per-node breakdown of control plane versus worker nodes, namespace views, and correlated system logs and Kubernetes events.

Grafana dashboard import is included, with JSON schema validation on import. The value is not the import mechanism itself but access to the community library of pre-built Kubernetes dashboards without leaving the platform.

Identity and access. VCF single sign-on for Active Directory and OpenLDAP no longer requires pre-provisioning of users and groups. With on-demand lookup enabled, the identity broker queries the directory directly at login and authorizes against current group membership, rather than against a local copy that is only as fresh as the last scheduled sync. Admins can enable it per identity provider, keep the legacy model, or run a hybrid. Two details from the documentation are worth carrying into a design: enabling on-demand lookup disables the Global Catalog option, and direct directory queries add minor latency at login. That is the correct trade — accuracy at authentication time — but it should be a deliberate choice.

Password and certificate management. Password coverage now includes all out-of-the-box OS and application accounts for vCenter, SDDC Manager and the VCF Operations network collector, plus a Last Password Update column for audit purposes. Password policies extend to VCF Automation accounts, the Operations Cloud Proxy and the network collector, with two workflow improvements that matter at fleet scale: you no longer need to run an initial compliance check after assigning a policy, and remediation now supports retrying only the failed components. Policies can also be detached from an instance.

Certificate management expands to vCenter (including STS and VMCA root certificates), NSX Edge, Supervisor, License Server, Cloud Proxy and the network collector. Two additions go beyond coverage:

• Admins can now view and manage components configured with non-TLS certificates, monitor third-party certificate expiry, and replace self-signed certificates with CA-issued ones from a Microsoft CA, OpenSSL or a third-party CA.
• Component-managed certificates — the internal category that only the component itself can renew — are now monitored for renewal failures, with alerts that carry knowledge base guidance. Previously a failed silent renewal surfaced as an outage.

Configuration management via API. The VMware Salt for VCF Component APIs expose more than 300 configuration settings across the core stack, published to developer.broadcom.com, so configuration enforcement, drift detection and remediation can be driven from pipelines instead of the console. The licensing dependency is easy to miss: these APIs are based on the full Salt API set licensed with the Advanced Cyber Compliance add-on for VCF. Budget for that before you design an automation around it.

Licensing gains IPv6 and dual-stack support for the license server, plus improved error handling for failures. Be precise about the IPv6 path: on a greenfield deployment the license server comes up IPv4, and IPv6 or dual-stack is configured after the fact either by powering the appliance down and changing its IP settings, or by deploying a second license server from the OVA and migrating. When deploying through the VCF Installer, IPv6 cannot be set before first boot.

VMware Intelligent Assist: read the availability note

The AI Assistant for VCF — VMware Intelligent Assist, or VIA — is the headline feature of the release, and it is available to select customers only. You need to work with your account team to enable it. Everything below describes capability that exists, not capability you can assume you have.

VIA is enabled as a Day-2 extension and requires two configuration steps: add an LLM provider, then select a model. In 9.1.1 the provider is either Google Gemini or VCF Private AI Services, which allows an on-premises or another public model. Once configured, models become available and each user can pick a model per session.

The interesting part is the tool layer. VIA ships with a fixed, non-customizable set of Broadcom-built tools that extend the LLM into the environment with real-time data: active_issues, esx_host_diagnostics, esx_hosts_health_triage, ops_inventory_query, ops_log_monitoring, resource_alerts, vmotion_troubleshoot, vmsp_active_issues and vmsp_relationships. The model analyses the prompt, selects the relevant tool, executes it, and folds the result into the answer. That is what separates a useful diagnostic assistant from a chatbot summarizing documentation, and it is also why the static tool list is a limitation rather than a feature.

There is an AI Observability tab for token usage, performance statistics, a per-tool usage breakdown, and an audit log of provider and model changes. For anyone worried about cost control on enterprise AI, that is the right control to ship first.

The second AI capability is more consequential for everyday operations: an AI-assisted Management Pack Builder. Building a management pack for third-party hardware used to take days of reading vendor API documentation and writing custom scripts — work that frequently never got done, leaving critical infrastructure unmonitored. Now an admin points the platform at a live API endpoint, describes what they want to monitor, and the AI analyses the schema, suggests metrics and properties, maps object relationships (power supplies, fans, network adapters, temperature sensors), and generates dashboards. Time to value drops from days to minutes, and the people who can do it no longer need development skills.

VCF Automation: Argo CD as a managed service

GitOps on VCF has been unnecessarily painful. In 9.0.1, Argo CD existed only as a Supervisor service; deploying an instance required vCenter access plus kubectl, the VCF CLI and the Argo CD CLI, and every namespace and VKS cluster endpoint had to be registered by hand — again, every time a new one appeared.

9.1.1 turns Argo CD into a VCF Service managed through Service Management in the provider portal. Provider admins install, lifecycle-manage and publish it to regions; organization users then create and manage their own instances from the VCF Automation console with no vCenter access and no CLI. Three things make this worth more than the UI convenience:

• OIDC configuration is injected automatically into each instance, so users log in with existing credentials through "Log in via VCF Automation" instead of retrieving and sharing an auto-generated admin password. Role-based access is assignable per user, with a default admin account retained for break-glass access.
• Attaching a vSphere Namespace or VKS cluster from the console registers the endpoint automatically. That is the zero-toil part, and it eliminates the repetitive step that made GitOps drift operationally.
• Each instance deploys one-to-one into a hosting namespace but can manage multiple namespaces and clusters within its region, so a single instance can act as the GitOps control plane for a whole region. CPU, memory, storage and replica allocations are tunable per component, though the hosting namespace must have those resources reserved.

The catch: this capability is in tech preview in 9.1.1. It is a strong signal of direction and a reasonable thing to evaluate, and a poor thing to build a production delivery pipeline on today.

Data Services Manager: the biggest functional jump in the release

DSM gets the least attention of any component in VCF and, on the evidence of 9.1.1, the most substantive work. Five themes define the release.

DSM becomes a VCF-native service. The VCF Provider Operator orchestrates the regional lifecycle — appliance bootstrap, rolling upgrades, rollbacks, automated disaster recovery, infrastructure policy bindings for Supervisor namespaces — with continuous monitoring of appliance health, repair of networking drift, and rotation of certificates and credentials. Authentication moves to VCF Automation refresh tokens with least-privilege RBAC, which removes a layer of static credential sprawl. Self-managed regions remain available where admins want manual control, and VCF-managed regions get the automation.

Multi-zone, three-node high availability. The headline resilience claim is surviving a zone failure with zero downtime. This is the item to validate hardest in a proof of value, since availability claims are where architectures quietly diverge from documentation.

A Health Validator operator runs on workload clusters and probes DNS, the DSM Gateway, vCenter, storage and S3 endpoints, Active Directory or OpenLDAP, telemetry and syslog, and inter-cluster replication networks. Results surface as structured Kubernetes conditions with actionable error codes, so misconfiguration is caught before provisioning or failover rather than during it. There is also network diagnostics, NSX-VPC-aware support bundles, and dual Prometheus targets.

Engine modernization across all three databases.

• PostgreSQL 18 support, dedicated streaming read replicas for offloading analytics and reporting with replication lag visibility, and configurable shared_preload_libraries (which is how extensions such as set_user become usable). Refactored background management loops also cut idle CPU, improving VM density per host.
• MySQL in-place major upgrades from 8.0 to 8.4 LTS for both standalone and Group Replication topologies, with pre-flight table-consistency checks, an automatic safety backup, and automatic abort and rollback if checks fail. Minor version patching runs inside scheduled maintenance windows, and a cluster can be restored from S3 backup files alone — no existing cluster object or DR pairing required.
• SQL Server 2025 with the latest cumulative updates, Group Managed Service Account integration that retrieves rotated passwords from AD and refreshes Kerberos keytabs without service interruption, striped multi-URL backups up to 12.8 TB to work around S3 single-file limits, per-database Transparent Data Encryption via T-SQL, and manual seeding for Always On Availability Groups to avoid timeouts on multi-terabyte databases.

Observability and brownfield onboarding. SQL Server monitoring becomes per-database — I/O latency, request rates, MB read and written, transaction-log backup health — with alerts that carry the CR name and route to the owning tenant namespace. Existing external SQL Server backups can be imported from S3 to bring workloads under DSM management, and jumbo frames (MTU 9000) support high-throughput replication fabrics.

For a release described as a minor version, that is a lot of movement. The honest summary is that DSM has moved from a competent DBaaS add-on to something that can carry regulated production workloads.

Private AI Services 3.0: hybrid models and multi-tenancy

VCF Private AI Services 3.0 ships with 9.1.1 and shifts the product from on-premises model serving toward a governed access layer.

Hybrid cloud LLM support adds public cloud providers — Gemini native, Gemini via OpenAI-compatible endpoints, Google Vertex (native and OpenAI-compatible), Mistral and OpenAI ChatGPT — behind the same API gateway used for on-premises models. Requests arrive over gRPC or HTTP from agents or cognitive pipelines, get routed and authenticated at the gateway, and are forwarded to the appropriate backend. Every call captures prompt, completion and total token counts, plus metrics per status code. Consistent governance and cost visibility across model endpoints is the actual product here; the model list is just the surface.

Multi-tenant Model-as-a-Service allows cross-namespace model sharing: a high-performance model deployment in one namespace can be consumed by other authorized tenants, with traffic passing through secure proxy gateways over mTLS. Isolation is by vSphere namespace or by VCF Automation organization namespace. For service providers and for internal platform teams, this is what turns expensive GPU capacity from a per-team cost into a shared asset.

Authorization consolidates into a unified access framework that supports OIDC providers, VCF Automation and static local credentials concurrently within a single instance, with cryptographic separation per organization and the ability to fall back to local credentials during bootstrap, maintenance or offline operation.

Deployment gets dramatically simpler. VCF Private AI Services can now be installed from the Local Consumption Interface, a vSphere-native plugin, and neither VCF Automation nor NSX is required to get started. A model-runtime-only stack makes data indexing and agent building optional, and pre-flight checks validate configuration before deployment. If your organization manages AI through VCF Automation instead, the Cloud Consumption Interface path enforces tenant boundaries using NSX VPC constructs.

Observability is per-namespace: a Prometheus server is deployed inside each tenant namespace so telemetry stays isolated, capturing request rates, model and agent latency, token usage, time-to-first-token and agent status, visualized in the product UI. For deeper work, tracing follows OpenTelemetry and OpenInference standards with export to any OTLP-compatible backend and contextual tags such as agent_id, knowledge_base_id and model_routing_name, covering agent runs, tool execution, indexing pipelines and retrieval paths.

Protection and Recovery: a small but pointed change

The Protection and Recovery track contains a single slide in the technical deck, and the message is about integration rather than new product: Clean Room architectures can now get per-VM network isolation through NSX VPC connectivity policies, using core VCF NSX functionality, and optionally through vDefend firewall capabilities where those are already licensed. The practical effect is simpler deployment and simpler licensing of Clean Room infrastructure for teams that would otherwise have to justify an additional firewall investment.

Given how Clean Room is typically sold — isolated recovery environments, often in a separate location, often under scrutiny from auditors and insurers — reducing its dependency on extra licensed components is a bigger deal than the slide implies.

What to watch before you upgrade

The technical content is real, but the constraints are where upgrade planning succeeds or fails:

• Mixed-version host environments. VNA support with EVPN/VXLAN external connections requires an explicit API opt-in precisely because it breaks in environments mixing VCF 9.1 and 9.1.1 hosts. Sequence your host upgrades accordingly.
• Tech preview. Argo CD as a managed service is tech preview. Evaluate it, do not standardize on it yet.
• Restricted availability. VMware Intelligent Assist, including the AI Assistant and the Management Pack Builder, is limited to select customers in 9.1.1 and requires engagement with your account team.
• Opt-in security. VKS node OS immutability is not enabled by default, is Photon 5 only, and excludes Ubuntu and RHEL images.
• Licensing dependencies. The Salt for VCF Component APIs assume the Advanced Cyber Compliance add-on. IPv6 on the license server cannot be configured before first boot when deploying through the VCF Installer.
• Architectural guardrails. Direct prefix routing needs BGP discipline in the physical network and capacity planning on both the NSX control plane and the switch silicon. VLAN-backed VPCs are a last resort with no NAT, no private subnets and no isolation.
• Unpublished scale numbers. Broadcom has not yet published exact NSX scale figures for direct prefix routing. Do not design to a number you have not seen.

Conclusion

VCF 9.1.1 does not change what VCF is. It removes friction at the points where VCF has historically been hardest to operate: EVPN designs that could not use centralized services, Kubernetes patching that coupled OS fixes to version upgrades, certificate and password management spread across components, GitOps that required three CLIs, database lifecycle management that depended on a specialist, and AI services that were difficult to deploy at all.

The most valuable items are not the ones with the biggest slides. Active/active route controllers remove a data plane outage from the failure model. Decoupling OS patching from Kubernetes versions solves a compliance problem that had no clean answer. Component-managed certificate alerting prevents a class of silent outage. And the DSM work is the strongest functional improvement in the release.

The least valuable thing you can do with this release is treat "maintenance" as "nothing to plan for." The features that matter here are gated by opt-ins, preview status and licensing, and those gates are exactly what an upgrade plan needs to account for.

With Broadcom's licensing changes to VMware's portfolio, more and more admins and homelabbers are looking for alternatives to vSphere for virtualization. One of the most mature open-source options is XCP-ng, a free Xen-based hypervisor, paired with Xen Orchestra as its management interface — the equivalent of what vCenter is for ESXi.

In this article we'll walk through setting up a complete XCP-ng + Xen Orchestra environment entirely inside VMware Fusion on a Mac. This is a great way to try out the stack in a lab environment before committing physical hardware to it, or simply to get familiar with the tooling.

Why XCP-ng?

XCP-ng is built on the Xen hypervisor — the same technology underpinning AWS EC2 for many years — and is completely free and open source, with no artificial feature gating. Paired with Xen Orchestra, it offers:

• Pool/cluster management
• Live migration
• Backup and replication
• A full REST API
• A modern web UI

Unlike ESXi, there's no license key, no feature tiers, and no vendor lock-in. The commercial model (XOA, the official Xen Orchestra Appliance) is entirely optional — you can build Xen Orchestra yourself from source for free, which is exactly what we did here using the Xen Orchestra Community Edition (XOA CE).

The Lab Setup

For this test we used two VMs inside VMware Fusion on an Intel-based Mac:

1. XCP-ng host — the hypervisor itself
2. Xen Orchestra — a minimal Debian 13 VM running the XO management stack

Both VMs were placed on bridged networking so they'd get their own IP addresses on the local LAN and could reach each other (and the outside world) directly.

A note on nested virtualization

Since XCP-ng is itself a type-1 hypervisor, running it inside a VM means you need nested virtualization support. In VMware Fusion, this is the "Enable hypervisor applications in this virtual machine" / "Virtualize Intel VT-x/EPT" option in the VM's processor settings. Without this enabled, the XCP-ng installer will refuse to boot properly or VMs created on top of it won't start.

Keep in mind this setup is for testing and learning purposes. Running a hypervisor nested inside another hypervisor adds overhead, so for production use, XCP-ng should be installed directly on bare-metal hardware.

Step 1 — Installing XCP-ng

1. Download the XCP-ng ISO from the official XCP-ng website.
2. Create a new VM in VMware Fusion, pointing the installer to the ISO. Give it a reasonable amount of RAM and CPU (4+ GB RAM and 2+ vCPUs is a sane minimum for a lab), a disk of at least 50 GB, and bridged networking.
3. Enable nested virtualization in the VM's CPU settings before first boot.
4. Boot the VM and walk through the XCP-ng text-mode installer: accept the keyboard layout, select the installation disk, set a strong root password, and configure networking (DHCP is fine for a lab).
5. Once installation finishes and the VM reboots, the console will show the host's IP address — this is what you'll use later to connect from Xen Orchestra.

Since XCP-ng 8.3, the host actually ships with a built-in web UI called XO Lite, reachable by simply browsing to the host’s IP address. It’s more capable than you might expect — a dashboard with host/VM status, resource usage stats, available patches, network and storage overviews, and even basic VM creation. What it doesn’t do is backup/replication jobs or multi-pool orchestration — for that, and for the full management experience, a proper Xen Orchestra instance is still the way to go (XO Lite even has a handy “Access XOA” button that links straight to it once it’s set up).

Step 2 — Installing Xen Orchestra (Community Edition)

Rather than using the official paid XOA appliance, we deployed Xen Orchestra from source, using the community-maintained xen-orchestra-installer-updater script by ronivay. This script automates the otherwise tedious process of building xo-server and xo-web from the official Vates repository.

1. Create a second VM in Fusion — a minimal Debian 13 (Trixie) install works well. During the Debian installer's software selection step, we deselected the desktop environment and GNOME (a GUI isn't needed for a headless server), keeping things lightweight.
2. After Debian finishes installing and reboots, log in as root on the console.
3. Install the basic tools needed to fetch the installer script:

   apt update && apt install -y git curl sudo

4. Clone the installer/updater repository:

   git clone https://github.com/ronivay/XenOrchestraInstallerUpdater.git
   
   cd XenOrchestraInstallerUpdater

5. Copy the sample configuration file — the defaults are sensible for a first install:

   cp sample.xo-install.cfg xo-install.cfg

6. Run the installer:

   sudo ./xo-install.sh --install

The script takes care of everything: installing Node.js, Yarn, and Redis, fetching the Xen Orchestra source code, and building xo-server and xo-web. This build step is the most time-consuming part of the whole process — on a modest lab VM it can easily take 10–15 minutes, so this really is a "grab a coffee" moment, as the script itself helpfully points out.

Once finished, the script reports that the web UI is available on port 80, with default credentials:

Default username: admin@admin.net

Default password: admin

Change this password immediately after your first login — more on that below.

Step 3 — Connecting Xen Orchestra to the XCP-ng Host

With Xen Orchestra running, open a browser and navigate to the IP address of the Debian VM (e.g. http://<xo-ip-address>). After logging in with the default credentials:

1. Click "+ Connect pool" on the dashboard.
2. Fill in:
   • IP address: the IP of your XCP-ng host
   • Username: root
   • Password: the root password you set during the XCP-ng install
3. Check "Accept self-signed certificates", since XCP-ng uses a self-signed cert by default.
4. Click Connect.

Within a few seconds, Xen Orchestra discovers the pool and host, and they appear in the tree view on the left. From here you have full access to create and manage VMs, monitor resource usage, configure storage repositories, and set up backup jobs — all from a clean, modern web interface.

Housekeeping: Change the Default Password

The very first thing to do after a fresh install is change the default Xen Orchestra admin password. In the web UI, go to Administration → Users, select the admin@admin.net account, and update the credentials to something strong and unique. Leaving the default admin/admin combination in place — even in a lab — is an easy way to get caught out later.

Where to Go From Here

This lab setup only scratches the surface of what the XCP-ng + Xen Orchestra combination offers. If you want to explore further, some good next steps are:

• Pools: add multiple XCP-ng hosts into a single pool for live migration and shared resource management.
• Storage repositories: connect NFS, iSCSI, or local storage, and experiment with shared storage across a pool.
• Backups: Xen Orchestra has a built-in backup/replication engine — well worth testing against a few throwaway VMs.
• Updates: the same XenOrchestraInstallerUpdater script used for the install can also be used to update Xen Orchestra in place by re-running it — keeping your CE build current without needing the paid XOA subscription.
• REST API: XCP-ng and Xen Orchestra both expose APIs, useful if you want to automate VM provisioning as part of an infrastructure-as-code workflow.
• Bare-metal install: once comfortable with the tooling, the natural next step is installing XCP-ng directly on physical hardware — nested virtualization is great for learning, but it adds a performance penalty you won't want in production.

Conclusion

For anyone evaluating alternatives to ESXi following VMware's licensing changes, XCP-ng combined with Xen Orchestra is a serious, mature, and completely free option. Spinning it up inside VMware Fusion — as shown here — is a low-risk, zero-cost way to get hands-on experience with the platform before deciding whether it's the right fit for your environment.

If you've ever wanted a self-contained virtualization lab on your Mac without touching your daily-driver setup, running Proxmox VE inside VMware Fusion is a surprisingly solid option. It gives you a nested hypervisor you can tear down and rebuild at will, perfect for testing clustering, backups, networking tricks, or just getting comfortable with Proxmox before deploying it on real hardware.

Here's how I set mine up from scratch — including a hardware-acceleration snag I didn't expect.

Why Proxmox VE in a VM?

Proxmox VE is a free, Debian-based type-1 hypervisor that bundles KVM virtualization and LXC containers with a clean web UI. Running it as a guest inside VMware Fusion on my Mac means I get a disposable lab environment: I can snapshot it, break it, and roll it back without any risk to my actual machine or network.

Step 1: Grabbing the ISO

First stop was the official Proxmox downloads page at proxmox.com, where I pulled the latest installer image: proxmox-ve_9.2-1.iso (about 1.71 GB), mirrored from enterprise.proxmox.com. Always get your ISOs from the official source — no third-party mirrors for a hypervisor you're going to trust with your lab.

Step 2: Creating the VM in VMware Fusion

In VMware Fusion, I went with File → New → Create a custom virtual machine rather than letting Fusion "Easy Install" an OS automatically — Proxmox's installer needs full control over the boot process, so a manual, custom VM is the way to go.

A fun detail: Fusion doesn't have a dedicated "Proxmox" entry in its guest OS list (no surprise, it's not a desktop/server OS Fusion ships support profiles for). Since Proxmox VE 9 is built on Debian 13 ("Trixie"), I simply selected Linux → Debian 13.x 64-bit as the guest OS type. This gets Fusion to apply sane defaults for a Debian-based Linux guest, which maps cleanly onto Proxmox's own underlying OS.

For firmware, I chose UEFI over Legacy BIOS — Proxmox VE 9 plays nicely with it, and it keeps things consistent with how most modern bare-metal Proxmox installs boot.

Step 3: Sizing the lab

Default settings are far too small for anything beyond a toy install, so I customized the hardware before first boot:

• CPU: 4 processor cores
• Memory: 8192 MB (8 GB)
• Disk: 64 GB (up from Fusion's default 20 GB)
• Network adapter: Bridged (Autodetect) — this puts the Proxmox VM directly on my LAN with its own IP address, exactly like a real node, so I can reach the web UI from any device on the network instead of fighting with NAT port forwarding.

These numbers leave enough headroom to run a handful of nested VMs or containers inside Proxmox itself once it's up — which is really the whole point of a lab like this.

Step 4: Mounting the ISO and booting

Back in the VM's settings, under CD/DVD (SATA), I pointed the virtual optical drive at the downloaded proxmox-ve_9.2-1.iso and made sure "Connect CD/DVD Drive" was checked. Then it was just a matter of hitting play.

A few seconds later, the familiar Proxmox boot screen appeared:

Proxmox VE 9.2 (iso release 1) - https://www.proxmox.com/

Install Proxmox VE (Graphical)

Install Proxmox VE (Terminal UI)

Advanced Options

From here, the installer takes over: disk selection, country/timezone/keyboard layout, network configuration, and — importantly — setting your own root password and admin email. That part you want to do yourself, live, rather than scripting it, since it's the one credential guarding your entire lab.

Step 5: The nested virtualization catch

Once Proxmox was installed and I logged into the web UI, I tried spinning up a test VM inside my new Proxmox lab — and immediately hit a wall:

No support for hardware-accelerated KVM virtualization detected.

Check BIOS settings for Intel VT / AMD-V / SVM.

Proxmox relies on KVM, which needs hardware virtualization extensions (Intel VT-x/AMD-V) exposed all the way down from the physical CPU, through the host hypervisor, into the guest. In other words: for nested virtualization to work, VMware Fusion itself has to pass those CPU features through to the Proxmox VM.

So I went back into Proxmox VE Lab → Settings → Processors & Memory → Advanced options in Fusion and enabled:

• Enable hypervisor applications in this virtual machine — this is Fusion's toggle for exposing Intel VT-x/EPT inside the guest, which is exactly what's needed to run "modern virtualization applications" like a nested KVM hypervisor.
• Enable IOMMU in this virtual machine — useful if you later want to experiment with PCI passthrough inside the nested lab.

Both checkboxes were there specifically to support this scenario, so it felt like the right fix. Worth noting, though: whether nested virtualization actually works after enabling these depends on your physical Mac's CPU and Fusion version — it's not a given on every machine. If you hit the same KVM error after flipping those switches, don't panic: your Proxmox install itself is fine, and LXC containers (which don't need KVM) will still run without any hardware-acceleration requirements. Full KVM-backed VMs inside the lab are the only thing affected.

A few lessons learned

• Bridged networking matters. If you plan to access the Proxmox web UI (https://<ip>:8006) from your Mac's browser or other devices, bridged mode avoids the headaches of NAT-only networking.
• Nested virtualization isn't automatic. Enabling "hypervisor applications" and IOMMU in Fusion's Processors & Memory settings is the right first step, but hardware-accelerated KVM inside a nested VM depends on your Mac's underlying CPU and Fusion's support for it — test this early if your lab plans involve running VMs (not just containers) inside Proxmox.
• Treat the disk size generously. 64 GB sounds like a lot until you've got a couple of nested VMs and some ISOs sitting in local storage.

Wrapping up

Within about fifteen minutes — most of it spent waiting on the ISO download — I went from "nothing" to a booted Proxmox VE installer running as a guest inside VMware Fusion, fully isolated from my host Mac. The one real bump was hardware-accelerated nested virtualization for KVM-backed VMs, which needed an explicit opt-in in Fusion's settings and still may not be guaranteed depending on your hardware. LXC containers, meanwhile, worked without any of that fuss.

If you're on a Mac and want a Proxmox sandbox without dedicating separate hardware to it, this setup gets you there in less time than it takes to read this post — just don't be surprised if your first nested VM boot throws that KVM warning at you.