Bug 842944 - vdsm judge cpu [i5-2400,3.1Ghz] to be Nehalem family
vdsm judge cpu [i5-2400,3.1Ghz] to be Nehalem family
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Kletzander
Depends On:
  Show dependency treegraph
Reported: 2012-07-24 23:13 EDT by Royce Lv
Modified: 2013-01-09 07:05 EST (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-02 05:12:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Royce Lv 2012-07-24 23:13:52 EDT
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):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Royce Lv 2012-07-24 23:25:27 EDT
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
Comment 2 Royce Lv 2012-07-29 02:58:13 EDT
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'/>
      <feature name='rdtscp'/>
      <feature name='avx'/>
      <feature name='osxsave'/>
      <feature name='xsave'/>
      <feature name='tsc-deadline'/>
      <feature name='x2apic'/>
      <feature name='pdcm'/>
      <feature name='xtpr'/>
      <feature name='tm2'/>
      <feature name='est'/>
      <feature name='smx'/>
      <feature name='vmx'/>
      <feature name='ds_cpl'/>
      <feature name='monitor'/>
      <feature name='dtes64'/>
      <feature name='pclmuldq'/>
      <feature name='pbe'/>
      <feature name='tm'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='acpi'/>
      <feature name='ds'/>
      <feature name='vme'/>

found it's judged to be Nehalem may because lack of "feature aes"
Comment 3 Martin Kletzander 2012-07-31 04:37:49 EDT
(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).
Comment 4 Itamar Heim 2012-07-31 08:18:22 EDT
strange, according to intel[1] it should have AES?
AES New Instructions: True

[1] http://ark.intel.com/products/52207
Comment 5 Martin Kletzander 2012-08-01 07:06:57 EDT
(In reply to comment #4)
Yes, it definitely should, but apparently the particular piece is not sharing this info with us through CPUID.
Comment 6 Royce Lv 2012-08-01 22:09:11 EDT
(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.
Comment 7 Martin Kletzander 2012-08-02 04:56:33 EDT
(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?

Comment 8 Martin Kletzander 2012-08-27 05:15:07 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.