Bug 1144833
| Summary: | AddVmFromScratchCommand can Fail to create a new Vm when executed from rest-api,py-sdk | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ori Gofen <ogofen> | ||||||
| Component: | ovirt-engine | Assignee: | Omer Frenkel <ofrenkel> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ori Gofen <ogofen> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 3.5.0 | CC: | acanan, ecohen, gklein, iheim, juan.hernandez, lpeer, lsurette, mavital, michal.skrivanek, ogofen, rbalakri, Rhev-m-bugs, sherold, yeylon | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | 3.5.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | virt | ||||||||
| Fixed In Version: | org.ovirt.engngine-root-3.5.0-17 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-02-17 08:26:56 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
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.
I need the script itself to be attached to this bug, plus some info on how to execute it with some steps. 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
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. 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? 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. verified on vt7 RHEV-M 3.5.0 has been released |
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: