Proxmox on Arm doesn't extend your cluster — it makes you run two

On 5 August, Proxmox Server Solutions released the first officially supported edition of Proxmox VE 9.2 for arm64. Not a preview, not a side branch, not a weekend experiment: same codebase, same repositories, same lifecycle and feature parity with the x86-64 build. And in the small print of the announcement there is one sentence that, for anyone who has to draw the infrastructure, weighs more than everything else put together: “guests only run on nodes matching their architecture, and live migration is only possible between nodes of the same architecture”.

And in case there was any doubt, the announcement itself answers the obvious question — can I mix x86-64 and arm64 nodes in one cluster? — with a reply worth reading in full: “this is not blocked technically, but mixed-architecture clusters are not officially supported”. In other words: if you rack an Arm node tomorrow, you have not extended your cluster. You have started your second one. And that is an architecture decision — two capacity pools, two failure reserves, two maintenance calendars and, while we are at it, two subscriptions — best taken deliberately rather than discovered the day a migrate comes back with an error.

What they actually shipped

This is not a half-done port, and that is worth saying before we get to the small print:

Ceph and ZFS being on that list is not a footnote. It means the storage conversation does not change when you cross architectures, and we have already written the criteria down: the replica 3 versus erasure coding maths works out the same on a Grace node as on a Xeon. What changes is not storage. It is movement.

The sentence that decides the design

Here is the axis of this post, and it is not a criticism of Proxmox. Two things get conflated and it is worth pulling them apart. First: your x86 machines do not run there. KVM does not emulate processors, it accelerates them, so an arm64 host runs arm64 guests; your Windows Server, your ERP compiled in 2014 and that one virtual machine nobody dares touch stay where they are. QEMU can emulate one architecture on another, but that is a test bench, not a production platform, and Proxmox does not offer it. Second, and this one really is irreducible: there is no live migration across the line. Moving live CPU state between two different instruction sets is not a matter of somebody writing the code. Not hot, not under HA, not when the Arm node runs out of memory on a Tuesday afternoon.

In the rooms we walk into, processor architecture has been a given rather than a decision for fifteen years. You bought servers and they were x86; the hypervisor moved workloads from one box to another and nobody looked at the socket label. That is over. From now on, every node you buy answers a new question — which side does it go on? — and that answer drags sizing along with it: if you have six x86 nodes and two Arm nodes, you do not have eight nodes of headroom, you have six and two. The reserve that lets a node fail without drama has to be calculated per architecture, and in a group of two that reserve is 50%. Worse still: two nodes do not give you real high availability either, because when one goes down the group loses quorum. The sensible minimum is three, or two plus a QDevice acting as the third vote.

The same goes for containers, unglamorous as that sounds: an LXC template is built for a specific architecture, so your template catalogue and your application images also split in two unless they are published for both. Easy to forget, right up until the day you check.

Four things you give up when you cross over

They are all in the announcement, and none is a defect of the port: they are consequences of the platform. But read them before you sign:

And one that is not technical but costs money and time: the Arm subscription is separate. Whatever x86-64 subscriptions you hold do not cover these nodes. And for now it is not a catalogue item either: the announcement says arm64 subscriptions are “currently available on request” and points you at their sales team for a quote. In a shop running on enterprise support, that is a new budget line, one more renewal date, and an email somebody has to write before anything can be quoted at all.

Not the Raspberry Pi. And that tells you who this is for

This is the headline that will sting in the forums: single-board computers described only through device tree — the Raspberry Pi first among them — are not supported. Some will read that as a disappointment. We read it as the clearest signal of who this was built for: if the requirement is UEFI and ACPI, and the fully supported platforms are Grace Hopper and Vera, the target is not the cupboard under the stairs. It is a rack of accelerated compute.

The money already moved, and that is not an opinion

When a project that has been shipping for x86 since 2008 spends a whole development cycle on another architecture, there is a spreadsheet behind the decision. IDC's numbers for the first quarter of 2026 explain it better than any statement: non-x86 servers took $58.7 billion in revenue, up 107% year on year, and 47.9% of market revenue. In the same quarter x86 took $63.9 billion and fell 2.9%, in its case because of component supply problems. And if you look only at accelerated compute, the crossover has already happened: $53.0 billion in non-x86 accelerated servers against $34.6 billion in x86.

It is worth understanding where that 107% comes from: companies are not moving their mail servers to Arm. It is the GPU rack. It is accelerated compute sold by the cabinet to train and serve models, with an Arm CPU bolted to the accelerator. That is the market Proxmox has just walked into, and it lines up with what its COO, Tim Marx, said about data centres shifting towards high-density, energy-efficient architectures. We saw the first signal of this move when Proxmox turned up in the NVIDIA Mission Control ecosystem, and we wrote back then that a logo will not migrate your infrastructure. That was an agreement; this is ISOs, repositories and a published list of limitations. But the warning from that post still holds — it just needs applying more carefully now.

When yes — and when this is not about you

If you do not have an accelerator in the rack and no plans to buy one, this release changes nothing for you today. You do not need it, you will not notice it, and it does not deserve an item on the agenda. Your x86 Proxmox is exactly as good as it was a week ago, and what does deserve a look is whether it is properly tightened up in production — there is pending work on that in almost every room we walk into.

That said, there are three situations where this genuinely is news and deserves a serious conversation:

The five questions before quoting an Arm node

This is literally what we ask in the first meeting, and the order matters because the first answer usually settles it:

None of those questions is really about Arm. They are the same ones we ask before adding any piece that does not match the rest: what runs on it, what it talks to, who maintains it and what happens when it fails. That is the part of consulting that never makes the slide deck, and the part that stops you buying an expensive server that ends up being nobody's problem.

What has actually changed

We think this is good news and we will say so without hedging: having a free hypervisor, with genuine enterprise support and no hostile licensing policy, available on the hardware where server spending is heading takes the trapped feeling away from a lot of people. That it is the same codebase and the same lifecycle — not a "community" branch abandoned in two years — is exactly what you should demand of a port like this.

What has changed is not that you can now run Proxmox on Arm. It is that processor architecture is a design decision again after years of not being one — and design decisions have a nasty habit of charging late: not on purchase day, but on incident day, when somebody discovers that the machine they need to bring up somewhere else will not start anywhere else.

If you are drawing a virtualisation infrastructure for the next five years and there is accelerated compute anywhere on that sheet, this is the conversation to have now rather than two budgets from now. Drop us a line and we will have it: what runs, how many nodes per side, and what happens when one of them dies.

Sources (verified): the official announcement of 5 August 2026 on the project forum — the primary source for almost everything technical in this post — covering the fully supported platforms (“NVIDIA Grace Hopper and NVIDIA Vera”), best-effort support for other UEFI-based ARMv9-A or newer hardware and for ARMv8-A, the exclusion of device-tree-only single-board computers (Raspberry Pi) and of systems without UEFI boot or ACPI, VMs booting through AAVMF with no SeaBIOS, the absence of AMD SEV and Intel GVT-g, the absence of an operating-system-level microcode package, the restriction that guests only run on nodes matching their architecture and that there is no cross-architecture live migration, the verbatim answer on mixed clusters (“this is not blocked technically, but mixed-architecture clusters are not officially supported”), arm64 subscriptions being separate and “currently available on request”, and the Debian 13.5 “Trixie”, kernel 7.0, QEMU 11.0, LXC 7.0 and ZFS 2.4 versions — the Proxmox VE arm64 announcement on the official forum. Feature parity, joint validation with NVIDIA and Supermicro on Grace Hopper systems, and quotes from Tim Marx (COO) and Thomas Lamprecht (CTO); the press release words the platforms as “systems based on the NVIDIA Grace and NVIDIA Vera CPU architectures” — Proxmox Server Solutions press release. Context for the announcement and ongoing work with other server vendors — The Register, 6 August 2026. Q1 2026 figures from IDC's Worldwide Quarterly Server Tracker ($58.7bn in non-x86 servers, up 107% year on year and 47.9% of revenue; $63.9bn in x86, down 2.9% on component supply constraints) — The Register, 16 June 2026. Accelerated-compute figures for the same quarter ($53.0bn in non-x86 accelerated servers against $34.6bn in x86) — IDC, Worldwide Quarterly AI Infrastructure Tracker. The quorum requirement and the QDevice as a third vote in two-node clusters — Proxmox VE clustering documentation. The per-architecture reserve maths, the five questions from the first meeting and the advice to move nothing unless there is accelerated compute in the rack are ours.