Bug 1144833 - AddVmFromScratchCommand can Fail to create a new Vm when executed from rest-api,py-sdk
Summary: AddVmFromScratchCommand can Fail to create a new Vm when executed from rest-a...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: 3.5.0
Assignee: Omer Frenkel
QA Contact: Ori Gofen
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-21 11:45 UTC by Ori Gofen
Modified: 2016-05-26 01:50 UTC (History)
14 users (show)

Fixed In Version: org.ovirt.engngine-root-3.5.0-17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 08:26:56 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
vdsm+engine logs (1.46 MB, application/octet-stream)
2014-09-21 11:45 UTC, Ori Gofen
no flags Details
vdsm+engine logs (981.41 KB, application/x-gzip)
2014-09-23 14:15 UTC, Ori Gofen
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 34156 0 master MERGED core: validate storage pool on add vm Never
oVirt gerrit 34158 0 ovirt-engine-3.5 ABANDONED core: validate storage pool on add vm Never
oVirt gerrit 34166 0 master MERGED core: validate storage pool on add vm Never
oVirt gerrit 34168 0 ovirt-engine-3.5 MERGED core: validate storage pool on add vm Never

Description Ori Gofen 2014-09-21 11:45:07 UTC
Created attachment 939732 [details]
vdsm+engine logs

Description of problem:
When having a domain which his DC was removed twice(both times the domain had entities that was created)

py-sdk fail to execute the creation VM script for the third time.

from engine's log:
2014-09-21 14:21:01,015 ERROR [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (ajp-/127.0.0.1:8702-3) [616cb1bd] Error during CanDoActionFailure.: org.ov
   ...at org.ovirt.engine.core.bll.CommandBase.internalValidateAndSetQuota(CommandBase.java:792) [bll.jar:]
   ...at org.ovirt.engine.core.bll.CommandBase.internalCanDoAction(CommandBase.java:743) [bll.jar:]
   ...at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:338) [bll.jar:]
   ...at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:430) [bll.jar:]
   ...at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:411) [bll.jar:]
   ...at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:369) [bll.jar:]
   ...at sun.reflect.GeneratedMethodAccessor482.invoke(Unknown Source) [:1.7.0_65]
   ...at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
   ...at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
   ...at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) [jboss-as-ee.jar:7.4.0.Final-
   ...at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) [jboss-as-ee.jar:7.4.0.Final-redhat-
   ...at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:74) [jboss-as-weld.jar:7.4.0.Final-redhat-19]
   ...at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:84) [jboss-as-weld.jar:7.4.0.Final-redhat-19]
   ...at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:97) [jboss-as-weld.jar:7.4.0.Final-redhat-19]
   ...at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) [jboss-as-ee.jar:7.4.0.Final-redhat-
   ...at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.ovirt.engine.core.bll.interceptors.ThreadLocalSessionCleanerInterceptor.injectWebContextToThreadLocal(ThreadLocalSessionCleanerInterceptor.java:13
   ...at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) [:1.7.0_65]
   ...at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
   ...at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
   ...at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) [jboss-as-e
   ...at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) [jboss-as-ee.jar:7.4.0.Final-redhat-
   ...at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3.jar:7.4.0.Fi
   ...at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.2.Final-redhat-1]
   ...at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:93) [jboss-as-weld.jar:7.4.0.Fi
   ...at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.2.Final-redhat-1]


when attempting to create those vm's via UI,operation is successful.

Version-Release number of selected component (if applicable):
vt3.1

How reproducible:
100%

Steps to Reproduce:

*** have OvfUpdateIntervalInMinutes set to one minute ***

1.have a dc with block domain(I had an iscsi domain)
2.create ten vm's with py-sdk script(call the vm's "vm_0,vm_1...vm_9"
3.remove the dc,create a new dc and attach the domain,repeat step 2(do not import any entities)
4.repeat step 3,then execute the same script

Actual results:
for the third times,the action fails

Expected results:
operation should be successful.

Additional info:

Comment 1 Juan Hernández 2014-09-22 08:35:40 UTC
The fist line of the exception is the following:

2014-09-21 14:24:13,406 ERROR [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (ajp-/127.0.0.1:8702-11) [7fff4a68] Error during CanDoActionFailure.: org.ovirt.engine.core.bll.quota.InvalidQuotaParametersException: Command: org.ovirt.engine.core.bll.AddVmFromScratchCommand. Storage pool is not available for quota calculation.
        at org.ovirt.engine.core.bll.CommandBase.internalValidateAndSetQuota(CommandBase.java:792) [bll.jar:]

So it looks like a backend quota issue.

Comment 2 Nikolai Sednev 2014-09-22 16:01:25 UTC
I need the script itself to be attached to this bug, plus some info on how to execute it with some steps.

Comment 3 Ori Gofen 2014-09-23 14:15:17 UTC
Created attachment 940462 [details]
vdsm+engine logs

reproduced again **note** ovf errors are different bug.
*the script that I used is attached at the earlier upload (crVm.py).

steps:
1.create dc with block domain
2.execute the script.
3.maintain the domain,remove the dc
4.create new dc,new cluster,add new host
5.re-attach the domain to the new dc
6.execute script
repeat 3-6

Comment 4 Gilad Chaplik 2014-10-14 12:42:10 UTC
The added VM selected cluster is orphan (not attached to any data center), and the addVM command CanDoAction doesn't block it. the UI filters out orphan clusters, so it's not reproducible there, which isn't the case for REST.

moving to virt.

Comment 5 Nikolai Sednev 2014-10-22 12:33:18 UTC
Hi Ori,
As I'm not the automation engineer, may you provide some way of reproduction of this bug and attach the script you're used?

Comment 6 Nikolai Sednev 2014-10-22 14:34:40 UTC
Forwarding this one to storage team as Ori have script and relevant iSCSI SD, plus he opened a bug and knows the best practice of reproduction.
Please make me know if my help is required, I'll do my best to assist.

Comment 7 Ori Gofen 2014-10-26 09:34:08 UTC
verified on vt7

Comment 8 Omer Frenkel 2015-02-17 08:26:56 UTC
RHEV-M 3.5.0 has been released


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