Proxmox now runs on Arm. Your x86 machines don't.

On 5 August Proxmox announced official support for a second CPU architecture: arm64. The news is real and it is big. In those same release notes there is a sentence that has not made it into a single headline: "Guests only run on nodes matching their architecture, and live migration is only possible between nodes of the same architecture."

What shipped on 5 August

Proxmox VE 9.2 for arm64, on Debian 13 "Trixie", with Linux kernel 7.0, QEMU 11.0, LXC 7.0 and ZFS 2.4. Its own ISO installer, the pve-enterprise repository available for arm64 from day one, and the same web interface as always. This is not an experimental branch or a community port: it is an edition with commercial support behind it.

The word the company keeps using is parity. Thomas Lamprecht, CTO: "Our goal was not simply to run Proxmox VE on a new architecture, but to deliver full feature parity: KVM, networking, clustering, ZFS, and Ceph all behaving exactly as our users expect from our x86-64 builds." Tim Marx, COO, supplies the commercial reason: "As data centers shift toward high-density, energy-efficient architectures, our customers require the exact same mission-critical stability on Arm64 that they have relied on with x86." The press release calls the launch the product of a "technical collaboration with NVIDIA and Supermicro"; The Register picked it up on 6 August.

All of that is true and well executed. It is just worth looking at what the parity is predicated of: the platform. KVM, networking, the cluster, ZFS and Ceph behave the same. What runs inside the virtual machines falls outside that promise, and nobody has said otherwise.

The track gauge

The conventional Spanish rail network was built with its rails 1,668 millimetres apart and the European one at 1,435. Two hundred and thirty-three millimetres. Same steel, same physics, same engineering: the trains do not go through. For decades, at Irún and at Portbou, the way to cross the border by train was to get off one and onto another. Gauge changers exist because somebody designed a train able to move the spacing of its own wheels as it passes through a facility built for the purpose, not because the problem dissolved over time.

An arm64 hypervisor hands you a different gauge. And here there is no gauge changer. A running virtual machine is the contents of registers and page tables that the destination CPU has to understand as they are; x86-64 and aarch64 share neither the instruction set nor the format of those tables. KVM virtualises, it does not translate. Translation is possible — QEMU emulates x86 on Arm through TCG — but at a cost no production workload pays, and Proxmox does not even expose it. So the limitation Proxmox publishes is not a pending checkbox on a roadmap: it is where what KVM can do runs out.

The left-hand column carries weight: whoever runs Proxmox today knows how to run Proxmox on Arm tomorrow, same interface, same commands. The learning curve is flat. The one for the workloads is not.

The guest that is not there

For a virtual machine to boot on an arm64 node, its operating system has to exist compiled for arm64. On Linux that has been settled for years: Debian, Ubuntu and Red Hat all ship arm64 as a first-class architecture. If your estate is Linux services, the work is reinstalling and restoring data. Tedious, bounded, plannable.

Windows Server is another conversation. There is no generally available Windows Server edition for Arm64, and you do not have to take our word for it: Microsoft says so on its own Insider programme forum, on 13 February 2026, through Artem Pronichkin. "Unfortunately, Windows Server 2025 is not available for ARM64, and there are currently no plans for that." What exists are preview builds. We also went looking for a commercial licensing path and did not find one; if somebody has found one, we would like to know, because we are more interested than they are.

Who this is actually for

Full support covers two platforms: NVIDIA Grace and NVIDIA Vera. For everything else, Proxmox's wording is "Other UEFI-based ARMv9-A or newer hardware is supported on a best-effort basis." And there is a boot requirement that rules out half of the forum conversation: "The host must boot through UEFI and describe its hardware through ACPI. Device-tree-only single-board computers, such as the Raspberry Pi, are not supported."

Grace and Vera are the CPUs NVIDIA places next to its GPUs in compute racks, not the metal in your rack. And there is another Proxmox press release, from 28 July, that shows the actual brief: hosting NVIDIA Mission Control on top of Proxmox VE, described as "the critical virtualization layer beneath this ecosystem", the substrate the management services of an AI factory run on. That is who this launch is for. This news is enormous if you buy GPU racks and fairly marginal if you have three nodes and a Ceph cluster.

The one thing that changes if you are leaving VMware

The signal that matters is not the CPU. It is that a project people were calling "the cheap alternative" three years ago has just been ported to a second architecture, with Ceph and cluster parity, with an enterprise repository on day one, in technical collaboration with the silicon vendor and a server vendor. A port like that costs money and hours from people who know what they are doing, and somebody put in both. For anyone deciding whether to leave vSphere, the relevant data point is who is holding up the project they are thinking of moving to.

Your migration plan, on the other hand, is the same as it was last week. It still goes from x86 to x86, with its inventory, its windows and its rollback plan, which is the part almost nobody prepares. The deadline that actually bites this month has nothing to do with Arm: it is the end of support for Proxmox VE 8 on 31 August, which your apt will not mention. And if you are building Ceph too, the parity announced is the platform's, not your disks': the real performance of a Ceph cluster is decided somewhere else entirely.

When we would not consider Arm

The conflict of interest here is a fat one: we sell VMware to Proxmox migrations. Any news that makes Proxmox look bigger is good for us. With that on the table, these are the four cases where today we would say no:

• If there is Windows in the estate. As long as there is no generally available Arm64 edition, that half does not move, and an estate split across two platforms costs more to run than the sum of the two.
• If the hardware on offer is neither Grace nor Vera. Then you are on best-effort, which is a reasonable answer from a vendor and also something nobody signs into a service contract. You do not build a production cluster on top of a best effort, least of all when the person answering for it at three in the morning is you.
• If what you are after is saving on licences. Here is a detail that has not appeared in any coverage and sits in the FAQ of the announcement itself: "Subscriptions for arm64 are separate from the x86-64 ones and are currently available on request." Arm64 subscriptions are a different product, they carry no published price, and you have to ask sales for a quote. Switching CPU takes nothing off your subscription; it puts you on a price list that does not exist yet. Arm's savings, where they exist, are in watts and in hardware purchase, and that sum has to be done with your density and your electricity bill. We have not done it for you, and nobody should be selling it to you pre-calculated.
• If the idea was to run it on a Raspberry Pi. It boots through device tree rather than ACPI, and that is why it is out.

Where we would look at it with real interest: new Linux workloads, born in containers, deployed from a repository, which cost nothing to reinstall because there was never anything to preserve. There the gauge does not matter, because no train has to cross: you build on the other side to begin with.

Of the virtual machines you have running right now, how many have an arm64 image of the system they run? Counting the Windows ones is usually enough to tell you what year it is.

Sources (verified on 19 August 2026): the announcement date, Proxmox VE 9.2 for arm64, the Debian 13 "Trixie" base, kernel 7.0, QEMU 11.0, LXC 7.0 and ZFS 2.4, the availability of the pve-enterprise repository and the sentences quoted verbatim — "Guests only run on nodes matching their architecture, and live migration is only possible between nodes of the same architecture", "Other UEFI-based ARMv9-A or newer hardware is supported on a best-effort basis", "The host must boot through UEFI and describe its hardware through ACPI. Device-tree-only single-board computers, such as the Raspberry Pi, are not supported", "This is not blocked technically, but mixed-architecture clusters are not officially supported" and "Subscriptions for arm64 are separate from the x86-64 ones and are currently available on request", plus the absence of SeaBIOS, AMD SEV and Intel GVT-g — from the Proxmox VE Roadmap and the official announcement on the Proxmox forum and its FAQ. The quotes from Thomas Lamprecht and Tim Marx, the feature parity list and the phrase "technical collaboration with NVIDIA and Supermicro", from the Proxmox press release of 5 August 2026; the 6 August coverage is The Register, by Simon Sharwood. The phrase "the critical virtualization layer beneath this ecosystem" and Proxmox VE's role as the substrate for NVIDIA Mission Control, from the Proxmox press release of 28 July 2026. Microsoft's statement on Windows Server for Arm64 — "Unfortunately, Windows Server 2025 is not available for ARM64, and there are currently no plans for that", by Artem Pronichkin, 13 February 2026 — from Microsoft's Windows Server Insiders forum; the fruitless search for a commercial licensing path is ours and is declared as such in the text. The 1,668 and 1,435 millimetre track gauges and how gauge changers work, from "Cambio de ancho". Ours: the track gauge analogy, the explanation of why cross-architecture live migration is not a pending checkbox but the limit of what KVM can do (with the caveat that QEMU does emulate in software), the table of what crosses and what stays, the reading that the announced parity is the platform's and not the guests', the argument that what matters to someone leaving VMware is who is holding up the project, and the four "when not to" cases. Proxmox and Microsoft quotes are left in English, their original language, so they can be verified word for word.