Bug 1275088 - Intel Core i7 4790k (Haswell, Devil's Canyon) CPU not properly detected [NEEDINFO]
Intel Core i7 4790k (Haswell, Devil's Canyon) CPU not properly detected
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Michal Skrivanek
Nisim Simsolo
Depends On:
  Show dependency treegraph
Reported: 2015-10-25 15:22 EDT by fdinoto
Modified: 2016-04-13 02:46 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-04-13 02:46:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jdenemar: needinfo? (fdinoto)
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

  None (edit)
Description fdinoto 2015-10-25 15:22:55 EDT
Building oVirt lab, engine/host on single system. CentOS 7.1

Defined a datacenter with CPU-type "Haswell" for my host with an i7 4790k CPU. The 4790 CPU is Haswell but the 4790k is named "Devil's Canyon". I assumed this was simply an unlocked Haswell CPU.

But I get error ID 515:
Host moved to Non-Operational state as host does not meet the cluster's minimum CPU level. Missing CPU features : model_Haswell

Is this a bug? Is there a workaround?
Comment 1 fdinoto 2015-10-25 16:41:33 EDT
I made another datacenter/cluster, this time of cpu-type Sandybridge. I was able to add the host to the cluster, but now virtual machines will not start. 

"VM c7-1 is down with error. Exit message: internal error: Cannot find suitable CPU model for given data."

I assume this is because the virtual machines are seeing the CPUs as Haswell and are expecting Sandybridge because of the cluster definition.
Comment 2 fdinoto 2015-10-25 21:23:48 EDT
I guess this is not a bug the 'K'(Devil's Canyon) designated Haswell CPUs have some features disabled. http://ark.intel.com/compare/75122,80806,80807

I have not correlated the features listed in the Intel docs to the flags in /proc/cpuinfo, but I was able to work around the issue using these settings in /usr/share/libvirt/cpu_map.xml:

    <model name='Haswell'>
      <model name='SandyBridge'/>
      <feature name='fma'/>
      <feature name='pcid'/>
      <feature name='movbe'/>
      <feature name='fsgsbase'/>
      <feature name='bmi1'/>
      <!-- <feature name='hle'/> -->
      <feature name='avx2'/>
      <feature name='smep'/>
      <feature name='bmi2'/>
      <feature name='erms'/>
      <feature name='invpcid'/>
      <!-- <feature name='rtm'/> -->
Comment 3 Michal Skrivanek 2016-01-29 07:36:45 EST
do we(you) need a new CPU definition?
Comment 4 Jaroslav Suchanek 2016-01-29 11:10:27 EST
(In reply to Michal Skrivanek from comment #3)
> do we(you) need a new CPU definition?

Probably not, as the definition from comment 2 corresponds to Haswell-noTSX. Jirka can you please confirm? But this might be present in rhel-7.2 (centos 7.2) though. Thanks.

To fdinoto@gmail.com, please provide also exact versions of used components, specifically libvirt in this case. Thanks.
Comment 5 Jiri Denemark 2016-01-29 15:51:17 EST
Yeah, the CPU is apparently Haswell-noTSX, which was added in 7.2. SandyBridge should work from libvirt's point of view. Just to be sure, could you provide "virsh capabilities" output (in addition to the libvirt version used)?
Comment 6 Michal Skrivanek 2016-03-24 10:53:16 EDT
any news? otherwise closing as working in 3.6
Comment 7 Tomas Jelinek 2016-04-13 02:46:43 EDT
The Haswell-noTSX has been added to libvirt in centos 7.2 -> closing as currentrelease

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