XCP-ng on Arm with Ampere

As a founder of the company, this is the kind of announcement I dreamed to do a while ago. And this year, for our first participation at KubeCon USA, we wanted to finally present it. On our booth, we showcased a working demonstration of XCP-ng and the Vates Virtualization Management Stack (VMS) running on an System76 Thelio Astra with an Ampere platform. This confirmed that XCP-ng can operate on modern ARM based infrastructure while also introducing the foundations of the upcoming XCP-ng 9.0, partially built on AlmaLinux.

This milestone reflects our alignment with ecosystem partners such as Ampere, AlmaLinux, and the open virtualization community. It supports a long term vision built on sustainable compute, hardware diversification, and open source infrastructure.

🪐 Why Ampere, and why ARM

Ampere processors combine high performance, strong energy efficiency and a modern arm64 design intended for cloud scale computing. Their many physical cores and the absence of hyperthreading provide excellent density and predictable performance, making the architecture ideal for virtualization workloads while using significantly less power than traditional Intel or AMD processors.

For years, virtualized infrastructures relied almost exclusively on x86 hardware. The maturity reached by the ARM ecosystem changes that landscape. With Ampere, organizations can diversify their compute strategies, reduce architectural dependency and adopt solutions aligned with long term sustainability.

Bringing XCP-ng to Ampere processors fits the broader Vates objective to support multiple architectures and maintain technological independence. ARM provides a modern processor design without legacy constraints, and its level of maturity now makes it a viable option for datacenter workloads.

🧩 The work behind the demo

Reaching a fully operational XCP-ng on Ampere requires months of sustained engineering work. The journey began when our engineering team succeeded in booting Xen on Ampere, which included selecting and integrating the required GRUB patches to ensure the hypervisor could start reliably on both Altra and Ampere One platforms.

This early milestone created the initial foothold for everything that followed and demonstrated that the platform was viable for a full XCP-ng stack.

But let's rewind a bit: Thanks to Ampere, we were able to get our hands on a brand-new Gigabyte ARM server, straight from the factory in Taiwan. That machine allowed us to bootstrap our work and validate Ampere’s flagship platform for the datacenter: Ampere One. Meet the R283-P92-AAF1:

But taking a full server from France to Atlanta for KubeCon wasn’t exactly practical. Ampere stepped in again and connected us with System76, who provided an Ampere Altra–based platform directly on site. That’s how we ended up running XCP-ng on a System76 Thelio Astra right at our booth.

Back to our "demo challenge": rebuilding XCP-ng for arm64 also means rebuilding our entire package ecosystem for a new architecture. XCP-ng isn’t just Xen and XAPI: it’s many RPMs, patched components, OCaml libraries, C helpers, Python tooling, storage and networking layers, and all the glue we maintain to keep the whole platform consistent. Every single package that we modify (or that depends on something we modify) must be rebuilt in an aarch64 buildroot.

Then, server-class ARM machines are a very different beast compared to the smaller embedded ARM systems that Xen has traditionally supported. In particular, their much larger memory footprints exposed some limits we hadn’t hit before, and tracking those down took time. Now that we understand the issue, the next step is to design a proper, generic patch that can be contributed upstream.

Another part is understanding and correcting Xen’s handling of MADT ACPI tables required careful investigation. The hypervisor previously supported only older versions of the specification, while modern Ampere systems use newer formats that initially prevented both Xen and dom0 from completing the boot sequence. Once the root cause was identified, updating the initialization logic restored compatibility and allowed the platform to boot normally.

The engineering team also created a new VM type in XAPI, delivered ARM specific implementations of xenctrl and xenguest, added ARM support to blktap and associated storage components and partially fixed issues such as xenconsoled crashes that appeared differently on AmpereOne and Ampere Altra processors.

The technical work came with practical challenges. The demo machine was first prepared remotely inside System76’s offices, but the final setup happened in a hotel room in Atlanta. Accessing the server involved navigating multiple layers of networking over unstable hotel WiFi, with a jet-lagged Nathanael calling hotel IT multiple times a day to get connectivity restored. The final setup even stretched across travel schedules, as part of the work was carried out from a moving car while the team stayed connected from wherever they were, all across time zones.

As our team noted after the first successful boot, running Xen on ARM was not the difficult part. The real challenge was making the entire XCP-ng stack operate smoothly on top of it.

🎛️ The demo at KubeCon

The demonstration displayed on the Vates booth was functional. The team successfully booted an AlmaLinux VM on XCP-ng, launched by using xl and presented a working XAPI instance connected to Xen Orchestra 5 and 6, as well as XO Lite

Although this remains a Proof of Concept, it clearly demonstrated that XCP-ng on ARM is technically solid and promising. Early testing reinforced how well ARM server processors, with their high core counts and strong energy efficiency, match the requirements of virtualized workloads by offering excellent density and reduced power consumption.

🔭 What’s next

This demonstrator is the first public milestone on the road to XCP-ng 9.0 — a major evolution of the platform across both x86 and ARM. What we’ve achieved so far is only the beginning: the next steps include reinforcing XAPI compatibility on ARM, deepening its integration with Xen Orchestra, and running extensive performance and stability testing. There’s still substantial engineering ahead on the installer, storage layers and compatibility components, supported by our ongoing collaboration with the Xen and AlmaLinux communities.

But beyond the technical work, this effort reflects a direction we’ve been preparing for a long time. Vates has always aimed at mastering the full stack, and ARM fits naturally into that vision. It offers real datacenter advantages: higher density, lower power consumption, and therefore lower cost, without sacrificing performance.

What’s especially exciting is seeing a kind of Xen convergence happening. Xen has powered ARM in the embedded world for years, and Ampere is now bringing ARM squarely into the datacenter. For the first time, both worlds meet on the same architecture, inside the same hypervisor project, and XCP-ng is becoming the bridge between them.

Our collaboration with Ampere strengthens this trajectory. Their hardware is modern, efficient and designed for serious workloads. Our goal is to deliver an experience on ARM that matches the operational comfort of x86, with the added benefits of better efficiency and improved density.

This initial demonstrator validates our approach: XCP-ng beyond x86 is not a future idea: it’s already real, and progressing steadily with clear goals and long-term commitment. ARM is becoming an integral part of the future of XCP-ng, and that’s genuinely exciting.

🌌 A great future ahead

Running XCP-ng on Ampere platforms marks a significant expansion of open virtualization. We’re only at the beginning, but the direction is clear. The journey has started, momentum is building, and the future of the platform (and of Xen in the datacenter) is getting broader, more efficient and more sustainable.

Exciting times ahead!