Proxmox VE 9.2 for Arm64 is the announcement I have been waiting on for years. The home lab story used to come with a built-in assumption: Proxmox meant x86, full stop. Anyone who wanted Arm virtualization was stitching community ports together and hoping nothing broke. That era is over. The vendor itself shipped an Arm64 build, validated it alongside NVIDIA and Supermicro, and parked it on the same support tier as the x86 edition. For once the marketing line and the engineering line up.
Why this matters goes beyond homelab curiosity. Arm in the server room is mainstream now. NVIDIA Grace Hopper and the upcoming Vera systems are designed for AI workloads at scale, and the hyperscalers are buying Arm servers by the million. If your next server purchase is anything like mine, there is a real chance it ends up being Arm. Until now the virtualization story on that hardware was rough at best. Proxmox on Arm64 changes the options you have on the day you unbox the machine.
The build, not a fork
A common worry with vendor Arm ports is that they are second-class citizens, built on a separate codebase with a delayed feature pipeline. That is not the case here. Proxmox VE 9.2 for Arm64 shares the same codebase, the same repositories, the same release cadence, and the same documentation site as the x86 product. The web interface, the cluster workflow, the storage layer, the network model, the API, and the support contract are all the same software, running on a different CPU.
Debian 13.5 “Trixie” with kernel 7.0 forms the base. The rest of the stack looks like this:
- QEMU 11.0 handles the VMs
- LXC 7.0 handles the containers
- ZFS 2.4 sits in the storage layer
- The SDN networking stack is the same code path as x86
KVM, Ceph, HA clustering, the backup system, and the rest of the feature list are identical to the x86 edition. You are not running a compatibility shim. You are running Proxmox.
The practical consequence is that the muscle memory built on x86 Proxmox transfers cleanly. Anyone who has spun up a VM, joined a node to a cluster, or restored from PBS will not need to relearn the workflow. That alone lowers the cost of trying it for most teams.
Where the support story actually points
The development partnership was with NVIDIA and Supermicro, centered on Grace Hopper and Vera hardware. Grace Hopper is the chip that combines an Arm CPU with an NVIDIA GPU on a single package, designed for AI training and inference. Vera is its successor. Both sit firmly in the data center end of the Arm market, and that is what Proxmox is committing to support first.
That focus is intentional, and it explains a few choices in the announcement. Official support is directed at Grace Hopper and Vera systems, full stop. UEFI-based ARMv9-A or later server systems get best-effort support. ARMv8-A machines will usually work, but you are on your own if something breaks. That line is honest. Trying to officially support every Arm board on the planet would be a maintenance nightmare, and the people running Proxmox know it.
What this means in practice is that you should not buy an Arm board tomorrow and expect day-one Proxmox compatibility. The supported hardware list is narrow, and the best-effort list is narrow in a different way. The second-hand market for retired Arm servers from cloud providers is the most realistic source of compatible hardware for homelab use right now. Ampere Altra systems, for instance, fit the best-effort profile cleanly: UEFI-based, ACPI-clean, and widely available.
What you give up
There is a real cost to going Arm64. Pretending otherwise is dishonest. A few things change under the hood that anyone considering the migration should know.
The boot and hardware contract is stricter than on x86. The host has to come up via UEFI and report its hardware through ACPI tables. That is the modern server standard, but it excludes a long list of small boards the homelab crowd uses. The Raspberry Pi line, for example, uses a device tree instead of ACPI, so it is outside the supported range. Community users will probably coax it into booting with extra firmware and manual configuration. You will not get a fix from Proxmox if it breaks.
Some x86-specific features simply do not exist on Arm. The notable absences:
- AMD Secure Encrypted Virtualization is gone, because it was never a generic virtualization feature
- Intel GVT-g mediated graphics virtualization is gone for the same reason
- SeaBIOS is not available; every Arm64 VM boots through UEFI on AAVMF, which is the Arm analog of OVMF
- Any architecture-specific x86 hardware passthrough that depended on those features
None of these were central to most workloads, but they were central to a few, and those workloads need a different plan.
The other thing to internalize is that architecture boundaries are hard. An Arm64 guest has to run on an Arm64 host. You cannot migrate a workload live from an x86 Proxmox node to an Arm node, because the instruction sets are not binary-compatible. You can rebuild the workload, but you cannot move the running VM. For teams that were hoping to mix architectures inside a single cluster, that means rebuilding the workloads, not just relaunching them.
Why this still matters for homelabs
The official support story lives at the data center end, but the best-effort story covers real hardware that homelabbers can actually buy. That is the part of the announcement that matters most for this audience.
For the first time, you can build a Proxmox cluster that mixes x86 and Arm nodes under the same management interface. Some of the boxes can be cheap retired desktops pulling double duty. Some of the boxes can be quiet, low-power Arm servers that sip electricity. The workflow is the same on both. The scheduling, the backup, the snapshotting, and the API calls are all identical across architectures. For years this was theoretically possible but practically miserable. With Arm64 treated as a first-class target, it becomes a real option you can build on a Saturday.
The other reason homelab users should care is independence from a single CPU vendor. Standardize your lab on Proxmox and you can pick hardware based on what fits the workload, not based on which vendor your hypervisor supports. That kind of optionality is worth more than it sounds, especially as Arm performance per watt keeps climbing.
Where to deploy it, and where to wait
Not every workload belongs on Arm64, and not every team should jump in this week.
The cleanest win is for teams already running Grace Hopper or planning to. You get the full Proxmox feature set on the same hardware your AI workloads already live on, with vendor support behind the virtualization layer. That combination did not exist a month ago.
Homelabbers with Ampere Altra, AmpereOne, or comparable Arm servers that boot UEFI and expose ACPI should give it a try on a non-production box. You are in the best-effort zone, so keep backups and a recovery plan. The fact that the management interface is the one you already know makes this a much smaller experiment than it would have been a year ago.
Anyone planning a Raspberry Pi cluster for Proxmox should look at lighter alternatives instead. Bare LXC, K3s, or plain Docker give you more of what a Pi cluster actually needs without trying to fit a square peg into a round hole.
Teams with a mission-critical x86 cluster should resist the urge to migrate just because the announcement happened. Arm is now a real choice, not an urgent one. The right move for most production workloads today is to wait for the first patch release and watch how the early deployments shake out.
Trade-offs
This release is not free, in any of the dimensions that matter. The community has not seen day-one bugs yet, so reviewer depth and patch volume will lag the x86 edition for at least the first quarter. Hardware support is narrower than the press release implies; the official line is Grace Hopper and Vera, and the best-effort line still demands UEFI plus ACPI. Migration from an x86 cluster is heavier than people assume, because cross-architecture live migration is not a thing, so moving a workload means rebuilding it. Several x86-only features (SEV, GVT-g, SeaBIOS) are gone for good, and any design that depends on them has to change. Commercial support is new, which is good news for buyers but means the first few large deployments are paying to be the early reference customers.
For most homelab and small business users the trade-off still comes out positive. The management interface is the one you already know, the feature set is complete, and the best-effort hardware list covers machines you can buy today. Early adopters who standardize now will benefit when the supported hardware list expands, and they will also surface the rough edges before the documentation catches up. That exchange is fair.
What to watch
The interesting question is whether Arm64 stays a first-class target or quietly becomes a side project. Based on the fact that Proxmox matched the support tier, the release cadence, and the underlying stack, my read is that they are serious. The first patch release will tell us whether the cadence holds. Beyond that, watch the supported hardware list. If UEFI-based ARMv9-A servers start appearing on the official list over the next two quarters, Arm64 has a real long-term future in this product. If the list stays frozen on Grace Hopper and Vera, the homelab story is going to stay best-effort for a while.
If you want to try this, pull the Arm64 installation ISO from the Proxmox wiki and check the current hardware compatibility list. Stand up a small VM and an LXC container on a spare box, then run your full backup-and-restore procedure on it. If everything works cleanly, you have a real new option for the next hardware refresh. If something stumbles, you have learned the limits without putting a production workload at risk.