engine: aarch64 support #1041

TrappM · 2025-07-07T14:58:27Z

Issue

ovirt engine currently does not support aarch64 hosts

Changes introduced with this PR

Add basic support for aarch64

Are you the owner of the code you are sending in, or do you have permission of the owner?

Yes

--

We've been working on aarch64 support in ovirt engine and these are the required changes to get
an aarch64 VM started in our dev setup.

It is still work in progress and there are several open topics,
but we want to share the current status, because we are looking for feedback and support.

We've built and tested with a x86_64 container based setup,
a single aarch64 host on CentOS 9 and local storage.
Installed a VM with CentOS 10 aarch64.
Basic storage/ISO/network access works as expected.
VNC based console access with keyboard + mouse is available.

At the moment, aarch64 is configured to be available in 'compatibility version' 4.8 (and 4.7 for testing)
and the OS type is restricted to 'Other OS'/Linux. Most of the platform specific values in the code
(hugepagesize, maxcpu ...) are copied from other architectures and should be validated.

The feature/model detection for aarch64 seems to be incomplete, we haven't found any 'model_' labeling
for aarch64. This might need additional patches in vdsm or qemu. Due to that, the current model detection in this PR
is very basic - just to get it up and running.

Known issues:

QEMU recommends the 'virt' board for aarch64 VMs and you will also need the following vdsm patch on the aarch64 host
oVirt/vdsm@4127dfc

We had to disable the repo 'resilientstorage' because it seems to be unavailabel for aarch64.

Open topics:

validate the current aarch64 settings
add feature/cpu/model detection
add aarch64 specific tests
migration
hotplug mem/cpu

dupondje

First of all thanks for this patch. I think this is a great addition! :)

I added some remarks in the code already. Think it's a very good start, just some things we need to improve.
Did you already had a running Arm VM in oVirt? Or not there yet?

I think it might be useful to have some full libvirt xml of the started VM also.
To see if everything is in there, and if we need to make some improvements.

...odules/bll/src/main/java/org/ovirt/engine/core/bll/architecture/HasMaximumNumberOfDisks.java

backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/UpdateVmCommandTest.java

...dules/bll/src/test/java/org/ovirt/engine/core/bll/utils/CompatibilityVersionUpdaterTest.java

...d/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/validator/VmValidatorTest.java

backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/utils/ovf/OvfManagerTest.java

packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql

TrappM · 2025-07-22T11:16:50Z

Did you already had a running Arm VM in oVirt? Or not there yet?

Of course, we had manual installations with ubuntu, centos, sles and rhel.

I think it might be useful to have some full libvirt xml of the started VM also. To see if everything is in there, and if we need to make some improvements.

See attached file
arm-vm1.xml.txt

backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/OsRepositoryImpl.java

TrappM · 2025-08-26T07:59:47Z

Is there anything blocking this PR or can we get it merged?

According to https://www.ovirt.org/develop/dev-process/install-nightly-snapshot.html

dnf copr enable -y ovirt/ovirt-master-snapshot centos-stream-9
dnf install -y ovirt-release-master

it would be great to reduce the effort for the enduser and get some feedback from the community.

@dupondje

dupondje

Sorry for the delay.
We are currently focussing on getting everything build for CentOS 10, which takes most of our time.

Getting this in would be very nice, but I want to make sure it's (almost) perfect before we merge it.
I added some additional comments when I reviewed the code.
Next to that, I also found some old patch the openkylin project did to support ARM on oVirt:
https://gitee.com/openkylin-backup/ovirt-engine/pulls/1/files

It would also be nice if we could get rid of the TODO's before we merge it.
Cause 'TODO' comments are good, but they will be forgotten and it will stay unimplemented,
So I think it would be nice to have them correct before getting merged.

A last point of attention is the CPU type we should pick for ARM and which flags should be used. I don't know on which CPU you are testing this?

Next to that it could be nice if you joined our Matrix channel. Then we can discuss this easily :)

...odules/bll/src/main/java/org/ovirt/engine/core/bll/architecture/HasMaximumNumberOfDisks.java

dupondje · 2025-08-28T13:36:05Z

...ager/modules/bll/src/main/java/org/ovirt/engine/core/bll/utils/VmOverheadCalculatorImpl.java

            int powerOf2 = Integer.highestOneBit(maxRam);
            pageTable = (maxRam > powerOf2 ? powerOf2 * 2 : powerOf2) / 64;
        } else {
+            // TODO, aarch64


What still has to be fixed here?

Looks like the current overhead calculation is a good guess.
This is what I can see from the two active VMs on different architectures:

aarch64:
oVirt: 48G = 49152 MB
VM /proc/meminfo: MemTotal: 48899820 kB

x86:
oVirt: 48G = 49152 MB
VM /proc/meminfo: MemTotal: 49316136 kB

I have not checked on ppc64le so far, but is this aarch64 specific overhead significant and should there be an aarch64 specific overhead?

...er/modules/bll/src/test/java/org/ovirt/engine/core/bll/exportimport/ImportVmCommandTest.java

...va/org/ovirt/engine/core/vdsbroker/architecture/CreateAdditionalControllersForDomainXml.java

...broker/src/main/java/org/ovirt/engine/core/vdsbroker/builder/vminfo/LibvirtVmXmlBuilder.java

packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql

TrappM · 2025-08-29T14:42:30Z

lscpu.txt
proc_cpuinfo.txt
here is the cpuinfo from our current hypervisor

This patch adds basic support for aarch64 hosts. The 'Compatibility Version' 4.8 provides * CPU architecture aarch64 * CPU type 'ARM64 V8' CPU model/feature detection is based on the asmid flag. Several architecture specific settings have initial values and should be validated. The intended scope of this patch is to add initial aarch64 support and a starting point for further aarch64 related patches. Co-authored-by: Richard Treu <[email protected]> Signed-off-by: Michael Trapp <[email protected]>

TrappM · 2025-11-13T13:58:06Z

Sorry for the delayed reply!

Based on our last discussion I've fixed a couple of things and had further tests.

First of all, it looks like copr is not available for aarch64 and with that, restricting aarch64 support to combat level 4.8 requires a local build of the copr packages for aarch64 and several manual tasks. There might be other ways around but that's not what you want for a test setup, especially when anybody else might be interested in testing this PR.

Secure boot support is not in the scope of this PR, I've already commented that in the review. On a bottom line it's not just another BiosType with a few modifications. But what I've seen, most of the related changes can be tested without the need for having a aarch64 host in a test setup.

I guess there are only two topics left on the list - memory overhead and memory alignment. Could you please review the changes and let me know what has to be fixed to merge this PR.

@dupondje

TrappM requested review from ahadas, bennyz, didib, emesika, michalskrivanek, sgratch and smelamud as code owners July 7, 2025 14:58

sandrobonazzola requested review from JasperB-TeamBlue and dupondje July 15, 2025 06:57

sandrobonazzola added the ARM label Jul 15, 2025

JasperB-TeamBlue assigned TrappM Jul 15, 2025

dupondje requested changes Jul 22, 2025

View reviewed changes

TrappM force-pushed the aarch64 branch from 7b3ec0b to eb471be Compare July 29, 2025 14:39

shubhaOracle reviewed Jul 29, 2025

View reviewed changes

backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/OsRepositoryImpl.java Show resolved Hide resolved

TrappM force-pushed the aarch64 branch 2 times, most recently from 201e924 to f8746f7 Compare August 1, 2025 10:33

TrappM force-pushed the aarch64 branch from 3cb1b46 to cdac233 Compare August 8, 2025 13:27

dupondje requested changes Aug 28, 2025

View reviewed changes

TrappM force-pushed the aarch64 branch from cdac233 to ecc4c68 Compare November 13, 2025 13:03

engine: aarch64 support #1041

Are you sure you want to change the base?

engine: aarch64 support #1041

Uh oh!

Conversation

TrappM commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Issue

Changes introduced with this PR

Are you the owner of the code you are sending in, or do you have permission of the owner?

Uh oh!

dupondje left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TrappM commented Jul 22, 2025

Uh oh!

Uh oh!

TrappM commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dupondje left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dupondje Aug 28, 2025

Choose a reason for hiding this comment

Uh oh!

TrappM Nov 13, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TrappM commented Aug 29, 2025

Uh oh!

TrappM commented Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

TrappM commented Jul 7, 2025 •

edited

Loading

TrappM commented Aug 26, 2025 •

edited

Loading

dupondje left a comment •

edited

Loading

TrappM commented Nov 13, 2025 •

edited

Loading