On Tue, Mar 05, 2013 at 12:32:31PM +0100, Patrick Hurrelmann wrote: > 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 http://gerrit.ovirt.org/12723 has no ill effects. Dan. _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
