Proxmox VE 9.2 Brings Official Arm64 Virtualization

Proxmox VE now officially supports 64-bit Arm targets, and after years of unofficial ports and community patches, the aarch64 build is a first-class citizen. The release landed August 7 as Proxmox VE 9.2 for arm64, and the support matrix is more specific than the headline suggests — which is exactly what you want from a hypervisor release note.

• Full support covers NVIDIA Grace Hopper and NVIDIA Vera platforms
• Best-effort support extends to UEFI-based Armv8-A and Armv9-A hardware
• Device-tree-only systems such as the Raspberry Pi are not supported, though community workarounds exist
• Built on Debian 13.5 Trixie with Linux 7.0, using AAVMF rather than SeaBIOS for VM firmware

Which Arm Hardware Does Proxmox VE 9.2 Support?

The tiering here is the whole story. NVIDIA Grace Hopper and Vera get full support, which is unsurprising given that NVIDIA sponsored the development work to underpin its Mission Control AI factory management stack. Anything else that boots via UEFI on Armv8-A or Armv9-A falls into best-effort territory — it should work, and Proxmox will take the bug reports, but it is not on the validation matrix.

That second tier is broader than it sounds. A growing share of Arm server and workstation silicon ships with proper UEFI firmware, and those machines are now candidates for a Proxmox host rather than a bespoke KVM setup. If you have been running Arm virtualization by hand, this is the release that lets you stop.

Why Is the Raspberry Pi Not Supported?

The exclusion is technical, not political. The Pi and most SBCs in its class boot from a device tree rather than UEFI firmware, and Proxmox VE 9.2 uses AAVMF — the Arm build of OVMF — to give virtual machines a UEFI boot path in place of the x86 SeaBIOS. No UEFI on the host, no supported install.

Community workarounds exist and will keep existing, because people have been putting Proxmox on Pi hardware for years. But the honest read is that this release targets Arm servers, not the SBC and router-class boards that dominate our mini PC and SBC coverage. UEFI availability on small Arm boards has been improving steadily — the NightRun project booting a local LLM on a Pi 5 with no OS is a good example of that firmware work paying off — so the gap is likely to narrow from the hardware side rather than the Proxmox side.

What Is Missing Compared to the x86 Build?

Three gaps are worth planning around. AMD SEV memory encryption and Intel GVT-g mediated vGPUs are x86-specific and simply do not appear. More consequentially, live migration is restricted to same-architecture nodes, so a mixed x86 and Arm cluster cannot shuffle a running VM between them. That is a fundamental constraint rather than a missing feature — you cannot migrate live CPU state across instruction sets — but it needs to be in your cluster design from day one.

The base is current: Debian 13.5 Trixie with Linux 7.0 means recent Arm platform support, driver coverage, and scheduler work come along for free.

What Changes for Homelab and Edge Virtualization?

For homelabs, the practical opening is Arm workstations and small Arm servers with UEFI firmware, which can now run the same management interface as the rest of the rack. For edge deployments, an officially supported hypervisor on Arm hardware removes a recurring procurement argument — the answer to whether the platform is supported is now yes rather than a link to a forum thread.

The strategic read is that NVIDIA funding aarch64 Proxmox development tells you where Arm virtualization demand is coming from: AI infrastructure, where Grace-class parts are already deployed and operators want ordinary tooling around them. Everyone else benefits from the fallout.

Sources: CNX Software — August 7, 2026; Proxmox — August 2026.