[jira] [Commented] (CLOUDSTACK-6938) Cannot create template from snapshot when using S3 storage

2014-06-21 Thread Daan Hoogland (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039982#comment-14039982
 ] 

Daan Hoogland commented on CLOUDSTACK-6938:
---

I submitted your patch as 736bf540e8ef759a101d221622c64f3b3c3ed425. next time 
please start your commit comment with the issue id (CLOUDSTACK-6938 in this 
case) so the link gets added automatically. I should have been looking for that 
as well by the way, sorry.

> Cannot create template from snapshot when using S3 storage
> --
>
> Key: CLOUDSTACK-6938
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6938
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.4.0
> Environment: KVM + S3 Secondary Storage
>Reporter: Logan B
>Priority: Critical
> Fix For: 4.4.0
>
>
> When trying to create a template from a snapshot with S3 secondary storage, 
> the command immediately fails with a NullPointerException.
> This appears to only happen when there is a pre-existing snapshot folder in 
> the NFS staging store.  This indicates that there is something wrong with the 
> copy command (e.g., it's using 'mkdir' instead of 'mkdir -p').
> The issue can be worked around by deleting the existing snapshot folder on 
> the staging store every time you want to create a new template.  This is 
> obviously not viable for end users.
> This issue should be fixed before 4.4 ships because it should be a stupid 
> simple thing to correct, but completely breaks restoring snapshots for end 
> users.  Waiting for 4.5 would be far too long for an issue like this.
> 2014-06-18 21:13:54,789 DEBUG [cloud.agent.Agent] 
> (agentRequest-Handler-2:null) Processing command: 
> org.apache.cloudstack.storage.command.CopyCommand
> 2014-06-18 21:13:54,789 INFO  [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:null) Determined host 172.16.48.99 corresponds to IP 
> 172.16.48.99
> 2014-06-18 21:13:54,797 ERROR [storage.resource.NfsSecondaryStorageResource] 
> (agentRequest-Handler-2:null) Unable to create directory 
> /mnt/SecStorage/6b9bdec9-fdc9-3fdd-a5f8-0481df177ae8/snapshots/2/25 to copy 
> from S3 to cache.
> I'm guessing it's an issue with the mkdirs() function in the code, but I've 
> been unable to find it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail

2014-06-21 Thread Simon Weller (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Weller updated CLOUDSTACK-6460:
-

Attachment: cloudstack-6460.patch

CS 4.3 patch attached

> Migration of CLVM volumes to another primary storage fail
> -
>
> Key: CLOUDSTACK-6460
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Volumes
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
> Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
>Reporter: Salvatore Sciacco
> Attachments: cloudstack-6460.patch
>
>
> ACS version: 4.2.1 
> Hypervisors: KVM 
> Storage pool type: CLVM
> Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary 
> storage pool fail. I've enabled debug on the agents side and I think there is 
> a problem with the format  type conversion
> Volume on database had format QCOW2
> these are the parameters for the first step (CLVM -> NFS):
> {quote}
> "srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO": 
> "uuid":"cda46430-52d7-4bf0-b0c2-adfc78dd011c","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":"uuid":"655d6965-b3f3-4118-a970-d50cf6afc365","id":211,"poolType":"CLVM","host":"localhost","path":"/FC10KY1","port":0,"name":"ROOT-4450","size":5368709120,"path":"39a25daf-23a1-4b65-99ac-fb98469ac197","volumeId":5937,"vmName":"i-402-4450-VM","accountId":402,"format":"QCOW2","id":5937,"hypervisorType":"KVM"}
> "destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"cda46430-52d7-4bf0-b0c2-adfc78dd011c","volumeType":"ROOT","dataStore":{"com.cloud.agent.api.to.NfsTO":
>  
> "_url":"nfs://192.168.11.6/home/a1iwstack","_role":"Image"},"name":"ROOT-4450","size":5368709120,"path":"volumes/402/5937","volumeId":5937,"vmName":"i-402-4450-VM","accountId":402,"format":"QCOW2","id":5937,"hypervisorType":"KVM"}
> {quote}
> Those commads are translated into the agent:
> {quote}
> DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img 
> info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
> DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is 
> successful.
> DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: 
> /bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
> /mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
>  
> {quote}
> With the result that the output file isn't a qcow2 file but a raw partition, 
> which in turn make the next step fail.
> (NFS -> CLVM)
> {quote}
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img 
> info 
> /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
>  
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img 
> convert -f qcow2 -O raw 
> /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
>  /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not 
> open 
> '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
>  Could not open 
> '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
> ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to 
> convert 
> /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
>  to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was: 
> qemu-img: Could not open 
> '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
>  Could not open 
> '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
> {quote}
> If I change on the database the format of the volume to RAW the effect is 
> even worse as data is lost in the process!
> These are the parameter for the first step (CLVM => NFS)
> {quote}
> "srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"cda46430-52d7-4bf0-b0c2-adfc78dd011c","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"655d6965-b3f3-4118-a970d50cf6afc365","id":211,"poolType":"CLVM","host":"localhost","path":"/FC10KY1","port":0,"name":"ROOT-4450"
> ,"size":5368709120,"path":"39a25daf-23a1-4b65-99ac-fb98469ac197","volumeId":5937,"vmName":"i-4024450VM","accountId":402,"format":"RAW","id":5937,"hypervisorType":"KVM"
> "destTO":{"org.apache.cloudstack.storage.

[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail

2014-06-21 Thread Simon Weller (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039847#comment-14039847
 ] 

Simon Weller commented on CLOUDSTACK-6460:
--

I wrote a patch for this yesterday that is identical to yours. I've been 
testing it, and it does seem to address the problem. I agree that source will 
always be raw, so unless we're missing something very obvious here, this should 
take care of the problem. 



> Migration of CLVM volumes to another primary storage fail
> -
>
> Key: CLOUDSTACK-6460
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Volumes
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
> Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
>Reporter: Salvatore Sciacco
>
> ACS version: 4.2.1 
> Hypervisors: KVM 
> Storage pool type: CLVM
> Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary 
> storage pool fail. I've enabled debug on the agents side and I think there is 
> a problem with the format  type conversion
> Volume on database had format QCOW2
> these are the parameters for the first step (CLVM -> NFS):
> {quote}
> "srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO": 
> "uuid":"cda46430-52d7-4bf0-b0c2-adfc78dd011c","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":"uuid":"655d6965-b3f3-4118-a970-d50cf6afc365","id":211,"poolType":"CLVM","host":"localhost","path":"/FC10KY1","port":0,"name":"ROOT-4450","size":5368709120,"path":"39a25daf-23a1-4b65-99ac-fb98469ac197","volumeId":5937,"vmName":"i-402-4450-VM","accountId":402,"format":"QCOW2","id":5937,"hypervisorType":"KVM"}
> "destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"cda46430-52d7-4bf0-b0c2-adfc78dd011c","volumeType":"ROOT","dataStore":{"com.cloud.agent.api.to.NfsTO":
>  
> "_url":"nfs://192.168.11.6/home/a1iwstack","_role":"Image"},"name":"ROOT-4450","size":5368709120,"path":"volumes/402/5937","volumeId":5937,"vmName":"i-402-4450-VM","accountId":402,"format":"QCOW2","id":5937,"hypervisorType":"KVM"}
> {quote}
> Those commads are translated into the agent:
> {quote}
> DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img 
> info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
> DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is 
> successful.
> DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: 
> /bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
> /mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
>  
> {quote}
> With the result that the output file isn't a qcow2 file but a raw partition, 
> which in turn make the next step fail.
> (NFS -> CLVM)
> {quote}
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img 
> info 
> /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
>  
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img 
> convert -f qcow2 -O raw 
> /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
>  /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
> DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not 
> open 
> '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
>  Could not open 
> '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
> ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to 
> convert 
> /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
>  to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was: 
> qemu-img: Could not open 
> '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
>  Could not open 
> '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
> {quote}
> If I change on the database the format of the volume to RAW the effect is 
> even worse as data is lost in the process!
> These are the parameter for the first step (CLVM => NFS)
> {quote}
> "srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"cda46430-52d7-4bf0-b0c2-adfc78dd011c","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"655d6965-b3f3-4118-a970d50cf6afc365","id":211,"poolType":"CLVM","host":"localhost","path":"/FC10KY1","port":0,"name":"ROOT-4450"
>

[jira] [Commented] (CLOUDSTACK-6971) createAutoScaleVmProfile failed with NPE due to lack of bean injection.

2014-06-21 Thread Rajesh Battala (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039765#comment-14039765
 ] 

Rajesh Battala commented on CLOUDSTACK-6971:


Am able to created autoscale polices successfuly now.

> createAutoScaleVmProfile failed with NPE due to lack of bean injection.
> ---
>
> Key: CLOUDSTACK-6971
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6971
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.4.0
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.4.0
>
>
> When creating autoscale policy, its failing to create with below NPE 
> exception.
> INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-4:ctx-f439aaf2 job-146) 
> Remove job-146 from job monitoring
> ERROR [c.c.a.ApiServer] (21050798@qtp-4315003-10:ctx-1bb507da ctx-db84c324) 
> unhandled exception executing api command: [Ljava.lang.String;@17b6fd
> java.lang.NullPointerException
> at 
> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:410)
> at 
> com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:222)
> at 
> com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:216)
> at 
> com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:88)
> at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
> at 
> com.cloud.network.as.AutoScaleManagerImpl.createAutoScaleVmProfile(AutoScaleManagerImpl.java:373)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy250.createAutoScaleVmProfile(Unknown Source)
> at 
> org.apache.cloudstack.api.command.user.autoscale.CreateAutoScaleVmProfileCmd.create(CreateAutoScaleVmProfileCmd.java:263)
> at 
> com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47)
> at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
> at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:79)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506)
> at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330)
> at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
> at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
> at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
> at