On 05.03.2013 11:14, Dan Kenigsberg wrote: <snip> >>>> >>>> My version of vdsm as stated by Dreyou: >>>> v 4.10.0-0.46 (.15), builded from >>>> b59c8430b2a511bcea3bc1a954eee4ca1c0f4861 (branch ovirt-3.1) >>>> >>>> I can't see that Ia241b09c96fa16441ba9421f61a2f9a417f0d978 was merged to >>>> 3.1 Branch? >>>> >>>> I applied that patch locally and restarted vdsmd but this does not >>>> change anything. Supported cpu is still as low as Conroe instead of >>>> Nehalem. Or is there more to do than patching libvirtvm.py? >>> >>> What is libvirt's opinion about your cpu compatibility? >>> >>> virsh -r cpu-compare <(echo '<cpu match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') >>> >>> If you do not get "Host CPU is a superset of CPU described in bla", then >>> the problem is within libvirt. >>> >>> Dan. >> >> Hi Dan, >> >> virsh -r cpu-compare <(echo '<cpu >> match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') >> Host CPU is a superset of CPU described in /dev/fd/63 >> >> So libvirt obviously is fine. Something different would have surprised >> my as virsh capabilities seemed correct anyway. > > So maybe, just maybe, libvirt has changed their cpu_map, a map that > ovirt-3.1 had a bug reading. > > Would you care to apply http://gerrit.ovirt.org/5035 to see if this is > it? > > Dan. Hi Dan, success! Applying that patch made the cpu recognition work again. The cpu type in admin portal shows again as Nehalem. Output from getVdsCaps: cpuCores = 4 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,xtopology,nonstop_tsc, aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2, ssse3,cx16,xtpr,pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida, dts,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem, model_Conroe,model_coreduo,model_core2duo,model_Penryn, model_n270 cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz cpuSockets = 1 cpuSpeed = 2393.769 I compared libvirt's cpu_map.xml on both Centos 6.3 and CentOS 6.4 and indeed they do differ in large portions. So this patch should probably be merged to 3.1 branch? I will contact Dreyou and request that this patch will also be included in his builds. I guess otherwise there will be quite some fallout after people start picking CentOS 6.4 for oVirt 3.1. Thanks again and best regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich