Bug 1462072 - It shows 16 as a valid number of threads/core in RHV-M whereas the supported maximum is actually just 8
It shows 16 as a valid number of threads/core in RHV-M whereas the supported ...
Status: NEW
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt (Show other bugs)
x86_64 Linux
low Severity medium (vote)
: ovirt-4.3.0
: ---
Assigned To: bugs@ovirt.org
meital avital
Depends On:
  Show dependency treegraph
Reported: 2017-06-16 02:02 EDT by jiyan
Modified: 2017-10-25 06:20 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tjelinek: ovirt‑4.3+

Attachments (Terms of Use)

  None (edit)
Description jiyan 2017-06-16 02:02:35 EDT
Description of problem:
It shows 16 as a valid number of threads/core in RHV-M whereas the supported maximum is actually just 8.

Version-Release number of selected component (if applicable):
RHV-M server:

RHV-M register host:

How reproducible:

Steps to Reproduce:
1.In the RHV-M GUI, configure the data center with hosts and storage, then New a vm called vm1, confirm the vm can start successfully.
2.Edit the vm1, configure 'system' option with 'Total Virtual CPUs' equals 160, 'Virtual Sockets' equals 2, 'Cores per Virtual Socket' equals 5, then the value of 'Threads per Core' will generated automatically.

Actual results:
The value of 'Threads per Core' will be generated as 16 automatically.

Expected results:
The supported maximum value of 'Threads per Core' is just 8, it can not be generated as 16.

Additional info:
Comment 1 Red Hat Bugzilla Rules Engine 2017-06-16 02:07:30 EDT
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 2 Tomas Jelinek 2017-06-16 04:38:20 EDT
The reason is that the maximum values are considered only when the num of CPUs changes, but not when any of the fields below.
In other words, also the coresPerSocketChanged(), threadsPerCoreChanged() and numOfSocketChanged() on the VmModelBehaviorBase will need to be made aware of the maximums.

On the other hand, when the "Total Virtual CPUs" is edited only, the values are calculated properly in a way which is preferred. The other fields are hidden under the advanced settings so I don't think it is a common issue to hit.
Comment 3 Michal Skrivanek 2017-06-16 05:24:49 EDT
right, but regardless other places the max threads is just 8 and never 16. So wherever it is hardcoded to 16 we can just change to 8:)
Comment 4 Tomas Jelinek 2017-10-13 09:42:46 EDT
actually it is not hardcoded but calculated and the algorithm does not handle this maximums correctly in this particular case.

But it is a low priority - moving out of 4.2 due to capacity.

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