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.
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
List Archives: 

Reply via email to