[jira] [Resolved] (CLOUDSTACK-6990) VM console displays blank page.AgentControlChannelException in cloud.log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala resolved CLOUDSTACK-6990.
Resolution: Fixed
> VM console displays blank page.AgentControlChannelException in cloud.log
>
>
> Key: CLOUDSTACK-6990
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6990
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
>Affects Versions: 4.4.0
>Reporter: manasaveloori
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: 4.4.0, 4.5.0
>
> Attachments: cloud.log, management-server.rar
>
>
> Deployed Cloudstack using the build :
> [root@RHEL63test ~]# cloudstack-sccs
> 9024ad14681858ac7caafaf86f267a213ce6b61c
> Deployed a user VM.
> Now try to open the console of any VM.
> It is displaying blank page.
> In CPVM cloud.log observed the following exception continuously:
> 2014-06-25 06:31:14,620 INFO [utils.exception.CSExceptionErrorCode] (Console
> Proxy GC Thread:null) Could not find exception:
> com.cloud.exception.AgentControlChannelException in error code list for
> exceptions
> 2014-06-25 06:31:14,621 ERROR [resource.consoleproxy.ConsoleProxyResource]
> (Console Proxy GC Thread:null) Unable to send out load info due to Unable to
> post agent control request as link is not available
> com.cloud.exception.AgentControlChannelException: Unable to post agent
> control request as link is not available
> at com.cloud.agent.Agent.postRequest(Agent.java:689)
> at com.cloud.agent.Agent.postRequest(Agent.java:677)
> at
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:418)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
> at
> com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
> 2014-06-25 06:31:14,621 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
> (Console Proxy GC Thread:null) Report load change : {
> "connections": []
> }
> 2014-06-25 06:31:14,897 INFO [cloud.agent.Agent] (Agent-Handler-4:null)
> Reconnecting...
> 2014-06-25 06:31:14,897 INFO [utils.nio.NioClient] (Agent-Selector:null)
> Connecting to 10.147.59.222:8250
> Attaching the Ms logs and CPVM log.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7313) Provisioning vpx in SDX from CS is failing
Rajesh Battala created CLOUDSTACK-7313: -- Summary: Provisioning vpx in SDX from CS is failing Key: CLOUDSTACK-7313 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7313 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.5.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7314) [LXC] getting libvirt exception while stopping VM
shweta agarwal created CLOUDSTACK-7314: -- Summary: [LXC] getting libvirt exception while stopping VM Key: CLOUDSTACK-7314 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7314 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: 1. Create a LXC VM 2. Stop the VM Bug: Even though VM stops Agent log show exception Failed to stop VM :i-2-71-VM : org.libvirt.LibvirtException: Mount namespaces are not available on this platform: Function not implemented at org.libvirt.ErrorHandler.processError(Unknown Source) at org.libvirt.Connect.processError(Unknown Source) at org.libvirt.Domain.processError(Unknown Source) at org.libvirt.Domain.shutdown(Unknown Source) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4566) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4505) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3478) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1262) at com.cloud.agent.Agent.processRequest(Agent.java:501) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808) at com.cloud.utils.nio.Task.run(Task.java:84) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7315) [LXC] libvirt Exception when deleting volume as a part of expunge VM
shweta agarwal created CLOUDSTACK-7315:
--
Summary: [LXC] libvirt Exception when deleting volume as a part of
expunge VM
Key: CLOUDSTACK-7315
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7315
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
Fix For: 4.5.0
Repro steps:
Create a LXC VM
Destroy the VM with expunge=true :
Agent log shows following exception :
Instructing libvirt to remove volume c24ecda3-128f-4e3e-bec9-04aca09cdeb1 from
pool dfa2ec3c-d133-3284-8583-0a0845aa4424
2014-08-12 04:38:37,759 DEBUG [kvm.storage.KVMStorageProcessor]
(agentRequest-Handler-3:null) Failed to delete volume:
com.cloud.utils.exception.CloudRuntimeException: org.libvirt.LibvirtException:
cannot remove directory
'/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/c24ecda3-128f-4e3e-bec9-04aca09cdeb1':
Directory not empty
at
com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.deletePhysicalDisk(LibvirtStorageAdaptor.java:856)
at
com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.deletePhysicalDisk(LibvirtStoragePool.java:175)
at
com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.deleteVolume(KVMStorageProcessor.java:1203)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:124)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:57)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1356)
at com.cloud.agent.Agent.processRequest(Agent.java:501)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
at com.cloud.utils.nio.Task.run(Task.java:84)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2014-08-12 04:38:37,759 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null)
Seq 1-4558487247829097659: { Ans: , MgmtId: 233845177509765, via: 1, Ver: v1,
Flags: 10,
[{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
org.libvirt.LibvirtException: cannot remove directory
'/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/c24ecda3-128f-4e3e-bec9-04aca09cdeb1':
Directory not empty","wait":0}}] }
2014-08-12 04:38:38,321 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null)
Processing command: com.cloud.agent.api.GetStorageStatsCommand
2014-08-12 04:38:38,321 DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-1:null)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7315) [LXC] libvirt Exception when deleting volume as a part of expunge VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-7315:
---
Attachment: agent.log
> [LXC] libvirt Exception when deleting volume as a part of expunge VM
>
>
> Key: CLOUDSTACK-7315
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7315
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: agent.log
>
>
> Repro steps:
> Create a LXC VM
> Destroy the VM with expunge=true :
> Agent log shows following exception :
> Instructing libvirt to remove volume c24ecda3-128f-4e3e-bec9-04aca09cdeb1
> from pool dfa2ec3c-d133-3284-8583-0a0845aa4424
> 2014-08-12 04:38:37,759 DEBUG [kvm.storage.KVMStorageProcessor]
> (agentRequest-Handler-3:null) Failed to delete volume:
> com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: cannot remove directory
> '/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/c24ecda3-128f-4e3e-bec9-04aca09cdeb1':
> Directory not empty
> at
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.deletePhysicalDisk(LibvirtStorageAdaptor.java:856)
> at
> com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.deletePhysicalDisk(LibvirtStoragePool.java:175)
> at
> com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.deleteVolume(KVMStorageProcessor.java:1203)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:124)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:57)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1356)
> at com.cloud.agent.Agent.processRequest(Agent.java:501)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
> at com.cloud.utils.nio.Task.run(Task.java:84)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2014-08-12 04:38:37,759 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-4558487247829097659: { Ans: , MgmtId:
> 233845177509765, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: cannot remove directory
> '/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/c24ecda3-128f-4e3e-bec9-04aca09cdeb1':
> Directory not empty","wait":0}}] }
> 2014-08-12 04:38:38,321 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command:
> com.cloud.agent.api.GetStorageStatsCommand
> 2014-08-12 04:38:38,321 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-1:null)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7314) [LXC] getting libvirt exception while stopping VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7314: --- Attachment: agent.log > [LXC] getting libvirt exception while stopping VM > - > > Key: CLOUDSTACK-7314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7314 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala > Fix For: 4.5.0 > > Attachments: agent.log > > > Repro steps: > 1. Create a LXC VM > 2. Stop the VM > Bug: > Even though VM stops Agent log show exception > Failed to stop VM :i-2-71-VM : > org.libvirt.LibvirtException: Mount namespaces are not available on this > platform: Function not implemented > at org.libvirt.ErrorHandler.processError(Unknown Source) > at org.libvirt.Connect.processError(Unknown Source) > at org.libvirt.Domain.processError(Unknown Source) > at org.libvirt.Domain.shutdown(Unknown Source) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4566) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4505) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3478) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1262) > at com.cloud.agent.Agent.processRequest(Agent.java:501) > at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808) > at com.cloud.utils.nio.Task.run(Task.java:84) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server
shweta agarwal created CLOUDSTACK-7316: -- Summary: hitting java.lang.reflect.InvocationTargetException while starting usage server Key: CLOUDSTACK-7316 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.5.0 Reporter: shweta agarwal Priority: Blocker Fix For: 4.5.0 Repro steps: Install MS and usage server Start MS and usage server Bug: Usage server will stop after starting -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7316: --- Attachment: usage.tar.gz > hitting java.lang.reflect.InvocationTargetException while starting usage > server > --- > > Key: CLOUDSTACK-7316 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Priority: Blocker > Fix For: 4.5.0 > > Attachments: usage.tar.gz > > > Repro steps: > Install MS and usage server > Start MS and usage server > Bug: > Usage server will stop after starting -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7316: --- Description: Repro steps: Install MS and usage server Start MS and usage server Bug: Usage server will stop after starting usage log shows : java.lang.reflect.InvocationTargetException 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.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243) Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'vmDiskUsageParser': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.cloud.usage.dao.UsageDao com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'usageDaoImpl' defined in URL [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]: BeanPostProcessor before instantiation of bean failed; nested exception is net.sf.cglib.core.CodeGenerationException: java.lang.ExceptionInInitializerError-->null at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479) at org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139) at org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:83) at com.cloud.usage.UsageServer.start(UsageServer.java:57) ... 5 more Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.cloud.usage.dao.UsageDao com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'usageDaoImpl' defined in URL [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]: BeanPostProcessor before instantiation of bean failed; nested exception is net.sf.cglib.core.CodeGenerationException: java.lang.ExceptionInInitializerError-->null at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:514) was: Repro steps: Install MS and usage server Start MS and usage server Bug: Usage server will stop after starting > hitting java.lang.reflect.InvocationTargetException while starting usage > server > --- > > Key: CLOUDSTACK-7316 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Priority: Blocker > Fix For: 4.5.0 > > Attachments: usage.tar.gz > > > Repro steps: > Install MS and usage serv
[jira] [Created] (CLOUDSTACK-7317) wrong message when trying to upgrade a running VM
shweta agarwal created CLOUDSTACK-7317:
--
Summary: wrong message when trying to upgrade a running VM
Key: CLOUDSTACK-7317
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7317
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: shweta agarwal
Fix For: 4.5.0
Repro steps:
1. Create a VM with small service offerings ( i did it on LXC hypervisor)
2. While VM is running change service offering
Bug:
We get message This operation not permitted for this hypervisor of the vm
Expected Result :
Message should be related to VM should be stopped while changing service
offerings
MS log shows :
2014-08-12 05:26:21,708 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-36:ctx-b9835d0e job-439) Executing AsyncJobVO {id:439,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin, cmdInfo:
{"id":"033042b7-0973-4e00-b4b8-d9f3af49c3ac","response":"json","sessionkey":"HEgqZRWcriIz5k+MxuauDaQK6Wc\u003d","serviceofferingid":"b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"033042b7-0973-4e00-b4b8-d9f3af49c3ac\",\"com.cloud.offering.ServiceOffering\":\"b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c\"}","cmdEventType":"VM.UPGRADE","ctxUserId":"2","httpmethod":"GET","_":"1407835578042","uuid":"033042b7-0973-4e00-b4b8-d9f3af49c3ac","ctxAccountId":"2","ctxStartEventId":"278"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-08-12 05:26:21,709 DEBUG [c.c.a.ApiServlet] (catalina-exec-11:ctx-ee357ccc
ctx-490ac18f) ===END=== 10.146.0.131 -- GET
command=scaleVirtualMachine&response=json&sessionkey=HEgqZRWcriIz5k%2BMxuauDaQK6Wc%3D&id=033042b7-0973-4e00-b4b8-d9f3af49c3ac&serviceofferingid=b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c&_=1407835578042
2014-08-12 05:26:21,880 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-36:ctx-b9835d0e job-439) Unexpected exception while executing
org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin
com.cloud.exception.InvalidParameterValueException: This operation not
permitted for this hypervisor of the vm
at
com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339)
at
com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328)
at
com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264)
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 $Proxy211.upgradeVirtualMachine(Unknown Source)
at
org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithCo
[jira] [Created] (CLOUDSTACK-7318) [LXC][UI] procesing wheel continue to spin even after error messaage during VM snapshot creation
shweta agarwal created CLOUDSTACK-7318: -- Summary: [LXC][UI] procesing wheel continue to spin even after error messaage during VM snapshot creation Key: CLOUDSTACK-7318 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: shweta agarwal Fix For: 4.5.0 Attachments: processingwheel.png Repro steps: Create a LXC VM When VM is running try to createa VM snapshot Bug: Notice you get message VM snapshot is not enabled for hypervisor type: LXC but spinnign wheel continue to spin . attaching snapshot -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7318) [LXC][UI] processing wheel continue to spin even after error messaage during VM snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7318: --- Summary: [LXC][UI] processing wheel continue to spin even after error messaage during VM snapshot creation (was: [LXC][UI] procesing wheel continue to spin even after error messaage during VM snapshot creation) > [LXC][UI] processing wheel continue to spin even after error messaage during > VM snapshot creation > - > > Key: CLOUDSTACK-7318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal > Fix For: 4.5.0 > > Attachments: processingwheel.png > > > Repro steps: > Create a LXC VM > When VM is running try to createa VM snapshot > Bug: > Notice you get message VM snapshot is not enabled for hypervisor type: LXC > but spinnign wheel continue to spin . attaching snapshot -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7318) [LXC][UI] processing wheel continue to spin even after error messaage during VM snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7318: --- Attachment: processingwheel.png > [LXC][UI] processing wheel continue to spin even after error messaage during > VM snapshot creation > - > > Key: CLOUDSTACK-7318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal > Fix For: 4.5.0 > > Attachments: processingwheel.png > > > Repro steps: > Create a LXC VM > When VM is running try to createa VM snapshot > Bug: > Notice you get message VM snapshot is not enabled for hypervisor type: LXC > but spinnign wheel continue to spin . attaching snapshot -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6526) Cloudstack simulator recipe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Duffy closed CLOUDSTACK-6526. - > Cloudstack simulator recipe > > > Key: CLOUDSTACK-6526 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6526 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Ian Duffy >Assignee: Ian Duffy > > Recipe to download/compile/configure Cloudstack in simulator mode. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6527) Cloudstack recipe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Duffy closed CLOUDSTACK-6527. - Resolution: Fixed > Cloudstack recipe > - > > Key: CLOUDSTACK-6527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6527 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Ian Duffy >Assignee: Ian Duffy > > Recipe to Download/Install/Configure Cloudstack setup as devcloud. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6526) Cloudstack simulator recipe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Duffy resolved CLOUDSTACK-6526. --- Resolution: Fixed > Cloudstack simulator recipe > > > Key: CLOUDSTACK-6526 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6526 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Ian Duffy >Assignee: Ian Duffy > > Recipe to download/compile/configure Cloudstack in simulator mode. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-7243) [VMware]Extract volume is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori closed CLOUDSTACK-7243. - Verified on latest build. Working fine.Hence closing the issue. > [VMware]Extract volume is failing > - > > Key: CLOUDSTACK-7243 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7243 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.5.0 >Reporter: manasaveloori >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.5.0 > > Attachments: management-server.rar > > > Steps: > 1. Deployed CS with ESXi5.1 > 2. Deployed a VM. > 3. Created a data disk V1 .(attach to VM and dettach) > 4. Upload a volume V2. > 5. Extract the volumeV1 and V2 > Observation: > Extract volume is failing with following exception: > 2014-08-05 10:53:31,719 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl] > (API-Job-Executor-25:ctx-545716e6 job-48 ctx-9fe6bdfd) Unsupported data > object (VOLUME, > org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@4e27c55d), no > need to delete from object in store ref table > 2014-08-05 10:53:31,762 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-25:ctx-545716e6 job-48) Unexpected exception while > executing org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd > com.cloud.utils.exception.CloudRuntimeException: Failed to copy the volume > from the source primary storage pool to secondary storage. > at > com.cloud.storage.VolumeApiServiceImpl.extractVolume(VolumeApiServiceImpl.java:2024) > 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:606) > 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 com.sun.proxy.$Proxy183.extractVolume(Unknown Source) > at > org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd.execute(ExtractVolumeCmd.java:137) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > 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 > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > 2014-08-05 10:53:31,765 DEBUG [o.a.c.f.j.i.AsyncJobMa
[jira] [Closed] (CLOUDSTACK-7248) [VMware]Snapshot of data volume not attached to any VM is failing to backup.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori closed CLOUDSTACK-7248. - Verified on latest build. Working fine.Closing the issue. > [VMware]Snapshot of data volume not attached to any VM is failing to backup. > > > Key: CLOUDSTACK-7248 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7248 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, Storage Controller >Affects Versions: 4.5.0 >Reporter: manasaveloori >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.5.0 > > Attachments: cloud.out, management-server.rar > > > Steps: > 1. Deployed CS with ESXi5.1. > 2. Deployed a VM with data disk (or)Deloy VM ,Create a volume and attach it > to VM. > 3. Detach the data disk from VM. > 4. Take snapshot of the data disk. > > Observation: > Snapshot is failing with following exception. > 2014-08-05 14:24:13,389 DEBUG [c.c.s.s.SnapshotManagerImpl] > (API-Job-Executor-48:ctx-41fc60ba job-94 ctx-11fcc509) Failed to create > snapshot > com.cloud.utils.exception.CloudRuntimeException: backup snapshot exception: > Exception: java.lang.Exception > Message: Unable to find related disk device for volume. volume path: > f394364f070a411c830e295a19c5ffd6 > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:971) > 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:606) > 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.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 com.sun.proxy.$Proxy179.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1534) > at > com.cloud.storage.VolumeApiServiceImpl.takeSnapshot(VolumeApiServiceImpl.java:1875) > 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:606) > 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.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 com.sun.proxy.$Proxy183.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:187) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRu
[jira] [Created] (CLOUDSTACK-7319) Copy Snapshot command to heavy on XenServer Dom0 resources when using dd to copy incremental snapshots
Joris van Lieshout created CLOUDSTACK-7319: -- Summary: Copy Snapshot command to heavy on XenServer Dom0 resources when using dd to copy incremental snapshots Key: CLOUDSTACK-7319 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7319 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Snapshot, XenServer Affects Versions: 4.2.0, 4.1.0, 4.0.2, 4.0.1, 4.0.0, 4.1.1, Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 Reporter: Joris van Lieshout Priority: Critical We noticed that the dd process was way to agressive on Dom0 causing all kinds of problems on a xenserver with medium workloads. ACS uses the dd command to copy incremental snapshots to secondary storage. This process is to heavy on Dom0 resources and even impacts DomU performance, and can even lead to domain freezes (including Dom0) of more then a minute. We've found that this is because the Dom0 kernel caches the read and write operations of dd. We've developed a patch on the xenserver scripts /etc/xapi.d/plugins/vmopsSnapshot that added the direct flag of both input and output files. Our test have shown that Dom0 load during snapshot copy is way lower. I will upload the patch on review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7319) Copy Snapshot command too heavy on XenServer Dom0 resources when using dd to copy incremental snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris van Lieshout updated CLOUDSTACK-7319: --- Summary: Copy Snapshot command too heavy on XenServer Dom0 resources when using dd to copy incremental snapshots (was: Copy Snapshot command to heavy on XenServer Dom0 resources when using dd to copy incremental snapshots) > Copy Snapshot command too heavy on XenServer Dom0 resources when using dd to > copy incremental snapshots > --- > > Key: CLOUDSTACK-7319 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7319 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, XenServer >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, Future, 4.2.1, > 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Joris van Lieshout >Priority: Critical > > We noticed that the dd process was way to agressive on Dom0 causing all kinds > of problems on a xenserver with medium workloads. > ACS uses the dd command to copy incremental snapshots to secondary storage. > This process is to heavy on Dom0 resources and even impacts DomU performance, > and can even lead to domain freezes (including Dom0) of more then a minute. > We've found that this is because the Dom0 kernel caches the read and write > operations of dd. > We've developed a patch on the xenserver scripts > /etc/xapi.d/plugins/vmopsSnapshot that added the direct flag of both input > and output files. > Our test have shown that Dom0 load during snapshot copy is way lower. I will > upload the patch on review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7319) Copy Snapshot command too heavy on XenServer Dom0 resources when using dd to copy incremental snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14093962#comment-14093962 ] Joris van Lieshout commented on CLOUDSTACK-7319: review https://reviews.apache.org/r/24598/ > Copy Snapshot command too heavy on XenServer Dom0 resources when using dd to > copy incremental snapshots > --- > > Key: CLOUDSTACK-7319 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7319 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, XenServer >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, Future, 4.2.1, > 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Joris van Lieshout >Priority: Critical > > We noticed that the dd process was way to agressive on Dom0 causing all kinds > of problems on a xenserver with medium workloads. > ACS uses the dd command to copy incremental snapshots to secondary storage. > This process is to heavy on Dom0 resources and even impacts DomU performance, > and can even lead to domain freezes (including Dom0) of more then a minute. > We've found that this is because the Dom0 kernel caches the read and write > operations of dd. > Some of the issues we have seen as a consequence of this are: > - DomU performance/freezes > - OVS freeze and not forwarding any traffic > - Including LACPDUs resulting in the bond going down > - keepalived heartbeat packets between RRVMs not being send/received > resulting in flapping RRVM master state > - Braking snapshot copy processes > - the xenserver heartbeat script reaching it's timeout and fencing the server > - poolmaster connection loss > - ACS marking the host as down and fencing the instances even though they are > still running on the origional host resulting in the same instance running on > to hosts in one cluster > - vhd corruption are a result of some of the issues mentioned above > We've developed a patch on the xenserver scripts > /etc/xapi.d/plugins/vmopsSnapshot that added the direct flag of both input > and output files (iflag=direct oflag=direct). > Our test have shown that Dom0 load during snapshot copy is way lower. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7319) Copy Snapshot command too heavy on XenServer Dom0 resources when using dd to copy incremental snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris van Lieshout updated CLOUDSTACK-7319: --- Description: We noticed that the dd process was way to agressive on Dom0 causing all kinds of problems on a xenserver with medium workloads. ACS uses the dd command to copy incremental snapshots to secondary storage. This process is to heavy on Dom0 resources and even impacts DomU performance, and can even lead to domain freezes (including Dom0) of more then a minute. We've found that this is because the Dom0 kernel caches the read and write operations of dd. Some of the issues we have seen as a consequence of this are: - DomU performance/freezes - OVS freeze and not forwarding any traffic - Including LACPDUs resulting in the bond going down - keepalived heartbeat packets between RRVMs not being send/received resulting in flapping RRVM master state - Braking snapshot copy processes - the xenserver heartbeat script reaching it's timeout and fencing the server - poolmaster connection loss - ACS marking the host as down and fencing the instances even though they are still running on the origional host resulting in the same instance running on to hosts in one cluster - vhd corruption are a result of some of the issues mentioned above We've developed a patch on the xenserver scripts /etc/xapi.d/plugins/vmopsSnapshot that added the direct flag of both input and output files (iflag=direct oflag=direct). Our test have shown that Dom0 load during snapshot copy is way lower. was: We noticed that the dd process was way to agressive on Dom0 causing all kinds of problems on a xenserver with medium workloads. ACS uses the dd command to copy incremental snapshots to secondary storage. This process is to heavy on Dom0 resources and even impacts DomU performance, and can even lead to domain freezes (including Dom0) of more then a minute. We've found that this is because the Dom0 kernel caches the read and write operations of dd. We've developed a patch on the xenserver scripts /etc/xapi.d/plugins/vmopsSnapshot that added the direct flag of both input and output files. Our test have shown that Dom0 load during snapshot copy is way lower. I will upload the patch on review. > Copy Snapshot command too heavy on XenServer Dom0 resources when using dd to > copy incremental snapshots > --- > > Key: CLOUDSTACK-7319 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7319 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, XenServer >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, Future, 4.2.1, > 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Joris van Lieshout >Priority: Critical > > We noticed that the dd process was way to agressive on Dom0 causing all kinds > of problems on a xenserver with medium workloads. > ACS uses the dd command to copy incremental snapshots to secondary storage. > This process is to heavy on Dom0 resources and even impacts DomU performance, > and can even lead to domain freezes (including Dom0) of more then a minute. > We've found that this is because the Dom0 kernel caches the read and write > operations of dd. > Some of the issues we have seen as a consequence of this are: > - DomU performance/freezes > - OVS freeze and not forwarding any traffic > - Including LACPDUs resulting in the bond going down > - keepalived heartbeat packets between RRVMs not being send/received > resulting in flapping RRVM master state > - Braking snapshot copy processes > - the xenserver heartbeat script reaching it's timeout and fencing the server > - poolmaster connection loss > - ACS marking the host as down and fencing the instances even though they are > still running on the origional host resulting in the same instance running on > to hosts in one cluster > - vhd corruption are a result of some of the issues mentioned above > We've developed a patch on the xenserver scripts > /etc/xapi.d/plugins/vmopsSnapshot that added the direct flag of both input > and output files (iflag=direct oflag=direct). > Our test have shown that Dom0 load during snapshot copy is way lower. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7305) Hypervisor type parameter is mandatory when deploying VM using ISO
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14093963#comment-14093963 ] ASF subversion and git services commented on CLOUDSTACK-7305: - Commit 6568e0bb31103ec9148a5c967db6563ca9af4307 in cloudstack's branch refs/heads/master from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6568e0b ] CLOUDSTACK-7305: hypervisor type parameter is mandatory when deploying VM using ISO Signed-off-by: Koushik Das > Hypervisor type parameter is mandatory when deploying VM using ISO > -- > > Key: CLOUDSTACK-7305 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7305 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0, 4.5.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > We need to make the parameter "hypervisor" mandate when vm deployed using ISO. > Steps to reproduce: > 1) Delpoy a VM from ISO using deployVmAPI without "hypervisor" paramter > 2) deployVmAPI fails > 3) Try to destroy VM (expunge) the VM, it fails with NPE and the VM stays in > "Expunging" state. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7192) BVT tests which don't apply to Hyper-V should be skipped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14093972#comment-14093972 ] ASF subversion and git services commented on CLOUDSTACK-7192: - Commit d75961d973021fbfec5058d907923f885ac8906a in cloudstack's branch refs/heads/master from [~johnmdilley] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d75961d ] CLOUDSTACK-7192: Skip tests on Hyper-V which don't apply > BVT tests which don't apply to Hyper-V should be skipped > > > Key: CLOUDSTACK-7192 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7192 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Affects Versions: 4.5.0 >Reporter: John Dilley >Assignee: John Dilley > > If a test is run through nose which doesn't apply to the hypervisor under > test, the test should be skipped. > In particular, there are many Hyper-V tests which this applies to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7319) Copy Snapshot command too heavy on XenServer Dom0 resources when using dd to copy incremental snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14093971#comment-14093971 ] Joris van Lieshout commented on CLOUDSTACK-7319: We believe Hot-fix 4 for XS62 sp1 contains a similar fix but for the sparse dd process used for the first copy of a chain. http://support.citrix.com/article/CTX140417 == begin quote == Copying a virtual disk between SRs uses the unbuffered I/O to avoid polluting the pagecache in the Control Domain (dom0). This reduces the dom0 vCPU overhead and allows the pagecache to work more effectively for other operations. == end quote == > Copy Snapshot command too heavy on XenServer Dom0 resources when using dd to > copy incremental snapshots > --- > > Key: CLOUDSTACK-7319 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7319 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, XenServer >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, Future, 4.2.1, > 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Joris van Lieshout >Priority: Critical > > We noticed that the dd process was way to agressive on Dom0 causing all kinds > of problems on a xenserver with medium workloads. > ACS uses the dd command to copy incremental snapshots to secondary storage. > This process is to heavy on Dom0 resources and even impacts DomU performance, > and can even lead to domain freezes (including Dom0) of more then a minute. > We've found that this is because the Dom0 kernel caches the read and write > operations of dd. > Some of the issues we have seen as a consequence of this are: > - DomU performance/freezes > - OVS freeze and not forwarding any traffic > - Including LACPDUs resulting in the bond going down > - keepalived heartbeat packets between RRVMs not being send/received > resulting in flapping RRVM master state > - Braking snapshot copy processes > - the xenserver heartbeat script reaching it's timeout and fencing the server > - poolmaster connection loss > - ACS marking the host as down and fencing the instances even though they are > still running on the origional host resulting in the same instance running on > to hosts in one cluster > - vhd corruption are a result of some of the issues mentioned above > We've developed a patch on the xenserver scripts > /etc/xapi.d/plugins/vmopsSnapshot that added the direct flag of both input > and output files (iflag=direct oflag=direct). > Our test have shown that Dom0 load during snapshot copy is way lower. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7320) [LXC] Provide default centos template for lxc
shweta agarwal created CLOUDSTACK-7320: -- Summary: [LXC] Provide default centos template for lxc Key: CLOUDSTACK-7320 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7320 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 We generally provide default template with all our hypervisor support . similarly we need to provide a default template for LXC as well -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7200) [LDAP] importUsersCmd for a group fails incase any member of a group is not an user
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-7200. - Resolution: Fixed > [LDAP] importUsersCmd for a group fails incase any member of a group is not > an user > --- > > Key: CLOUDSTACK-7200 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7200 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Labels: ldap > Fix For: 4.5.0 > > > If the group has all users, import is successful. > Import fails if the group has any member other than type 'user' -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6983) unable to register lxc template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-6983. - Resolution: Fixed > unable to register lxc template > --- > > Key: CLOUDSTACK-6983 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6983 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.5.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi >Priority: Critical > Labels: lxc > Attachments: Screen Shot 2014-06-24 at 11.59.24 am.png > > > lxc templates are just a tar.gz of filesystem. > in the below commit, it doesn't recognize it as a valid format and register > fails with message > "Template content is unsupported, or mismatch between selected format and > template content. Found : POSIX tar archive (GNU) (gzip compressed data, from > Unix, last modifie" > commit 15ac47e47b4c9a2323888d73f6988cb967647e28 > Author: Marcus Sorensen > AuthorDate: Wed May 28 15:36:13 2014 -0600 > Commit: Marcus Sorensen > CommitDate: Wed May 28 15:40:57 2014 -0600 > CLOUDSTACK-6088: Check first bytes of template when downloading to verify > format/type -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-7264) NPE while creating scheduled/recurring snapshots for the removed account with cleanup_needed=1
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
manasaveloori closed CLOUDSTACK-7264.
-
Verified on latest build
Schedule snapshots not triggered for removed accounts with cleanup=1
Closing the issue.
> NPE while creating scheduled/recurring snapshots for the removed account with
> cleanup_needed=1
> --
>
> Key: CLOUDSTACK-7264
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7264
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot
>Affects Versions: 4.5.0
>Reporter: manasaveloori
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.rar, mysqldump45.dmp
>
>
> 1. Created an account "test" with a user "testuser"
> 2. Deployed a VM with data disk.
> 3. Created snapshots of both root and data disks.
> 4. Scheduled hourly,daily,weekly,monthly snapshots of both data and root
> volumes.
> 5. While the snapshot is in backingup state deleted the account "test"
> Observation:
> 1. Account "test" got deleted but clean up of account failed as one of the
> snapshot is in "backingup" state.
> id: 5
>account_name: acct
>uuid: deb3b748-63ca-4566-8c34-a8bf6685bf11
>type: 0
> domain_id: 1
> state: enabled
> removed: 2014-08-06 07:15:23
> cleanup_needed: 1
> network_domain: NULL
> default_zone_id: NULL
> default: 0
> 2. Now changed the "account.cleanup.interval"=300sec
> 3. Now that account is removed with cleanup_needed=1 and scheduled snapshot
> is triggered.
> Snapshot creation failed with NPE and left in Allocated state
> 2014-08-06 12:51:42,597 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-11:ctx-0e534263 job-279) Add job-279 into job monitoring
> 2014-08-06 12:51:42,597 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-11:ctx-0e534263 job-279) Executing AsyncJobVO {id:279,
> userId: 1, accountId: 5, instanceType: Snapshot, instanceId: 52, cmd:
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo:
> {"id":"52","ctxUserId":"1","volumeid":"24","ctxAccountId":"5","ctxStartEventId":"1","policyid":"15"}
> , cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> result: null, initMsid: 6876007760021, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-06 12:51:42,600 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (API-Job-Executor-11:ctx-0e534263 job-279) Unexpected exception while
> executing org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd
> java.lang.NullPointerException
> at org.apache.cloudstack.context.CallContext.(CallContext.java:82)
> at org.apache.cloudstack.context.CallContext.register(CallContext.java:156)
> at org.apache.cloudstack.context.CallContext.register(CallContext.java:143)
> at org.apache.cloudstack.context.CallContext.register(CallContext.java:180)
> at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:100)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> 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
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> 2014-08-06 12:51:42,606 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-11:ctx-0e534263 job-279) Complete async job-279, jobStatus:
> FAILED, resultCode: 530, result:
> org.apache.cloudstack.api.response.ExceptionResponse/null/
> {"uuidList":[],"errorcode":530}
> 2014-08-06 12:51:42,614 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-11:ctx-0e534263 job-279) Done executing
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-279
> 4. Now as the snapshot state is
[jira] [Closed] (CLOUDSTACK-7263) Account Clean up is failing when there are snapshots in allocated state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
manasaveloori closed CLOUDSTACK-7263.
-
Verified on latest build
Scheduled snapshots not triggered for removed accounts with cleanup=1
So account clean up succeeded.
Closing the issue.
> Account Clean up is failing when there are snapshots in allocated state.
>
>
> Key: CLOUDSTACK-7263
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7263
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Storage Controller
>Affects Versions: 4.5.0
>Reporter: manasaveloori
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.rar, mysqldump45.dmp
>
>
> Steps:
> 1. Created an account "test" with a user "testuser"
> 2. Deployed a VM with data disk.
> 3. Created snapshots of both root and data disks.
> 4. Scheduled hourly,daily,weekly,monthly snapshots of both data and root
> volumes.
> 5. While the snapshot is in backingup state deleted the account "test"
> Observation:
> 1. Account "test" got deleted but clean up of account failed as one of the
> snapshot is in "backingup" state.
> 2. Now changed the "account.cleanup.interval"=300sec
> 3. After 300secs...Account cleanup is triggered and at the same time
> scheduled snapshot creation is triggered.
> Snapshot creation failed with NPE and left in Allocated state
> 2014-08-06 12:51:42,597 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-11:ctx-0e534263 job-279) Add job-279 into job monitoring
> 2014-08-06 12:51:42,597 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-11:ctx-0e534263 job-279) Executing AsyncJobVO {id:279,
> userId: 1, accountId: 5, instanceType: Snapshot, instanceId: 52, cmd:
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo:
> {"id":"52","ctxUserId":"1","volumeid":"24","ctxAccountId":"5","ctxStartEventId":"1","policyid":"15"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 6876007760021, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-06 12:51:42,600 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (API-Job-Executor-11:ctx-0e534263 job-279) Unexpected exception while
> executing org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd
> java.lang.NullPointerException
> at
> org.apache.cloudstack.context.CallContext.(CallContext.java:82)
> at
> org.apache.cloudstack.context.CallContext.register(CallContext.java:156)
> at
> org.apache.cloudstack.context.CallContext.register(CallContext.java:143)
> at
> org.apache.cloudstack.context.CallContext.register(CallContext.java:180)
> at
> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:100)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> 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
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> 2014-08-06 12:51:42,606 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-11:ctx-0e534263 job-279) Complete async job-279, jobStatus:
> FAILED, resultCode: 530, result:
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530}
> 2014-08-06 12:51:42,614 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-11:ctx-0e534263 job-279) Done executing
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-279
> 4. Now as the snapshot state is left in "allocated state...everytime cleanup
> is triggered it is failed with below exception
[jira] [Closed] (CLOUDSTACK-7237) template sync unable to find already downloaded template after restarting MS
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7237.
--
> template sync unable to find already downloaded template after restarting MS
> -
>
> Key: CLOUDSTACK-7237
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7237
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> 1. created an advance zone
> 2. Register a template
> 3. Wait till download is complete and template in ready state
> 4. Restart MS
> 5. wait for template sync to happen
> Bug:
> template sync says Template Sync did not find
> 206-2-832d2ef8-9355-3958-9331-0847b502ad2a on image store 1, may request
> download based on available hypervisor types
> MS log to show template 206-2-832d2ef8-9355-3958-9331-0847b502ad2a was
> downloaded successfully before restarting MS
> 2014-08-04 08:02:50,676 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Work-Job-Executor-1:ctx-2494f7c7 job-121/job-122 ctx-7f2fe1fe) template 206
> is already in store:1, type:Primary
> 2014-08-04 08:02:50,677 DEBUG [o.a.c.s.v.VolumeServiceImpl]
> (Work-Job-Executor-1:ctx-2494f7c7 job-121/job-122 ctx-7f2fe1fe) Found
> template 206-2-832d2ef8-9355-3958-9331-0847b502ad2a in storage pool 1 with
> VMTemplateStoragePool id: 7
> 2014-08-04 08:02:50,686 DEBUG [o.a.c.s.v.VolumeServiceImpl]
> (Work-Job-Executor-1:ctx-2494f7c7 job-121/job-122 ctx-7f2fe1fe) Acquire lock
> on VMTemplateStoragePool 7 with timeout 3600 seconds
> 2014-08-04 08:02:50,688 INFO [o.a.c.s.v.VolumeServiceImpl]
> (Work-Job-Executor-1:ctx-2494f7c7 job-121/job-122 ctx-7f2fe1fe) lock is
> acquired for VMTemplateStoragePool 7
> 2014-08-04 08:02:50,776 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (Work-Job-Executor-1:ctx-2494f7c7 job-121/job-122 ctx-7f2fe1fe) copyAsync
> inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE
> 2014-08-04 08:02:50,790 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-1:ctx-2494f7c7 job-121/job-122 ctx-7f2fe1fe) Seq
> 1-7372392590005502037: Sending { Cmd , MgmtId: 233845177509765, via:
> 1(Rack1Pod1Host23), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/2/206/2dd5a66f-96a8-3871-bce4-748777aa6529.tar","origUrl":"http://10.147.28.7/templates/lxc-templates/debian.tar.gz","uuid":"005df498-a1fe-4f69-ac27-53a762891389","id":206,"format":"TAR","accountId":2,"checksum":"6d2578f600440f302425839978220b32","hvm":false,"displayText":"deb-final","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/shweta/goleta.lxc.secondary","_role":"Image"}},"name":"206-2-832d2ef8-9355-3958-9331-0847b502ad2a","hypervisorType":"LXC"}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"origUrl":"http://10.147.28.7/templates/lxc-templates/debian.tar.gz","uuid":"005df498-a1fe-4f69-ac27-53a762891389","id":206,"format":"TAR","accountId":2,"checksum":"6d2578f600440f302425839978220b32","hvm":false,"displayText":"deb-final","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"206-2-832d2ef8-9355-3958-9331-0847b502ad2a","hypervisorType":"LXC"}},"executeInSequence":false,"options":{},"wait":10800}}]
> }
> 2014-08-04 08:02:51,092 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
> Seq 1-7372392590005502037: Processing: { Ans: , MgmtId: 233845177509765,
> via: 1, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"005df498-a1fe-4f69-ac27
> .
> .
> .
> .
> .
> after restart MS log shows
> 2014-08-04 08:07:20,606 INFO [o.a.c.s.i.TemplateServiceImpl]
> (AgentConnectTaskPool-6:ctx-5d641ba5) Template Sync did not find routing-8 on
> image store 1, may request download based on available hypervisor types
> 2014-08-04 08:07:20,606 INFO [o.a.c.s.i.TemplateServiceImpl]
> (AgentConnectTaskPool-6:ctx-5d641ba5) Template Sync did not find routing-9 on
> image store 1, may request download based on available hypervisor types
> 2014-08-04 08:07:20,607 INFO [o.a.c.s.i.TemplateServiceImpl]
> (AgentConnectTaskPool-6:ctx-5d641ba5) Template Sync
[jira] [Resolved] (CLOUDSTACK-7305) Hypervisor type parameter is mandatory when deploying VM using ISO
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala resolved CLOUDSTACK-7305. - Resolution: Fixed > Hypervisor type parameter is mandatory when deploying VM using ISO > -- > > Key: CLOUDSTACK-7305 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7305 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0, 4.5.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > We need to make the parameter "hypervisor" mandate when vm deployed using ISO. > Steps to reproduce: > 1) Delpoy a VM from ISO using deployVmAPI without "hypervisor" paramter > 2) deployVmAPI fails > 3) Try to destroy VM (expunge) the VM, it fails with NPE and the VM stays in > "Expunging" state. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7284) Holder for KVM regression test script issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094060#comment-14094060 ] ASF subversion and git services commented on CLOUDSTACK-7284: - Commit 045a290cec2dbdf9b284934a4cd92836c227d513 in cloudstack's branch refs/heads/master from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=045a290 ] CLOUDSTACK-7284: Fixed cleanup issue in test_escalations_snapshots.py > Holder for KVM regression test script issues > > > Key: CLOUDSTACK-7284 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7284 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > This bug is holder for all test script issues identified in KVM regression > run. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7284) Holder for KVM regression test script issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094064#comment-14094064 ] ASF subversion and git services commented on CLOUDSTACK-7284: - Commit 07abf7d7c1cd4953bea0322f21aeb8379fc49e14 in cloudstack's branch refs/heads/master from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=07abf7d ] CLOUDSTACK-7284: Fixed VM delete issue, expunge not allowed by user api client > Holder for KVM regression test script issues > > > Key: CLOUDSTACK-7284 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7284 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > This bug is holder for all test script issues identified in KVM regression > run. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7284) Holder for KVM regression test script issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094067#comment-14094067 ] ASF subversion and git services commented on CLOUDSTACK-7284: - Commit 97ecd5575c4b408ecb4e08a1b81933bb703b324a in cloudstack's branch refs/heads/master from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=97ecd55 ] CLOUDSTACK-7284: Fixed cleanup issue in test_escalations_instances.py, VM should be deleted before deleting the network > Holder for KVM regression test script issues > > > Key: CLOUDSTACK-7284 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7284 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > This bug is holder for all test script issues identified in KVM regression > run. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7322) [Automation] Tag disruptive tests
Alex Brett created CLOUDSTACK-7322: -- Summary: [Automation] Tag disruptive tests Key: CLOUDSTACK-7322 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7322 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 Some Marvin tests are disruptive, in that they cannot be run in parallel with other tests. An example being a test which reboots the secondary storage VM. Current automation systems which run tests in parallel have manually defined lists of these disruptive tests - we should instead put an attribute on them, in order that they can be picked up by standard nosetests attribute filtering, and then run in serial. I have a patch prepared which does this for known disruptive tests, and if accepted I will put some documentation on the wiki regarding how to identify tests which can't be run in parallel using nosetests. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7323) [vGPU] Creation of VM snapshot with "memory" is failing
Abhinav Roy created CLOUDSTACK-7323:
---
Summary: [vGPU] Creation of VM snapshot with "memory" is failing
Key: CLOUDSTACK-7323
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7323
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server, Snapshot
Affects Versions: 4.5.0
Environment: Xenserver 6.2 SP1 + vGPU
Reporter: Abhinav Roy
Priority: Critical
Fix For: 4.5.0
Steps :
1. Deploy CloudStack setup with Xenserver 6.2 sp1 host which has GPU cards.
2. Create a VM with windows template.
3. Install PV drivers in the VM created above.
4. Take VM snapshot with "memory"
Expected behavior :
VM snapshot should be successful.
Observed behavior :
===
VM snapshot fails with the following error :
2014-08-12 19:39:34,089 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-28:ctx-52530808 job-605/job-606) Run VM work job:
com.cloud.vm.snapshot.VmWorkCreateVMSnapshot for VM 38, job origin: 605
2014-08-12 19:39:34,093 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-28:ctx-52530808 job-605/job-606 ctx-05ea1ea9) Execute VM
work job:
com.cloud.vm.snapshot.VmWorkCreateVMSnapshot{"vmSnapshotId":2,"quiesceVm":false,"userId":61,"accountId":61,"vmId":38,"handlerName":"VMSnapshotManagerImpl"}
2014-08-12 19:39:34,120 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-28:ctx-52530808 job-605/job-606 ctx-05ea1ea9) Seq
1-2048293405523443998: Sending { Cmd , MgmtId: 55355881446856, via:
1(cldstk-R720-66), Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.CreateVMSnapshotCommand":{"vmState":"Running","volumeTOs":[{"uuid":"3af646dd-6f53-490a-a897-978428b5d608","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96438f80-3b68-34fe-8492-f6ac9e3db3dc","id":1,"poolType":"NetworkFilesystem","host":"10.102.192.101","path":"/Sailaja/goletaps1","port":2049,"url":"NetworkFilesystem://10.102.192.101/Sailaja/goletaps1/?ROLE=Primary&STOREUUID=96438f80-3b68-34fe-8492-f6ac9e3db3dc"}},"name":"ROOT-38","size":21474836480,"path":"e8645c41-4904-4a7c-adb0-87ce0d414da7","volumeId":39,"vmName":"i-61-38-VM","accountId":61,"format":"VHD","provisioningType":"THIN","id":39,"deviceId":0,"hypervisorType":"XenServer"}],"target":{"id":2,"snapshotName":"i-61-38-VM_VS_20140812140932","type":"DiskAndMemory","current":false,"quiescevm":false},"vmName":"i-61-38-VM","guestOSType":"Windows
8 (64-bit)","platformEmulator":"Windows 8 (64-bit)","wait":1800}}] }
2014-08-12 19:39:34,121 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-28:ctx-52530808 job-605/job-606 ctx-05ea1ea9) Seq
1-2048293405523443998: Executing: { Cmd , MgmtId: 55355881446856, via:
1(cldstk-R720-66), Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.CreateVMSnapshotCommand":{"vmState":"Running","volumeTOs":[{"uuid":"3af646dd-6f53-490a-a897-978428b5d608","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96438f80-3b68-34fe-8492-f6ac9e3db3dc","id":1,"poolType":"NetworkFilesystem","host":"10.102.192.101","path":"/Sailaja/goletaps1","port":2049,"url":"NetworkFilesystem://10.102.192.101/Sailaja/goletaps1/?ROLE=Primary&STOREUUID=96438f80-3b68-34fe-8492-f6ac9e3db3dc"}},"name":"ROOT-38","size":21474836480,"path":"e8645c41-4904-4a7c-adb0-87ce0d414da7","volumeId":39,"vmName":"i-61-38-VM","accountId":61,"format":"VHD","provisioningType":"THIN","id":39,"deviceId":0,"hypervisorType":"XenServer"}],"target":{"id":2,"snapshotName":"i-61-38-VM_VS_20140812140932","type":"DiskAndMemory","current":false,"quiescevm":false},"vmName":"i-61-38-VM","guestOSType":"Windows
8 (64-bit)","platformEmulator":"Windows 8 (64-bit)","wait":1800}}] }
2014-08-12 19:39:34,121 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-36:ctx-9bff71f3) Seq 1-2048293405523443998: Executing request
2014-08-12 19:39:34,224 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-36:ctx-9bff71f3) Task failed! Task record: uuid:
ba41eab1-b90c-a468-d1b3-55b1024b81b8
nameLabel: Async.VM.checkpoint
nameDescription:
allowedOperations: []
currentOperations: {}
created: Tue Aug 12 18:27:26 IST 2014
finished: Tue Aug 12 18:27:26 IST 2014
status: failure
residentOn: com.xensource.xenapi.Host@fb990ea3
progress: 1.0
type:
result:
errorInfo: [VM_HAS_VGPU,
OpaqueRef:f197581b-ad88-d3eb-3229-ab9732fa6aaf]
otherConfig: {CS_VM_SNAPSHOT_KEY=i-61-38-VM_VS_20140812140932}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
2014-08-12 19:39:34,237 ERROR [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-36:ctx-9bff71f3) Creating VM Snapshot i-61-38-VM_VS_20140812140932
failed due to:
2014-08-12 19:39:34
[jira] [Updated] (CLOUDSTACK-7323) [vGPU] Creation of VM snapshot with "memory" is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinav Roy updated CLOUDSTACK-7323:
Attachment: CS-7323.zip
Attaching MS logs and DB dump
> [vGPU] Creation of VM snapshot with "memory" is failing
>
>
> Key: CLOUDSTACK-7323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7323
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Snapshot
>Affects Versions: 4.5.0
> Environment: Xenserver 6.2 SP1 + vGPU
>Reporter: Abhinav Roy
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: CS-7323.zip
>
>
> Steps :
>
> 1. Deploy CloudStack setup with Xenserver 6.2 sp1 host which has GPU cards.
> 2. Create a VM with windows template.
> 3. Install PV drivers in the VM created above.
> 4. Take VM snapshot with "memory"
> Expected behavior :
>
> VM snapshot should be successful.
> Observed behavior :
> ===
> VM snapshot fails with the following error :
> 2014-08-12 19:39:34,089 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-28:ctx-52530808 job-605/job-606) Run VM work job:
> com.cloud.vm.snapshot.VmWorkCreateVMSnapshot for VM 38, job origin: 605
> 2014-08-12 19:39:34,093 DEBUG [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-28:ctx-52530808 job-605/job-606 ctx-05ea1ea9) Execute VM
> work job:
> com.cloud.vm.snapshot.VmWorkCreateVMSnapshot{"vmSnapshotId":2,"quiesceVm":false,"userId":61,"accountId":61,"vmId":38,"handlerName":"VMSnapshotManagerImpl"}
> 2014-08-12 19:39:34,120 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-28:ctx-52530808 job-605/job-606 ctx-05ea1ea9) Seq
> 1-2048293405523443998: Sending { Cmd , MgmtId: 55355881446856, via:
> 1(cldstk-R720-66), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"vmState":"Running","volumeTOs":[{"uuid":"3af646dd-6f53-490a-a897-978428b5d608","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96438f80-3b68-34fe-8492-f6ac9e3db3dc","id":1,"poolType":"NetworkFilesystem","host":"10.102.192.101","path":"/Sailaja/goletaps1","port":2049,"url":"NetworkFilesystem://10.102.192.101/Sailaja/goletaps1/?ROLE=Primary&STOREUUID=96438f80-3b68-34fe-8492-f6ac9e3db3dc"}},"name":"ROOT-38","size":21474836480,"path":"e8645c41-4904-4a7c-adb0-87ce0d414da7","volumeId":39,"vmName":"i-61-38-VM","accountId":61,"format":"VHD","provisioningType":"THIN","id":39,"deviceId":0,"hypervisorType":"XenServer"}],"target":{"id":2,"snapshotName":"i-61-38-VM_VS_20140812140932","type":"DiskAndMemory","current":false,"quiescevm":false},"vmName":"i-61-38-VM","guestOSType":"Windows
> 8 (64-bit)","platformEmulator":"Windows 8 (64-bit)","wait":1800}}] }
> 2014-08-12 19:39:34,121 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-28:ctx-52530808 job-605/job-606 ctx-05ea1ea9) Seq
> 1-2048293405523443998: Executing: { Cmd , MgmtId: 55355881446856, via:
> 1(cldstk-R720-66), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"vmState":"Running","volumeTOs":[{"uuid":"3af646dd-6f53-490a-a897-978428b5d608","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96438f80-3b68-34fe-8492-f6ac9e3db3dc","id":1,"poolType":"NetworkFilesystem","host":"10.102.192.101","path":"/Sailaja/goletaps1","port":2049,"url":"NetworkFilesystem://10.102.192.101/Sailaja/goletaps1/?ROLE=Primary&STOREUUID=96438f80-3b68-34fe-8492-f6ac9e3db3dc"}},"name":"ROOT-38","size":21474836480,"path":"e8645c41-4904-4a7c-adb0-87ce0d414da7","volumeId":39,"vmName":"i-61-38-VM","accountId":61,"format":"VHD","provisioningType":"THIN","id":39,"deviceId":0,"hypervisorType":"XenServer"}],"target":{"id":2,"snapshotName":"i-61-38-VM_VS_20140812140932","type":"DiskAndMemory","current":false,"quiescevm":false},"vmName":"i-61-38-VM","guestOSType":"Windows
> 8 (64-bit)","platformEmulator":"Windows 8 (64-bit)","wait":1800}}] }
> 2014-08-12 19:39:34,121 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-36:ctx-9bff71f3) Seq 1-2048293405523443998: Executing request
> 2014-08-12 19:39:34,224 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-36:ctx-9bff71f3) Task failed! Task record: uuid:
> ba41eab1-b90c-a468-d1b3-55b1024b81b8
>nameLabel: Async.VM.checkpoint
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Tue Aug 12 18:27:26 IST 2014
> finished: Tue Aug 12 18:27:26 IST 2014
> status: failure
> residentOn: com.xensource.xenapi.Host@fb990ea3
> progress: 1.0
> type:
> result:
>errorInfo: [VM_HAS_VGPU,
> O
[jira] [Commented] (CLOUDSTACK-7309) NPE when project was already deleted
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094205#comment-14094205
]
Simon Godard commented on CLOUDSTACK-7309:
--
I faced the same issue yesterday when trying to listUsageRecords after a
project was removed.
The bug is in the following code:
{code:title=ApiResponseHelper.java|borderStyle=solid}
Account account =
ApiDBUtils.findAccountById(usageRecord.getAccountId());
if (account.getType() == Account.ACCOUNT_TYPE_PROJECT) {
//find the project
Project project =
ApiDBUtils.findProjectByProjectAccountId(account.getId());
usageRecResponse.setProjectId(project.getUuid());
usageRecResponse.setProjectName(project.getName());
} else {
usageRecResponse.setAccountId(account.getUuid());
usageRecResponse.setAccountName(account.getAccountName());
}
{code}
The Account lookup by ID is performed including the removed Accounts, but the
Project lookup by ID doesn't included the removed Projects. There is an
assumption that the project won't be null since the account isn't.
I will try to create a Pull request to fix this problem. This is a blocker
issue for us since we rely on the Usage reporting.
> NPE when project was already deleted
>
>
> Key: CLOUDSTACK-7309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7309
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Usage
>Affects Versions: 4.3.0, 4.4.0, 4.3.1
>Reporter: Daniel Vega Simoes
>
> When listing usage records for running VMs and project to which this VM
> belonged was removed, a Null Pointer Exception happens at the time of
> building an usage response. Steps to reproduce the error:
> 1 - create a new project
> 2 - create a new VM under this project
> 3 - remove the project (which also removes the VM)
> 4 - collect usage data (usually happens overnight automatically)
> 5 - list usage records by issuing following command on Cloudmonkey (make sure
> the date range comprises the project removal event)
> list usagerecords startdate=2014-08-05 enddate=2014-08-08 type=1
> Bug happens at the ApiResponseHelper.java file. Whenever account type is
> ACCOUNT_TYPE_PROJECT, it tries to retrieve the Project object, which returns
> null when project was removed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7309) NPE when project was already deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094280#comment-14094280 ] Daniel Vega Simoes commented on CLOUDSTACK-7309: Hi, Simon We implemented a fix for it and submitted for review. You can check it here: https://reviews.apache.org/r/24571/ > NPE when project was already deleted > > > Key: CLOUDSTACK-7309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7309 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0, 4.4.0, 4.3.1 >Reporter: Daniel Vega Simoes > > When listing usage records for running VMs and project to which this VM > belonged was removed, a Null Pointer Exception happens at the time of > building an usage response. Steps to reproduce the error: > 1 - create a new project > 2 - create a new VM under this project > 3 - remove the project (which also removes the VM) > 4 - collect usage data (usually happens overnight automatically) > 5 - list usage records by issuing following command on Cloudmonkey (make sure > the date range comprises the project removal event) > list usagerecords startdate=2014-08-05 enddate=2014-08-08 type=1 > Bug happens at the ApiResponseHelper.java file. Whenever account type is > ACCOUNT_TYPE_PROJECT, it tries to retrieve the Project object, which returns > null when project was removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7309) NPE when project was already deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094297#comment-14094297 ] Simon Godard commented on CLOUDSTACK-7309: -- Thanks Daniel ! > NPE when project was already deleted > > > Key: CLOUDSTACK-7309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7309 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0, 4.4.0, 4.3.1 >Reporter: Daniel Vega Simoes > > When listing usage records for running VMs and project to which this VM > belonged was removed, a Null Pointer Exception happens at the time of > building an usage response. Steps to reproduce the error: > 1 - create a new project > 2 - create a new VM under this project > 3 - remove the project (which also removes the VM) > 4 - collect usage data (usually happens overnight automatically) > 5 - list usage records by issuing following command on Cloudmonkey (make sure > the date range comprises the project removal event) > list usagerecords startdate=2014-08-05 enddate=2014-08-08 type=1 > Bug happens at the ApiResponseHelper.java file. Whenever account type is > ACCOUNT_TYPE_PROJECT, it tries to retrieve the Project object, which returns > null when project was removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7324) listAsyncJobs returns jobs with no cmd
Brian Angus created CLOUDSTACK-7324:
---
Summary: listAsyncJobs returns jobs with no cmd
Key: CLOUDSTACK-7324
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7324
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: Brian Angus
Priority: Minor
when running listAsyncJobs it will return jobids that do not have a cmd.
Like this:{code}
{
"accountid": "72e70a88-18d8-11e4-98d6-5254004eff4f",
"userid": "72e71cf8-18d8-11e4-98d6-5254004eff4f",
"jobstatus": 0,
"jobprocstatus": 0,
"jobresultcode": 0,
"created": "2014-08-07T10:51:43-0600",
"jobid": "d17b557b-e36c-4f1e-badd-2013b1eb3af1"
},
{code}
jobstatus,jobprocstataus, and jobresultcode are always 0.
These appear to be internal threads to cloudstack and not related to any user
submitted jobs.
They do have an entry in the async_job table but provide no useful data in the
listAsyncJobs API call.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6590) No option in UI to acquire secondary IP for VM nic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1409#comment-1409 ] Brian Federle commented on CLOUDSTACK-6590: --- There may have been a regression with this, so it is still an open issue. I will double-check it and fix it if needed. > No option in UI to acquire secondary IP for VM nic > -- > > Key: CLOUDSTACK-6590 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6590 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, UI >Affects Versions: 4.4.0 >Reporter: manasaveloori >Assignee: Brian Federle >Priority: Critical > Fix For: 4.4.0 > > > Deploy a user Vm. > Go to Nics > Observed that there is no option to acquire a secondary ip for the VM nic. > This a regression issue... > Able to acquire the secondary IP using API. > Build commit id: > [root@RHEL63test secondaryxen]# cloudstack-sccs > ed088c72c461c08a061881f78cceae7f74794b9c -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6940) Templates cannot be downloaded from URLs without matching file extensions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-6940: - Description: When registering templates with CloudStack, it is necessary to provide a URL from which the template can be downloaded. CloudStack validates the format of these URLs, but it does so quite aggressively, sometimes rejecting URLs that are perfectly valid. In particular, CloudStack expects and requires the URL to carry a file extension in the end that matches the expected template, eg. ".vhd" or ".vhd.gz". If the URL doesn't have such an extension in the end, it will be rejected, even if it is a perfectly valid URL from which a VHD can be downloaded. was: When registering templates with CloudStack, it is necessary to provide a URL from which the template can be downloaded. CloudStack validates the format of these URLs, but it does so quite aggressively, sometimes rejecting URLs that are perfectly valid. In particular, CloudStack expects and requires the URL to carry a file extension that matches the expected template, eg. ".vhd" or ".vhd.gz". If the URL doesn't have such an extension, it will be rejected, even if it is a perfectly valid URL from which a VHD can be downloaded. > Templates cannot be downloaded from URLs without matching file extensions > - > > Key: CLOUDSTACK-6940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 >Reporter: Min Chen >Assignee: Min Chen > Fix For: 4.5.0 > > > When registering templates with CloudStack, it is necessary to provide a URL > from which the template can be downloaded. > CloudStack validates the format of these URLs, but it does so quite > aggressively, sometimes rejecting URLs that are perfectly valid. > In particular, CloudStack expects and requires the URL to carry a file > extension in the end that matches the expected template, eg. ".vhd" or > ".vhd.gz". If the URL doesn't have such an extension in the end, it will be > rejected, even if it is a perfectly valid URL from which a VHD can be > downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7325) bug in iSCSI disconnectPhysicalDiskByPath
Brian Angus created CLOUDSTACK-7325:
---
Summary: bug in iSCSI disconnectPhysicalDiskByPath
Key: CLOUDSTACK-7325
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7325
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.4.0
Reporter: Brian Angus
in
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/IscsiAdmStorageAdaptor.java
disconnectPhysicalDiskByPath
If the disk does not have {noformat}-iscsi-{noformat} in its path then this
code is ran:{code}
// this volume doesn't below to this adaptor, so just return true
return true;
{code}
It should return false. This way if the disk belongs to another storage
adapter that adapter can disconnect the disk in the
disconnectPhysicalDiskByPath function in KVMStoragePoolManager.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7302) UI: Remove Hover Interaction from breadcrumbs at top page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094468#comment-14094468 ] ASF subversion and git services commented on CLOUDSTACK-7302: - Commit af377430453ecf1fb9b44ed3e29541b7f20ce5d5 in cloudstack's branch refs/heads/master from [~mihaelas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=af37743 ] CLOUDSTACK-7302: UI: Remove Hover Interaction from breadcrumbs at top page Signed-off-by: Mihaela Stoica > UI: Remove Hover Interaction from breadcrumbs at top page > - > > Key: CLOUDSTACK-7302 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7302 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Fix For: 4.5.0 > > > Upon hover over breadcrumb tabs at top of page, user sees pop-up, but is > unable to interact with it. > This was apparently a mistake/ unintended interaction. It should be removed, > so that there is no display on hover. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7288) [Automation] TestRebootRouter.test_reboot_router failing while deleting PF rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-7288:
Assignee: Gaurav Aradhye (was: Rayees Namathponnan)
> [Automation] TestRebootRouter.test_reboot_router failing while deleting PF
> rules
>
>
> Key: CLOUDSTACK-7288
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7288
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM and VMware
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed with BVT run
> test_network. test_reboot_router, performs below steps
> 1) Create account
> 2) Create network , firewall, PF rule, and deploy VM
> 3) login to VM
> 4) Reboot the router
> 5) Delete PF rules
> {noformat}
> 2014-08-07 01:55:21,355 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-3:ctx-4273ec8f ctx-5664d0a7 ctx-79e27adc) ===END=== 10.2
> 23.240.195 -- GET
> jobid=d14d2409-921b-4f44-8539-27523a62b4e5&apiKey=diYjewXwBTISgyIbDjjey2uCbG8aMoca8mpJKVnR5fp_DeHRObdQ
> K8QNg-pSkpfOaqoyovosRz0RzFocRC2mhw&command=queryAsyncJobResult&response=json&signature=PlpuAJmeTDCVh2zzglXff0oaxjo%3D
> 2014-08-07 01:55:21,360 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-200f3091) ===START=== 10.223.240.195 -- GET respo
> nse=json&apiKey=diYjewXwBTISgyIbDjjey2uCbG8aMoca8mpJKVnR5fp_DeHRObdQK8QNg-pSkpfOaqoyovosRz0RzFocRC2mhw&command=deletePort
> ForwardingRule&id=6d6e77b8-11ee-4e04-92a7-e25e42978481&signature=ToF1GXXWkz3YrRz4peulI97nXfM%3D
> 2014-08-07 01:55:21,363 INFO [c.c.h.v.m.VmwareManagerImpl]
> (DirectAgentCronJob-21:ctx-c85f7d8a) Check to see if a worker
> VM with tag 1407403381758-null needs to be recycled
> 2014-08-07 01:55:21,363 ERROR [c.c.h.v.m.VmwareManagerImpl]
> (DirectAgentCronJob-21:ctx-c85f7d8a) Invalid worker VM tag 14
> 07403381758-null
> 2014-08-07 01:55:21,365 DEBUG [c.c.a.d.ParamProcessWorker]
> (catalina-exec-1:ctx-200f3091 ctx-3080c34b ctx-231ae9f3) Objec
> t entity uuid = 6d6e77b8-11ee-4e04-92a7-e25e42978481 does not exist in the
> database.
> 2014-08-07 01:55:21,365 INFO [c.c.a.ApiServer] (catalina-exec-1:ctx-200f3091
> ctx-3080c34b ctx-231ae9f3) Unable to execut
> e API command deleteportforwardingrule due to invalid value. Invalid
> parameter id value=6d6e77b8-11ee-4e04-92a7-e25e42978
> 481 due to incorrect long value format, or entity does not exist or due to
> incorrect parameter annotation for the field i
> n api cmd class.
> 2014-08-07 01:55:21,366 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-200f3091 ctx-3080c34b ctx-231ae9f3) ===END===
> 10.223.240.195 -- GET
> response=json&apiKey=diYjewXwBTISgyIbDjjey2uCbG8aMoca8mpJKVnR5fp_DeHRObdQK8QNg-pSkpfOaqoyovosRz0RzFocRC2mhw&command=deletePortForwardingRule&id=6d6e77b8-11ee-4e04-92a7-e25e42978481&signature=ToF1GXXWkz3YrRz4peulI97nXfM%3D
> 2014-08-07 01:55:21,382 INFO [c.c.h.v.r.VmwareResource]
> (DirectAgentCronJob-82:ctx-dd3254e7) Scan hung worker VM to recycle
> {noformat}
> Logs available at
> https://citrix.sharefile.com/d/s3ebf0273ad349968
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7288) [Automation] TestRebootRouter.test_reboot_router failing while deleting PF rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-7288:
Issue Type: Test (was: Bug)
> [Automation] TestRebootRouter.test_reboot_router failing while deleting PF
> rules
>
>
> Key: CLOUDSTACK-7288
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7288
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM and VMware
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed with BVT run
> test_network. test_reboot_router, performs below steps
> 1) Create account
> 2) Create network , firewall, PF rule, and deploy VM
> 3) login to VM
> 4) Reboot the router
> 5) Delete PF rules
> {noformat}
> 2014-08-07 01:55:21,355 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-3:ctx-4273ec8f ctx-5664d0a7 ctx-79e27adc) ===END=== 10.2
> 23.240.195 -- GET
> jobid=d14d2409-921b-4f44-8539-27523a62b4e5&apiKey=diYjewXwBTISgyIbDjjey2uCbG8aMoca8mpJKVnR5fp_DeHRObdQ
> K8QNg-pSkpfOaqoyovosRz0RzFocRC2mhw&command=queryAsyncJobResult&response=json&signature=PlpuAJmeTDCVh2zzglXff0oaxjo%3D
> 2014-08-07 01:55:21,360 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-200f3091) ===START=== 10.223.240.195 -- GET respo
> nse=json&apiKey=diYjewXwBTISgyIbDjjey2uCbG8aMoca8mpJKVnR5fp_DeHRObdQK8QNg-pSkpfOaqoyovosRz0RzFocRC2mhw&command=deletePort
> ForwardingRule&id=6d6e77b8-11ee-4e04-92a7-e25e42978481&signature=ToF1GXXWkz3YrRz4peulI97nXfM%3D
> 2014-08-07 01:55:21,363 INFO [c.c.h.v.m.VmwareManagerImpl]
> (DirectAgentCronJob-21:ctx-c85f7d8a) Check to see if a worker
> VM with tag 1407403381758-null needs to be recycled
> 2014-08-07 01:55:21,363 ERROR [c.c.h.v.m.VmwareManagerImpl]
> (DirectAgentCronJob-21:ctx-c85f7d8a) Invalid worker VM tag 14
> 07403381758-null
> 2014-08-07 01:55:21,365 DEBUG [c.c.a.d.ParamProcessWorker]
> (catalina-exec-1:ctx-200f3091 ctx-3080c34b ctx-231ae9f3) Objec
> t entity uuid = 6d6e77b8-11ee-4e04-92a7-e25e42978481 does not exist in the
> database.
> 2014-08-07 01:55:21,365 INFO [c.c.a.ApiServer] (catalina-exec-1:ctx-200f3091
> ctx-3080c34b ctx-231ae9f3) Unable to execut
> e API command deleteportforwardingrule due to invalid value. Invalid
> parameter id value=6d6e77b8-11ee-4e04-92a7-e25e42978
> 481 due to incorrect long value format, or entity does not exist or due to
> incorrect parameter annotation for the field i
> n api cmd class.
> 2014-08-07 01:55:21,366 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-200f3091 ctx-3080c34b ctx-231ae9f3) ===END===
> 10.223.240.195 -- GET
> response=json&apiKey=diYjewXwBTISgyIbDjjey2uCbG8aMoca8mpJKVnR5fp_DeHRObdQK8QNg-pSkpfOaqoyovosRz0RzFocRC2mhw&command=deletePortForwardingRule&id=6d6e77b8-11ee-4e04-92a7-e25e42978481&signature=ToF1GXXWkz3YrRz4peulI97nXfM%3D
> 2014-08-07 01:55:21,382 INFO [c.c.h.v.r.VmwareResource]
> (DirectAgentCronJob-82:ctx-dd3254e7) Scan hung worker VM to recycle
> {noformat}
> Logs available at
> https://citrix.sharefile.com/d/s3ebf0273ad349968
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7288) [Automation] TestRebootRouter.test_reboot_router failing while deleting PF rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094478#comment-14094478
]
Rayees Namathponnan commented on CLOUDSTACK-7288:
-
Waiting for this patch to review
https://reviews.apache.org/r/24603/diff/#index_header
> [Automation] TestRebootRouter.test_reboot_router failing while deleting PF
> rules
>
>
> Key: CLOUDSTACK-7288
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7288
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM and VMware
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed with BVT run
> test_network. test_reboot_router, performs below steps
> 1) Create account
> 2) Create network , firewall, PF rule, and deploy VM
> 3) login to VM
> 4) Reboot the router
> 5) Delete PF rules
> {noformat}
> 2014-08-07 01:55:21,355 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-3:ctx-4273ec8f ctx-5664d0a7 ctx-79e27adc) ===END=== 10.2
> 23.240.195 -- GET
> jobid=d14d2409-921b-4f44-8539-27523a62b4e5&apiKey=diYjewXwBTISgyIbDjjey2uCbG8aMoca8mpJKVnR5fp_DeHRObdQ
> K8QNg-pSkpfOaqoyovosRz0RzFocRC2mhw&command=queryAsyncJobResult&response=json&signature=PlpuAJmeTDCVh2zzglXff0oaxjo%3D
> 2014-08-07 01:55:21,360 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-200f3091) ===START=== 10.223.240.195 -- GET respo
> nse=json&apiKey=diYjewXwBTISgyIbDjjey2uCbG8aMoca8mpJKVnR5fp_DeHRObdQK8QNg-pSkpfOaqoyovosRz0RzFocRC2mhw&command=deletePort
> ForwardingRule&id=6d6e77b8-11ee-4e04-92a7-e25e42978481&signature=ToF1GXXWkz3YrRz4peulI97nXfM%3D
> 2014-08-07 01:55:21,363 INFO [c.c.h.v.m.VmwareManagerImpl]
> (DirectAgentCronJob-21:ctx-c85f7d8a) Check to see if a worker
> VM with tag 1407403381758-null needs to be recycled
> 2014-08-07 01:55:21,363 ERROR [c.c.h.v.m.VmwareManagerImpl]
> (DirectAgentCronJob-21:ctx-c85f7d8a) Invalid worker VM tag 14
> 07403381758-null
> 2014-08-07 01:55:21,365 DEBUG [c.c.a.d.ParamProcessWorker]
> (catalina-exec-1:ctx-200f3091 ctx-3080c34b ctx-231ae9f3) Objec
> t entity uuid = 6d6e77b8-11ee-4e04-92a7-e25e42978481 does not exist in the
> database.
> 2014-08-07 01:55:21,365 INFO [c.c.a.ApiServer] (catalina-exec-1:ctx-200f3091
> ctx-3080c34b ctx-231ae9f3) Unable to execut
> e API command deleteportforwardingrule due to invalid value. Invalid
> parameter id value=6d6e77b8-11ee-4e04-92a7-e25e42978
> 481 due to incorrect long value format, or entity does not exist or due to
> incorrect parameter annotation for the field i
> n api cmd class.
> 2014-08-07 01:55:21,366 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-200f3091 ctx-3080c34b ctx-231ae9f3) ===END===
> 10.223.240.195 -- GET
> response=json&apiKey=diYjewXwBTISgyIbDjjey2uCbG8aMoca8mpJKVnR5fp_DeHRObdQK8QNg-pSkpfOaqoyovosRz0RzFocRC2mhw&command=deletePortForwardingRule&id=6d6e77b8-11ee-4e04-92a7-e25e42978481&signature=ToF1GXXWkz3YrRz4peulI97nXfM%3D
> 2014-08-07 01:55:21,382 INFO [c.c.h.v.r.VmwareResource]
> (DirectAgentCronJob-82:ctx-dd3254e7) Scan hung worker VM to recycle
> {noformat}
> Logs available at
> https://citrix.sharefile.com/d/s3ebf0273ad349968
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7310) [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7310: Issue Type: Test (was: Bug) > [Automation] XenServer does not support shrink data disk. CloudStack should > prevent such an operation on XenServer > -- > > Key: CLOUDSTACK-7310 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Volumes, XenServer >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > XenServer does not allowing shrinking of disks currently. Please add code on > Cloudstack to prevent such an operation (similar to VMWare case). Failing to > prevent such an operation on XenServer leads to > https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7310) [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7310: Assignee: Chandan Purushothama > [Automation] XenServer does not support shrink data disk. CloudStack should > prevent such an operation on XenServer > -- > > Key: CLOUDSTACK-7310 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Volumes, XenServer >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > XenServer does not allowing shrinking of disks currently. Please add code on > Cloudstack to prevent such an operation (similar to VMWare case). Failing to > prevent such an operation on XenServer leads to > https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6940) Templates cannot be downloaded from URLs without matching file extensions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094492#comment-14094492 ] ASF subversion and git services commented on CLOUDSTACK-6940: - Commit a8316de725db149aec8545bb5b0dfb7c71be2824 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a8316de ] Revert "CLOUDSTACK-6940:Templates cannot be downloaded from URLs without" This reverts commit 569e94908b6fa471f2f72578e1ff21f3fa7c6a4e. > Templates cannot be downloaded from URLs without matching file extensions > - > > Key: CLOUDSTACK-6940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 >Reporter: Min Chen >Assignee: Min Chen > Fix For: 4.5.0 > > > When registering templates with CloudStack, it is necessary to provide a URL > from which the template can be downloaded. > CloudStack validates the format of these URLs, but it does so quite > aggressively, sometimes rejecting URLs that are perfectly valid. > In particular, CloudStack expects and requires the URL to carry a file > extension in the end that matches the expected template, eg. ".vhd" or > ".vhd.gz". If the URL doesn't have such an extension in the end, it will be > rejected, even if it is a perfectly valid URL from which a VHD can be > downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7312) ISO/volume format name checking is crude and doesn't work with advanced URLs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094494#comment-14094494
]
ASF subversion and git services commented on CLOUDSTACK-7312:
-
Commit 83bd4d60f118050840cf53e9636c6e0582ad in cloudstack's branch
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=83bd4d6 ]
Revert "CLOUDSTACK-7312:ISOs cannot be downloaded from URLs without matching"
This reverts commit 737f76df8c8b47ba347ae46fc10d73b1fee6.
> ISO/volume format name checking is crude and doesn't work with advanced URLs
>
>
> Key: CLOUDSTACK-7312
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7312
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller
>Affects Versions: 4.2.0
>Reporter: Min Chen
>Assignee: Min Chen
> Fix For: 4.5.0
>
>
> When registering ISO/Volume with CloudStack, it is necessary to provide a URL
> from which the ISO/Volume can be downloaded.
> SO/Volume name checking currently just looks at the very end of the url
> string. e.g.:
> private void checkFormat(String format, String url) {
> if((!url.toLowerCase().endsWith("vhd"))
> This breaks functionality for S3 pre-signed URL, or anything where the file
> extension is not the last part of the URL. We should at least attempt to
> parse the URL for filename vs parameters.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6940) Templates cannot be downloaded from URLs without matching file extensions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094497#comment-14094497 ] ASF subversion and git services commented on CLOUDSTACK-6940: - Commit e3564658befaa72cbe5fd510bea2a25b40f108f5 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e356465 ] CLOUDSTACK-6940, CLOUDSTACK-7312, CLOUDSTACK-5512: Template/ISO/Volume upload rejects some valid URL formats. Also consolidate URL format check into one util routine. > Templates cannot be downloaded from URLs without matching file extensions > - > > Key: CLOUDSTACK-6940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 >Reporter: Min Chen >Assignee: Min Chen > Fix For: 4.5.0 > > > When registering templates with CloudStack, it is necessary to provide a URL > from which the template can be downloaded. > CloudStack validates the format of these URLs, but it does so quite > aggressively, sometimes rejecting URLs that are perfectly valid. > In particular, CloudStack expects and requires the URL to carry a file > extension in the end that matches the expected template, eg. ".vhd" or > ".vhd.gz". If the URL doesn't have such an extension in the end, it will be > rejected, even if it is a perfectly valid URL from which a VHD can be > downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5512) template format name checking is crude and doesn't work with advanced URLs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094503#comment-14094503
]
ASF subversion and git services commented on CLOUDSTACK-5512:
-
Commit e3564658befaa72cbe5fd510bea2a25b40f108f5 in cloudstack's branch
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e356465 ]
CLOUDSTACK-6940, CLOUDSTACK-7312, CLOUDSTACK-5512: Template/ISO/Volume
upload rejects some valid URL formats. Also consolidate URL format check
into one util routine.
> template format name checking is crude and doesn't work with advanced URLs
> --
>
> Key: CLOUDSTACK-5512
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5512
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.0.0, 4.1.0, 4.2.0
>Reporter: Marcus Sorensen
>Assignee: Rohit Yadav
> Fix For: 4.4.0
>
>
> Template name checking currently just looks at the very end of the url
> string. e.g.:
> private void checkFormat(String format, String url) {
> if((!url.toLowerCase().endsWith("vhd"))
> This breaks functionality such as registering a template via an S3 pre-signed
> URL, or anything where the file extension is not the last part of the URL. We
> should at least attempt to parse the URL for filename vs parameters.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7312) ISO/volume format name checking is crude and doesn't work with advanced URLs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094499#comment-14094499
]
ASF subversion and git services commented on CLOUDSTACK-7312:
-
Commit e3564658befaa72cbe5fd510bea2a25b40f108f5 in cloudstack's branch
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e356465 ]
CLOUDSTACK-6940, CLOUDSTACK-7312, CLOUDSTACK-5512: Template/ISO/Volume
upload rejects some valid URL formats. Also consolidate URL format check
into one util routine.
> ISO/volume format name checking is crude and doesn't work with advanced URLs
>
>
> Key: CLOUDSTACK-7312
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7312
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller
>Affects Versions: 4.2.0
>Reporter: Min Chen
>Assignee: Min Chen
> Fix For: 4.5.0
>
>
> When registering ISO/Volume with CloudStack, it is necessary to provide a URL
> from which the ISO/Volume can be downloaded.
> SO/Volume name checking currently just looks at the very end of the url
> string. e.g.:
> private void checkFormat(String format, String url) {
> if((!url.toLowerCase().endsWith("vhd"))
> This breaks functionality for S3 pre-signed URL, or anything where the file
> extension is not the last part of the URL. We should at least attempt to
> parse the URL for filename vs parameters.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7310) [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama updated CLOUDSTACK-7310: - Issue Type: Bug (was: Test) > [Automation] XenServer does not support shrink data disk. CloudStack should > prevent such an operation on XenServer > -- > > Key: CLOUDSTACK-7310 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Volumes, XenServer >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > XenServer does not allowing shrinking of disks currently. Please add code on > Cloudstack to prevent such an operation (similar to VMWare case). Failing to > prevent such an operation on XenServer leads to > https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7310) [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama updated CLOUDSTACK-7310: - Assignee: Animesh Chaturvedi (was: Chandan Purushothama) > [Automation] XenServer does not support shrink data disk. CloudStack should > prevent such an operation on XenServer > -- > > Key: CLOUDSTACK-7310 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Volumes, XenServer >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Animesh Chaturvedi >Priority: Critical > Fix For: 4.5.0 > > > XenServer does not allowing shrinking of disks currently. Please add code on > Cloudstack to prevent such an operation (similar to VMWare case). Failing to > prevent such an operation on XenServer leads to > https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7310) [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094558#comment-14094558 ] Chandan Purushothama commented on CLOUDSTACK-7310: -- Rayees, I already addressed the test case in BVT Test Suite. This bug is to fix the problem with the CloudStack Code, Thank you, Chandan. > [Automation] XenServer does not support shrink data disk. CloudStack should > prevent such an operation on XenServer > -- > > Key: CLOUDSTACK-7310 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Volumes, XenServer >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Animesh Chaturvedi >Priority: Critical > Fix For: 4.5.0 > > > XenServer does not allowing shrinking of disks currently. Please add code on > Cloudstack to prevent such an operation (similar to VMWare case). Failing to > prevent such an operation on XenServer leads to > https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6590) No option in UI to acquire secondary IP for VM nic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-6590. --- Resolution: Fixed commit d9fcb877309ce176d5458e63bfd1a174344b5fce Author: Brian Federle Date: Tue Aug 12 13:19:40 2014 -0700 CLOUDSTACK-6590: Fix view all link for multi-item detail view -- Specifically, this fixes issue where secondary IP 'view all' link was not displaying, due to a change in the rows' CSS naming conventions in the widget. > No option in UI to acquire secondary IP for VM nic > -- > > Key: CLOUDSTACK-6590 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6590 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, UI >Affects Versions: 4.4.0 >Reporter: manasaveloori >Assignee: Brian Federle >Priority: Critical > Fix For: 4.4.0 > > > Deploy a user Vm. > Go to Nics > Observed that there is no option to acquire a secondary ip for the VM nic. > This a regression issue... > Able to acquire the secondary IP using API. > Build commit id: > [root@RHEL63test secondaryxen]# cloudstack-sccs > ed088c72c461c08a061881f78cceae7f74794b9c -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6590) No option in UI to acquire secondary IP for VM nic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094609#comment-14094609 ] ASF subversion and git services commented on CLOUDSTACK-6590: - Commit d9fcb877309ce176d5458e63bfd1a174344b5fce in cloudstack's branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d9fcb87 ] CLOUDSTACK-6590: Fix view all link for multi-item detail view -- Specifically, this fixes issue where secondary IP 'view all' link was not displaying, due to a change in the rows' CSS naming conventions in the widget. > No option in UI to acquire secondary IP for VM nic > -- > > Key: CLOUDSTACK-6590 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6590 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, UI >Affects Versions: 4.4.0 >Reporter: manasaveloori >Assignee: Brian Federle >Priority: Critical > Fix For: 4.4.0 > > > Deploy a user Vm. > Go to Nics > Observed that there is no option to acquire a secondary ip for the VM nic. > This a regression issue... > Able to acquire the secondary IP using API. > Build commit id: > [root@RHEL63test secondaryxen]# cloudstack-sccs > ed088c72c461c08a061881f78cceae7f74794b9c -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7327) Failed to deploy instance when using an IP from freshly added IP pool
Loic Lambiel created CLOUDSTACK-7327:
Summary: Failed to deploy instance when using an IP from freshly
added IP pool
Key: CLOUDSTACK-7327
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7327
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.3.0
Environment: Cloudstack 4.3, Basic networking, KVM on ubuntu 12.04
Reporter: Loic Lambiel
Hi,
We have a case where an instance failed to deploy when it takes an IP from a
freshly added IP pool range.
Our setup: Cloudstack 4.3, Basic networking, KVM on Ubuntu 12.04. Our setup is
running since 4.0.0.
The workaround is to change the vlan_id field of the ip pool in the cloud.vlan
table from "EC2://untagged" to "untagged"
Below the logs:
*Management server:*
{quote}
ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-13:ctx-3e34bc70
ctx-b69247df) Failed to start instance
VM[User|VM-fe3812d7-9d3d-49d8-9692-d9a8c976
6c6f]
com.cloud.utils.exception.CloudRuntimeException: Unable to get answer that is
of class com.cloud.agent.api.StartAnswer
at com.cloud.agent.manager.Commands.getAnswer(Commands.java:80)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:992)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601)
at
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:228)
at
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3581)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3161)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3147)
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:606)
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
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
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 com.sun.proxy.$Proxy169.startVirtualMachine(Unknown Source)
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:443)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
at
com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109)
at
com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66)
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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:509)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
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
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAd
[jira] [Assigned] (CLOUDSTACK-25) Allow Virtual Load Balancer with basic zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk reassigned CLOUDSTACK-25: --- Assignee: Alena Prokharchyk > Allow Virtual Load Balancer with basic zone > --- > > Key: CLOUDSTACK-25 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-25 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Caleb Call >Assignee: Alena Prokharchyk > Fix For: Future > > > Currently, using a virtual lb is not allowed when using a basic zone. This > would be a great feature to have for companies that don't have hardware load > balancers. I'm told this was an option in the 2.x branch but got left out of > 3.x. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-25) Allow Virtual Load Balancer with basic zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-25: Assignee: (was: Alena Prokharchyk) > Allow Virtual Load Balancer with basic zone > --- > > Key: CLOUDSTACK-25 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-25 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Caleb Call > Fix For: Future > > > Currently, using a virtual lb is not allowed when using a basic zone. This > would be a great feature to have for companies that don't have hardware load > balancers. I'm told this was an option in the 2.x branch but got left out of > 3.x. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7328) [Automation] Register ISO failing with error "CentOS-6.4-i386-minimal.iso is an invalid for the format iso"
Rayees Namathponnan created CLOUDSTACK-7328: --- Summary: [Automation] Register ISO failing with error "CentOS-6.4-i386-minimal.iso is an invalid for the format iso" Key: CLOUDSTACK-7328 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: ISO Affects Versions: 4.5.0 Environment: KVM and Xen Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.5.0 Attachments: vmops.log Steps to reproduce 1) Run the BVT test TestISO Register ISO fails with below error 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET account=test-a-TestCreateIso-W648O8&domainid=af30b8e6-2219-11e4-9b06-00163e189e44&name=ISO+1&isfeatured=True&ispublic=True&isextractable=True&zoneid=144183bf-f5a5-4b7e-810e-a5136db32441&url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.iso&apiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQw&displaytext=Test+ISO+1&ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44&signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3D&command=registerIso&response=json 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) Created a vif fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for the format iso -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7328) [Automation] Register ISO failing with error "CentOS-6.4-i386-minimal.iso is an invalid for the format iso"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7328: Attachment: vmops.log > [Automation] Register ISO failing with error "CentOS-6.4-i386-minimal.iso is > an invalid for the format iso" > --- > > Key: CLOUDSTACK-7328 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO >Affects Versions: 4.5.0 > Environment: KVM and Xen >Reporter: Rayees Namathponnan >Priority: Blocker > Fix For: 4.5.0 > > Attachments: vmops.log > > > Steps to reproduce > 1) Run the BVT test TestISO > Register ISO fails with below error > 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] > (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET > account=test-a-TestCreateIso-W648O8&domainid=af30b8e6-2219-11e4-9b06-00163e189e44&name=ISO+1&isfeatured=True&ispublic=True&isextractable=True&zoneid=144183bf-f5a5-4b7e-810e-a5136db32441&url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.iso&apiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQw&displaytext=Test+ISO+1&ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44&signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3D&command=registerIso&response=json > 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is > 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e > 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) Created a vif > fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 > 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] > (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please > specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for > the format iso -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7328) [Automation] Register ISO failing with invalid iso format error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7328: Summary: [Automation] Register ISO failing with invalid iso format error (was: [Automation] Register ISO failing with error "CentOS-6.4-i386-minimal.iso is an invalid for the format iso") > [Automation] Register ISO failing with invalid iso format error > - > > Key: CLOUDSTACK-7328 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO >Affects Versions: 4.5.0 > Environment: KVM and Xen >Reporter: Rayees Namathponnan >Priority: Blocker > Fix For: 4.5.0 > > Attachments: vmops.log > > > Steps to reproduce > 1) Run the BVT test TestISO > Register ISO fails with below error > 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] > (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET > account=test-a-TestCreateIso-W648O8&domainid=af30b8e6-2219-11e4-9b06-00163e189e44&name=ISO+1&isfeatured=True&ispublic=True&isextractable=True&zoneid=144183bf-f5a5-4b7e-810e-a5136db32441&url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.iso&apiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQw&displaytext=Test+ISO+1&ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44&signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3D&command=registerIso&response=json > 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is > 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e > 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) Created a vif > fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 > 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] > (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please > specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for > the format iso -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7328) [Automation] Register ISO failing with invalid iso format error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7328: Description: Steps to reproduce 1) Run the BVT test TestISO 2) Test case registering ISO with valid URL, Result Register ISO fails with below error 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET account=test-a-TestCreateIso-W648O8&domainid=af30b8e6-2219-11e4-9b06-00163e189e44&name=ISO+1&isfeatured=True&ispublic=True&isextractable=True&zoneid=144183bf-f5a5-4b7e-810e-a5136db32441&url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.iso&apiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQw&displaytext=Test+ISO+1&ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44&signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3D&command=registerIso&response=json 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) Created a vif fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for the format iso was: Steps to reproduce 1) Run the BVT test TestISO Register ISO fails with below error 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET account=test-a-TestCreateIso-W648O8&domainid=af30b8e6-2219-11e4-9b06-00163e189e44&name=ISO+1&isfeatured=True&ispublic=True&isextractable=True&zoneid=144183bf-f5a5-4b7e-810e-a5136db32441&url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.iso&apiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQw&displaytext=Test+ISO+1&ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44&signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3D&command=registerIso&response=json 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) Created a vif fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for the format iso > [Automation] Register ISO failing with invalid iso format error > - > > Key: CLOUDSTACK-7328 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO >Affects Versions: 4.5.0 > Environment: KVM and Xen >Reporter: Rayees Namathponnan >Priority: Blocker > Fix For: 4.5.0 > > Attachments: vmops.log > > > Steps to reproduce > 1) Run the BVT test TestISO > 2) Test case registering ISO with valid URL, > Result > Register ISO fails with below error > 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] > (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET > account=test-a-TestCreateIso-W648O8&domainid=af30b8e6-2219-11e4-9b06-00163e189e44&name=ISO+1&isfeatured=True&ispublic=True&isextractable=True&zoneid=144183bf-f5a5-4b7e-810e-a5136db32441&url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.iso&apiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQw&displaytext=Test+ISO+1&ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44&signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3D&command=registerIso&response=json > 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is > 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e > 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) Created a vif > fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 > 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] > (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please > specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for > the format iso -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-7328) [Automation] Register ISO failing with invalid iso format error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7328: Assignee: Min Chen > [Automation] Register ISO failing with invalid iso format error > - > > Key: CLOUDSTACK-7328 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO >Affects Versions: 4.5.0 > Environment: KVM and Xen >Reporter: Rayees Namathponnan >Assignee: Min Chen >Priority: Blocker > Fix For: 4.5.0 > > Attachments: vmops.log > > > Steps to reproduce > 1) Run the BVT test TestISO > 2) Test case registering ISO with valid URL, > Result > Register ISO fails with below error > 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] > (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET > account=test-a-TestCreateIso-W648O8&domainid=af30b8e6-2219-11e4-9b06-00163e189e44&name=ISO+1&isfeatured=True&ispublic=True&isextractable=True&zoneid=144183bf-f5a5-4b7e-810e-a5136db32441&url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.iso&apiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQw&displaytext=Test+ISO+1&ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44&signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3D&command=registerIso&response=json > 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is > 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e > 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) Created a vif > fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 > 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] > (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please > specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for > the format iso -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7309) NPE when project was already deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094765#comment-14094765 ] ASF subversion and git services commented on CLOUDSTACK-7309: - Commit e7ef14abae3b0fd43a391eb6757088fd98e74253 in cloudstack's branch refs/heads/4.3 from Luis Henrique Okama [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e7ef14a ] bugfix CLOUDSTACK-7309 using findProjectByProjectAccountIdIncludingRemoved Signed-off-by: Rohit Yadav > NPE when project was already deleted > > > Key: CLOUDSTACK-7309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7309 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0, 4.4.0, 4.3.1 >Reporter: Daniel Vega Simoes > > When listing usage records for running VMs and project to which this VM > belonged was removed, a Null Pointer Exception happens at the time of > building an usage response. Steps to reproduce the error: > 1 - create a new project > 2 - create a new VM under this project > 3 - remove the project (which also removes the VM) > 4 - collect usage data (usually happens overnight automatically) > 5 - list usage records by issuing following command on Cloudmonkey (make sure > the date range comprises the project removal event) > list usagerecords startdate=2014-08-05 enddate=2014-08-08 type=1 > Bug happens at the ApiResponseHelper.java file. Whenever account type is > ACCOUNT_TYPE_PROJECT, it tries to retrieve the Project object, which returns > null when project was removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7309) NPE when project was already deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094769#comment-14094769 ] ASF subversion and git services commented on CLOUDSTACK-7309: - Commit 260e694e89cdf15d224ea3b137987e8a44549a18 in cloudstack's branch refs/heads/4.4 from Luis Henrique Okama [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=260e694 ] bugfix CLOUDSTACK-7309 using findProjectByProjectAccountIdIncludingRemoved Signed-off-by: Rohit Yadav > NPE when project was already deleted > > > Key: CLOUDSTACK-7309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7309 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0, 4.4.0, 4.3.1 >Reporter: Daniel Vega Simoes > > When listing usage records for running VMs and project to which this VM > belonged was removed, a Null Pointer Exception happens at the time of > building an usage response. Steps to reproduce the error: > 1 - create a new project > 2 - create a new VM under this project > 3 - remove the project (which also removes the VM) > 4 - collect usage data (usually happens overnight automatically) > 5 - list usage records by issuing following command on Cloudmonkey (make sure > the date range comprises the project removal event) > list usagerecords startdate=2014-08-05 enddate=2014-08-08 type=1 > Bug happens at the ApiResponseHelper.java file. Whenever account type is > ACCOUNT_TYPE_PROJECT, it tries to retrieve the Project object, which returns > null when project was removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7309) NPE when project was already deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094773#comment-14094773 ] ASF subversion and git services commented on CLOUDSTACK-7309: - Commit cb9319d3d8a1269af786986d49df6c41c69833c1 in cloudstack's branch refs/heads/master from Luis Henrique Okama [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cb9319d ] bugfix CLOUDSTACK-7309 using findProjectByProjectAccountIdIncludingRemoved Signed-off-by: Rohit Yadav > NPE when project was already deleted > > > Key: CLOUDSTACK-7309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7309 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0, 4.4.0, 4.3.1 >Reporter: Daniel Vega Simoes > Fix For: 4.4.0, 4.4.1 > > > When listing usage records for running VMs and project to which this VM > belonged was removed, a Null Pointer Exception happens at the time of > building an usage response. Steps to reproduce the error: > 1 - create a new project > 2 - create a new VM under this project > 3 - remove the project (which also removes the VM) > 4 - collect usage data (usually happens overnight automatically) > 5 - list usage records by issuing following command on Cloudmonkey (make sure > the date range comprises the project removal event) > list usagerecords startdate=2014-08-05 enddate=2014-08-08 type=1 > Bug happens at the ApiResponseHelper.java file. Whenever account type is > ACCOUNT_TYPE_PROJECT, it tries to retrieve the Project object, which returns > null when project was removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7309) NPE when project was already deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-7309. - Resolution: Fixed > NPE when project was already deleted > > > Key: CLOUDSTACK-7309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7309 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0, 4.4.0, 4.3.1 >Reporter: Daniel Vega Simoes > > When listing usage records for running VMs and project to which this VM > belonged was removed, a Null Pointer Exception happens at the time of > building an usage response. Steps to reproduce the error: > 1 - create a new project > 2 - create a new VM under this project > 3 - remove the project (which also removes the VM) > 4 - collect usage data (usually happens overnight automatically) > 5 - list usage records by issuing following command on Cloudmonkey (make sure > the date range comprises the project removal event) > list usagerecords startdate=2014-08-05 enddate=2014-08-08 type=1 > Bug happens at the ApiResponseHelper.java file. Whenever account type is > ACCOUNT_TYPE_PROJECT, it tries to retrieve the Project object, which returns > null when project was removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7329) [Automation] Test suite "test_region_vpc" fails with error in service offering
Rayees Namathponnan created CLOUDSTACK-7329:
---
Summary: [Automation] Test suite "test_region_vpc" fails with
error in service offering
Key: CLOUDSTACK-7329
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7329
Project: CloudStack
Issue Type: Test
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Priority: Critical
Fix For: 4.5.0
Test cases from test_region_vpc failing due to wrong service offering
1)
integration.component.test_region_vpc.TestRegionVpcOffering.test_01_create_vpc_offering_with_regionlevelvpc_service_capability
Error Message
VPC offering is not set up for region level VPC
>> begin captured stdout << -
=== TestName:
test_01_create_vpc_offering_with_regionlevelvpc_service_capability | Status :
FAILED ===
- >> end captured stdout << --
>> begin captured logging <<
CSLog: DEBUG: Payload: {'apiKey':
u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
'command': 'listDomains', 'signature': 'LT9kazKdEbvGfsD7KsWGo0Z9Zgw=',
'response': 'json'}
CSLog: DEBUG: Sending GET Cmd : listDomains===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.49.195
2)
integration.component.test_region_vpc.TestRegionVpcOffering.test_02_create_vpc_from_offering_with_regionlevelvpc_service_capability
Error Message
VPC created should have 'distributedvpcrouter' set to True
>> begin captured stdout << -
=== TestName:
test_02_create_vpc_from_offering_with_regionlevelvpc_service_capability |
Status : FAILED ===
3)
integration.component.test_region_vpc.TestRegionVpcOffering.test_03_deploy_vms_in_vpc_with_regionlevelvp
VPC offering is not set up for region level VPC
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7309) NPE when project was already deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-7309: Fix Version/s: 4.4.1 4.4.0 > NPE when project was already deleted > > > Key: CLOUDSTACK-7309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7309 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0, 4.4.0, 4.3.1 >Reporter: Daniel Vega Simoes > Fix For: 4.4.0, 4.4.1 > > > When listing usage records for running VMs and project to which this VM > belonged was removed, a Null Pointer Exception happens at the time of > building an usage response. Steps to reproduce the error: > 1 - create a new project > 2 - create a new VM under this project > 3 - remove the project (which also removes the VM) > 4 - collect usage data (usually happens overnight automatically) > 5 - list usage records by issuing following command on Cloudmonkey (make sure > the date range comprises the project removal event) > list usagerecords startdate=2014-08-05 enddate=2014-08-08 type=1 > Bug happens at the ApiResponseHelper.java file. Whenever account type is > ACCOUNT_TYPE_PROJECT, it tries to retrieve the Project object, which returns > null when project was removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7328) [Automation] Register ISO failing with invalid iso format error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094803#comment-14094803 ] ASF subversion and git services commented on CLOUDSTACK-7328: - Commit a22abeb0e7c8090f018b65e8a0594db589a13cd2 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a22abeb ] CLOUDSTACK-7328:[Automation] Register ISO failing with invalid iso format error. > [Automation] Register ISO failing with invalid iso format error > - > > Key: CLOUDSTACK-7328 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO >Affects Versions: 4.5.0 > Environment: KVM and Xen >Reporter: Rayees Namathponnan >Assignee: Min Chen >Priority: Blocker > Fix For: 4.5.0 > > Attachments: vmops.log > > > Steps to reproduce > 1) Run the BVT test TestISO > 2) Test case registering ISO with valid URL, > Result > Register ISO fails with below error > 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] > (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET > account=test-a-TestCreateIso-W648O8&domainid=af30b8e6-2219-11e4-9b06-00163e189e44&name=ISO+1&isfeatured=True&ispublic=True&isextractable=True&zoneid=144183bf-f5a5-4b7e-810e-a5136db32441&url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.iso&apiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQw&displaytext=Test+ISO+1&ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44&signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3D&command=registerIso&response=json > 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is > 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e > 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-157:ctx-44b5242a) Created a vif > fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 > 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] > (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please > specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for > the format iso -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7330) [Automation] test_persistent_networks.TestVPCNetworkOperations test failed to ListNetwrok API call
Rayees Namathponnan created CLOUDSTACK-7330:
---
Summary: [Automation]
test_persistent_networks.TestVPCNetworkOperations test failed to ListNetwrok
API call
Key: CLOUDSTACK-7330
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7330
Project: CloudStack
Issue Type: Test
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Priority: Critical
Fix For: 4.5.0
Test integration/component/test_persistent_networks.py", line 1928, in
test_vpc_force_delete_domain failing while list network
test_vpc_force_delete_domain
(integration.component.test_persistent_networks.TestVPCNetworkOperations):
DEBUG: Response : {domain : u'domain-4M0XO1', specifyipranges : False, related
: u'6286d150-0603-45e1-8ae7-7c017ea08f00', zoneid :
u'169dbf29-8372-43f9-891d-8002e7d27f3f', domainid :
u'427de23b-229f-48f1-8a4d-ce700e66fbc6', displaytext : u'Isolated Network',
gateway : u'10.1.1.1', canusefordeploy : True, physicalnetworkid :
u'8cf2dd88-61b7-45b5-9be9-79acc15981de', networkdomain : u'csbcauto.advanced',
service : [{name : u'StaticNat'}, {capability : [{value : u'true', name :
u'DhcpAccrossMultipleSubnets', canchooseservicecapability : False}], name :
u'Dhcp'}, {capability : [{value : u's2svpn', name : u'VpnTypes',
canchooseservicecapability : False}, {value : u'pptp,l2tp,ipsec', name :
u'SupportedVpnTypes', canchooseservicecapability : False}], name : u'Vpn'},
{capability : [{value : u'peraccount', name : u'SupportedSourceNatTypes',
canchooseservicecapability : False}, {value : u'false', name :
u'RedundantRouter', canchooseservicecapability : False}], name : u'SourceNat'},
{name : u'PortForwarding'}, {capability : [{value : u'tcp,udp,icmp', name :
u'SupportedProtocols', canchooseservicecapability : False}], name :
u'NetworkACL'}, {capability : [{value : u'true', name :
u'AllowDnsSuffixModification', canchooseservicecapability : False}], name :
u'Dns'}, {name : u'UserData'}], strechedl2subnet : False, id :
u'6286d150-0603-45e1-8ae7-7c017ea08f00', state : u'Implemented', type :
u'Isolated', broadcasturi : u'vlan://2347', zonename : u'Adv-KVM-Zone1',
networkofferingavailability : u'Optional', networkofferingid :
u'1079d837-1006-4ed4-8275-3874dc03f352', tags : [], displaynetwork : True, vlan
: u'2347', networkofferingdisplaytext : u'VPC Network off-CZSZH7', traffictype
: u'Guest', netmask : u'255.255.255.0', vpcid :
u'f1c80510-9971-49de-a25a-3b421a6927ce', cidr : u'10.1.1.0/24', restartrequired
: False, broadcastdomaintype : u'Vlan', account :
u'test-a-TestVPCNetworkOperations-test_vpc_force_delete_domain-3K82RQ',
ispersistent : True, name : u'Isolated Network', dns1 : u'8.8.8.8',
networkofferingconservemode : False, acltype : u'Account', networkofferingname
: u'VPC Network offering-B2EPH9', issystem : False}
test_vpc_force_delete_domain
(integration.component.test_persistent_networks.TestVPCNetworkOperations):
DEBUG: Payload: {'apiKey':
u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
'id': u'6286d150-0603-45e1-8ae7-7c017ea08f00', 'response': 'json', 'command':
'listNetworks', 'signature': 'd4+7JeVeAlODVIDRzOkZtn5wxh0='}
test_vpc_force_delete_domain
(integration.component.test_persistent_networks.TestVPCNetworkOperations):
DEBUG: Sending GET Cmd : listNetworks===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.49.195
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?signature=d4%2B7JeVeAlODVIDRzOkZtn5wxh0%3D&apiKey=78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ&command=listNetworks&id=6286d150-0603-45e1-8ae7-7c017ea08f00&response=json
HTTP/1.1" 200 32
test_vpc_force_delete_domain
(integration.component.test_persistent_networks.TestVPCNetworkOperations):
DEBUG: Response : None
test_vpc_force_delete_domain
(integration.component.test_persistent_networks.TestVPCNetworkOperations):
CRITICAL: FAILED: test_vpc_force_delete_domain: ['Traceback (most recent call
last):\n', ' File "/usr/local/lib/python2.7/unittest/case.py", line 318, in
run\ntestMethod()\n', ' File
"/Repo_30X/ipcl/cloudstack/test/integration/component/test_persistent_networks.py",
line 1928, in test_vpc_force_delete_domain\nself.fail(e)\n', ' File
"/usr/local/lib/python2.7/unittest/case.py", line 393, in fail\nraise
self.failureException(msg)\n', 'AssertionError: Networks list validation
failed\n']
- >> end captured logging << -
Stacktrace
File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
testMethod()
File
"/Repo_30X/ipcl/cloudstack/test/integration/component/test_persistent_networks.py",
line 1928, in test_vpc_for
[jira] [Created] (CLOUDSTACK-7331) [Automation] test_vpc_network_life_cycle_1_delete failed while deleting VPC network
Rayees Namathponnan created CLOUDSTACK-7331:
---
Summary: [Automation] test_vpc_network_life_cycle_1_delete failed
while deleting VPC network
Key: CLOUDSTACK-7331
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7331
Project: CloudStack
Issue Type: Test
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Priority: Critical
Fix For: 4.5.0
integration.component.test_persistent_networks.TestVPCNetworkOperations.test_vpc_network_life_cycle_1_delete
This failure need more analysis, from the log look, like test case trying to
delete VPC , which used by 2 networks
Error Message
Job failed: {jobprocstatus : 0, created : u'2014-08-11T18:10:39-0700', cmd :
u'org.apache.cloudstack.api.command.user.vpc.DeleteVPCCmd', userid :
u'c0533784-2197-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid :
u'55fb327b-ca86-4ae8-9489-4f50cc3e0b6b', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u"Can't delete VPC [VPC
[30-vpc_vpn-ONQVTO] as its used by 2 networks"}, accountid :
u'c0532ca8-2197-11e4-9ac6-1a6f7bb0d0a8'}
>> begin captured stdout << -
=== TestName: test_vpc_network_life_cycle_1_delete | Status : EXCEPTION ===
- >> end captured stdout << --
>> begin captured logging <<
test_vpc_network_life_cycle_1_delete
(integration.component.test_persistent_networks.TestVPCNetworkOperations):
DEBUG: STARTED : TC: test_vpc_network_life_cycle_1_delete
:::
test_vpc_network_life_cycle_1_delete
(integration.component.test_persistent_networks.TestVPCNetworkOperations):
DEBUG: Payload: {'username':
'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
'domainid': u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', 'firstname': 'test',
'lastname': 'test', 'response': 'json', 'apiKey':
u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
'command': 'createAccount', 'accounttype': 0, 'signature':
'r41I7ga909Z8suAixwuNvXMPZXg=', 'password': 'password', 'email':
'test-acco...@test.com'}
test_vpc_network_life_cycle_1_delete
(integration.component.test_persistent_networks.TestVPCNetworkOperations):
DEBUG: Sending GET Cmd : createAccount===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.49.195
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?username=test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q&domainid=6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8&firstname=test&lastname=test&email=test-account%40test.com&apiKey=78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ&command=createAccount&accounttype=0&signature=r41I7ga909Z8suAixwuNvXMPZXg%3D&password=password&response=json
HTTP/1.1" 200 1737
test_vpc_network_life_cycle_1_delete
(integration.component.test_persistent_networks.TestVPCNetworkOperations):
DEBUG: Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT',
domainid : u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', vpclimit : u'Unlimited',
iplimit : u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0,
secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal :
0, id : u'a6046056-0ef6-41d3-a49d-24a3296f856a', cpuavailable : u'Unlimited',
snapshotlimit : u'Unlimited', networklimit : u'Unlimited', iptotal : 0,
volumetotal : 0, projectlimit : u'Unlimited', state : u'enabled', networktotal
: 0, accounttype : 0, networkavailable : u'Unlimited', primarystoragetotal : 0,
templatelimit : u'Unlimited', snapshottotal : 0, templateavailable :
u'Unlimited', vmlimit : u'Unlimited', vpcavailable : u'Unlimited',
memoryavailable : u'Unlimited', secondarystoragetotal : 0, templatetotal : 0,
projecttotal : 0, user : [{username :
u'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
account :
u'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
domainid : u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', firstname : u'test',
created : u'2014-08-11T18:09:30-0700', lastname : u'test', domain : u'ROOT', id
: u'7c010648-ba13-4b79-b20c-383670fdc77c', iscallerchilddomain : False, state :
u'enabled', accounttype : 0, email : u'test-acco...@test.com', isdefault :
False, accountid : u'a6046056-0ef6-41d3-a49d-24a3296f856a'}], groups : [],
projectavailable : u'Unlimited', isdefault : False, primarystoragelimit :
u'Unlimited', secondarystoragelimit : u'Unlimited', volumeavailable :
u'Unlimited', name :
u'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
vmavailable : u'Unlimited', ipava
[jira] [Commented] (CLOUDSTACK-7331) [Automation] test_vpc_network_life_cycle_1_delete failed while deleting VPC network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094886#comment-14094886
]
Rayees Namathponnan commented on CLOUDSTACK-7331:
-
Logs available at https://citrix.sharefile.com/d/sfad0763a90349fa9
> [Automation] test_vpc_network_life_cycle_1_delete failed while deleting VPC
> network
>
>
> Key: CLOUDSTACK-7331
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7331
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> integration.component.test_persistent_networks.TestVPCNetworkOperations.test_vpc_network_life_cycle_1_delete
> This failure need more analysis, from the log look, like test case trying to
> delete VPC , which used by 2 networks
> Error Message
> Job failed: {jobprocstatus : 0, created : u'2014-08-11T18:10:39-0700', cmd :
> u'org.apache.cloudstack.api.command.user.vpc.DeleteVPCCmd', userid :
> u'c0533784-2197-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid :
> u'55fb327b-ca86-4ae8-9489-4f50cc3e0b6b', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 530, errortext : u"Can't delete VPC [VPC
> [30-vpc_vpn-ONQVTO] as its used by 2 networks"}, accountid :
> u'c0532ca8-2197-11e4-9ac6-1a6f7bb0d0a8'}
> >> begin captured stdout << -
> === TestName: test_vpc_network_life_cycle_1_delete | Status : EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_vpc_network_life_cycle_1_delete
> (integration.component.test_persistent_networks.TestVPCNetworkOperations):
> DEBUG: STARTED : TC: test_vpc_network_life_cycle_1_delete
> :::
> test_vpc_network_life_cycle_1_delete
> (integration.component.test_persistent_networks.TestVPCNetworkOperations):
> DEBUG: Payload: {'username':
> 'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
> 'domainid': u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
> 'command': 'createAccount', 'accounttype': 0, 'signature':
> 'r41I7ga909Z8suAixwuNvXMPZXg=', 'password': 'password', 'email':
> 'test-acco...@test.com'}
> test_vpc_network_life_cycle_1_delete
> (integration.component.test_persistent_networks.TestVPCNetworkOperations):
> DEBUG: Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.195
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q&domainid=6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8&firstname=test&lastname=test&email=test-account%40test.com&apiKey=78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ&command=createAccount&accounttype=0&signature=r41I7ga909Z8suAixwuNvXMPZXg%3D&password=password&response=json
> HTTP/1.1" 200 1737
> test_vpc_network_life_cycle_1_delete
> (integration.component.test_persistent_networks.TestVPCNetworkOperations):
> DEBUG: Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT',
> domainid : u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', vpclimit : u'Unlimited',
> iplimit : u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0,
> secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal
> : 0, id : u'a6046056-0ef6-41d3-a49d-24a3296f856a', cpuavailable :
> u'Unlimited', snapshotlimit : u'Unlimited', networklimit : u'Unlimited',
> iptotal : 0, volumetotal : 0, projectlimit : u'Unlimited', state :
> u'enabled', networktotal : 0, accounttype : 0, networkavailable :
> u'Unlimited', primarystoragetotal : 0, templatelimit : u'Unlimited',
> snapshottotal : 0, templateavailable : u'Unlimited', vmlimit : u'Unlimited',
> vpcavailable : u'Unlimited', memoryavailable : u'Unlimited',
> secondarystoragetotal : 0, templatetotal : 0, projecttotal : 0, user :
> [{username :
> u'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
> account :
> u'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
> domainid : u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', firstname : u'test',
> created : u'2014-08-11T18:09:30-0700', lastname : u'test', domain : u'ROOT',
> id : u'7c010648-ba13-4b79-b20c-383670fdc77c', iscallerchilddomain
[jira] [Created] (CLOUDSTACK-7332) CloudMonkey setup.py undefined variable 'requires'
Scott Trotter created CLOUDSTACK-7332:
-
Summary: CloudMonkey setup.py undefined variable 'requires'
Key: CLOUDSTACK-7332
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7332
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Cloudmonkey
Environment: Windows 8.1, cmd.exe, python 2.7.8, pip 1.5.6
Reporter: Scott Trotter
Priority: Minor
I'm setting up a Windows system to see how effective (or not) it is for FOSS
development. I installed the following components, in order, one right after
another, using cmd.exe CLI, not PowerShell or Git Bash:
Github for Windows 2.2.0.0
Python (x64) 2.7.8
ez_setup.py
get-pip.py
pip install cloudmonkey
The latter resulted in the following error, which I copied from pip.log:
File "e:\temp\pip_build_Scott\cloudmonkey\setup.py", line 32, in
requires.append('readline')
NameError: name 'requires' is not defined
I downloaded apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2 and unpacked it
manually. Here is the problem area, starting with line 29:
try:
import readline
except ImportError:
requires.append('readline')
This test FAILED on my system, but I'm guessing that it typically doesn't fail
on others because readline is typically already installed by the time someone
tries to install CloudMonkey.
I also poked around in the repo, and it's easy to see how this bug got
introduced. In the last commit on Mar. 19, 2013, the maintainer changed the way
that required modules are handled, in part by removing the 'requires' variable,
but missed the try/except clause shown above. It probably remained undiscovered
this long due to my unusual installation sequence.
This should be very simple to fix. I have pip.log if you need it, but I don't
see any way to attach files in this report form. I can email it to you if you
want.
Questions? sc...@trotternet.com
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7332) CloudMonkey setup.py undefined variable 'requires'
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095095#comment-14095095
]
Scott Trotter commented on CLOUDSTACK-7332:
---
FYI, after installing 'anyreadline' which in turn installs 'pyreadline',
cloudmonkey installed successfully.
> CloudMonkey setup.py undefined variable 'requires'
> --
>
> Key: CLOUDSTACK-7332
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7332
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Cloudmonkey
> Environment: Windows 8.1, cmd.exe, python 2.7.8, pip 1.5.6
>Reporter: Scott Trotter
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I'm setting up a Windows system to see how effective (or not) it is for FOSS
> development. I installed the following components, in order, one right after
> another, using cmd.exe CLI, not PowerShell or Git Bash:
> Github for Windows 2.2.0.0
> Python (x64) 2.7.8
> ez_setup.py
> get-pip.py
> pip install cloudmonkey
> The latter resulted in the following error, which I copied from pip.log:
> File "e:\temp\pip_build_Scott\cloudmonkey\setup.py", line 32, in
> requires.append('readline')
> NameError: name 'requires' is not defined
> I downloaded apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2 and unpacked it
> manually. Here is the problem area, starting with line 29:
> try:
> import readline
> except ImportError:
> requires.append('readline')
> This test FAILED on my system, but I'm guessing that it typically doesn't
> fail on others because readline is typically already installed by the time
> someone tries to install CloudMonkey.
> I also poked around in the repo, and it's easy to see how this bug got
> introduced. In the last commit on Mar. 19, 2013, the maintainer changed the
> way that required modules are handled, in part by removing the 'requires'
> variable, but missed the try/except clause shown above. It probably remained
> undiscovered this long due to my unusual installation sequence.
> This should be very simple to fix. I have pip.log if you need it, but I don't
> see any way to attach files in this report form. I can email it to you if you
> want.
> Questions? sc...@trotternet.com
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7302) UI: Remove Hover Interaction from breadcrumbs at top page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica resolved CLOUDSTACK-7302. Resolution: Fixed > UI: Remove Hover Interaction from breadcrumbs at top page > - > > Key: CLOUDSTACK-7302 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7302 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Fix For: 4.5.0 > > > Upon hover over breadcrumb tabs at top of page, user sees pop-up, but is > unable to interact with it. > This was apparently a mistake/ unintended interaction. It should be removed, > so that there is no display on hover. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7218) [Automation] NPE observed while deleting account in automation run
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095179#comment-14095179 ] Jayapal Reddy commented on CLOUDSTACK-7218: --- Hi Animesh, Last week I worked on security issues. I am back from vacation today. I will look into this. Thanks, Jayapal > [Automation] NPE observed while deleting account in automation run > -- > > Key: CLOUDSTACK-7218 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7218 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: KVM (RHEL 6.3) >Reporter: Rayees Namathponnan >Assignee: Jayapal Reddy >Priority: Critical > Fix For: 4.5.0 > > > This issue is observed in automation log, NPE thrown while deleting account > 2014-07-31 02:20:56,102 DEBUG [c.c.n.r.RulesManagerImpl] > (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) There are no static > nat > rules to apply for ip id=28 > 2014-07-31 02:20:56,105 WARN [c.c.u.AccountManagerImpl] > (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) Failed to cleanup > accou > nt > Acct[b1cf2381-ab36-4ebc-90ff-f08acaf5e02d-test-account-TestVmNetworkOperations-test_add_static_nat_rule_1_ISOLATED-YI0OCS] > due to > java.lang.NullPointerException > at > com.cloud.network.rules.RulesManagerImpl.createStaticNatForIp(RulesManagerImpl.java:1391) > at > com.cloud.network.rules.RulesManagerImpl.applyStaticNatForIp(RulesManagerImpl.java:1321) > at > com.cloud.network.rules.RulesManagerImpl.revokeAllPFAndStaticNatRulesForIp(RulesManagerImpl.java:1104) > at sun.reflect.GeneratedMethodAccessor524.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > 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.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 com.sun.proxy.$Proxy105.revokeAllPFAndStaticNatRulesForIp(Unknown > Source) > at > com.cloud.network.IpAddressManagerImpl.cleanupIpResources(IpAddressManagerImpl.java:540) > at > com.cloud.network.IpAddressManagerImpl.applyIpAssociations(IpAddressManagerImpl.java:936) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.cleanupNetworkResources(NetworkOrchestrator.java:2650) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2196) > at > com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:793) > at > com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:667) > at > com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1441) > at sun.reflect.GeneratedMethodAccessor542.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > 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.ReflectiveMethodInvoc
[jira] [Closed] (CLOUDSTACK-6990) VM console displays blank page.AgentControlChannelException in cloud.log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
manasaveloori closed CLOUDSTACK-6990.
-
Verified on latest build.Working fine.Closing the issue.
> VM console displays blank page.AgentControlChannelException in cloud.log
>
>
> Key: CLOUDSTACK-6990
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6990
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
>Affects Versions: 4.4.0
>Reporter: manasaveloori
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: 4.4.0, 4.5.0
>
> Attachments: cloud.log, management-server.rar
>
>
> Deployed Cloudstack using the build :
> [root@RHEL63test ~]# cloudstack-sccs
> 9024ad14681858ac7caafaf86f267a213ce6b61c
> Deployed a user VM.
> Now try to open the console of any VM.
> It is displaying blank page.
> In CPVM cloud.log observed the following exception continuously:
> 2014-06-25 06:31:14,620 INFO [utils.exception.CSExceptionErrorCode] (Console
> Proxy GC Thread:null) Could not find exception:
> com.cloud.exception.AgentControlChannelException in error code list for
> exceptions
> 2014-06-25 06:31:14,621 ERROR [resource.consoleproxy.ConsoleProxyResource]
> (Console Proxy GC Thread:null) Unable to send out load info due to Unable to
> post agent control request as link is not available
> com.cloud.exception.AgentControlChannelException: Unable to post agent
> control request as link is not available
> at com.cloud.agent.Agent.postRequest(Agent.java:689)
> at com.cloud.agent.Agent.postRequest(Agent.java:677)
> at
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:418)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
> at
> com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
> 2014-06-25 06:31:14,621 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
> (Console Proxy GC Thread:null) Report load change : {
> "connections": []
> }
> 2014-06-25 06:31:14,897 INFO [cloud.agent.Agent] (Agent-Handler-4:null)
> Reconnecting...
> 2014-06-25 06:31:14,897 INFO [utils.nio.NioClient] (Agent-Selector:null)
> Connecting to 10.147.59.222:8250
> Attaching the Ms logs and CPVM log.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7284) Holder for KVM regression test script issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095191#comment-14095191 ] ASF subversion and git services commented on CLOUDSTACK-7284: - Commit 76cecc325fca5ead8b610c49608cb8fe8a4395c5 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=76cecc3 ] CLOUDSTACK-7284: Fixed test script related to expunge VM in test_add_remove_network.py > Holder for KVM regression test script issues > > > Key: CLOUDSTACK-7284 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7284 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > This bug is holder for all test script issues identified in KVM regression > run. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7294) [Automation] ListUser API call returns null, with admin user
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095203#comment-14095203
]
ASF subversion and git services commented on CLOUDSTACK-7294:
-
Commit 9d7b85153747dfe378031455fc1231bcd6088d08 in cloudstack's branch
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9d7b851 ]
CLOUDSTACK-7294: Passing listall=True for listUser api admin call
> [Automation] ListUser API call returns null, with admin user
>
>
> Key: CLOUDSTACK-7294
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7294
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This is issue observed in automation run, listUser API call from admin
> account its not returning anything
> {noformat}
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-a-TestScaleVmDynamicServiceOffering-test_check_vm_stats_1_ADMIN_ACCOUNT-CSLTD9&apiKey=6zw5hCTgehiuRygidlX9Lg089xLncrgdPOB1kUI32G6CG19hYJiT8hEKlIyJL5hOaSW9nJ2s0hc3a605fi0wVQ&command=listUsers&response=json&signature=spQJXI%2Bz76Enm%2B1mthEXDtdFc64%3D
> HTTP/1.1" 200 29
> test_check_vm_stats_1_ADMIN_ACCOUNT
> (integration.component.test_dynamic_compute_offering.TestDynamicServiceOffering):
> DEBUG: Response : None
> test_check_vm_stats_1_ADMIN_ACCOUNT
> (integration.component.test_dynamic_compute_offering.TestDynamicServiceOffering):
> ERROR: Exception Occurred Under getUserApiClient : ['Traceback (most recent
> call last):\n', ' File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py", line
> 349, in __createUserApiClient\nuserId = listuserRes[0].id\n', "TypeError:
> 'NoneType' object is not subscriptable\n"]
> Traceback (most recent call last):
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py", line
> 349, in __createUserApiClient
> userId = listuserRes[0].id
> TypeError: 'NoneType' object is not subscriptable
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7294) [Automation] ListUser API call returns null, with admin user
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye resolved CLOUDSTACK-7294.
Resolution: Fixed
> [Automation] ListUser API call returns null, with admin user
>
>
> Key: CLOUDSTACK-7294
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7294
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This is issue observed in automation run, listUser API call from admin
> account its not returning anything
> {noformat}
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-a-TestScaleVmDynamicServiceOffering-test_check_vm_stats_1_ADMIN_ACCOUNT-CSLTD9&apiKey=6zw5hCTgehiuRygidlX9Lg089xLncrgdPOB1kUI32G6CG19hYJiT8hEKlIyJL5hOaSW9nJ2s0hc3a605fi0wVQ&command=listUsers&response=json&signature=spQJXI%2Bz76Enm%2B1mthEXDtdFc64%3D
> HTTP/1.1" 200 29
> test_check_vm_stats_1_ADMIN_ACCOUNT
> (integration.component.test_dynamic_compute_offering.TestDynamicServiceOffering):
> DEBUG: Response : None
> test_check_vm_stats_1_ADMIN_ACCOUNT
> (integration.component.test_dynamic_compute_offering.TestDynamicServiceOffering):
> ERROR: Exception Occurred Under getUserApiClient : ['Traceback (most recent
> call last):\n', ' File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py", line
> 349, in __createUserApiClient\nuserId = listuserRes[0].id\n', "TypeError:
> 'NoneType' object is not subscriptable\n"]
> Traceback (most recent call last):
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py", line
> 349, in __createUserApiClient
> userId = listuserRes[0].id
> TypeError: 'NoneType' object is not subscriptable
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-7331) [Automation] test_vpc_network_life_cycle_1_delete failed while deleting VPC network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye reassigned CLOUDSTACK-7331:
--
Assignee: Gaurav Aradhye
> [Automation] test_vpc_network_life_cycle_1_delete failed while deleting VPC
> network
>
>
> Key: CLOUDSTACK-7331
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7331
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> integration.component.test_persistent_networks.TestVPCNetworkOperations.test_vpc_network_life_cycle_1_delete
> This failure need more analysis, from the log look, like test case trying to
> delete VPC , which used by 2 networks
> Error Message
> Job failed: {jobprocstatus : 0, created : u'2014-08-11T18:10:39-0700', cmd :
> u'org.apache.cloudstack.api.command.user.vpc.DeleteVPCCmd', userid :
> u'c0533784-2197-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid :
> u'55fb327b-ca86-4ae8-9489-4f50cc3e0b6b', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 530, errortext : u"Can't delete VPC [VPC
> [30-vpc_vpn-ONQVTO] as its used by 2 networks"}, accountid :
> u'c0532ca8-2197-11e4-9ac6-1a6f7bb0d0a8'}
> >> begin captured stdout << -
> === TestName: test_vpc_network_life_cycle_1_delete | Status : EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_vpc_network_life_cycle_1_delete
> (integration.component.test_persistent_networks.TestVPCNetworkOperations):
> DEBUG: STARTED : TC: test_vpc_network_life_cycle_1_delete
> :::
> test_vpc_network_life_cycle_1_delete
> (integration.component.test_persistent_networks.TestVPCNetworkOperations):
> DEBUG: Payload: {'username':
> 'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
> 'domainid': u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
> 'command': 'createAccount', 'accounttype': 0, 'signature':
> 'r41I7ga909Z8suAixwuNvXMPZXg=', 'password': 'password', 'email':
> 'test-acco...@test.com'}
> test_vpc_network_life_cycle_1_delete
> (integration.component.test_persistent_networks.TestVPCNetworkOperations):
> DEBUG: Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.195
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q&domainid=6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8&firstname=test&lastname=test&email=test-account%40test.com&apiKey=78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ&command=createAccount&accounttype=0&signature=r41I7ga909Z8suAixwuNvXMPZXg%3D&password=password&response=json
> HTTP/1.1" 200 1737
> test_vpc_network_life_cycle_1_delete
> (integration.component.test_persistent_networks.TestVPCNetworkOperations):
> DEBUG: Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT',
> domainid : u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', vpclimit : u'Unlimited',
> iplimit : u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0,
> secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal
> : 0, id : u'a6046056-0ef6-41d3-a49d-24a3296f856a', cpuavailable :
> u'Unlimited', snapshotlimit : u'Unlimited', networklimit : u'Unlimited',
> iptotal : 0, volumetotal : 0, projectlimit : u'Unlimited', state :
> u'enabled', networktotal : 0, accounttype : 0, networkavailable :
> u'Unlimited', primarystoragetotal : 0, templatelimit : u'Unlimited',
> snapshottotal : 0, templateavailable : u'Unlimited', vmlimit : u'Unlimited',
> vpcavailable : u'Unlimited', memoryavailable : u'Unlimited',
> secondarystoragetotal : 0, templatetotal : 0, projecttotal : 0, user :
> [{username :
> u'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
> account :
> u'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
> domainid : u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', firstname : u'test',
> created : u'2014-08-11T18:09:30-0700', lastname : u'test', domain : u'ROOT',
> id : u'7c010648-ba13-4b79-b20c-383670fdc77c', iscallerchilddomain : False,
> state : u'enabled', accounttype : 0, email : u'te
[jira] [Created] (CLOUDSTACK-7333) [vGPU] Windows VM with GPU cards and PV drivers is going to repair state when deployed with "dynamic scaling enabled" option.
Abhinav Roy created CLOUDSTACK-7333: --- Summary: [vGPU] Windows VM with GPU cards and PV drivers is going to repair state when deployed with "dynamic scaling enabled" option. Key: CLOUDSTACK-7333 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7333 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, XenServer Affects Versions: 4.5.0 Environment: Xenserver 6.2.5 + PV drivers (up to date) Reporter: Abhinav Roy Priority: Blocker Fix For: 4.5.0 There are 4 scenarios which i tried : Setup : = CS 4.5 advanced zone with Xen 6.2.5 + PV drivers ( XS Tools) Dynamic scaling is enabled on zone level. Scenario 1 : 1. Register a windows 8 or windows 2012 template ( without dynamic scaling enabled) and deploy a VM with vGPU service offering from it. -- Template is registered and VM is deployed. 2. Install the PV drivers on the VM. -- PV drivers are installed successfully (make sure they are latest) 3. Now stop the VM, enable dynamic scaling and start the VM. -- VM fails to start and goes into the repair state. Scenario 2 : 1. Register a windows 8 or windows 2012 template ( with dynamic scaling enabled) and deploy a VM with vGPU service offering from it. -- Template is registered and VM is deployed. 2. Install the PV drivers on the VM. -- PV drivers fail to install and VM goes to repair state. Scenario 3 : 1. Register a windows 8 or windows 2012 template ( with dynamic scaling enabled and PV drivers installed) and deploy a VM with vGPU service offering from it. -- Template is registered and VM fails to deploy, it goes into repair state. Scenario 4 : 1. Register a windows 8 or windows 2012 template ( without dynamic scaling enabled but PV drivers are installed) and deploy a VM with vGPU service offering from it. -- Template is registered and VM is deployed. 2. Now stop the VM, enable dynamic scaling and start the VM. -- VM fails to start and goes into the repair state Scenario 5 : 1. Register a windows 8 or windows 2012 ISO and deploy a VM with vGPU service offering from it. -- ISO is registered and VM is deployed. 2. Install the PV drivers on the VM. -- PV drivers are installed successfully (make sure they are latest) 3. Now stop the VM, enable dynamic scaling and start the VM. -- VM fails to start and goes into the repair state -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7275) [Automation] NPE thrown in MS log while starting ConsoleProxy
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095215#comment-14095215
]
Rajani Karuturi commented on CLOUDSTACK-7275:
-
[~rayeesn], Can you specify the test case which failed?
> [Automation] NPE thrown in MS log while starting ConsoleProxy
> -
>
> Key: CLOUDSTACK-7275
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7275
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: Aug_06_KVM.rar
>
>
> Below NPE thrown in MS while starting Console Proxy
> {noformat}
> 2014-08-06 08:00:48,370 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Deplo
> ymentPlanningManagerImpl
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Clust
> eredVirtualMachineManagerImpl
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Netwo
> rkOrchestrator
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Downl
> oadListener
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener:
> DirectNetworkStatsListener
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener:
> UploadListener
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener:
> BehindOnPingListener
> 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener:
> ConsoleProxyListener
> 2014-08-06 08:00:48,442 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-7:null) Ping from 3
> 2014-08-06 08:00:48,496 INFO [c.c.c.ConsoleProxyManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Proxy 4 is no longer in DB, skip
> sending startup command
> 2014-08-06 08:00:48,497 ERROR [c.c.c.AgentHookBase]
> (AgentConnectTaskPool-66:ctx-277af113) Unexpected exception when sending http
> handling startup command(time out) to the console proxy resource for proxy:4
> java.lang.NullPointerException
> at
> com.cloud.consoleproxy.AgentHookBase.startAgentHttpHandlerInVM(AgentHookBase.java:212)
> at
> com.cloud.consoleproxy.ConsoleProxyListener.processConnect(ConsoleProxyListener.java:71)
> at
> com.cloud.agent.manager.AgentManagerImpl.notifyMonitorsOfConnection(AgentManagerImpl.java:537)
> at
> com.cloud.agent.manager.AgentManagerImpl.handleConnectedAgent(AgentManagerImpl.java:1030)
> at
> com.cloud.agent.manager.AgentManagerImpl.access$000(AgentManagerImpl.java:119)
> at
> com.cloud.agent.manager.AgentManagerImpl$HandleAgentConnectTask.runInContext(AgentManagerImpl.java:1114)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> 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
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> 2014-08-06 08:00:48,497 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener:
> SshKeysDistriMonitor
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7333) [vGPU] Windows VM with GPU cards and PV drivers is going to repair state when deployed with "dynamic scaling enabled" option.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinav Roy updated CLOUDSTACK-7333: Attachment: CS-7333.zip Attaching MS logs, DB dumps and xe-param-list output for vgpu and non-vgpu VMs > [vGPU] Windows VM with GPU cards and PV drivers is going to repair state when > deployed with "dynamic scaling enabled" option. > - > > Key: CLOUDSTACK-7333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7333 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.5.0 > Environment: Xenserver 6.2.5 + PV drivers (up to date) >Reporter: Abhinav Roy >Priority: Blocker > Fix For: 4.5.0 > > Attachments: CS-7333.zip > > > There are 4 scenarios which i tried : > Setup : > = > CS 4.5 advanced zone with Xen 6.2.5 + PV drivers ( XS Tools) > Dynamic scaling is enabled on zone level. > Scenario 1 : > > 1. Register a windows 8 or windows 2012 template ( without dynamic scaling > enabled) and deploy a VM with vGPU service offering from it. > > -- Template is registered and VM is deployed. > 2. Install the PV drivers on the VM. > -- PV drivers are installed successfully (make sure they are latest) > 3. Now stop the VM, enable dynamic scaling and start the VM. > -- VM fails to start and goes into the repair state. > Scenario 2 : > > 1. Register a windows 8 or windows 2012 template ( with dynamic scaling > enabled) and deploy a VM with vGPU service offering from it. > > -- Template is registered and VM is deployed. > 2. Install the PV drivers on the VM. > -- PV drivers fail to install and VM goes to repair state. > Scenario 3 : > > 1. Register a windows 8 or windows 2012 template ( with dynamic scaling > enabled and PV drivers installed) and deploy a VM with vGPU service offering > from it. > > -- Template is registered and VM fails to deploy, it goes into repair > state. > Scenario 4 : > > 1. Register a windows 8 or windows 2012 template ( without dynamic scaling > enabled but PV drivers are installed) and deploy a VM with vGPU service > offering from it. > > -- Template is registered and VM is deployed. > 2. Now stop the VM, enable dynamic scaling and start the VM. > -- VM fails to start and goes into the repair state > Scenario 5 : > > 1. Register a windows 8 or windows 2012 ISO and deploy a VM with vGPU service > offering from it. > > -- ISO is registered and VM is deployed. > 2. Install the PV drivers on the VM. > -- PV drivers are installed successfully (make sure they are latest) > 3. Now stop the VM, enable dynamic scaling and start the VM. > -- VM fails to start and goes into the repair state -- This message was sent by Atlassian JIRA (v6.2#6252)
