Bug 842944

Summary: vdsm judge cpu [i5-2400,3.1Ghz] to be Nehalem family
Product: [Community] Virtualization Tools Reporter: Royce Lv <lvroyce>
Component: libvirtAssignee: Martin Kletzander <mkletzan>
Status: CLOSED NOTABUG QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: abaron, acathrow, amit.shah, bazulay, berrange, cfergeau, dallan, dwmw2, dyasny, iheim, itamar, knoel, mgoldboi, pbonzini, rjones, scottt.tw, virt-maint, ykaul
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-02 09:12:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Royce Lv 2012-07-25 03:13:52 UTC
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:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Royce Lv 2012-07-25 03:25:27 UTC
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 06:58:13 UTC
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:
<capabilities>

  <host>
    <uuid>f5cccac4-5498-6b0e-8bad-9a4a17a8bc76</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Nehalem</model>
      <vendor>Intel</vendor>
      <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'/>
    </cpu>

found it's judged to be Nehalem may because lack of "feature aes"

Comment 3 Martin Kletzander 2012-07-31 08:37:49 UTC
(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 12:18:22 UTC
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 11:06:57 UTC
(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-02 02:09:11 UTC
(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.

Martin,
  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 08:56:33 UTC
(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?

Thanks,
Martin

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