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
Thank you for reporting this issue and verifying its fix.
I'm not completely sure that we should keep maintaining the ovirt-3.1
branch upstream - but a build destined for el6.4 must have it.
If you believe we should release a fix version for 3.1, please verify
that