Bug 1408584

Was it there in the past?
'Could be nice to add it' sounds like a RFE to me?

I see this using latest master and version 4 of the API:

  <cpu>
    <name>Intel Core Processor (Skylake)</name>
    <speed>2808</speed>
    <topology>
      <cores>1</cores>
      <sockets>1</sockets>
      <threads>1</threads>
    </topology>
  </cpu>

Also with version 3 of the API, but a bit different:

  <cpu>
    <topology sockets="1" cores="1" threads="1"/>
    <name>Intel Core Processor (Skylake)</name>
    <speed>2808</speed>
  </cpu>

Is that what you are looking for? Isn't it reported in your environment?

Note also that there is an small chance that the information isn't reported, if the GetCapabilities VDS command hasn't been executed for that host yet.

(In reply to Juan Hernández from comment #2)
> I see this using latest master and version 4 of the API:
> 
>   <cpu>
>     <name>Intel Core Processor (Skylake)</name>
>     <speed>2808</speed>
>     <topology>
>       <cores>1</cores>
>       <sockets>1</sockets>
>       <threads>1</threads>
>     </topology>
>   </cpu>
> 
> Also with version 3 of the API, but a bit different:
> 
>   <cpu>
>     <topology sockets="1" cores="1" threads="1"/>
>     <name>Intel Core Processor (Skylake)</name>
>     <speed>2808</speed>
>   </cpu>
> 
> Is that what you are looking for? Isn't it reported in your environment?
> 
> Note also that there is an small chance that the information isn't reported,
> if the GetCapabilities VDS command hasn't been executed for that host yet.

I have a setup with 4 hosts, I refreshed capabilities as well. I think the thing is that on some cpus the name includes the type but for some it doesn't. I Have 2 Opeteron G1 hosts, 1 penryn and 1 sandyBridge. What I see in api under <cpu><name> is:

<name>Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz</name>
<name>Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz</name>
<name>AMD Opteron(tm) Processor 4170 HE</name>
<name>AMD Opteron(tm) Processor 4170 HE</name>

These values corresponds to the cpuModel value that is returned in getVdsCaps cmd, but the thing is that there is some inconsistencies in the system in all that concerns cpu type values.
e.g. in cluster the value would be 'Intel Conroe Family', on vm level (if you want to pass custom_cpu_model e.g.) it would be 'intel_Conroe' or just 'Conroe'.
Maybe we can add another sub-attribute that specifies the model family, or passes the highest model from cpuFlags list?

I will change the bug to an RFE as Yaniv suggests.

Targeting this due to the CPU deprecations

The CPU Type has now been added to the REST API's cpu section:

<cpu>
<name>Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz</name>
<speed>3900</speed>
<topology>
<cores>4</cores>
<sockets>1</sockets>
<threads>2</threads>
</topology>
<type>Intel Haswell-noTSX IBRS SSBD Family</type>
</cpu>

Verified on ovirt-engine-4.3.0-0.6.alpha2.el7.noarch

This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

Steven, I edited the doc text. Is this accurate:

Previously the REST API did not include the CPU Type when it returned information about the host. Now, the CPU Type is part of the information about the host that the REST API returns, consistent with the Administration Portal.

It is OK, I might say: 

Now, the CPU Type is included with the rest of the information concerning the host that the REST API returns which is consistent with the Administration Portal.