Bug 1279178
| Summary: | Allow NUMA VMs topology without host pinning | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Artyom <alukiano> | ||||
| Component: | Backend.Core | Assignee: | Roman Mohr <rmohr> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Artyom <alukiano> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.6.0.2 | CC: | alukiano, amarchuk, bugs, dfediuck, dyuan, lhuang, mgoldboi, rgolan, xuzhang, ylavi | ||||
| Target Milestone: | ovirt-3.6.3 | Keywords: | Triaged | ||||
| Target Release: | 3.6.3 | Flags: | rule-engine:
ovirt-3.6.z+
rule-engine: exception+ mgoldboi: planning_ack+ dfediuck: devel_ack+ mavital: testing_ack+ |
||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| 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 07:23:27 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | SLA | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1265953, 1289967 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
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. Possibly not a bug, if alma is the NUMA server ( I see master is currently highlighted) Artyom can you confirm? No, master-vds10.qa.lab.tlv.redhat.com NUMA server and alma07.qa.lab.tlv.redhat.com not NUMA server. Thanks 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" ? Done 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. 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. 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. 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. 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. 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. Still POST only. the other patch sets were just preparations/cleanups. 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. 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. 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. 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. 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. 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? (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. 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? Checked on rhevm-backend-3.6.3.2-0.1.el6.noarch 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 |
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: