Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1148039

Summary: When create vm NUMA node it useless to specify host numa node index
Product: [oVirt] ovirt-engine Reporter: Artyom <alukiano>
Component: RestAPIAssignee: Andrej Krejcir <akrejcir>
Status: CLOSED CURRENTRELEASE QA Contact: Artyom <alukiano>
Severity: medium Docs Contact:
Priority: medium    
Version: ---CC: akrejcir, alukiano, bazulay, bugs, dfediuck, lbopf, lsurette, mavital, rbalakri, Rhev-m-bugs, sherold, srevivo, ykaul
Target Milestone: ovirt-4.1.0-alphaKeywords: Triaged
Target Release: 4.1.0.2Flags: rule-engine: ovirt-4.1+
rule-engine: planning_ack+
dfediuck: devel_ack+
mavital: testing_ack+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
undefined
 Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-01 14:43:34 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:

Description Artyom 2014-09-30 14:50:44 UTC 
Description of problem:
When create vm NUMA node pinning it useless to specify host numa node index

Version-Release number of selected component (if applicable):
rhevm-3.5.0-0.13.beta.el6ev.noarch

How reproducible:
Always

Steps to Reproduce:
1. Create vm with numa node
2. Pin vm numa node to host numa node
3. <vm_numa_node>
<numa_node_pins>
<numa_node_pin pinned="true" index="2">
<host_numa_node id="host_numa_node_id"/>
</numa_node_pin>
</numa_node_pins>
</vm_numa_node>

Actual results:
if host_numa_node_id index=0 in result I will also have index=0 

Expected results:
Make possible to pin vm numa node without specify index

Additional info:
if I try <vm_numa_node>
<numa_node_pins>
<numa_node_pin pinned="true">
<host_numa_node id="host_numa_node_id"/>
</numa_node_pin>
</numa_node_pins>
</vm_numa_node>
I receive:


    <html><head><title>JBoss Web/7.4.8.Final-redhat-4 - JBWEB000064: Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>JBWEB000065: HTTP Status 500 - java.lang.ClassCastException: org.ovirt.engine.api.model.VirtualNumaNode cannot be cast to org.ovirt.engine.api.model.VM</h1><HR size="1" noshade="noshade"><p><b>JBWEB000309: type</b> JBWEB000066: Exception report</p><p><b>JBWEB000068: message</b> <u>java.lang.ClassCastException: org.ovirt.engine.api.model.VirtualNumaNode cannot be cast to org.ovirt.engine.api.model.VM</u></p><p><b>JBWEB000069: description</b> <u>JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.</u></p><p><b>JBWEB000070: exception</b> <pre>org.jboss.resteasy.spi.UnhandledException: java.lang.ClassCastException: org.ovirt.engine.api.model.VirtualNumaNode cannot be cast to org.ovirt.engine.api.model.VM
    org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:365)
    org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:233)
    org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:209)
    org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:557)
    org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
    org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
    org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
    org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
    org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
    org.ovirt.engine.core.aaa.filters.RestApiSessionMgmtFilter.doFilter(RestApiSessionMgmtFilter.java:69)
    org.ovirt.engine.core.aaa.filters.EnforceAuthFilter.doFilter(EnforceAuthFilter.java:39)
    org.ovirt.engine.core.aaa.filters.LoginFilter.doFilter(LoginFilter.java:73)
    org.ovirt.engine.core.aaa.filters.NegotiationFilter.doFilter(NegotiationFilter.java:112)
    org.ovirt.engine.core.aaa.filters.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:75)
    org.ovirt.engine.core.aaa.filters.SessionValidationFilter.doFilter(SessionValidationFilter.java:63)
    org.ovirt.engine.core.aaa.filters.RestApiSessionValidationFilter.doFilter(RestApiSessionValidationFilter.java:31)
    org.ovirt.engine.api.common.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:110)
    org.ovirt.engine.api.common.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:101)
    </pre></p><p><b>JBWEB000071: root cause</b> <pre>java.lang.ClassCastException: org.ovirt.engine.api.model.VirtualNumaNode cannot be cast to org.ovirt.engine.api.model.VM
    org.ovirt.engine.api.restapi.resource.BackendVmResource.update(BackendVmResource.java:85)
    sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    java.lang.reflect.Method.invoke(Method.java:606)
    org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
    org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
    org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
    org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
    org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
    org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
    org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
    org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
    org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
    org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
    org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
    org.ovirt.engine.core.aaa.filters.RestApiSessionMgmtFilter.doFilter(RestApiSessionMgmtFilter.java:69)
    org.ovirt.engine.core.aaa.filters.EnforceAuthFilter.doFilter(EnforceAuthFilter.java:39)
    org.ovirt.engine.core.aaa.filters.LoginFilter.doFilter(LoginFilter.java:73)
    org.ovirt.engine.core.aaa.filters.NegotiationFilter.doFilter(NegotiationFilter.java:112)
    org.ovirt.engine.core.aaa.filters.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:75)
    org.ovirt.engine.core.aaa.filters.SessionValidationFilter.doFilter(SessionValidationFilter.java:63)
    org.ovirt.engine.core.aaa.filters.RestApiSessionValidationFilter.doFilter(RestApiSessionValidationFilter.java:31)
    org.ovirt.engine.api.common.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:110)
    org.ovirt.engine.api.common.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:101)
    </pre></p><p><b>JBWEB000072: note</b> <u>JBWEB000073: The full stack trace of the root cause is available in the JBoss Web/7.4.8.Final-redhat-4 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.4.8.Final-redhat-4</h3></body></html>
Comment 2 Eyal Edri 2015-02-25 08:40:10 UTC 
3.5.1 is already full with bugs (over 80), and since none of these bugs were added as urgent for 3.5.1 release in the tracker bug, moving to 3.5.2
Comment 3 Eyal Edri 2015-04-28 11:22:07 UTC 
moving to 3.5.4 due to capacity planning for 3.5.3.
if you believe this should remain in 3.5.3, please sync with pm/dev/qe and a full triple ack for it. also - ensure priority is set accordingly.
Comment 4 Sandro Bonazzola 2015-10-26 12:39:08 UTC 
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015.
Please review this bug and if not a blocker, please postpone to a later release.
All bugs not postponed on GA release will be automatically re-targeted to

- 3.6.1 if severity >= high
- 4.0 if severity < high
Comment 5 Roy Golan 2015-11-04 08:41:49 UTC 
Why do we want to support the host numa node id? This id is strictly logical and
made up by the engine and this abstraction is useless. I'd like to remove it 
from our code and use index only.
Comment 6 Doron Fediuck 2015-12-21 16:13:24 UTC 
We can consider it for 4.0.
Comment 7 Mike McCune 2016-03-28 22:14:36 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 8 Sandro Bonazzola 2016-05-02 09:57:10 UTC 
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Comment 9 Yaniv Lavi 2016-05-23 13:18:26 UTC 
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 10 Yaniv Lavi 2016-05-23 13:25:17 UTC 
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 11 Andrej Krejcir 2016-06-15 13:53:27 UTC 
The host numa node id in the pinning is not used anywhere in the code. It is probably a leftover. We could easily remove it.
Is this bug still relevant?
Comment 12 Artyom 2016-06-15 14:06:14 UTC 
rhevm-4.0.0.4-0.1.el7ev.noarch
When I try to pin VNUMA node to host NUMA node without specifiying the index:
<vm_numa_node>
<numa_node_pins>
<numa_node_pin pinned="true">
<host_numa_node id="f1e671bd-4ddf-41b9-9805-ebd84c5a0072"/>
</numa_node_pin>
</numa_node_pins>
</vm_numa_node>

I receive:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<fault>
    <reason>Operation Failed</reason>
    <detail>[NUMA node pinned index error.]</detail>
</fault>

So looks like bug is still relevant.
Comment 13 Artyom 2016-06-15 14:40:03 UTC 
If I send update without <host_numa_node id="f1e671bd-4ddf-41b9-9805-ebd84c5a0072"/>
Update works fine, so I believe it also good, that we can send only host NUMA node index without specifiyng id.
Comment 14 Andrej Krejcir 2016-08-23 15:35:02 UTC 
I think it is better to remove the id from numa node pinning and leave only the index. The id is not used anywhere, only stored in the db.
Comment 15 Doron Fediuck 2016-09-07 11:10:36 UTC 
Since this never worked, we'll remove it in 4.1 and leave place holder for compatibility.
Comment 16 Sandro Bonazzola 2016-12-12 14:02:24 UTC 
The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified.
Comment 17 Artyom 2016-12-13 14:31:55 UTC 
Verified on ovirt-engine-setup-plugin-ovirt-engine-4.1.0-0.2.master.20161212172238.gitea103bd.el7.centos.noarch

PUT request:
<vm_numa_node>
<numa_node_pins>
<numa_node_pin>
<index>0</index>
</numa_node_pin>
</numa_node_pins>
</vm_numa_node>

Works fine