Re: [Users] ovirt reporting wrong cpu family
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 model name : Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz $ rpm -qa | grep -i ovirt ; rpm -qa | grep -i vdsm ovirt-release-fedora-5-2.noarch vdsm-python-4.10.0-10.fc17.x86_64 vdsm-cli-4.10.0-10.fc17.noarch vdsm-4.10.0-10.fc17.x86_64 vdsm-xmlrpc-4.10.0-10.fc17.noarch ----- Mensaje original -----
De: "Jithin Raju" <rajujith@gmail.com> Para: "Itamar Heim" <iheim@redhat.com> CC: users@ovirt.org Enviados: Jueves, 3 de Enero 2013 4:49:34 Asunto: Re: [Users] ovirt reporting wrong cpu family
Hi ,
Please find the requested flags below:
[root@fig /]# vdsClient -s 0 getVdsCaps | grep -i flags 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,pdpe1gb,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,dca,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb,xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_coreduo,model_Conroe
Thanks, Jithin
On Thu, Jan 3, 2013 at 2:03 AM, Itamar Heim < iheim@redhat.com > wrote:
On 01/02/2013 03:37 PM, Jithin Raju wrote:
Hi,
I have installed ovirt 3.1 on fedora 17.
I added my node wtih intel E5-2620 (sandy bridge) to cluster.
Even though model is detected properly,CPU name is shown as Intel Conroe
family instead of sandy bridge.
Since my cluster is configured as sandy bridge i got this error:
Host fig moved to Non-Operational state as host does not meet the
cluster's minimum CPU level. Missing CPU features : model_SandyBridge.
as per cpuinfo :model name : Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz.
i moved the cluster to conroe ,got the host up.
reference:
http://en.wikipedia.org/wiki/ Sandy_Bridge_( microarchitecture)
PFA for screenshot.
Thanks,
Jithin
-- -- Adrián Gibanel I.T. Manager +34 675 683 301 www.btactic.com Ens podeu seguir a/Nos podeis seguir en: i Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos. AVIS: El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge . AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje .
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
you cpu is identified as model_Conroe, which should work. just set the cluster level to Conroe (should happen automatically if first host added to the cluster)
model name : Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz
$ rpm -qa | grep -i ovirt ; rpm -qa | grep -i vdsm ovirt-release-fedora-5-2.noarch vdsm-python-4.10.0-10.fc17.x86_64 vdsm-cli-4.10.0-10.fc17.noarch vdsm-4.10.0-10.fc17.x86_64 vdsm-xmlrpc-4.10.0-10.fc17.noarch
----- Mensaje original -----
De: "Jithin Raju" <rajujith@gmail.com> Para: "Itamar Heim" <iheim@redhat.com> CC: users@ovirt.org Enviados: Jueves, 3 de Enero 2013 4:49:34 Asunto: Re: [Users] ovirt reporting wrong cpu family
Hi ,
Please find the requested flags below:
[root@fig /]# vdsClient -s 0 getVdsCaps | grep -i flags 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,pdpe1gb,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,dca,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb,xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_coreduo,model_Conroe
Thanks, Jithin
On Thu, Jan 3, 2013 at 2:03 AM, Itamar Heim < iheim@redhat.com > wrote:
On 01/02/2013 03:37 PM, Jithin Raju wrote:
Hi,
I have installed ovirt 3.1 on fedora 17.
I added my node wtih intel E5-2620 (sandy bridge) to cluster.
Even though model is detected properly,CPU name is shown as Intel Conroe
family instead of sandy bridge.
Since my cluster is configured as sandy bridge i got this error:
Host fig moved to Non-Operational state as host does not meet the
cluster's minimum CPU level. Missing CPU features : model_SandyBridge.
as per cpuinfo :model name : Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz.
i moved the cluster to conroe ,got the host up.
reference:
http://en.wikipedia.org/wiki/ Sandy_Bridge_( microarchitecture)
PFA for screenshot.
Thanks,
Jithin
------=_Part_937_12812134.1361047563378 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, I know. I meant a workaround where the processor is detected as SandyB= ridge.=20 Thank you.=20 ----- Mensaje original -----
De: "Itamar Heim" <iheim@redhat.com> Para: "Adrian Gibanel" <adrian.gibanel@btactic.com> CC: "Jithin Raju" <rajujith@gmail.com>, users@ovirt.org Enviados: S=C3=A1bado, 16 de Febrero 2013 21:36:38 Asunto: Re: [Users] ovirt reporting wrong cpu family
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 =3D 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,const= ant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmper= f,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,=
On 16/02/2013 18:56, Adrian Gibanel wrote: pdcm,pcid,sse4_1,sse4_2,popcnt,tsc_deadline_timer,xsave,avx,lahf_lm,arat,ep= b,xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_cored= uo,model_Conroe
you cpu is identified as model_Conroe, which should work. just set the cluster level to Conroe (should happen automatically if first host added to the cluster)
model name : Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz
$ rpm -qa | grep -i ovirt ; rpm -qa | grep -i vdsm ovirt-release-fedora-5-2.noarch vdsm-python-4.10.0-10.fc17.x86_64 vdsm-cli-4.10.0-10.fc17.noarch vdsm-4.10.0-10.fc17.x86_64 vdsm-xmlrpc-4.10.0-10.fc17.noarch
--=20 Adri=C3=A1n Gibanel=20 I.T. Manager=20 +34 675 683 301=20 www.btactic.com=20 Ens podeu seguir a/Nos podeis seguir en:=20 i=20 Abans d=C2=B4imprimir aquest missatge, pensa en el medi ambient. El medi am= bient =C3=A9s cosa de tothom. / Antes de imprimir el mensaje piensa en el m= edio ambiente. El medio ambiente es cosa de todos.=20 AVIS:=20 El contingut d'aquest missatge i els seus annexos =C3=A9s confidencial. Si = no en sou el destinatari, us fem saber que est=C3=A0 prohibit utilitzar-lo,= divulgar-lo i/o copiar-lo sense tenir l'autoritzaci=C3=B3 corresponent. Si= heu rebut aquest missatge per error, us agrairem que ho feu saber immediat= ament al remitent i que procediu a destruir el missatge .=20 AVISO:=20 El contenido de este mensaje y de sus anexos es confidencial. Si no es el d= estinatario, les hacemos saber que est=C3=A1 prohibido utilizarlo, divulgar= lo y/o copiarlo sin tener la autorizaci=C3=B3n correspondiente. Si han reci= bido este mensaje por error, les agradecer=C3=ADamos que lo hagan saber inm= ediatamente al remitente y que procedan a destruir el mensaje .=20 ------=_Part_937_12812134.1361047563378 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>Yes, I know. I meant a workaround where the processor is detect= ed as SandyBridge.<br><br>Thank you.<br><br><hr id=3D"zwchr"><blockquote st= yle=3D"border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:= 5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;fo= nt-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"Itamar He= im" <iheim@redhat.com><br><b>Para: </b>"Adrian Gibanel" <adrian.gi= banel@btactic.com><br><b>CC: </b>"Jithin Raju" <rajujith@gmail.com>= ;, users@ovirt.org<br><b>Enviados: </b>S=C3=A1bado, 16 de Febrero 2013 21:3= 6:38<br><b>Asunto: </b>Re: [Users] ovirt reporting wrong cpu family<br><br>= On 16/02/2013 18:56, Adrian Gibanel wrote:<br>> I happen to have the sam= e problem in oVirt 3.1 on Fedora.<br>> Any workaround?<br>><br>> $= sudo vdsClient -s 0 getVdsCaps | grep -i flags ; echo -e -n "\n" ;cat /pro= c/cpuinfo | grep "model name" | head -n 1<br>> cpuFlags =3D fpu,vme,de,p= se,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acp= i,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_per= fmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,p= clmulqdq,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,p= ts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_coreduo,model_Conroe<= br><br>you cpu is identified as model_Conroe, which should work. just set t= he <br>cluster level to Conroe (should happen automatically if first host a= dded <br>to the cluster)<br><br>><br>> model name : Intel(R) Core(TM)= i3-2130 CPU @ 3.40GHz<br>><br>> $ rpm -qa | grep -i ovirt ; rpm -qa = | grep -i vdsm<br>> ovirt-release-fedora-5-2.noarch<br>> vdsm-python-= 4.10.0-10.fc17.x86_64<br>> vdsm-cli-4.10.0-10.fc17.noarch<br>> vdsm-4= .10.0-10.fc17.x86_64<br>> vdsm-xmlrpc-4.10.0-10.fc17.noarch<br></blockqu= ote>-- <br><div><span name=3D"x"></span><font style=3D"font-weight: bold;" = size=3D"3"><a style=3D"color: rgb(0, 0, 0);" href=3D"http://www.btactic.com= /"><span id=3D"DWT100"><font class=3D"Apple-style-span" face=3D"verdana, he= lvetica, sans-serif"><span class=3D"Apple-style-span" style=3D"background-c= olor: rgb(255, 255, 255);"></span></font></span></a></font><font style=3D"f= ont-family: 'Times New Roman';" color=3D"#5f5f5f" face=3D"Arial" size=3D"1"=
<font size=3D"3"><span style=3D"font-family: verdana,helvetica,sans-serif;=
color: rgb(0, 0, 0);"><font style=3D"font-family: helvetica;" size=3D"2"><= strong>Adri=C3=A1n Gibanel</strong><br>I.T. Manager<br><br>+34 675 683 301<= br><a href=3D"http://btactic.com/">www.btactic.com</a></font><br><br></span= ></font></font><font color=3D"#008000" face=3D"Arial" size=3D"1"><img src= =3D"http://www.btactic.com/signaturabtacticmail/btacticsignature.png" style= =3D"border-width: 0px;"><br></font><font class=3D"Apple-style-span" face=3D= "Arial"><b><span class=3D"Apple-style-span" style=3D"font-family: Verdana; = font-weight: normal;"><span id=3D"bc4bed34-88ab-466b-a731-c40f5c09ab6c"><fo= nt color=3D"#5f5f5f" face=3D"Arial" size=3D"1"><br>Ens podeu seguir a/Nos p= odeis seguir en:<br> <br> </font></span><a href=3D"http://www.facebook.com/pages/btactic/118651634826= 400?v=3Dapp_9953271133"><img style=3D"border: 0pt none;" src=3D"http://www.= btactic.com/wp-content/themes/btactic/img/facebookfoot.jpg"></a> i <a href= =3D"http://twitter.com/btactic"><img style=3D"border: 0pt none;" src=3D"htt= p://www.btactic.com/wp-content/themes/btactic/img/twitterfoot.jpg"></a></sp= an></b></font><br><font color=3D"#008000" face=3D"Arial" size=3D"1"><br></f= ont><div><font color=3D"#008000" face=3D"Arial" size=3D"1">Abans d=C2=B4imp= rimir aquest missatge, pensa en el medi ambient. El medi ambient =C3=A9s cosa de= =20 tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio=20 ambiente es cosa de todos. </font><font color=3D"#5f5f5f" face=3D"Arial" size=3D"1">= <br> <br> AVIS: <br> El contingut d'aquest missatge i els seus annexos =C3=A9s confidencial. Si = no en sou el destinatari, us fem saber que est=C3=A0 prohibit utilitzar-lo,=20 divulgar-lo i/o copiar-lo sense tenir l'autoritzaci=C3=B3 corresponent. Si heu rebut=20 aquest missatge per error, us agrairem que ho feu saber immediatament <span class= =3D"Object" id=3D"OBJ_PREFIX_DWT103">al remitent i que procediu a destruir el missatge</span>.<br> <br> AVISO:<br> El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que est=C3=A1 prohibido utilizarlo,=20 divulgarlo y/o copiarlo sin tener la autorizaci=C3=B3n correspondiente. Si han recibid= o este mensaje por error, les agradecer=C3=ADamos que lo hagan saber=20 inmediatamente <span class=3D"Object" id=3D"OBJ_PREFIX_DWT104">al remitente y que procedan= a destruir el mensaje</span>.</font>
</div><span name=3D"x"></span><br></div></div></body></html> ------=_Part_937_12812134.1361047563378--
On 16/02/2013 22:46, Adrian Gibanel wrote:
Yes, I know. I meant a workaround where the processor is detected as SandyBridge.
Adrian - please provide libvirt version. Martin - can you please take a look? Adrian - can you later please wikify this recurring question? Thanks, Itamar
Thank you.
------------------------------------------------------------------------
*De: *"Itamar Heim" <iheim@redhat.com> *Para: *"Adrian Gibanel" <adrian.gibanel@btactic.com> *CC: *"Jithin Raju" <rajujith@gmail.com>, users@ovirt.org *Enviados: *Sábado, 16 de Febrero 2013 21:36:38 *Asunto: *Re: [Users] ovirt reporting wrong cpu family
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
you cpu is identified as model_Conroe, which should work. just set the cluster level to Conroe (should happen automatically if first host added to the cluster)
> > model name : Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz > > $ rpm -qa | grep -i ovirt ; rpm -qa | grep -i vdsm > ovirt-release-fedora-5-2.noarch > vdsm-python-4.10.0-10.fc17.x86_64 > vdsm-cli-4.10.0-10.fc17.noarch > vdsm-4.10.0-10.fc17.x86_64 > vdsm-xmlrpc-4.10.0-10.fc17.noarch
-- <http://www.btactic.com/>*Adrián Gibanel* I.T. Manager
+34 675 683 301 www.btactic.com <http://btactic.com/>
* Ens podeu seguir a/Nos podeis seguir en:
<http://www.facebook.com/pages/btactic/118651634826400?v=app_9953271133> i <http://twitter.com/btactic>*
Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos.
AVIS: El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge.
AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje.
Here there's my libvirt version: $ rpm -qa | grep libvirt libvirt-daemon-config-nwfilter-0.9.11.9-1.fc17.x86_64 libvirt-python-0.9.11.9-1.fc17.x86_64 libvirt-client-0.9.11.9-1.fc17.x86_64 libvirt-daemon-0.9.11.9-1.fc17.x86_64 libvirt-lock-sanlock-0.9.11.9-1.fc17.x86_64 libvirt-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-network-0.9.11.9-1.fc17.x86_64 Yes, I suppose I will be able to wikify it. ----- Mensaje original -----
De: "Itamar Heim" <iheim@redhat.com> Para: "Adrian Gibanel" <adrian.gibanel@btactic.com> CC: users@ovirt.org, "Jithin Raju" <rajujith@gmail.com>, "Martin Kletzander" <mkletzan@redhat.com> Enviados: Sábado, 16 de Febrero 2013 22:02:01 Asunto: Re: [Users] ovirt reporting wrong cpu family
On 16/02/2013 22:46, Adrian Gibanel wrote:
Yes, I know. I meant a workaround where the processor is detected as SandyBridge.
Adrian - please provide libvirt version. Martin - can you please take a look? Adrian - can you later please wikify this recurring question?
Thanks, Itamar
Thank you.
------------------------------------------------------------------------
*De: *"Itamar Heim" <iheim@redhat.com> *Para: *"Adrian Gibanel" <adrian.gibanel@btactic.com> *CC: *"Jithin Raju" <rajujith@gmail.com>, users@ovirt.org *Enviados: *Sábado, 16 de Febrero 2013 21:36:38 *Asunto: *Re: [Users] ovirt reporting wrong cpu family
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
you cpu is identified as model_Conroe, which should work. just set the cluster level to Conroe (should happen automatically if first host added to the cluster)
model name : Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz
$ rpm -qa | grep -i ovirt ; rpm -qa | grep -i vdsm ovirt-release-fedora-5-2.noarch vdsm-python-4.10.0-10.fc17.x86_64 vdsm-cli-4.10.0-10.fc17.noarch vdsm-4.10.0-10.fc17.x86_64 vdsm-xmlrpc-4.10.0-10.fc17.noarch
-- -- Adrián Gibanel I.T. Manager +34 675 683 301 www.btactic.com Ens podeu seguir a/Nos podeis seguir en: i Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos. AVIS: El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge . AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje .
On 02/16/2013 10:02 PM, Itamar Heim wrote:
On 16/02/2013 22:46, Adrian Gibanel wrote:
Yes, I know. I meant a workaround where the processor is detected as SandyBridge.
Adrian - please provide libvirt version. Martin - can you please take a look?
I'm not sure what kind of help I can give here, but let me see.
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). [...]
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? 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. [...]
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. Martin [1] http://wiki.libvirt.org/page/Libvirt_identifies_host_processor_as_a_differen...
Sorry for the late answer. I was kind of busy. I reply inline below. ----- Mensaje original -----
De: "Martin Kletzander" <mkletzan@redhat.com> Para: "Itamar Heim" <iheim@redhat.com> CC: "Adrian Gibanel" <adrian.gibanel@btactic.com>, users@ovirt.org, "Jithin Raju" <rajujith@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> <vendor>Intel</vendor> <topology sockets='1' cores='2' threads='2'/> <feature name='rdtscp'/> <feature name='avx'/> <feature name='osxsave'/> <feature name='xsave'/> <feature name='tsc-deadline'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pclmuldq'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> <power_management> <suspend_mem/> <suspend_disk/> <suspend_hybrid/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='4'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> </cpus> </cell> </cells> </topology> <secmodel> <model>selinux</model> <doi>0</doi> </secmodel> </host> <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <machine>pc-0.15</machine> <machine>pc-1.0</machine> <machine canonical='pc-1.0'>pc</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-0.15</machine> <machine>pc-1.0</machine> <machine canonical='pc-1.0'>pc</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> </domain> </arch> <features> <cpuselection/> <deviceboot/> <pae/> <nonpae/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <machine>pc-0.15</machine> <machine>pc-1.0</machine> <machine canonical='pc-1.0'>pc</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-0.15</machine> <machine>pc-1.0</machine> <machine canonical='pc-1.0'>pc</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> </domain> </arch> <features> <cpuselection/> <deviceboot/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> </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_differen...
-- -- Adrián Gibanel I.T. Manager +34 675 683 301 www.btactic.com Ens podeu seguir a/Nos podeis seguir en: i Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos. AVIS: El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge . AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje .
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@redhat.com> Para: "Itamar Heim" <iheim@redhat.com> CC: "Adrian Gibanel" <adrian.gibanel@btactic.com>, users@ovirt.org, "Jithin Raju" <rajujith@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_differen...
This is another server which I have also problems with. I cannot select SandyBridge as the cpu type. Still oVirt 3.1 in Fedora 17. * Tecnology : Sandy Bridge E * CPU : Intel Xeon E5-1620 * Cores / Threads : 4 / 8 * Frecuency : 3.6GHz / 3.8GHz Turbo Boost #cpuinfo: Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz # rpm -qa | grep -E 'vdsm|libvirt' | sort libvirt-0.9.11.9-1.fc17.x86_64 libvirt-client-0.9.11.9-1.fc17.x86_64 libvirt-daemon-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-network-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-nwfilter-0.9.11.9-1.fc17.x86_64 libvirt-lock-sanlock-0.9.11.9-1.fc17.x86_64 libvirt-python-0.9.11.9-1.fc17.x86_64 vdsm-4.10.0-10.fc17.x86_64 vdsm-cli-4.10.0-10.fc17.noarch vdsm-python-4.10.0-10.fc17.x86_64 vdsm-xmlrpc-4.10.0-10.fc17.noarch # virsh -r capabilities <capabilities> <host> <uuid>00000000-0000-0000-0000-002590a41888</uuid> <cpu> <arch>x86_64</arch> <model>SandyBridge</model> <vendor>Intel</vendor> <topology sockets='1' cores='4' threads='2'/> <feature name='pdpe1gb'/> <feature name='osxsave'/> <feature name='dca'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='smx'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> <power_management> <suspend_mem/> <suspend_disk/> <suspend_hybrid/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='8'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> <cpu id='4'/> <cpu id='5'/> <cpu id='6'/> <cpu id='7'/> </cpus> </cell> </cells> </topology> <secmodel> <model>selinux</model> <doi>0</doi> </secmodel> </host> <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <machine>pc-0.15</machine> <machine>pc-1.0</machine> <machine canonical='pc-1.0'>pc</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-0.15</machine> <machine>pc-1.0</machine> <machine canonical='pc-1.0'>pc</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> </domain> </arch> <features> <cpuselection/> <deviceboot/> <pae/> <nonpae/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <machine>pc-0.15</machine> <machine>pc-1.0</machine> <machine canonical='pc-1.0'>pc</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-0.15</machine> <machine>pc-1.0</machine> <machine canonical='pc-1.0'>pc</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> </domain> </arch> <features> <cpuselection/> <deviceboot/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> </capabilities> ----- Mensaje original -----
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?
-- Adrián Gibanel I.T. Manager +34 675 683 301 www.btactic.com Ens podeu seguir a/Nos podeis seguir en: i Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos. AVIS: El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge . AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje .
I've read again the wiki page and as you might ask for it here's the cpuinfo flags output: 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 pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid If we check the mentioned cpu_max.xml file we find : <model name='SandyBridge'> <model name='Westmere'/> <feature name='pclmuldq'/> <feature name='x2apic'/> <feature name='tsc-deadline'/> <feature name='xsave'/> <feature name='avx'/> <feature name='rdtscp'/> </model> So I suppose that pclmuldq is expected in the flags but it's not there. Isn't it? So I need to add my specific model at hand and trying to infer which are the specific flags for it? Or maybe that needs something more to be hacked in the libvirt code... and thus I should wait for libvirt people to add it? Well, I mean, going to their ML and asking there? Or isn't there any hope for my particular sandbridge cpu? Thank you. ----- Mensaje original -----
De: "Adrian Gibanel" <adrian.gibanel@btactic.com> Para: users@ovirt.org CC: "Itamar Heim" <iheim@redhat.com>, "Jithin Raju" <rajujith@gmail.com>, "Martin Kletzander" <mkletzan@redhat.com> Enviados: Sábado, 2 de Marzo 2013 17:21:43 Asunto: Re: [Users] ovirt reporting wrong cpu family (2nd server)
This is another server which I have also problems with. I cannot select SandyBridge as the cpu type. Still oVirt 3.1 in Fedora 17.
* Tecnology : Sandy Bridge E * CPU : Intel Xeon E5-1620 * Cores / Threads : 4 / 8 * Frecuency : 3.6GHz / 3.8GHz Turbo Boost
#cpuinfo: Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
# rpm -qa | grep -E 'vdsm|libvirt' | sort libvirt-0.9.11.9-1.fc17.x86_64 libvirt-client-0.9.11.9-1.fc17.x86_64 libvirt-daemon-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-network-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-nwfilter-0.9.11.9-1.fc17.x86_64 libvirt-lock-sanlock-0.9.11.9-1.fc17.x86_64 libvirt-python-0.9.11.9-1.fc17.x86_64 vdsm-4.10.0-10.fc17.x86_64 vdsm-cli-4.10.0-10.fc17.noarch vdsm-python-4.10.0-10.fc17.x86_64 vdsm-xmlrpc-4.10.0-10.fc17.noarch
# virsh -r capabilities
<capabilities> [...]
----- Mensaje original -----
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?
-- --
-- Adrián Gibanel I.T. Manager +34 675 683 301 www.btactic.com Ens podeu seguir a/Nos podeis seguir en: i Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos. AVIS: El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge . AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje .
On 02/03/2013 18:39, Adrian Gibanel wrote:
I've read again the wiki page and as you might ask for it here's the cpuinfo flags output:
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 pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
If we check the mentioned cpu_max.xml file we find :
<model name='SandyBridge'> <model name='Westmere'/> <feature name='pclmuldq'/> <feature name='x2apic'/> <feature name='tsc-deadline'/> <feature name='xsave'/> <feature name='avx'/> <feature name='rdtscp'/> </model>
So I suppose that pclmuldq is expected in the flags but it's not there. Isn't it?
well, it kind of looks like a bug, since you have pclmulqdq (additional 'q' in the middle'). martin?
So I need to add my specific model at hand and trying to infer which are the specific flags for it? Or maybe that needs something more to be hacked in the libvirt code... and thus I should wait for libvirt people to add it? Well, I mean, going to their ML and asking there?
Or isn't there any hope for my particular sandbridge cpu?
Thank you.
----- Mensaje original -----
De: "Adrian Gibanel" <adrian.gibanel@btactic.com> Para: users@ovirt.org CC: "Itamar Heim" <iheim@redhat.com>, "Jithin Raju" <rajujith@gmail.com>, "Martin Kletzander" <mkletzan@redhat.com> Enviados: Sábado, 2 de Marzo 2013 17:21:43 Asunto: Re: [Users] ovirt reporting wrong cpu family (2nd server)
This is another server which I have also problems with. I cannot select SandyBridge as the cpu type. Still oVirt 3.1 in Fedora 17.
* Tecnology : Sandy Bridge E * CPU : Intel Xeon E5-1620 * Cores / Threads : 4 / 8 * Frecuency : 3.6GHz / 3.8GHz Turbo Boost
#cpuinfo: Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
# rpm -qa | grep -E 'vdsm|libvirt' | sort libvirt-0.9.11.9-1.fc17.x86_64 libvirt-client-0.9.11.9-1.fc17.x86_64 libvirt-daemon-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-network-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-nwfilter-0.9.11.9-1.fc17.x86_64 libvirt-lock-sanlock-0.9.11.9-1.fc17.x86_64 libvirt-python-0.9.11.9-1.fc17.x86_64 vdsm-4.10.0-10.fc17.x86_64 vdsm-cli-4.10.0-10.fc17.noarch vdsm-python-4.10.0-10.fc17.x86_64 vdsm-xmlrpc-4.10.0-10.fc17.noarch
# virsh -r capabilities
<capabilities> [...]
----- Mensaje original -----
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?
--
On 03/02/2013 08:46 PM, Itamar Heim wrote:
On 02/03/2013 18:39, Adrian Gibanel wrote:
I've read again the wiki page and as you might ask for it here's the cpuinfo flags output:
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 pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
If we check the mentioned cpu_max.xml file we find :
<model name='SandyBridge'> <model name='Westmere'/> <feature name='pclmuldq'/> <feature name='x2apic'/> <feature name='tsc-deadline'/> <feature name='xsave'/> <feature name='avx'/> <feature name='rdtscp'/> </model>
So I suppose that pclmuldq is expected in the flags but it's not there. Isn't it?
well, it kind of looks like a bug, since you have pclmulqdq (additional 'q' in the middle'). martin?
Hi, this is expected. While working on these features, the names sometime change and in this case pclmulqdq is the same as pclmuldq. Mostly it is referred to it as pclmulqdq, but when this feature was added in qemu, the name was without the 'q', alias was added later on: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02376.html
# virsh -r capabilities
<capabilities>
<host> <uuid>00000000-0000-0000-0000-002590a41888</uuid> <cpu> <arch>x86_64</arch> <model>SandyBridge</model>
But from this output (which I pasted from the older mail, so the indentation may not fit), I see libvirt is detecting the CPU perfectly in this case.
So I need to add my specific model at hand and trying to infer which are the specific flags for it? Or maybe that needs something more to be hacked in the libvirt code... and thus I should wait for libvirt people to add it? Well, I mean, going to their ML and asking there?
Or isn't there any hope for my particular sandbridge cpu?
There definitely is, as mentioned above. There almost always is, I remember only one CPU without a chance and that was because the HW itself really didn't know the function. Unfortunately, sometimes (HW-dependant) it really has to be set in BIOS/UEFI. For some changes there are utilities, so you don't have to have physical access to the machine, but as seen from the capabilities, this is not your case.
Thank you.
----- Mensaje original -----
De: "Adrian Gibanel" <adrian.gibanel@btactic.com> Para: users@ovirt.org CC: "Itamar Heim" <iheim@redhat.com>, "Jithin Raju" <rajujith@gmail.com>, "Martin Kletzander" <mkletzan@redhat.com> Enviados: Sábado, 2 de Marzo 2013 17:21:43 Asunto: Re: [Users] ovirt reporting wrong cpu family (2nd server)
This is another server which I have also problems with. I cannot select SandyBridge as the cpu type. Still oVirt 3.1 in Fedora 17.
* Tecnology : Sandy Bridge E * CPU : Intel Xeon E5-1620 * Cores / Threads : 4 / 8 * Frecuency : 3.6GHz / 3.8GHz Turbo Boost
#cpuinfo: Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
# rpm -qa | grep -E 'vdsm|libvirt' | sort libvirt-0.9.11.9-1.fc17.x86_64 libvirt-client-0.9.11.9-1.fc17.x86_64 libvirt-daemon-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-network-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-nwfilter-0.9.11.9-1.fc17.x86_64 libvirt-lock-sanlock-0.9.11.9-1.fc17.x86_64 libvirt-python-0.9.11.9-1.fc17.x86_64 vdsm-4.10.0-10.fc17.x86_64 vdsm-cli-4.10.0-10.fc17.noarch vdsm-python-4.10.0-10.fc17.x86_64 vdsm-xmlrpc-4.10.0-10.fc17.noarch
# virsh -r capabilities
<capabilities> [...]
----- Mensaje original -----
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?
--
participants (3)
-
Adrian Gibanel -
Itamar Heim -
Martin Kletzander