I have seen this type of behavior when building a HCI cluster on Atoms.
The problem is that at this poing the machine that is generated for the management engine
has a machine type that is above what is actually supported in hardware.
Since it's not the first VM that is run during the setup process, it's not really
intuitive but the libvirt configuration for that prototypical management engine is created
by code that assumes to modern a default (I never found the source, but since all
development has ceased it won't matter any more).
While modern Atoms are actually more like Core CPUs in terms of the instruction set they
support, my Goldmont Plus/Gemini Lake Atoms were regarded by KVM as next to a Nehalem CPU
and the VM would refuse to start.
It's very hard to find in the logs, because it is actually a KVM issue (created by the
oVirt ME creation mechanism, of couse).
I got out of that fix using removable storage: I had the setup run on an i7-7700k (was a
bit faster, too) and then changed the machine type of the management engine (and lowest
common denominator for the cluster) to Nehalem before transplanting the SSD back into the
Atom.
I've gone through that excercise with ovirt 4.3 and again with Oracle's 4.4
variant, which is by far the most stable oVirt/RHEV available right now.