That's a great question that gets at the heart of Broadcom's post-acquisition strategy. Let me dig into what they've actually said about this.Here's what Broadcom means and how it's possible:

The 8,000 SKUs: How VMware Got That Bloated

VMware didn't have 8,000 distinct products. It had roughly 168 products and bundles, but those multiplied into thousands of SKUs through what can only be described as licensing combinatorics. Each product could be sold under multiple dimensions:

• License type: perpetual licenses, term licenses, subscription, support & subscription (SnS) renewals, hybrid purchase program credits
• Edition tiers: Standard, Enterprise, Enterprise Plus, Advanced, etc.
• Metric basis: per-CPU, per-core, per-VM, per-user, per-terabyte
• Bundle variations: vSphere alone, vSphere + vSAN, vSphere + NSX, various "suites" (vCloud Suite, vRealize Suite, etc.)
• Add-ons sold separately: disaster recovery, logging, monitoring, automation, networking
• OEM and partner-specific SKUs: versions sold through Dell, HPE, Cisco, and other OEMs with their own packaging

Multiply these dimensions across 168 products and you easily arrive at thousands of line items. Broadcom CEO Hock Tan described the old model as creating "channel chaos and conflict in the marketplace" — customers couldn't easily figure out what to buy, partners were competing on SKU arbitrage rather than value-add services, and VMware's own sales force spent enormous energy managing the complexity.

The "4": What They Collapsed It To

Post-acquisition, Broadcom collapsed everything into essentially four core offerings:

Add-ons like vSAN (storage), disaster recovery, and security services can still be purchased separately, but the core menu went from thousands of line items to a handful.

Why This Was Possible

Independent VMware had every incentive to proliferate SKUs — more SKUs meant more ways to price-discriminate, extract incremental revenue from different customer segments, and create switching costs through complexity. Broadcom, by contrast, runs a famously disciplined business focused on its largest, most strategic accounts. It was willing to lose smaller customers who bought low-end SKUs in exchange for a simpler, higher-margin subscription model aimed at large enterprises. In their 10-K, Broadcom repeatedly warns that "if VMware customers do not accept" the simplified portfolio and subscription transition, it could harm results — but they made the bet anyway.

The trade-off is real: customers who once bought a bare-bones perpetual vSphere license for a few thousand dollars now face a mandatory subscription bundled with features they may not need, often at significantly higher cost. But for the ~2,000 largest strategic accounts Broadcom serves directly, the simpler model of "buy VCF, get everything" is arguably easier to manage.

Yes, that's right — vSphere (ESXi) is the hypervisor that lets you run multiple virtual machines, each with its own OS, on a single physical server. But that's just the foundation. Here's what VCF adds.

VMware Cloud Foundation (VCF): The Full Stack

Think of vSphere as the engine. VCF is the entire car — and the road it drives on. It bundles everything needed to run a private cloud into a single integrated platform:

The key word is integrated. Before VCF, you'd buy vSphere for compute, then separately evaluate, license, and integrate vSAN for storage and NSX for networking — each with its own version matrix, upgrade cadence, and compatibility headaches. VCF ships them as a single validated stack that deploys together.

What You Actually Get

Practically, VCF lets an enterprise build something that behaves like AWS or Azure, but runs in their own data center:

• Self-service provisioning: Developers request VMs, storage, and network segments through a portal, without IT tickets
• Software-defined everything: You manage storage and networking in software, not by physically cabling SAN arrays and configuring switches
• Lifecycle automation: Patching and upgrading the entire stack — firmware, hypervisor, storage, networking — is automated and validated together
• License portability: You can take the same VCF subscription and run it on-premises, or shift it to a supported public cloud (Google Cloud was the first to support this)

Why Broadcom Bet the Farm on It

Hock Tan's thesis is that large enterprises don't want to stitch together virtualization components themselves — they want a private cloud platform that works out of the box. By collapsing the old VMware menu of 168 products into VCF as the flagship, Broadcom is telling customers: don't buy pieces, buy the platform. The 50% list price cut on VCF subscriptions was the carrot; the end of perpetual vSphere licenses was the stick.

You're right — the hyperscalers (AWS, Azure, Google Cloud) build their own virtualization stacks. VCF's buyers are a different group entirely. Let me pull some data on who actually runs this.Here's the picture of who actually buys VCF.

The Core Buyer Profile

Organizations that run their own data centers and don't want to — or legally can't — put everything in the public cloud. Three big forces drive them to VCF:

Data sovereignty & regulation. Financial institutions, government agencies, and healthcare organizations must keep sensitive data on-premises to satisfy regulators. They can't dump patient records or citizen data into AWS and call it done.

Latency & control. Manufacturers running factory floors (Audi), exchanges processing trades (LSEG), and retailers managing global supply chains (Walmart) need workloads physically close to operations, with deterministic performance.

Economics at scale. If you're already running thousands of servers 24/7/365, the math of renting public cloud capacity often doesn't work out — owning the infrastructure is cheaper, but you need cloud-like automation to run it efficiently.

Who, Specifically

The Scale

Broadcom disclosed that 87% of its 10,000 largest VMware customers have adopted VCF, with over 100 million cores licensed worldwide. The total VMware customer base is roughly 300,000 — so the VCF strategy is explicitly focused on the top ~3% of accounts. The remaining ~290,000 smaller customers are an open question, and many are actively reducing their VMware footprint or migrating to alternatives like Nutanix or Proxmox.

So the short answer: hyperscalers don't need VMware — they built their own. VCF's buyers are the banks, hospitals, governments, factories, and retailers that run the rest of the world's on-premises infrastructure and need private cloud with public-cloud-like automation.

That's exactly the right set of questions. Let me break each one down.

Why Any Company Would Want Virtualization (Beyond Selling It)

You're thinking of the AWS/multi-tenant model — one physical server, sliced up and sold to different paying customers. That's one use case, but it's not the main one for enterprise buyers.

The primary reason a bank or hospital buys virtualization is server consolidation and operational efficiency. Before virtualization became mainstream in the mid-2000s, a typical enterprise ran one application per physical server. That server sat at 10-15% CPU utilization, consuming power, space, and cooling 24/7. If the ERP team needed a new server, they ordered hardware — weeks of procurement, cabling, and setup.

Virtualization means:

• 20 VMs on one physical box instead of 20 physical boxes. The hardware runs at 70-80% utilization instead of 15%.
• Provisioning in minutes, not weeks. A developer needs a test environment? They request it through a portal and get it instantly.
• Live migration. You can move a running VM from one physical host to another with zero downtime — patching hardware, load balancing, disaster avoidance all happen without anyone noticing.
• Snapshots and recovery. Screw up a configuration change? Roll back to a snapshot in seconds.

It's not about selling slices to external customers. It's about running your own internal workloads efficiently.

The Shared Farm Model

Yes — exactly what you described. A large company buys racks of standardized servers (usually from Dell, HPE, or Cisco), installs the hypervisor on all of them, and they become a pooled resource. The marketing team's web servers, the finance team's SAP instance, the developers' test environments — they all run on the same physical cluster. Nobody in marketing knows or cares which physical server their VM happens to land on. The hypervisor schedules it.

This is what "private cloud" means: your own server farm, running on your own premises, but behaving like a cloud — self-service provisioning, elastic capacity, automated operations.

So Why Pay for VMware When Linux/KVM Is Free?

This is the real question, and it's the one Broadcom's critics ask constantly. Here's the honest answer:

KVM, Xen, Proxmox, and oVirt all exist and work. They absolutely can run VMs. The difference is everything around the hypervisor.

For a 50-person company running 10 VMs, Proxmox or KVM is absolutely the right answer — and many VMware refugees are headed there post-Broadcom.

For LSEG running trading infrastructure, or Audi running a factory floor, or ChristianaCare running a trauma center — the cost of the license is noise compared to the cost of outage. A full-stack engineer who can debug a KVM/Ceph/OVS integration at 3 AM costs $200K+ and is hard to hire. The VMware license is an insurance policy: one vendor, one validated stack, one phone number.

That said, Broadcom's pricing changes are pushing even large enterprises to ask whether the insurance premium is still worth it. Nutanix AHV (a commercial KVM-based alternative) is gaining share precisely because it offers the same "one vendor, one stack" value proposition at a lower price. The question isn't whether open source can do it — it's whether the cost savings justify the operational risk for your specific workloads.

Let me search for the pricing data and the Dell-VMware spin-off rationale.## VMware Pricing: Before and After Broadcom

Here's a representative annual cost comparison for a mid-size enterprise with 800 physical cores — 500 in production (with vSAN/NSX), 200 in non-production (vSphere only), and 100 in DR standby (vSphere only):

Bottom line: +100% to +200% increase for the same footprint, even with negotiated discounts.

Cost Increase by Previous Usage Pattern

The customers hit hardest are those who ran just vSphere — the hypervisor alone — because now they're forced into VCF or VVF with a 16-core-per-CPU minimum, subscription-only pricing, and no perpetual option. A vSphere-only shop that previously paid ~$77/core/year (amortized perpetual + support) now faces $135–$350/core/year depending on the bundle.

The Mechanics of Why

1. Perpetual → subscription. You used to buy a license once and pay ~20% annually for support. Now you repurchase the license every year.
2. Per-CPU → per-core with 16-core minimum. Old model: one license per physical CPU socket. New model: pay per core, with a floor of 16 cores per socket even if the CPU has fewer.
3. À la carte → bundles. If you used vSphere + vSAN but not NSX, you now pay for NSX anyway inside VCF.

Why Dell Spun Off VMware

Dell acquired VMware indirectly through its $67 billion purchase of EMC in 2016 — VMware was 81% owned by EMC, which Dell bought. The spin-off in 2021 had three drivers:

1. The hardware-software conglomerate discount. Dell's stock traded at a discount because investors didn't know how to value a company that was part PC/server manufacturer and part high-growth software platform. "The market does not appear to appreciate a hardware-software combination," Michael Dell said on the investor call. Splitting them let each command its own multiple — VMware got a software valuation, Dell got an infrastructure valuation.

2. Debt paydown. The EMC acquisition left Dell with ~$50 billion in debt. The spin-off structure — VMware paid an $11.5-$12 billion special dividend, of which Dell's 81% share was ~$9.5 billion — let Dell slash that debt and move toward investment-grade credit ratings.

3. Strategic freedom for both. VMware wanted to partner with everyone (AWS, Azure, Google Cloud, every hardware vendor) without being seen as "the Dell software company." Dell wanted to sell hyper-converged infrastructure with Nutanix, Azure Stack, and other alternatives without offending its own subsidiary. The five-year commercial agreement preserved the co-engineering relationship (VxRail, etc.) while letting both companies pursue independent strategies.

The irony, of course, is that spinning off VMware to unlock its value as an independent company made it a takeover target — and Broadcom swooped in less than two years later.

That's the most important question in enterprise IT right now, and it cuts to whether Broadcom's pricing strategy is sustainable.

The Real Math

The question isn't "can open source do this?" — it always could. The question is what do you actually need from the stack, and who writes and maintains the glue.

Here's what a sysadmin team would need to build to replace what VCF provides out of the box:

So yes, a competent infrastructure team with modern coding agents could absolutely build the top 80% of this. The bottom 20% — the edge cases, the integrations nobody thought of, the 3 AM failure modes — is where the pain lives.

What Changes With Coding Agents

Pre-LLM, the argument for VMware was: "Hiring enough Linux kernel/storage/networking engineers to build and maintain this is impossibly expensive and talent-scarce."

Post-LLM, a team of five strong engineers with coding agents can produce dramatically more output. The agents write the Ansible, the Terraform, the monitoring configs, the migration scripts. They don't need to be KVM kernel experts — they need to be good enough to review, test, and deploy what the agents generate.

This shifts the build-versus-buy calculus meaningfully.

But the Constraint Isn't Code — It's Accountability

Here's why most large enterprises won't go fully DIY, agents or not:

The CIO problem. If you buy VCF and the private cloud goes down at 3 AM, you call Broadcom and wake up their support org. If you build it yourself and it goes down, you wake up your own team. The CIO who chose "we'll build it" owns every outage personally. Most will pay the premium to transfer that risk.

Compliance and audit. A bank regulator or hospital compliance officer doesn't care how clever your Ansible scripts are. They want a supported platform from a vendor with SLA-backed security patches. "Our team built it with coding agents" does not satisfy most audit frameworks.

The long tail of integration. VCF integrates with thousands of enterprise applications that vendors explicitly certify against VMware, not KVM. Running SAP or Oracle DB on a DIY KVM stack voids support contracts. That alone kills it for most large shops.

Where the Cracks Will Show

The real threat to Broadcom isn't large enterprises going full DIY. It's a three-pronged erosion:

1. Tier-2 workloads move to Proxmox/Nutanix/Hyper-V. The 200 non-production cores in that pricing example — those are easy to migrate. Agents make the migration scripts trivial.

2. New workloads bypass VMware entirely. Kubernetes on bare metal or public cloud. If the app is containerized, it doesn't need vSphere.

3. The next 20,000 mid-market customers leave. Hock Tan himself said "stay tuned" on whether VCF makes sense for the tier below the top 10,000 accounts. For a 500-person company with 50 servers, the math of DIY + agents vs. VCF subscription is not close.

So the answer is layered: no, most sysadmins at Fortune 500 banks won't replace VCF with homegrown KVM stacks, even with coding agents — accountability and compliance block that. But yes, a significant share of workloads will bleed off the platform to simpler, cheaper alternatives, and coding agents accelerate how fast and credibly that migration can happen. Broadcom's bet is that the top 10,000 accounts are sticky enough to justify losing portions of the other 290,000.