Built and verified that both the latest fedora rawhide qemu and the latest QEMU from git do not resolve this. Here: fedora/development/rawhide/source/SRPMS/q/qemu-1.0-15.fc18.src.rpm) and Here: http://git.qemu.org/qemu.git
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. - DHC On Sun, Apr 22, 2012 at 5:40 AM, Ayal Baron <aba...@redhat.com> wrote: > Sounds like vdsm should just require a newer version of qemu-kvm as well? > Have you tested with a newer qemu-kvm? > > ----- Original Message ----- > > > > Seeing an issue wherein ovirt moves a managed host to non-operational > > state. > > This occurs with the currently released version of ovirt and the > > latest development builds. > > The ovirt host is loaded with Fedora core 16 and equipped with most > > current development version of the vdsm. > > *Editorial node* > > 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. > > Ultimately however none of the newer packages have any bearing on > > this failure mode. > > > > The failure mode is as follows. > > Upon successfully adding the host and setting the cluster CPU > > compatibility level oVirt will offline the host with the following > > message: > > --> Host ovirtnode moved to Non-Operational state as host does not > > meet the cluster's minimum CPU level. Missing CPU features : > > model_Nehalem > > > > Under the hood the actual cause of this failure is that qemu is not > > correctly able to identify the host CPU feature flags. > > This can be observed by doing: qemu-system-x86_64 -cpu Nehalem,check > > which fails with: > > warning: host cpuid 0000_0000 lacks requested flag 'fpu' [0x00000001] > > warning: host cpuid 0000_0000 lacks requested flag 'de' [0x00000004] > > and on and on... > > > > A simple check of "cat /proc/cpuinfo | grep flags" > > 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 > > > > 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. > > > > 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. > > See: http://wiki.qemu.org/Features/CPUModels#Examples and this: > > https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=689665 > > and this related discussion in qemu-devel: > > http://www.mail-archive.com/qemu-devel@nongnu.org/msg101360.html > > > > 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. > > Fedora hosts--> psql -U postgres engine -c "update vdc_options set > > option_value='pc-0.14' where option_name='EmulatedMachine' and > > version='3.0';" > > EL hosts --> psql -U postgres engine -c "update vdc_options set > > option_value='rhel6.2.0' where option_name='EmulatedMachine' and > > version='3.0';" > > > > 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. > > > > -DHC > > > > _______________________________________________ > > Users mailing list > > Users@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users