Bug 1462072 - It shows 16 as a valid number of threads/core in RHV-M whereas the supported maximum is actually just 8
Summary: It shows 16 as a valid number of threads/core in RHV-M whereas the supported ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.1.3.2
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-16 06:02 UTC by jiyan
Modified: 2022-06-27 07:31 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-03 12:49:46 UTC
oVirt Team: Virt
Embargoed:
sbonazzo: ovirt-4.3-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-46516 0 None None None 2022-06-27 07:31:04 UTC

Description jiyan 2017-06-16 06:02:35 UTC
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:
rhevm-4.1.3.2-0.1.el7.noarch

RHV-M register host:
qemu-kvm-rhev-2.9.0-9.el7.x86_64
libvirt-3.2.0-9.el7.x86_64
kernel-3.10.0-679.el7.x86_64
vdsm-4.19.18-1.el7ev.x86_64


How reproducible:
100%


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 06:07:30 UTC
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 08:38:20 UTC
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 09:24:49 UTC
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 13:42:46 UTC
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.

Comment 5 Ryan Barry 2019-01-03 12:49:46 UTC
This will not be addressed in a reasonable timeframe. Please re-open if it's still important.


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