Bug 1279178 - Allow NUMA VMs topology without host pinning
Allow NUMA VMs topology without host pinning
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core (Show other bugs)
3.6.0.2
x86_64 Linux
medium Severity medium (vote)
: ovirt-3.6.3
: 3.6.3
Assigned To: Roman Mohr
Artyom
: Triaged
Depends On: 1265953 1289967
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-08 07:36 EST by Artyom
Modified: 2016-03-11 02:23 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Backend did not check if a a host has a NUMA architecture when manipulating the VMs NUMA topology. Consequence: It was possible to add and modify virtual NUMA topologies on in VMs which where supposed to run on a host without NUMA topology. Fix: Always check in the related commands if the selected host supports numa. This ensures consistent validation results for UI and REST. Result: Backend only allows the execution of NUMA related commands through UI or REST when the host where a VM is pinned to has a NUMA architecture.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-11 02:23:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: SLA
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑3.6.z+
rule-engine: exception+
mgoldboi: planning_ack+
dfediuck: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)
screenshot (61.24 KB, image/png)
2015-11-08 07:36 EST, Artyom
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 48719 master MERGED core: Return empty list if no VM numa nodes are present Never
oVirt gerrit 48720 master MERGED core: Refactor NUMA node validation Never
oVirt gerrit 49056 ovirt-engine-3.6 MERGED core: Return empty list if no VM numa nodes are present Never
oVirt gerrit 49149 ovirt-engine-3.6.1 MERGED core: Return empty list if no VM numa nodes are present Never
oVirt gerrit 49163 ovirt-engine-3.6 MERGED core: Refactor NUMA node validation Never
oVirt gerrit 51380 master MERGED webadmin: Fix check if selected dedicated host supports NUMA 2016-01-12 08:45 EST
oVirt gerrit 51629 master MERGED core: Add check to validator if host has a NUMA architecture 2016-01-14 07:13 EST
oVirt gerrit 51640 ovirt-engine-3.6 MERGED webadmin: Fix check if selected dedicated host supports NUMA 2016-01-14 09:18 EST
oVirt gerrit 51641 ovirt-engine-3.6 MERGED core: Add check to validator if host has a NUMA architectur 2016-01-14 09:19 EST

  None (edit)
Description Artyom 2015-11-08 07:36:17 EST
Created attachment 1091259 [details]
screenshot

Description of problem:
Have two hosts in cluster, the first with NUMA support and the second one without, so when I pin vm to host with NUMA support I must have possibility to add NUMA node to vm and also pin it to physical NUMA node, but all fields connect to NUMA configuration remain closed.

Version-Release number of selected component (if applicable):
rhevm-3.6.0.3-0.1.el6.noarch

How reproducible:
Always

Steps to Reproduce:
1. Add two hosts to cluster, one with NUMA support and other without.
2. Create vm and pin it to host with NUMA support
3. Try to add NUMA node to vm

Actual results:
NUMA configuration fields remain closed

Expected results:
If I pin vm to host with NUMA support all NUMA configuration fields must be open and editable.

Additional info:
Comment 1 Red Hat Bugzilla Rules Engine 2015-11-15 04:57:05 EST
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 2 Roy Golan 2015-11-15 04:57:37 EST
Possibly not a bug, if alma is the NUMA server ( I see master is currently highlighted)

Artyom can you confirm?
Comment 3 Artyom 2015-11-15 07:01:00 EST
No, master-vds10.qa.lab.tlv.redhat.com NUMA server and alma07.qa.lab.tlv.redhat.com not NUMA server.
Thanks
Comment 4 Roy Golan 2015-11-16 03:21:47 EST
So obviously the options are blocked because you have >1 server in the dropdown. 
We currently ban that. We want to make a change of behaviour and let users do Numa without host pinning constraint (its supported by underlying layers).
 So lets use this bug. Can you change the description to "Allow NUMA VMs topology without host pinning" ?
Comment 5 Artyom 2015-11-16 03:56:45 EST
Done
Comment 6 Red Hat Bugzilla Rules Engine 2015-11-16 04:32:15 EST
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 7 Red Hat Bugzilla Rules Engine 2015-11-16 04:32:15 EST
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 8 Red Hat Bugzilla Rules Engine 2015-11-16 05:00:27 EST
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 9 Red Hat Bugzilla Rules Engine 2015-12-02 05:21:22 EST
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 11 Roman Mohr 2015-12-14 03:54:52 EST
More detailed way to reproduce the issue:

1) Create a host with numa support and a host without numa support
2) Make sure that the host without numa support is before the host without support in all lists (e.g. name host without numa 'A' and the other host 'B")
3) Try to configure NUMA from the VM configuration sceen.


This is not possible then because the first host in the dedicated host list field has no NUMA support and the frontend checks only the first host for numa support.
Comment 14 Red Hat Bugzilla Rules Engine 2015-12-16 16:35:54 EST
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 15 Roman Mohr 2016-01-14 09:26:05 EST
Still POST only. the other patch sets were just preparations/cleanups.
Comment 16 Roman Mohr 2016-01-27 05:31:09 EST
The expected result is now given. Note that you still only can create numa nodes when there is more than one numa node on the host.
Comment 17 Red Hat Bugzilla Rules Engine 2016-01-28 07:16:14 EST
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Comment 18 Red Hat Bugzilla Rules Engine 2016-01-28 07:24:56 EST
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Comment 19 Red Hat Bugzilla Rules Engine 2016-01-28 07:29:13 EST
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Comment 20 Roman Mohr 2016-02-10 10:42:01 EST
I just saw the selection box for preferred hosts in the VM edit screen still has issues. See https://bugzilla.redhat.com/1265953 for details. This patch fixes REST and the backend logic.
Comment 21 Roy Golan 2016-02-22 03:08:23 EST
Artyom, both Bug 1265953 ad Bug 1289967 are UI bugs so they do not block the verification of this bug/. I think you can remove the "depends on" and continute with REST?
Comment 22 Roman Mohr 2016-02-22 04:35:21 EST
(In reply to Roy Golan from comment #21)
> Artyom, both Bug 1265953 ad Bug 1289967 are UI bugs so they do not block the
> verification of this bug/. I think you can remove the "depends on" and
> continute with REST?

Yes you can test this with REST. Also even if the UI accepts some wrong variations because of Bug 1265953, the backend should still not allow them.
Comment 23 Artyom 2016-02-22 05:03:07 EST
I tried to assign NUMA node to VM that pinned to host without NUMA architecture via REST and looks like problem not only in the UI, but also in the backend:

Request:
<vm_numa_node>
<index>0</index>
<memory>1024</memory>
<cpu>
<cores>
<core index="0" />
</cores>
</cpu>
</vm_numa_node>

Answer:
<fault>
<reason>Operation Failed</reason>
<detail>[Host has no NUMA architecture]</detail>
 </fault>

so I can move this bug to ASSIGNED or just wait until all dependencies will be fixed.
What do you prefer?
Comment 24 Artyom 2016-02-22 05:04:33 EST
Checked on rhevm-backend-3.6.3.2-0.1.el6.noarch
Comment 25 Artyom 2016-02-22 05:27:38 EST
Verified on rhevm-backend-3.6.3.2-0.1.el6.noarch
So after discussion with Roman:
1) we block add VNUMA node to vm that pinned to non-NUMA host
2) we allow add VNUMA node to vm that pinned to NUMA host

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