[Users] fedora qemu modern CPU recognition issues cause ovirt manged host to go non-operational

[Dead Horse]

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 <abaron at 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20120422/d7769813/attachment-0001.html>