Broadcom made the case for Proxmox better than Proxmox ever could

There is a server in your plant running four or five virtual machines. One is the SCADA gateway, one is the historian, one is an engineering workstation someone RDPs into twice a year, and one is a Windows box running a reporting package whose vendor stopped answering the phone in 2019. It has been running like that since the last upgrade project. Nobody has thought about the layer underneath it since the day it was commissioned, because that layer has never once been the thing that broke.

Then the renewal quote arrives and the number has moved. Not by the eight percent you budget for, but by a multiple.

The question this post is actually about is not "is Proxmox good?" It's the one you're sitting with when that quote lands: do I pay this, or do I move, and what does moving actually cost me in a place where downtime is measured in money per minute? That's a harder question than the internet's answer to it, and the honest version has a few more edges than the enthusiast version.

What actually changed#

Broadcom completed its acquisition of VMware in November 2023, and the commercial model changed faster than most plants change a set of instrument tags. The sequence matters more than any single item in it:

TWENTY-FOUR MONTHS OF COMMERCIAL MODEL

• NOV 2023Broadcom completes the VMware acquisition
• DEC 2023New perpetual licences withdrawn. Subscription only, from here on
• FEB 2024The free ESXi hypervisor is discontinued
• LATE 2024Essentials Plus — the small three-host kit — is phased out
• APR 2025Minimum purchase raised from 16 cores to 72
• APR 2025Free ESXi quietly returns, as an entry-level download
• OCT 2025vSphere 7.x general support ends
• LATE 2025The 72-core minimum is reversed. Back to 16

Red = the purchasing floor moved. Amber = something was withdrawn or restored. A plant asset is specified for fifteen years. This is what two of them looked like.

Read that as a list of price changes and you'll miss the point. Read it as a list of floor movements and it lands properly. The minimum purchase went to 72 cores in April 2025 and came back down to 16 later that year after the backlash. That reversal is usually reported as good news. For anyone planning a ten-year asset it is the opposite of good news, because the thing that changed twice in a year is the thing you were supposed to be able to build a capital plan on.

The other change that gets underplayed: the catalogue went from something like eight thousand SKUs to a handful of bundles. Essentials Plus — the kit that existed precisely for a small three-host cluster, which is exactly the shape of a plant — was phased out. There is no longer a product whose description matches what a mid-sized site actually needs. You buy the bundle, and the bundle is sized for a datacentre.

Why this hit OT harder than IT#

An IT department running a two-hundred-node estate hates the new pricing, but it can negotiate. It has volume, an account manager, and a procurement team whose job is exactly this. It will get a discount off list and it will grudgingly re-sign.

The plant is a completely different shape, and three things about that shape make the same change land much harder.

The estate is wide, not deep. A water utility with fourteen pump stations does not have one big cluster. It has fourteen small ones, or fourteen single hosts, each with two sockets and a modest core count, each doing very little work by datacentre standards. Per-core licensing with a minimum floor is close to the worst possible pricing model for that topology. You are buying capacity you will never schedule a single workload onto, fourteen times over.

ONE MODEST THREE-NODE CLUSTER · THE SHAPE OF A PLANT, NOT A DATACENTRE

VMWARE VSPHERE FOUNDATION

subscription, per core

• HARDWARE · 3 nodes × 2 sockets × 8 cores = 48 physical cores
• LICENSED AS · 16-core minimum per socket → 32 cores per node
• BILLABLE CORES · 96 — twice what the tin actually has
• UNIT · $135 per core per year, vSphere Foundation list

$12,960 / year

PROXMOX VE

subscription, per socket

• HARDWARE · the same three nodes
• LICENSED AS · per occupied physical socket
• BILLABLE SOCKETS · 6
• UNIT · from €115 per socket per year, community tier

€690 / year

Those are list prices and nobody pays list, so treat the ratio as directional rather than as a quote. But you can discount the left column by half and it still doesn't come close, and that gap is what makes this a strategy question rather than a procurement one.

The money is the wrong shape. OT budgets are capital-shaped. A project gets approved, the hardware and licences get bought, the system runs for ten to fifteen years, and the operating budget covers support contracts and spares. A perpetual licence fitted that model exactly. A subscription that must be renewed annually, at a price the vendor can reset, moves a line from capex to opex and hands somebody else a lever on your operating cost. Plant managers are not being sentimental about perpetual licences. They're objecting to an uncontrolled variable in a budget they have to defend for a decade.

The upgrade path is blocked at the top. vSphere 7 general support ended in October 2025. The normal answer is to upgrade, and the normal answer runs straight into a validation matrix: your SCADA vendor certifies specific versions, your OEM skid supplier certifies a frozen image, and the reporting package nobody supports anymore certifies nothing at all. In IT, "upgrade the hypervisor" is a maintenance window. In OT it can mean revalidating an entire application stack, and sometimes it means a conversation with a vendor who would rather sell you a new system.

Put those together and the plant ends up in a genuinely bad spot: paying substantially more, for a version it may not be able to move off, on a commercial model that changed twice while it was deciding.

What Proxmox actually is#

Proxmox VE is a Debian system with KVM and LXC on top, a clustering layer, a web interface, and a storage stack that includes ZFS and Ceph. Version 9.0 landed in August 2025 on Debian 13. KVM has been in the mainline Linux kernel since 2007 and is the hypervisor underneath most of the public cloud, so the part doing the actual virtualising is not a hobby project — it is arguably the most heavily exercised hypervisor in existence. What Proxmox adds is the management layer that makes it usable without assembling it yourself.

The licensing model is the part that matters here. The software is open source under AGPLv3 and there is no paid tier that unlocks features. A subscription buys you access to the enterprise package repository and support, priced per physical socket per year starting around €115 for the community tier, with higher tiers for real support response times. You can also run it with no subscription at all on the no-subscription repository, which is the same software on a less conservative update track.

For a plant, several second-order properties matter more than the price:

Nothing phones home. There is no entitlement server, no activation, no licence key that expires and takes a gateway VM down with it. If you have ever had a plant system fail because a licence server on a different VLAN was unreachable, you already understand why this is the feature people mention first. An air-gapped Proxmox cluster runs indefinitely with no connectivity of any kind.

Passthrough is straightforward. OT hardware is full of things that need to reach the guest directly: serial ports for legacy RTUs, USB dongles for HMI licences, PCIe cards for proprietary fieldbus. KVM handles serial, USB and PCIe passthrough well, and Proxmox exposes it in the interface without a support ticket.

The config is text. Guest definitions live in flat files under /etc/pve, replicated across the cluster. You can read them, diff them, and put them in version control, which turns "what changed on the virtualisation host" from an archaeology exercise into a question with an answer.

Snapshots make change safe. Snapshot before a firmware push, roll back in seconds if the gateway comes up wrong. Not unique to Proxmox, but with ZFS underneath it's fast and it's free, which means people actually do it rather than skipping it because the storage budget was tight.

Old hardware stays useful. No hardware compatibility list is quietly dropping your five-year-old server to force a refresh. If Debian's kernel drives it, Proxmox runs on it.

And if you're migrating, the import wizard added in Proxmox VE 8.2 pulls VMs directly from an ESXi host or vCenter over the API, which removes most of the tedium from the part of this that people dread.

The part the enthusiast posts skip#

Here is where I part company with most of what's been written about this over the last two years. The technical case for Proxmox is strong and it is not the binding constraint. The binding constraint is your application vendor's support matrix, and on that front the picture is genuinely mixed.

WILL YOUR VENDOR SUPPORT YOU ON IT · as of early 2026

• ✓Siemens WinCC OA — Officially supportedsince patches V3.20.004 and V3.19.017; announced Feb 2024
• ✓Historians, SQL, MQTT brokers, dashboards — Runs anywherethe hypervisor was never in the support conversation
• ?Rockwell FactoryTalk — No clear statementand an Industrial Data Center ships as a VMware appliance
• ✗AVEVA System Platform — Not on the supported listpractitioners report it working — which is not the same claim

Check your own matrix before you check anyone's benchmark. This is the row that decides the project, and it is the row the enthusiast posts leave out.

Siemens is the one worth dwelling on, because it is the strongest signal in the industry so far. WinCC OA has officially supported Proxmox since patches V3.20.004 and V3.19.017, and the knowledge base article announcing it went up in February 2024 — which is to say, straight after the Broadcom changes started biting. A tier-one automation vendor added support for an open-source hypervisor because its customers asked. That is not a small thing, and it is the clearest evidence available that this is a real industry movement rather than a forum enthusiasm.

Siemens is also honest about the trade in its own documentation, noting that internal testing showed a slight performance drop for Proxmox VMs relative to VMware. I'd rather quote that than pretend it doesn't exist. For a SCADA server that is comfortably within its envelope, a few percent is noise. For one already running hot, measure before you commit.

AVEVA System Platform is the other end. Proxmox is not on the supported list. People run it and report that it works, and "it works" is not the same claim as "my vendor will help me at 3am during an outage." Rockwell's position on alternative hypervisors is thinner still, and if you're running FactoryTalk on an Industrial Data Center you are buying an appliance that ships as a VMware stack — that's the product, not a preference you can configure away.

So the honest framing is not Proxmox wins. It's this: for the majority of what actually runs in a plant — historians, databases, reporting servers, engineering workstations, Linux-based gateways, MQTT brokers, dashboards — vendor support is either present or irrelevant, and the economics are no longer close. For the specific tier-one HMI and DCS applications with hard support matrices, you check the matrix, and sometimes the matrix says no.

That's a much more useful sentence to take to a plant manager than "Proxmox is better," because it survives the first question they'll ask.

How I'd actually do it#

Not a big-bang migration. The sequence below is ordered by how much you lose if a step goes wrong, lowest first, and each step earns the right to the next.

1. Build a lab cluster on hardware you already wrote off. Two or three decommissioned boxes. Cluster them, break things deliberately, practise a restore. This costs nothing but time and it's where you learn whether your team likes the tool.
2. Move the things nobody is paged for. Test systems, the development gateway, the engineering workstation, a reporting server. Real workloads, zero consequence, and after six months you have operational evidence rather than a vendor's slide.
3. Move the read-only tier. Historian replicas, dashboards, MQTT brokers, analytics. Data flows in, nothing flows out to a controller. If it stops, you lose visibility and history, not control.
4. Re-check the matrix before the control tier, and be willing to stop. Some sites will move the SCADA servers. Some will keep a small, correctly licensed VMware footprint for exactly the applications that require it and run everything else on Proxmox. A split estate is not a failure. It's the correct answer when the constraint is contractual rather than technical.
5. Never migrate the safety-related systems as part of a cost exercise. If it's part of a SIL loop or a validated batch environment, it moves on its own project, with its own validation, or it doesn't move.

The fourth point is the one I'd push hardest. The goal is not hypervisor purity. It's removing a supplier's ability to reprice the invisible layer underneath your plant, and you get most of that benefit from moving most of the estate. The last twenty percent is where the risk lives, and it's fine to leave it alone.

The actual lesson#

The interesting thing here isn't Proxmox. It's that the plant floor spent thirty years treating infrastructure software as a decision you make once and never revisit, and that assumption just failed in public. The hypervisor turned out to be a supplier relationship, and supplier relationships change hands.

The same question applies to every layer you haven't looked at recently. What else is sitting under your plant, quietly working, owned by a company that could be acquired next year? The historian's storage engine. The reporting tool. The remote access product. The answer isn't to rip all of it out — it's to know which layers you could replace inside a year if you had to, and which ones would take five.

Broadcom did the industry a genuine favour by asking that question loudly enough that people had to answer it. I doubt that was the intention.

---

Running Proxmox in production on a plant network, or evaluating the move? I'd like to hear what your vendor said when you asked. Reply by email.