Bug 1462072
Summary: | It shows 16 as a valid number of threads/core in RHV-M whereas the supported maximum is actually just 8 | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | jiyan <jiyan> |
Component: | BLL.Virt | Assignee: | bugs <bugs> |
Status: | CLOSED WONTFIX | QA Contact: | meital avital <mavital> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 4.1.3.2 | CC: | bugs, dyuan, jiyan, lmen, lsurette, michal.skrivanek, Rhev-m-bugs, srevivo, tjelinek, xuzhang, ykaul |
Target Milestone: | --- | Flags: | sbonazzo:
ovirt-4.3-
|
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-01-03 12:49:46 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
jiyan
2017-06-16 06:02:35 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. 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. 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:) 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. This will not be addressed in a reasonable timeframe. Please re-open if it's still important. |