Seeing an issue wherein ovirt moves a managed host to non-operational state.<br>This occurs with the currently released version of ovirt and the latest development builds.<br>The ovirt host is loaded with Fedora core 16 and equipped with most current development version of the vdsm.<br>
*Editorial node*<br>The latest vdsm to work on the FC16 host required building and adding newer versions of the sanlock, libvirt, lvm2 and device-mapper packages than what FC16 provides.<br>Ultimately however none of the newer packages have any bearing on this failure mode.<br>
<br>The failure mode is as follows.<br>Upon successfully adding the host and setting the cluster CPU compatibility level oVirt will offline the host with the following message:<br>--> Host ovirtnode moved to Non-Operational state as host does not meet the cluster's minimum CPU level. Missing CPU features : model_Nehalem<br>
<br>Under the hood the actual cause of this failure is that qemu is not correctly able to identify the host CPU feature flags.<br>This can be observed by doing: qemu-system-x86_64 -cpu Nehalem,check<br>which fails with:<br>
warning: host cpuid 0000_0000 lacks requested flag 'fpu' [0x00000001]<br>warning: host cpuid 0000_0000 lacks requested flag 'de' [0x00000004]<br>and on and on...<br><br>A simple check of "cat /proc/cpuinfo | grep flags"<br>
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid<br>
<br>Thus the CPU is more than capable of everything being asked of it via the cpudef for "Nehalem" in /etc/qemu/target-x86_64.conf.<br><br>This is only an issue on Fedora hosts. RHEL/CentOS/SL hosts work fine. This was recognized as an issue RHEL and fixed there but has not been fixed in Fedora.<br>
See: <a href="http://wiki.qemu.org/Features/CPUModels#Examples">http://wiki.qemu.org/Features/CPUModels#Examples</a> and this: <a href="https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=689665">https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=689665</a> and this related discussion in qemu-devel: <a href="http://www.mail-archive.com/qemu-devel@nongnu.org/msg101360.html">http://www.mail-archive.com/qemu-devel@nongnu.org/msg101360.html</a><br>
<br>Thus is appears that the changes were made to the RHEL qemu (eg: cpu type rhel6) AKA the change one needs to make to the ovirt engine database to have ovirt manage a EL based host.<br>Fedora hosts--> psql -U postgres engine -c "update vdc_options set option_value='pc-0.14' where option_name='EmulatedMachine' and version='3.0';"<br>
EL hosts --> psql -U postgres engine -c "update vdc_options set option_value='rhel6.2.0' where option_name='EmulatedMachine' and version='3.0';"<br><br>Thus at the moment any host loaded with Fedora and manged by oVirt utilizing a Sandy Bridge, Nehalem or Westmere processor will be dead in the water.<br>
<br>-DHC<br>