4:42 a.m.
On 03/02/2013 05:07 PM, Adrian Gibanel wrote:
Sorry for the late answer. I was kind of busy. I reply inline below.
----- Mensaje original -----
> De: "Martin Kletzander" <mkletzan(a)redhat.com>
> Para: "Itamar Heim" <iheim(a)redhat.com>
> CC: "Adrian Gibanel" <adrian.gibanel(a)btactic.com>, users(a)ovirt.org,
"Jithin
> Raju" <rajujith(a)gmail.com>
> Enviados: Martes, 19 de Febrero 2013 15:11:05
> Asunto: Re: [Users] ovirt reporting wrong cpu family
> On 02/16/2013 10:02 PM, Itamar Heim wrote:
>> Adrian - can you later please wikify this recurring question?
>>
> If this is related to libvirt detecting the wrong CPU, we have a short
> wiki page [1] for that either, you can link to that in yours (or maybe
> it'll help you write it).
Thank you. I'll take a look. More below.
> [...]
>>> On 16/02/2013 18:56, Adrian Gibanel wrote:
>>>> I happen to have the same problem in oVirt 3.1 on Fedora.
>>>> Any workaround?
>>>>
>>>> $ sudo vdsClient -s 0 getVdsCaps | grep -i flags ; echo -e -n
"\n" ;cat
>>>> /proc/cpuinfo | grep "model name" | head -n 1
>>>> cpuFlags =
>>>>
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,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,popcnt,tsc_deadline_timer,xsave,avx,lahf_lm,arat,epb,xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_coreduo,model_Conroe
>>>>
> At first, let me say that this is very weird CPU detection as according
> to these flags, the processor described in here should be "Nehalem".
> Could you try running 'virsh -r capabilities' on the host to check what
> libvirt reports?
Here you are:
<capabilities>
<host>
<uuid>c090c38a-5202-e211-bbb4-4c72b97c99ed</uuid>
<cpu>
<arch>x86_64</arch>
<model>Nehalem</model>
And it is really Nehalem, so my manual cpu flags hunt was right. But
this means there is a problem lower than in libvirt. I'm afraid that
the sentence about the BIOS/UEFI not being your case which I wrote in
http://lists.ovirt.org/pipermail/users/2013-March/012908.html is no
longer true for this server. The only solution I can come up with right
now is what already once helped for resolving Nehalem-related detection
and it's the link from the wiki page (that was outdated, so I updated it):
http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=TOOL-ASU
but that's applicable for BladeCenters only. If this is not suitable
for you, I'm afraid you'll have to contact your HW vendor in order to
resolve the CPU issue.
Hope it helps and please keep me posted, I'd like to summarize all the
related info on one place and resolve related bugs (if there are any) so
similar issues go away, because they seem to be appearing more and more
frequently.
Have a nice day,
Martin
[...]
</capabilities>
> There might be a possible workaround if you want your CPU to be
> identified as different model, most probably by editing
> '/usr/share/libvirt/cpu_map.xml', but that should be omitted since it
> may lead to problems.
Non applicable workaround then. I should have expected it. Ok, I prefer not having
additional problems.
> [...]
>>>> model name : Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz
>>>>
> And as I see the CPU is SandyBridge, so this should be solved properly
> (probably a bug somewhere or very low-level misconfiguration). Check
> [1], maybe some features can get enabled.
The machine is in a datacentre so I doubt I can change any BIOS or UEFI settings.
> Martin
> [1]
>
http://wiki.libvirt.org/page/Libvirt_identifies_host_processor_as_a_diffe...