Bug 1275088

Summary:	Intel Core i7 4790k (Haswell, Devil's Canyon) CPU not properly detected
Product:	[oVirt] ovirt-engine	Reporter:	fdinoto
Component:	BLL.Virt	Assignee:	Michal Skrivanek <michal.skrivanek>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Nisim Simsolo <nsimsolo>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.4.0	CC:	bugs, fdinoto, jdenemar, jsuchane, mavital, tjelinek
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:	2016-04-13 06:46:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description fdinoto 2015-10-25 19:22:55 UTC

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 20:41:33 UTC

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-26 01:23:48 UTC

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'/> -->
    </model>

Comment 3 Michal Skrivanek 2016-01-29 12:36:45 UTC

do we(you) need a new CPU definition?

Comment 4 Jaroslav Suchanek 2016-01-29 16:10:27 UTC

(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, please provide also exact versions of used components, specifically libvirt in this case. Thanks.

Comment 5 Jiri Denemark 2016-01-29 20:51:17 UTC

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 14:53:16 UTC

any news? otherwise closing as working in 3.6

Comment 7 Tomas Jelinek 2016-04-13 06:46:43 UTC

The Haswell-noTSX has been added to libvirt in centos 7.2 -> closing as currentrelease