|
On 03/03/2014 10:44, Martin Kletzander
wrote:
Ok thanks Martin. If the amd64 and i386 versions of the package are behaving differently in this respect, on otherwise the same hardware, kernel and distro, then I can only presume this is a bug, so my next step would be to raise this on the development list.On Mon, Mar 03, 2014 at 10:30:11AM +0000, Struan Bartlett wrote:Hi Martin Thanks for your response. Here's the output of that grep: # grep ^flags /proc/cpuinfo | sort -u flags : 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 xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid I've just managed to install the libvirt-bin:amd64 package on the same machine, on the wheezy-i386 distribution. The output of 'virsh capabilities' is now reported correctly, and my VMs that required SandyBridge are now booting. Have you any further suggestions?Oh, I missed the fact that it was 32 bit distro. In that case, I guess some cpu features won't be available. No other ideas. MartinStruan On 03/03/2014 10:00, Martin Kletzander wrote:On Fri, Feb 28, 2014 at 03:45:01PM +0000, Struan Bartlett wrote:Hi On a range of Dell servers containing Intel 64bit processors, 'virsh capabilities' reports the cpu differently on Debian Wheezy-amd64 and Wheezy-i386. The results given by the Wheezy-i386 version seem very wrong (since n270 is an Atom processor). Apart from architecture, the package versions of libvirt-bin are identical: 1.2.1-1~bpo70+1. /usr/share/libvirt/cpu_map.xml files are identical. Is this a known issue? Details for one server are: # cat /proc/cpuinfo| head -n 26 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2650L 0 @ 1.80GHz stepping : 7 microcode : 0x70d cpu MHz : 1800.054 cache size : 20480 KB physical id : 0 siblings : 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : 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 xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 3600.10 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: ... </proc/cpuinfo for processors 1..31 snipped here for brevity>Check if all 32 CPUs have *exactly* the same flags, I remember an issue when we reported a wrong cpu because the probing code was scheduled on one of them which had one flag missing. If package and cpu_map.xml are the same, this is the only thing I can think of. Simple 'grep ^flags /proc/cpuinfo | sort -u' should do. If only one line is printed out than I don't know where the problem might be... Martin --
Struan Bartlett
The UK's #1 News Portal: Also tailored for Mobile: Now with FREE Personalisation: Bespoke B2B Internet News Monitoring: Bespoke B2B Headlines for Websites: NewsNow Publishing Limited, trading also as NewsNow.co.uk, is a company registered in England and Wales under company no. 3435857 with registered office The Euston Office, 1 Euston Square, 40 Melton Street, London NW1 2FD |
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
