----- Original Message -----
From: "Dead Horse" <deadhorseconsulting(a)gmail.com>
To: "Ayal Baron" <abaron(a)redhat.com>
Sent: Sunday, April 22, 2012 6:28:48 PM
Subject: Re: [Users] fedora qemu modern CPU recognition issues cause ovirt manged host to
Built and verified that both the latest fedora rawhide qemu and the
latest QEMU from git do not resolve this.
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
Yes, that's correct, here's the Fedora BZ to track.
On Sun, Apr 22, 2012 at 5:40 AM, Ayal Baron < abaron(a)redhat.com >
Sounds like vdsm should just require a newer version of qemu-kvm as
Have you tested with a newer qemu-kvm?
----- Original Message -----
> Seeing an issue wherein ovirt moves a managed host to
> 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
> 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
> --> Host ovirtnode moved to Non-Operational state as host does not
> meet the cluster's minimum CPU level. Missing CPU features :
> 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
> which fails with:
> warning: host cpuid 0000_0000 lacks requested flag 'fpu'
> warning: host cpuid 0000_0000 lacks requested flag 'de'
> 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
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
> rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
> 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
> 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 related discussion in qemu-devel:
> Thus is appears that the changes were made to the RHEL qemu (eg:
> 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
> EL hosts --> psql -U postgres engine -c "update vdc_options set
> option_value='rhel6.2.0' where option_name='EmulatedMachine' and
> Thus at the moment any host loaded with Fedora and manged by oVirt
> utilizing a Sandy Bridge, Nehalem or Westmere processor will be
> in the water.
> Users mailing list
Users mailing list