Yup, that's a bug in the ansible code, I've come across on hosts that had 512GB of
RAM.
I quite simply deleted the checks from the ansible code and re-ran the wizard.
I can't read YAML or Python or whatever it is that Ansible uses, but my impression is
that things are 'cast' or converted into an INT data type on these checks that
overflows at that point. I wound up commenting out the entire set of checks to get past
this, because I could see no easy way to fix this. I just checked that the commands used
to retrieve the memory size returned the proper number of kilobytes and then rolled my
eyes at what seemd like a type cast operation.
I never went deeper, because at that point I have a hard time keeping the beast inside me
at bay, that sees how Ansible can bring a Xeon Scalable Gold system to what seems slower
than a 6502 executing BASIC. The hosted-setup takes what seems like an hour, no matter how
fast or slow your hardware.
I was so fed up at the speed of Ansible and the quality of oVirt QA, I couldn't bring
myself to open a ticket, I hope you're better motivated.
BTW things aren't much better at the low end either. While Ansible doesn't seem
that much slower on an Atom farm I also operate, the hosted-engine setup does fail on
them, so replug their SSDs for that part into an i7 and then replug the SSDs to the Atoms
aftwards. Once, up and running oVirt is just fine on Atoms (mine have 32GB of RAM each).
I am almost ready to donate my Atoms to the project, because I keep thinking that
oVirt's major chance would be as edge HCI, but they are asking for 128GB RAM
minimum...
BTW. I was running oVirt 4.3 on CentOS7 when hitting that error. No idea if it's still
the same with 4.4/COS8 as my 'perhaps-next-but-more-likely-never' generation test
farm runs on NUCs with 64GB.