<div class="gmail_extra">Built and verified that both the latest fedora rawhide qemu and the latest QEMU from git do not resolve this.</div><div class="gmail_extra">Here: fedora/development/rawhide/source/SRPMS/q/qemu-1.0-15.fc18.src.rpm)</div>
<div class="gmail_extra">and</div><div class="gmail_extra">Here: <a href="http://git.qemu.org/qemu.git" target="_blank">http://git.qemu.org/qemu.git</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">I suspect that unless the patches made to RHEL qemu, mentioned by the qemu developers in the below discussion on qemu-devel are applied to Fedora's qemu or an explicit resolution to the issue is reached by the qemu developers this will remain an issue for Fedora based ovirt hosts.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- DHC<br><br><div class="gmail_quote">On Sun, Apr 22, 2012 at 5:40 AM, Ayal Baron <span dir="ltr"><<a href="mailto:abaron@redhat.com" target="_blank">abaron@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sounds like vdsm should just require a newer version of qemu-kvm as well?<br>
Have you tested with a newer qemu-kvm?<br>
<div><div><br>
----- Original Message -----<br>
><br>
> Seeing an issue wherein ovirt moves a managed host to non-operational<br>
> state.<br>
> This occurs with the currently released version of ovirt and the<br>
> latest development builds.<br>
> The ovirt host is loaded with Fedora core 16 and equipped with most<br>
> current development version of the vdsm.<br>
> *Editorial node*<br>
> The latest vdsm to work on the FC16 host required building and adding<br>
> newer versions of the sanlock, libvirt, lvm2 and device-mapper<br>
> packages than what FC16 provides.<br>
> Ultimately however none of the newer packages have any bearing on<br>
> this failure mode.<br>
><br>
> The failure mode is as follows.<br>
> Upon successfully adding the host and setting the cluster CPU<br>
> compatibility level oVirt will offline the host with the following<br>
> message:<br>
> --> Host ovirtnode moved to Non-Operational state as host does not<br>
> meet the cluster's minimum CPU level. Missing CPU features :<br>
> model_Nehalem<br>
><br>
> Under the hood the actual cause of this failure is that qemu is not<br>
> 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<br>
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx<br>
> rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology<br>
> nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3<br>
> cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow<br>
> vnmi flexpriority ept vpid<br>
><br>
> Thus the CPU is more than capable of everything being asked of it via<br>
> 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<br>
> fine. This was recognized as an issue RHEL and fixed there but has<br>
> not been fixed in Fedora.<br>
> See: <a href="http://wiki.qemu.org/Features/CPUModels#Examples" target="_blank">http://wiki.qemu.org/Features/CPUModels#Examples</a> and this:<br>
> <a href="https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=689665" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=689665</a><br>
> and this related discussion in qemu-devel:<br>
> <a href="http://www.mail-archive.com/qemu-devel@nongnu.org/msg101360.html" target="_blank">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<br>
> type rhel6) AKA the change one needs to make to the ovirt engine<br>
> database to have ovirt manage a EL based host.<br>
> Fedora hosts--> psql -U postgres engine -c "update vdc_options set<br>
> option_value='pc-0.14' where option_name='EmulatedMachine' and<br>
> version='3.0';"<br>
> EL hosts --> psql -U postgres engine -c "update vdc_options set<br>
> option_value='rhel6.2.0' where option_name='EmulatedMachine' and<br>
> version='3.0';"<br>
><br>
> Thus at the moment any host loaded with Fedora and manged by oVirt<br>
> utilizing a Sandy Bridge, Nehalem or Westmere processor will be dead<br>
> in the water.<br>
><br>
> -DHC<br>
><br>
</div></div>> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
><br>
</blockquote></div><br></div>