The arrival of official ARM64 support creates an obvious question for existing Proxmox users: can ARM64 and x86 64 nodes join the same cluster? The official answer is cautious. In its ARM64 release announcement and FAQ, Proxmox says mixed architecture clusters are not technically blocked, but they are not officially supported. Guests can run only on nodes that match their architecture, and live migration between ARM64 and x86 64 is not possible. This limits many of the benefits administrators normally expect from a homogeneous cluster. Before combining hardware, teams should review the clustering, high availability, storage, backup, and governance requirements in a Proxmox enterprise operations guide.
One Cluster Does Not Create One Compute Pool
A cluster provides shared management, membership, configuration, and coordination. It does not make two processor architectures interchangeable. An x86 64 virtual machine cannot restart on an ARM64 node after a host failure, and an ARM64 guest cannot live migrate to an x86 64 server for maintenance. The cluster may display both node types in one interface, but available capacity remains divided into separate architecture pools.
This changes high availability planning. A workload needs enough compatible nodes to survive the failure or maintenance of one host. Adding an ARM64 node to a group of x86 servers does not create failover capacity for existing x86 guests. Teams must calculate resilience separately for each architecture and ensure that storage, networks, and backup systems can support both.
Guest Data Can Move but the Workload Must Change
Proxmox says guest data may be moved through offline migration, backup and restore, or shared storage. That does not make the guest executable on the new architecture. The operating system, boot process, application packages, drivers, and dependencies must be rebuilt or reconfigured for ARM64.
For stateless services, this may be manageable. A team can create a new ARM64 image, deploy the application, restore its configuration, and reconnect data. Stateful systems require more careful migration because databases, file formats, plugins, agents, and third party components may have architecture specific assumptions. The Proxmox automation guide is useful here because templates, cloud init, APIs, Terraform, Ansible, and documented provisioning can reduce differences between x86 and ARM deployments without pretending the underlying machines are identical.
Shared Storage Does Not Solve Compute Compatibility
Shared NFS, iSCSI, Ceph, or another storage platform can make disks visible to multiple nodes, but a disk image still contains software built for a particular processor architecture. Storage also needs its own compatibility and support review. If storage services run inside the cluster, administrators must understand whether their placement and recovery rules assume identical nodes.
Backup design should remain architecture aware. A backup may preserve guest data correctly while still requiring a compatible target node and recovery image. The Proxmox backup guide explains why job completion is not enough. Teams need restore tests that confirm a complete workload can be recovered within the required time and on the hardware that will actually be available.
Mixed Clusters Fit Narrow Use Cases
A mixed cluster may be useful for laboratories, centralized administration, software testing, or a gradual evaluation of ARM hardware. It may also support separate workload groups that do not need cross architecture failover. The risks increase when administrators expect uniform high availability, automated balancing, or interchangeable maintenance capacity.
For most production environments, separate clusters are easier to support and reason about. One cluster can serve x86 workloads, while another serves ARM64 systems, with shared standards for monitoring, identity, backup, and automation. A mixed architecture design should be chosen only when its management convenience outweighs the unsupported status and the permanent separation of guest mobility.
Originally published on the Mr.PlanB blog.
Top comments (0)