Red Hat Bugzilla – Bug 842944
vdsm judge cpu [i5-2400,3.1Ghz] to be Nehalem family
Last modified: 2013-01-09 07:05:37 EST
Description of problem:
add a i5-2400 machine to a sandybridge cluster results in error of cpu imcompatibility.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
turns out to be libvirt virConnectCompareCPU returns Nehalem family,
/usr/bin/qemu-system-x86_64 -cpu ? returns to be Nehalam compatible
So it's a qemu bug
we add qemu patch for support of Sandy Bridge, but found libvirt Capabilities problem remains, So I beleive we still need to fix libvirt for this:
the output of the i5-2400 machine:
<topology sockets='1' cores='4' threads='1'/>
found it's judged to be Nehalem may because lack of "feature aes"
(In reply to comment #2)
According to the output, the processor really doesn't support AES. The feature is probably missing from /proc/cpuinfo as well, I guess. If you want to add this machine to the cluster (even though its processor doesn't have AES), the appropriate place would be handling it in upper layer (vdsm, oVirt). Either by allowing this model to be added there (which could cause a problem in case the feature gets used on the machine) or making the cluster as a 'SandyBridge,-aes' cluster (which would disable the AES on all machines and guests).
strange, according to intel it should have AES?
AES New Instructions: True
(In reply to comment #4)
Yes, it definitely should, but apparently the particular piece is not sharing this info with us through CPUID.
(In reply to comment #5)
> (In reply to comment #4)
> Yes, it definitely should, but apparently the particular piece is not
> sharing this info with us through CPUID.
You're right , I checked the /proc/cpuinfo, no aes exposed.And calling cpuid with EAX=1,ECX=0X1dbae3ff,no aes support.
I'm a little concerned to make our users confused by introducing cluster "SandyBridge, -aes".Guess we need to turn to Intel guys about this.
(In reply to comment #6)
That would be probably the best option. I suggested it just as a one of the options in case you really want to have this CPU in the cluster and the time is pressing you.
On the other hand, I'm relieved it's not our fault, thanks for the cooperation. Is it ok with you if I close this bug (in order to keep our queues clean) as a NOTABUG?
(In reply to comment #6)
This is a wild guess, but I've remembered that somebody else got to the similar issue as you did and solved it with enabling the NX bit in BIOS. This of course doesn't change the status nor the resolution.
Hope this helps, have a nice day.