[jira] [Updated] (CLOUDSTACK-2232) Automation: Add automation for Persistent networks without running a VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-2232: --- Assignee: (was: Gaurav Aradhye) Automation: Add automation for Persistent networks without running a VM Key: CLOUDSTACK-2232 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2232 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sudha Ponnaganti Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798906#comment-13798906 ] ASF subversion and git services commented on CLOUDSTACK-4792: - Commit 2b6b99ffb36a25f234b62143e2040a5809be6303 in branch refs/heads/4.2 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2b6b99f ] CLOUDSTACK-4792: added the connection and socket timeout parameters for SMTP and sending message in new thread so that HA doesn't get blocked beacause of hang in sending email alert Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2232) Automation: Add automation for Persistent networks without running a VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798913#comment-13798913 ] ASF subversion and git services commented on CLOUDSTACK-2232: - Commit 325c94ed60ba62f6dda2400c5362d51139b9fcce in branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=325c94e ] CLOUDSTACK-2232: marvin tests for Persistent networks without running a VM Automation: Add automation for Persistent networks without running a VM Key: CLOUDSTACK-2232 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2232 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sudha Ponnaganti Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798922#comment-13798922 ] Milamber commented on CLOUDSTACK-4792: -- It's would be better to add in Global configuration these new timeout settings? At least add some doc/comments that says the timeout value to 30 secs? Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4596) CloudStack is currently allowing same ip range to be defined in different VLANs across public and portable ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798957#comment-13798957 ] ASF subversion and git services commented on CLOUDSTACK-4596: - Commit c1294fdfa019e4e86e52299378b244d46b06b5c2 in branch refs/heads/4.2 from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c1294fd ] CLOUDSTACK-4596: CloudStack is currently allowing same ip range to be defined in different VLANs across public and portable ranges added checks to restric same ip range to be configure as both public ip range and portable ip range CloudStack is currently allowing same ip range to be defined in different VLANs across public and portable ranges - Key: CLOUDSTACK-4596 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4596 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Priority: Critical Fix For: 4.2.1 Steps to reproduce : 1. Have latest CloudStack with at least 1 advanced zone. 2. Have at least 1 public VLAN and a range added for advanced zone For ex : VLAN : 44 Startip : 10.147.44.100 Endip : 10.147.44.109 netmask : 255.255.255.0 3. add the same above ip range for portable IPs with a different VLAN Observations: (i) The above step (3) doesn't throw any error that the same ip range is being used in different VLAN and that is allowing it. (ii) Due to the above behaviour when user tries to acquire the same ip from different vlans then it throws an error saying Entity already exists Here is the snippet from mgmt server log. 2013-09-03 04:39:50,996 DEBUG [cloud.api.ApiServlet] (catalina-exec-7:null) ===START=== 10.252.192.43 -- GET command=associateIpAddressresponse=jsonsessionkey=A9SZ7jF%2Fu24xbL7DG%2BGdGT4BcyY%3Disportable=truenetworkid=24c91328-27a8-4981-a704-1efd6e5aeca8_=1378197591134 2013-09-03 04:39:51,038 DEBUG [db.Transaction.Transaction] (catalina-exec-7:null) Rolling back the transaction: Time = 13 Name = allocatePortableIp; called by -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close:665-TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-NetworkManagerImpl.allocatePortableIp:870-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-NetworkServiceImpl.allocatePortableIP:589-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-AssociateIPAddrCmd.create:276-ApiDispatcher.dispatchCreateCmd:104-ApiServer.queueCommand:460 2013-09-03 04:39:51,150 ERROR [cloud.api.ApiServer] (catalina-exec-7:null) unhandled exception executing api command: associateIpAddress javax.persistence.EntityExistsException: Entity already exists: at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1346) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.NetworkManagerImpl.allocatePortableIp(NetworkManagerImpl.java:870) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.NetworkServiceImpl.allocatePortableIP(NetworkServiceImpl.java:589) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd.create(AssociateIPAddrCmd.java:276) at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:104) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:460) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at
[jira] [Updated] (CLOUDSTACK-4888) API:UCS:NPE Refresh blades on a decommissioned chassis results in NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4888: --- Assignee: frank zhang API:UCS:NPE Refresh blades on a decommissioned chassis results in NPE - Key: CLOUDSTACK-4888 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4888 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, UCS Affects Versions: 4.2.0 Environment: UCS Reporter: Parth Jagirdar Assignee: frank zhang Priority: Critical Fix For: 4.2.1 Expecting an appropriate error. When refresh blades is issues on a decommissioned chassis. 2013-10-17 13:52:26,432 DEBUG [cloud.api.ApiServlet] (catalina-exec-6:null) ===START=== 10.215.2.19 -- GET command=refreshUcsBladesresponse=jsonsessionkey=e0Kgb2hcBQPMXSe5O%2FDeRH8v2%2B8%3Ducsmanagerid=f185ae78-08cb-4a06-a3c8-47c3d2afa896_=1382043146927 2013-10-17 13:52:26,451 DEBUG [ucs.manager.UcsHttpClient] (catalina-exec-6:null) UCS call: configResolveClass cookie=1382042998/2e94d89b-026b-4fbd-be82-489759483570 inHierarchical=false classId=computeBlade / 2013-10-17 13:52:26,458 WARN [ucs.manager.UcsManagerImpl] (catalina-exec-6:null) null java.lang.NullPointerException at com.cloud.ucs.structure.ComputeBlade.fromXmlObject(ComputeBlade.java:62) at com.cloud.ucs.structure.ComputeBlade.fromXmString(ComputeBlade.java:55) at com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:285) at com.cloud.ucs.manager.UcsManagerImpl.access$100(UcsManagerImpl.java:65) at com.cloud.ucs.manager.UcsManagerImpl$SyncBladesThread.syncBlades(UcsManagerImpl.java:141) at com.cloud.ucs.manager.UcsManagerImpl$SyncBladesThread.run(UcsManagerImpl.java:156) at com.cloud.ucs.manager.UcsManagerImpl.refreshBlades(UcsManagerImpl.java:624) at org.apache.cloudstack.api.RefreshUcsBladesCmd.execute(RefreshUcsBladesCmd.java:42) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013-10-17 13:52:26,468 DEBUG [ucs.manager.UcsHttpClient] (catalina-exec-6:null) UCS call: configResolveClass cookie=1382042998/2e94d89b-026b-4fbd-be82-489759483570 inHierarchical=false classId=computeBlade / 2013-10-17 13:52:26,471 WARN [cloudstack.api.RefreshUcsBladesCmd] (catalina-exec-6:null) unhandled exception: java.lang.NullPointerException at com.cloud.ucs.structure.ComputeBlade.fromXmlObject(ComputeBlade.java:62) at com.cloud.ucs.structure.ComputeBlade.fromXmString(ComputeBlade.java:55) at com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:285) at com.cloud.ucs.manager.UcsManagerImpl.refreshBlades(UcsManagerImpl.java:627) at
[jira] [Resolved] (CLOUDSTACK-4596) CloudStack is currently allowing same ip range to be defined in different VLANs across public and portable ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-4596. -- Resolution: Fixed CloudStack is currently allowing same ip range to be defined in different VLANs across public and portable ranges - Key: CLOUDSTACK-4596 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4596 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Priority: Critical Fix For: 4.2.1 Steps to reproduce : 1. Have latest CloudStack with at least 1 advanced zone. 2. Have at least 1 public VLAN and a range added for advanced zone For ex : VLAN : 44 Startip : 10.147.44.100 Endip : 10.147.44.109 netmask : 255.255.255.0 3. add the same above ip range for portable IPs with a different VLAN Observations: (i) The above step (3) doesn't throw any error that the same ip range is being used in different VLAN and that is allowing it. (ii) Due to the above behaviour when user tries to acquire the same ip from different vlans then it throws an error saying Entity already exists Here is the snippet from mgmt server log. 2013-09-03 04:39:50,996 DEBUG [cloud.api.ApiServlet] (catalina-exec-7:null) ===START=== 10.252.192.43 -- GET command=associateIpAddressresponse=jsonsessionkey=A9SZ7jF%2Fu24xbL7DG%2BGdGT4BcyY%3Disportable=truenetworkid=24c91328-27a8-4981-a704-1efd6e5aeca8_=1378197591134 2013-09-03 04:39:51,038 DEBUG [db.Transaction.Transaction] (catalina-exec-7:null) Rolling back the transaction: Time = 13 Name = allocatePortableIp; called by -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close:665-TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-NetworkManagerImpl.allocatePortableIp:870-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-NetworkServiceImpl.allocatePortableIP:589-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-AssociateIPAddrCmd.create:276-ApiDispatcher.dispatchCreateCmd:104-ApiServer.queueCommand:460 2013-09-03 04:39:51,150 ERROR [cloud.api.ApiServer] (catalina-exec-7:null) unhandled exception executing api command: associateIpAddress javax.persistence.EntityExistsException: Entity already exists: at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1346) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.NetworkManagerImpl.allocatePortableIp(NetworkManagerImpl.java:870) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.NetworkServiceImpl.allocatePortableIP(NetworkServiceImpl.java:589) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd.create(AssociateIPAddrCmd.java:276) at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:104) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:460) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at
[jira] [Commented] (CLOUDSTACK-4596) CloudStack is currently allowing same ip range to be defined in different VLANs across public and portable ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798975#comment-13798975 ] ASF subversion and git services commented on CLOUDSTACK-4596: - Commit aaa99cd9de3c671a4fe5d95fa6dff4f19d8c0fba in branch refs/heads/master from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aaa99cd ] CLOUDSTACK-4596: CloudStack is currently allowing same ip range to be defined in different VLANs across public and portable ranges added checks to restric same ip range to be configure as both public ip range and portable ip range CloudStack is currently allowing same ip range to be defined in different VLANs across public and portable ranges - Key: CLOUDSTACK-4596 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4596 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Priority: Critical Fix For: 4.2.1 Steps to reproduce : 1. Have latest CloudStack with at least 1 advanced zone. 2. Have at least 1 public VLAN and a range added for advanced zone For ex : VLAN : 44 Startip : 10.147.44.100 Endip : 10.147.44.109 netmask : 255.255.255.0 3. add the same above ip range for portable IPs with a different VLAN Observations: (i) The above step (3) doesn't throw any error that the same ip range is being used in different VLAN and that is allowing it. (ii) Due to the above behaviour when user tries to acquire the same ip from different vlans then it throws an error saying Entity already exists Here is the snippet from mgmt server log. 2013-09-03 04:39:50,996 DEBUG [cloud.api.ApiServlet] (catalina-exec-7:null) ===START=== 10.252.192.43 -- GET command=associateIpAddressresponse=jsonsessionkey=A9SZ7jF%2Fu24xbL7DG%2BGdGT4BcyY%3Disportable=truenetworkid=24c91328-27a8-4981-a704-1efd6e5aeca8_=1378197591134 2013-09-03 04:39:51,038 DEBUG [db.Transaction.Transaction] (catalina-exec-7:null) Rolling back the transaction: Time = 13 Name = allocatePortableIp; called by -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close:665-TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-NetworkManagerImpl.allocatePortableIp:870-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-NetworkServiceImpl.allocatePortableIP:589-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-AssociateIPAddrCmd.create:276-ApiDispatcher.dispatchCreateCmd:104-ApiServer.queueCommand:460 2013-09-03 04:39:51,150 ERROR [cloud.api.ApiServer] (catalina-exec-7:null) unhandled exception executing api command: associateIpAddress javax.persistence.EntityExistsException: Entity already exists: at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1346) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.NetworkManagerImpl.allocatePortableIp(NetworkManagerImpl.java:870) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.NetworkServiceImpl.allocatePortableIP(NetworkServiceImpl.java:589) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd.create(AssociateIPAddrCmd.java:276) at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:104) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:460) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at
[jira] [Commented] (CLOUDSTACK-4811) Adding Incorrect CIDR in public ip range of zone create wizard is allowing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798982#comment-13798982 ] ASF subversion and git services commented on CLOUDSTACK-4811: - Commit 51a4d2677cdc5964916378c568fd7da18d0aaa5f in branch refs/heads/4.2 from [~damoder.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=51a4d26 ] CLOUDSTACK-4811:Fixed zone creation wizard is allowing to accept wrong sub net mask which is cauing wrong cidr value for a given ip range Signed-off-by: Jayapal jaya...@apache.org Adding Incorrect CIDR in public ip range of zone create wizard is allowing -- Key: CLOUDSTACK-4811 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4811 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Jayapal Reddy Assignee: Damodar Reddy T Priority: Critical Fix For: 4.2.1 1. Add a new zone from UI add zone wizard. 2. Add incorrect cidr in in 3rd tab Setup network PUBLIC TRAFFIC gateway netmask VLANStart IP End IP 10.147.52.1 255.255.25.0 52 10.147.52.100 10.147.52.120 3. UI is allowing the above config 4. The zone will also get deployed. 5. The problem is coming in creating the public interface in system vms. If the interface got created problem in reaching the public network. 6. This issue is pain to user because after deploying zone user need to recreate zone again. Also some times user don't realise about the misconfiguration. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4811) Adding Incorrect CIDR in public ip range of zone create wizard is allowing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798983#comment-13798983 ] ASF subversion and git services commented on CLOUDSTACK-4811: - Commit a92095a4a6ce771387956a7c35fcbf47dbd35eee in branch refs/heads/master from [~damoder.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a92095a ] CLOUDSTACK-4811:Fixed zone creation wizard is allowing to accept wrong sub net mask which is cauing wrong cidr value for a given ip range Signed-off-by: Jayapal jaya...@apache.org Adding Incorrect CIDR in public ip range of zone create wizard is allowing -- Key: CLOUDSTACK-4811 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4811 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Jayapal Reddy Assignee: Damodar Reddy T Priority: Critical Fix For: 4.2.1 1. Add a new zone from UI add zone wizard. 2. Add incorrect cidr in in 3rd tab Setup network PUBLIC TRAFFIC gateway netmask VLANStart IP End IP 10.147.52.1 255.255.25.0 52 10.147.52.100 10.147.52.120 3. UI is allowing the above config 4. The zone will also get deployed. 5. The problem is coming in creating the public interface in system vms. If the interface got created problem in reaching the public network. 6. This issue is pain to user because after deploying zone user need to recreate zone again. Also some times user don't realise about the misconfiguration. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4783) Unable to see a derieved template if the parent template is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala reassigned CLOUDSTACK-4783: --- Assignee: Harikrishna Patnala (was: Kishan Kavala) Unable to see a derieved template if the parent template is deleted --- Key: CLOUDSTACK-4783 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4783 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.2.1 Functionality required/broken – For a template, if the parent template info (template Id) is provided in the listTemplates API then one should be able to query for the parent template id as well (whether existing/removed doesn't matter) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4783) Unable to see a derieved template if the parent template is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala updated CLOUDSTACK-4783: Status: Ready To Review (was: In Progress) Unable to see a derieved template if the parent template is deleted --- Key: CLOUDSTACK-4783 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4783 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.2.1 Functionality required/broken – For a template, if the parent template info (template Id) is provided in the listTemplates API then one should be able to query for the parent template id as well (whether existing/removed doesn't matter) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4256) [Automation] TestSharedNetworks test cases failed while creating network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-4256. -- Resolution: Fixed Patch merged. [Automation] TestSharedNetworks test cases failed while creating network - Key: CLOUDSTACK-4256 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4256 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.2.0 Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Priority: Critical Fix For: 4.3.0 Below test cases failed integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_accountSpecific integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_domainSpecific integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_projectSpecific integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 integration.component.test_shared_networks.TestSharedNetworks.test_deployVM_isolatedAndShared integration.component.test_shared_networks.TestSharedNetworks.test_deployVM_multipleSharedNetwork Test cases failed while creating network\, observed below error Error Message Execute cmd: createnetwork failed, due to: errorCode: 431, errorText:There is a isolated/shared network with vlan id: 1200 already exists in zone 1 begin captured logging testclient.testcase.TestSharedNetworks: DEBUG: Admin type account created: admin-XABU1-Q7G53T testclient.testcase.TestSharedNetworks: DEBUG: User type account created: admin-XABU1-1Q3UHH testclient.testcase.TestSharedNetworks: DEBUG: Physical Network found: 4b414b4e-8e90-4ef4-9e33-eb56970cd30f testclient.testcase.TestSharedNetworks: DEBUG: Shared Network Offering created: 699901f7-083a-41f7-96f0-6ee88d05ae78 - 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_shared_networks.py, line 1030, in test_createSharedNetwork_accountSpecific zoneid=self.zone.id File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line 1940, in create return Network(apiclient.createNetwork(cmd).__dict__) File /usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 1709, in createNetwork response = self.connection.marvin_request(command, response_type=response, method=method) File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) Execute cmd: createnetwork failed, due to: errorCode: 431, errorText:There is a isolated/shared network with vlan id: 1200 already exists in zone 1 begin captured logging testclient.testcase.TestSharedNetworks: DEBUG: Admin type account created: admin-XABU1-Q7G53T testclient.testcase.TestSharedNetworks: DEBUG: User type account created: admin-XABU1-1Q3UHH testclient.testcase.TestSharedNetworks: DEBUG: Physical Network found: 4b414b4e-8e90-4ef4-9e33-eb56970cd30f testclient.testcase.TestSharedNetworks: DEBUG: Shared Network Offering created: 699901f7-083a-41f7-96f0-6ee88d05ae78 - end captured logging - -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4875) VMWARE:SYSTEM VM: Unable to create deployment for VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799013#comment-13799013
]
Ram Ganesh commented on CLOUDSTACK-4875:
is this related to https://issues.apache.org/jira/browse/CLOUDSTACK-4131 ?
VMWARE:SYSTEM VM: Unable to create deployment for VM
Key: CLOUDSTACK-4875
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4875
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM, VMware
Affects Versions: 4.2.1
Environment: Master with vCenter 5.5 / ESXi 5.5
Reporter: Parth Jagirdar
Assignee: Sateesh Chodapuneedi
Priority: Blocker
Fix For: 4.2.1
Attachments: catalina.out, management-server.log, VC5.5.jpg
Unable to launch system VM's
See attached logs
2013-10-15 13:31:40,061 DEBUG [cloud.storage.VolumeManagerImpl]
(consoleproxy-1:null) Unable to create
Vol[2|vm=2|ROOT]:java.lang.RuntimeException: File
[803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
2013-10-15 13:31:40,061 INFO [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Unable to contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is
unreachable: Unable to create Vol[2|vm=2|ROOT]:java.lang.RuntimeException:
File [803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
at
com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2566)
at
com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2617)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:889)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:571)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:556)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:928)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1672)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157)
at
com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
at
com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33)
at
com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81)
at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
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:679)
2013-10-15 13:31:40,068 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Cleaning up resources for the vm
VM[ConsoleProxy|v-2-VM] in Starting state
type TEMPLATE copyAsync inspecting dest type VOLUME
2013-10-15 13:33:00,630 DEBUG [agent.transport.Request] (secstorage-1:null)
Seq 1-401276957: Waiting for Seq 401276956 Scheduling: { Cmd , MgmtId:
15929225863658, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:b8766e32c0c838539a8f75c2cc62a30b,origUrl:http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova,uuid:e1eb1bf2-35c3-11e3-a10c-0e7ccfd961ea,id:8,format:OVA,accountId:1,checksum:8fde62b1089e5844a9cd3b9b953f9596,hvm:false,displayText:SystemVM
Template
[jira] [Updated] (CLOUDSTACK-4875) VMWARE:SYSTEM VM: Unable to create deployment for VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ram Ganesh updated CLOUDSTACK-4875:
---
Assignee: Likitha Shetty (was: Sateesh Chodapuneedi)
VMWARE:SYSTEM VM: Unable to create deployment for VM
Key: CLOUDSTACK-4875
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4875
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM, VMware
Affects Versions: 4.2.1
Environment: Master with vCenter 5.5 / ESXi 5.5
Reporter: Parth Jagirdar
Assignee: Likitha Shetty
Priority: Blocker
Fix For: 4.2.1
Attachments: catalina.out, management-server.log, VC5.5.jpg
Unable to launch system VM's
See attached logs
2013-10-15 13:31:40,061 DEBUG [cloud.storage.VolumeManagerImpl]
(consoleproxy-1:null) Unable to create
Vol[2|vm=2|ROOT]:java.lang.RuntimeException: File
[803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
2013-10-15 13:31:40,061 INFO [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Unable to contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is
unreachable: Unable to create Vol[2|vm=2|ROOT]:java.lang.RuntimeException:
File [803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
at
com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2566)
at
com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2617)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:889)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:571)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:556)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:928)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1672)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157)
at
com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
at
com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33)
at
com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81)
at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
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:679)
2013-10-15 13:31:40,068 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Cleaning up resources for the vm
VM[ConsoleProxy|v-2-VM] in Starting state
type TEMPLATE copyAsync inspecting dest type VOLUME
2013-10-15 13:33:00,630 DEBUG [agent.transport.Request] (secstorage-1:null)
Seq 1-401276957: Waiting for Seq 401276956 Scheduling: { Cmd , MgmtId:
15929225863658, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:b8766e32c0c838539a8f75c2cc62a30b,origUrl:http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova,uuid:e1eb1bf2-35c3-11e3-a10c-0e7ccfd961ea,id:8,format:OVA,accountId:1,checksum:8fde62b1089e5844a9cd3b9b953f9596,hvm:false,displayText:SystemVM
Template
[jira] [Commented] (CLOUDSTACK-4681) data disk with local disk offering are geting created on shared storage .
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799016#comment-13799016 ] ASF subversion and git services commented on CLOUDSTACK-4681: - Commit 624b324cc1299f93ca2aaf08f8d6484cf39adaa3 in branch refs/heads/4.2 from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=624b324 ] CLOUDSTACK-4681: data disk with local disk offering are geting created on shared storage The cluster and zone wide storage pool allocators returned shared pools even for volumes meant to be on local storage pool. If the VM uses local disk then cluster and zone storage allocators should not handle it and return null or empty list. Also fixed the deployment planner to avoid a cluster if a. avoid set returned by storage pool allocators is empty OR b. all local or shared pools in a cluster are in avoid state data disk with local disk offering are geting created on shared storage . - Key: CLOUDSTACK-4681 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4681 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 Environment: hypervisor:KVM Reporter: prashant kumar mishra Assignee: Koushik Das Priority: Critical Fix For: 4.2.1 Attachments: Logs_DB.rar Steps to reproduce 1-prapare a CS setup with kvm host +zone wide primary 2-deploy a vm 3-enable local storage at zone level(do not restart MS ) 4-create a local disk offering 5-create a service offering with storage type local 6-deploy a vm with local SO and local disk offering Expected -- 1-since local storage is not visible to MS(did not restart MS) vm deployment should fail Actual --- vm root and data disk are getting created on shared storage My observation -- 1-After MS restart root disk and data disk are getting created on local storage. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4681) data disk with local disk offering are geting created on shared storage .
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799041#comment-13799041 ] ASF subversion and git services commented on CLOUDSTACK-4681: - Commit 0c1800f70f2faa919ceaf92b00e9edeb79f2c15c in branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0c1800f ] CLOUDSTACK-4681: data disk with local disk offering are geting created on shared storage The cluster and zone wide storage pool allocators returned shared pools even for volumes meant to be on local storage pool. If the VM uses local disk then cluster and zone storage allocators should not handle it and return null or empty list. Also fixed the deployment planner to avoid a cluster if a. avoid set returned by storage pool allocators is empty OR b. all local or shared pools in a cluster are in avoid state Conflicts: engine/storage/src/org/apache/cloudstack/storage/allocator/ClusterScopeStoragePoolAllocator.java engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java data disk with local disk offering are geting created on shared storage . - Key: CLOUDSTACK-4681 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4681 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 Environment: hypervisor:KVM Reporter: prashant kumar mishra Assignee: Koushik Das Priority: Critical Fix For: 4.2.1 Attachments: Logs_DB.rar Steps to reproduce 1-prapare a CS setup with kvm host +zone wide primary 2-deploy a vm 3-enable local storage at zone level(do not restart MS ) 4-create a local disk offering 5-create a service offering with storage type local 6-deploy a vm with local SO and local disk offering Expected -- 1-since local storage is not visible to MS(did not restart MS) vm deployment should fail Actual --- vm root and data disk are getting created on shared storage My observation -- 1-After MS restart root disk and data disk are getting created on local storage. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4681) data disk with local disk offering are geting created on shared storage .
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-4681. - Resolution: Fixed data disk with local disk offering are geting created on shared storage . - Key: CLOUDSTACK-4681 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4681 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 Environment: hypervisor:KVM Reporter: prashant kumar mishra Assignee: Koushik Das Priority: Critical Fix For: 4.2.1 Attachments: Logs_DB.rar Steps to reproduce 1-prapare a CS setup with kvm host +zone wide primary 2-deploy a vm 3-enable local storage at zone level(do not restart MS ) 4-create a local disk offering 5-create a service offering with storage type local 6-deploy a vm with local SO and local disk offering Expected -- 1-since local storage is not visible to MS(did not restart MS) vm deployment should fail Actual --- vm root and data disk are getting created on shared storage My observation -- 1-After MS restart root disk and data disk are getting created on local storage. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4811) Adding Incorrect CIDR in public ip range of zone create wizard is allowing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T resolved CLOUDSTACK-4811. - Resolution: Fixed Adding Incorrect CIDR in public ip range of zone create wizard is allowing -- Key: CLOUDSTACK-4811 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4811 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Jayapal Reddy Assignee: Damodar Reddy T Priority: Critical Fix For: 4.2.1 1. Add a new zone from UI add zone wizard. 2. Add incorrect cidr in in 3rd tab Setup network PUBLIC TRAFFIC gateway netmask VLANStart IP End IP 10.147.52.1 255.255.25.0 52 10.147.52.100 10.147.52.120 3. UI is allowing the above config 4. The zone will also get deployed. 5. The problem is coming in creating the public interface in system vms. If the interface got created problem in reaching the public network. 6. This issue is pain to user because after deploying zone user need to recreate zone again. Also some times user don't realise about the misconfiguration. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-3420) [Portable IP] Generate alerts when Portable IP usage goes beyond thresh hold
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-3420: - Priority: Major (was: Critical) Fix Version/s: (was: 4.2.1) Future [Portable IP] Generate alerts when Portable IP usage goes beyond thresh hold Key: CLOUDSTACK-3420 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3420 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit id # 67cab313c969e5f488d6c0f92f9ec058288a96a0 Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Fix For: Future Attachments: logs.tgz Step to reproduce: 1. Have at least one CloudStack with at least 2 advanced zones. 2. Add a portable IP range 3. Login as at least one non-ROOT domain user and try acquire all the Portable IPs to a network that non-ROOT domain user holds. 4. verify for alerts as admin and non-ROOT domain user Observations: (i) There is no alert generated during the above process saying IPs are low (or) there are no IPs free. Attaching all the required logs along with db dump to the bug. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3911) [PortableIP] there is no check while adding a zone public range to see whether the same VLAN exists in portable IP range.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799052#comment-13799052 ] ASF subversion and git services commented on CLOUDSTACK-3911: - Commit 779ef4b4c51ca8961098f885811d18d6f1401e0e in branch refs/heads/4.2 from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=779ef4b ] CLOUDSTACK-3911: [PortableIP] there is no check while adding a zone public range to see whether the same VLAN exists in portable IP range. added check to enusre a VLAN id used for a public IP range is not used for portable ip range [PortableIP] there is no check while adding a zone public range to see whether the same VLAN exists in portable IP range. -- Key: CLOUDSTACK-3911 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3911 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: commit # ca474d0e09f772cb22abf2802a308a2da5351592 Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Priority: Critical Fix For: 4.2.1 Steps to reproduce: 1. Have at least one portable IP range added for ex: VLAN 54, start ip : 10.147.54.100, end ip : 10.147.54.150, netmask : 255.255.255.0 2. create an advanced zone. during the creation of advanced zone specify the above VLAN with either the same of different ip ranges. Observations: (i) zone gets created successfully without any issues. (ii) Ideally it should throw an error saying there is another VLAN exists on the network. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3420) [Portable IP] Generate alerts when Portable IP usage goes beyond thresh hold
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799051#comment-13799051 ] Murali Reddy commented on CLOUDSTACK-3420: -- Pushed out of 4.2.1. Its good to have this functionality but not critical enough to fix it in 4.2.1. [Portable IP] Generate alerts when Portable IP usage goes beyond thresh hold Key: CLOUDSTACK-3420 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3420 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit id # 67cab313c969e5f488d6c0f92f9ec058288a96a0 Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Fix For: Future Attachments: logs.tgz Step to reproduce: 1. Have at least one CloudStack with at least 2 advanced zones. 2. Add a portable IP range 3. Login as at least one non-ROOT domain user and try acquire all the Portable IPs to a network that non-ROOT domain user holds. 4. verify for alerts as admin and non-ROOT domain user Observations: (i) There is no alert generated during the above process saying IPs are low (or) there are no IPs free. Attaching all the required logs along with db dump to the bug. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3911) [PortableIP] there is no check while adding a zone public range to see whether the same VLAN exists in portable IP range.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799063#comment-13799063 ] ASF subversion and git services commented on CLOUDSTACK-3911: - Commit a3b1a49c303a929c754561ca07fd8a9ed84e0382 in branch refs/heads/master from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a3b1a49 ] CLOUDSTACK-3911: [PortableIP] there is no check while adding a zone public range to see whether the same VLAN exists in portable IP range. added check to enusre a VLAN id used for a public IP range is not used for portable ip range Conflicts: server/src/com/cloud/configuration/ConfigurationManagerImpl.java [PortableIP] there is no check while adding a zone public range to see whether the same VLAN exists in portable IP range. -- Key: CLOUDSTACK-3911 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3911 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: commit # ca474d0e09f772cb22abf2802a308a2da5351592 Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Priority: Critical Fix For: 4.2.1 Steps to reproduce: 1. Have at least one portable IP range added for ex: VLAN 54, start ip : 10.147.54.100, end ip : 10.147.54.150, netmask : 255.255.255.0 2. create an advanced zone. during the creation of advanced zone specify the above VLAN with either the same of different ip ranges. Observations: (i) zone gets created successfully without any issues. (ii) Ideally it should throw an error saying there is another VLAN exists on the network. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-3911) [PortableIP] there is no check while adding a zone public range to see whether the same VLAN exists in portable IP range.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-3911. -- Resolution: Fixed [PortableIP] there is no check while adding a zone public range to see whether the same VLAN exists in portable IP range. -- Key: CLOUDSTACK-3911 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3911 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: commit # ca474d0e09f772cb22abf2802a308a2da5351592 Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Priority: Critical Fix For: 4.2.1 Steps to reproduce: 1. Have at least one portable IP range added for ex: VLAN 54, start ip : 10.147.54.100, end ip : 10.147.54.150, netmask : 255.255.255.0 2. create an advanced zone. during the creation of advanced zone specify the above VLAN with either the same of different ip ranges. Observations: (i) zone gets created successfully without any issues. (ii) Ideally it should throw an error saying there is another VLAN exists on the network. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4849) LXC not working when using nonoss build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799065#comment-13799065 ] ASF subversion and git services commented on CLOUDSTACK-4849: - Commit a99694b82edc3a8ba9bd496e6c41d8806a06df6c in branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a99694b ] [CLOUDSTACK-4849] adding lxc to the spring context LXC not working when using nonoss build --- Key: CLOUDSTACK-4849 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4849 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Francois Gaudreault Priority: Critical Fix For: 4.2.1 When you compile nonoss RPMs, the LXC manager will not work. There is a line missing in the nonossComponentContext.xml file. The error in the log will be : Could not find corresponding resource manager for LXC You can fix that by changing the following block: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean To: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=LxcServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4849) LXC not working when using nonoss build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799067#comment-13799067 ] ASF subversion and git services commented on CLOUDSTACK-4849: - Commit 8f5965c7933489f2b39c8eeaa112fbd871d2c357 in branch refs/heads/4.2 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8f5965c ] [CLOUDSTACK-4849] adding lxc to the spring context LXC not working when using nonoss build --- Key: CLOUDSTACK-4849 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4849 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Francois Gaudreault Priority: Critical Fix For: 4.2.1 When you compile nonoss RPMs, the LXC manager will not work. There is a line missing in the nonossComponentContext.xml file. The error in the log will be : Could not find corresponding resource manager for LXC You can fix that by changing the following block: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean To: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=LxcServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4849) LXC not working when using nonoss build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland resolved CLOUDSTACK-4849. --- Resolution: Fixed added lxc to spring context for nonoss LXC not working when using nonoss build --- Key: CLOUDSTACK-4849 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4849 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Francois Gaudreault Priority: Critical Fix For: 4.2.1 When you compile nonoss RPMs, the LXC manager will not work. There is a line missing in the nonossComponentContext.xml file. The error in the log will be : Could not find corresponding resource manager for LXC You can fix that by changing the following block: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean To: bean id=resourceDiscoverers class=com.cloud.utils.component.AdapterList property name=Adapters list ref bean=XcpServerDiscoverer/ ref bean=SecondaryStorageDiscoverer/ ref bean=KvmServerDiscoverer/ ref bean=LxcServerDiscoverer/ ref bean=BareMetalDiscoverer/ ref bean=OvmDiscoverer/ ref bean=vmwareServerDiscoverer/ /list /property /bean -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4891) support advanced shared network with 'security groups' and with L4-L7 service
Murali Reddy created CLOUDSTACK-4891: Summary: support advanced shared network with 'security groups' and with L4-L7 service Key: CLOUDSTACK-4891 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4891 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Murali Reddy Fix For: Future From 4.2, advanced zone 'shared network' supports security group based isolation. Also 'shared networks' can now support full set of L4-L7 services available for isolated networks. Idea is to be able to provide L4-L7 services in shared network with security group isolation. There are hardcoded assumptions and restriction which make the functionality not to work. - public traffic type is not allowed in advanced 'shared' network with SG - Source NAT can not be used with security groups This bug is to explore the possibility and relax the restriction so that use case can be met. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799084#comment-13799084 ] Anshul Gangwar commented on CLOUDSTACK-4792: I will add the global configuration parameter for timeout settings. My concern is whether it is ok to make such change for 4.2.1? Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4783) Unable to see a derieved template if the parent template is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799097#comment-13799097 ] ASF subversion and git services commented on CLOUDSTACK-4783: - Commit 5eb5594e8e646dbba29746c5aeb8cb8dd2a3c343 in branch refs/heads/4.2 from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5eb5594 ] CLOUDSTACK-4783: Added supported for listing all templates/ISOs with showremoved = true Unable to see a derieved template if the parent template is deleted --- Key: CLOUDSTACK-4783 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4783 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.2.1 Functionality required/broken – For a template, if the parent template info (template Id) is provided in the listTemplates API then one should be able to query for the parent template id as well (whether existing/removed doesn't matter) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799101#comment-13799101 ] Milamber commented on CLOUDSTACK-4792: -- I think we need 2 new parameters only (connecttimeout and timeout - the same for http/https). I'm not sure if is an acceptable change for minor version 4.2.1 in all cases (hard coding in code or set by global conf). I think with that 30 sec timeout (instead of infinite), you introduce a new behavior which may prejudicial for current installation CS 4.2. For example, if I have a CS installation with a good smtp server but it's very slow ( 30 secs) to accept a new email, then the 30 secs timeout will break the email sending. To respect the current behavior (CS 4.X), in my mind, we need to add these new settings in global conf, with the default value 'infinite' (default value from javamail), and allows user to change this in the Web UI. If we select (or prefer to have) the default value to 30 secs, it's must be annotated in Release Notes of 4.2.1. I thinks that the master (4.3) branch must have too this new settings. Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4892) KVM snapshots are failing on CLVM
Ivan Kozlov created CLOUDSTACK-4892:
---
Summary: KVM snapshots are failing on CLVM
Key: CLOUDSTACK-4892
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4892
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM, Snapshot
Affects Versions: 4.2.0
Environment: CentOS 6.4, KVM, CLVM
Reporter: Ivan Kozlov
Creating snaphot fails hanging with state CreatedOnPrimary. Sometimes creating
snaphot is successful.
Snapshot logical volume is created and not deleted.
When running snaphot with only single host snapshot is created normaly. Guess
snapshot backup is trying access snapshot LV from host on which snapshot LV is
not opened.
Here is management log:
2013-10-18 17:32:58,512 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-10:null) submit async job-41 = [
88ec27d7-78af-4664-a01b-eeca4469e37c ], details: AsyncJobVO {id:41, userId: 2,
accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 10, cmd:
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd,
cmdOriginator: null, cmdInfo:
{id:10,response:json,sessionkey:HKb50xNHyZm2wJx/IHi5S7UWBGQ\u003d,cmdEventType:SNAPSHOT.CREATE,ctxUserId:2,httpmethod:GET,_:1382106777170,volumeid:560a9f6e-9864-43cc-8096-ed9cd6c97311,ctxAccountId:2,ctxStartEventId:126},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 161342718518,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-10-18 17:32:58,514 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Executing
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-41 =
[ 88ec27d7-78af-4664-a01b-eeca4469e37c ]
2013-10-18 17:32:58,549 INFO [user.snapshot.CreateSnapshotCmd]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) VOLSS:
createSnapshotCmd starts:1382106778549
2013-10-18 17:32:58,925 DEBUG [agent.transport.Request] (Job-Executor-22:job-41
= [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Seq 1-111542657: Sending { Cmd ,
MgmtId: 161342718518, via: 1, Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.CreateObjectCommand:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{volume:{uuid:560a9f6e-9864-43cc-8096-ed9cd6c97311,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4a975c8c-997a-4d1d-aa88-810fd281cb04,id:1,poolType:CLVM,host:localhost,path:/vg_primary,port:0}},name:ROOT-5,size:8589934592,path:4f3e8cfc-d3be-4e55-bc13-5c236a689c83,volumeId:5,vmName:i-2-5-VM,accountId:2,format:RAW,id:5,hypervisorType:KVM},parentSnapshotPath:/dev/vg_primary/4f3e8cfc-d3be-4e55-bc13-5c236a689c83/7e85ab28-4ea5-4b5e-8ec1-1abadf2d571e,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4a975c8c-997a-4d1d-aa88-810fd281cb04,id:1,poolType:CLVM,host:localhost,path:/vg_primary,port:0}},vmName:i-2-5-VM,name:test-100_ROOT-5_20131018143258,hypervisorType:KVM,id:10}},wait:0}}]
}
2013-10-18 17:32:59,986 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 1-111542657: Processing: { Ans: , MgmtId:
161342718518, via: 1, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CreateObjectAnswer:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/dev/vg_primary/4f3e8cfc-d3be-4e55-bc13-5c236a689c83/c6c900d1-1377-4347-ba69-9ba09f264f69,id:0}},result:true,wait:0}}]
}
2013-10-18 17:32:59,986 DEBUG [agent.transport.Request] (Job-Executor-22:job-41
= [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Seq 1-111542657: Received: { Ans:
, MgmtId: 161342718518, via: 1, Ver: v1, Flags: 10, { CreateObjectAnswer } }
2013-10-18 17:33:00,497 DEBUG [storage.motion.AncientDataMotionStrategy]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) copyAsync
inspecting src type SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-10-18 17:33:00,547 DEBUG [agent.transport.Request] (Job-Executor-22:job-41
= [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Seq 4-1918238786: Sending { Cmd ,
MgmtId: 161342718518, via: 4, Ver: v1, Flags: 100111,
[jira] [Created] (CLOUDSTACK-4893) Documentation about Security Groups and OVS
Ivan Kozlov created CLOUDSTACK-4893: --- Summary: Documentation about Security Groups and OVS Key: CLOUDSTACK-4893 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4893 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Environment: KVM, OVS Reporter: Ivan Kozlov Priority: Trivial In Installation Guide (8.1. KVM Hypervisor Host Installation - 8.1.8. Configure the network using OpenVswitch) nothing is said about compatability of Security Groups and OVS. I think it should be mentioned. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4864) Create VMWare 64 bit system VM template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-4864: - Attachment: systemvmtemplate64.ovf OVF file for system vm template based on Debian7-64-bit. Make sure name of vmdk disk image (disk1 of this system vm template) is named as systemvmtemplate64-disk1 Create VMWare 64 bit system VM template --- Key: CLOUDSTACK-4864 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4864 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Reporter: Abhinandan Prateek Assignee: Sateesh Chodapuneedi Priority: Blocker Fix For: 4.2.1 Attachments: systemvmtemplate64.ovf VMWare 64 bit template requires some custom work. Default template that is generated by jenkins has wrong cdrom setup and vmware tools, that needs to be fixed manually. Harddisk type is also incompatible. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (CLOUDSTACK-4864) Create VMWare 64 bit system VM template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799307#comment-13799307 ] Sateesh Chodapuneedi edited comment on CLOUDSTACK-4864 at 10/18/13 5:13 PM: OVF file for system vm template based on Debian7-64-bit. Make sure name of vmdk disk image (disk1 of this system vm template) is named as systemvmtemplate64-disk1.vmdk was (Author: sateeshc): OVF file for system vm template based on Debian7-64-bit. Make sure name of vmdk disk image (disk1 of this system vm template) is named as systemvmtemplate64-disk1 Create VMWare 64 bit system VM template --- Key: CLOUDSTACK-4864 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4864 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Reporter: Abhinandan Prateek Assignee: Sateesh Chodapuneedi Priority: Blocker Fix For: 4.2.1 Attachments: systemvmtemplate64.ovf VMWare 64 bit template requires some custom work. Default template that is generated by jenkins has wrong cdrom setup and vmware tools, that needs to be fixed manually. Harddisk type is also incompatible. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4864) Create VMWare 64 bit system VM template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi resolved CLOUDSTACK-4864. -- Resolution: Fixed Provided fixed OVF. Create VMWare 64 bit system VM template --- Key: CLOUDSTACK-4864 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4864 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Reporter: Abhinandan Prateek Assignee: Sateesh Chodapuneedi Priority: Blocker Fix For: 4.2.1 Attachments: systemvmtemplate64.ovf VMWare 64 bit template requires some custom work. Default template that is generated by jenkins has wrong cdrom setup and vmware tools, that needs to be fixed manually. Harddisk type is also incompatible. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4892) KVM snapshots are failing on CLVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799313#comment-13799313
]
Ivan Kozlov commented on CLOUDSTACK-4892:
-
managesnapshot.sh checks snapshot with the following command:
if ! dmsetup info -c --noheadings -o name ${vg_dm}-${snapshotname} /dev/null
21; then
it is successful on one host (i think host that created snaphot on primary)
dmsetup info -c --noheadings -o name
vg_primary-7ce7c39f59b6391a287a19906241060d
vg_primary-7ce7c39f59b6391a287a19906241060d
and fails on others
dmsetup info -c --noheadings -o name vg_primary-7ce7c39f59b6391a287a19906241060d
Device does not exist.
Command failed
However on every host vg_primary-7ce7c39f59b6391a287a19906241060d--cow is
present
KVM snapshots are failing on CLVM
-
Key: CLOUDSTACK-4892
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4892
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Snapshot
Affects Versions: 4.2.0
Environment: CentOS 6.4, KVM, CLVM
Reporter: Ivan Kozlov
Creating snaphot fails hanging with state CreatedOnPrimary. Sometimes
creating snaphot is successful.
Snapshot logical volume is created and not deleted.
When running snaphot with only single host snapshot is created normaly. Guess
snapshot backup is trying access snapshot LV from host on which snapshot LV
is not opened.
Here is management log:
2013-10-18 17:32:58,512 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-10:null) submit async job-41 = [
88ec27d7-78af-4664-a01b-eeca4469e37c ], details: AsyncJobVO {id:41, userId:
2, accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 10,
cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd,
cmdOriginator: null, cmdInfo:
{id:10,response:json,sessionkey:HKb50xNHyZm2wJx/IHi5S7UWBGQ\u003d,cmdEventType:SNAPSHOT.CREATE,ctxUserId:2,httpmethod:GET,_:1382106777170,volumeid:560a9f6e-9864-43cc-8096-ed9cd6c97311,ctxAccountId:2,ctxStartEventId:126},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 161342718518,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-10-18 17:32:58,514 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Executing
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-41
= [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]
2013-10-18 17:32:58,549 INFO [user.snapshot.CreateSnapshotCmd]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) VOLSS:
createSnapshotCmd starts:1382106778549
2013-10-18 17:32:58,925 DEBUG [agent.transport.Request]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Seq
1-111542657: Sending { Cmd , MgmtId: 161342718518, via: 1, Ver: v1, Flags:
100011,
[{org.apache.cloudstack.storage.command.CreateObjectCommand:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{volume:{uuid:560a9f6e-9864-43cc-8096-ed9cd6c97311,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4a975c8c-997a-4d1d-aa88-810fd281cb04,id:1,poolType:CLVM,host:localhost,path:/vg_primary,port:0}},name:ROOT-5,size:8589934592,path:4f3e8cfc-d3be-4e55-bc13-5c236a689c83,volumeId:5,vmName:i-2-5-VM,accountId:2,format:RAW,id:5,hypervisorType:KVM},parentSnapshotPath:/dev/vg_primary/4f3e8cfc-d3be-4e55-bc13-5c236a689c83/7e85ab28-4ea5-4b5e-8ec1-1abadf2d571e,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4a975c8c-997a-4d1d-aa88-810fd281cb04,id:1,poolType:CLVM,host:localhost,path:/vg_primary,port:0}},vmName:i-2-5-VM,name:test-100_ROOT-5_20131018143258,hypervisorType:KVM,id:10}},wait:0}}]
}
2013-10-18 17:32:59,986 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 1-111542657: Processing: { Ans: , MgmtId:
161342718518, via: 1, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CreateObjectAnswer:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/dev/vg_primary/4f3e8cfc-d3be-4e55-bc13-5c236a689c83/c6c900d1-1377-4347-ba69-9ba09f264f69,id:0}},result:true,wait:0}}]
}
2013-10-18 17:32:59,986 DEBUG [agent.transport.Request]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Seq
1-111542657: Received: { Ans: , MgmtId: 161342718518, via: 1, Ver: v1,
Flags: 10, { CreateObjectAnswer } }
2013-10-18 17:33:00,497 DEBUG [storage.motion.AncientDataMotionStrategy]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) copyAsync
inspecting src type SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-10-18 17:33:00,547 DEBUG [agent.transport.Request]
(Job-Executor-22:job-41
[jira] [Commented] (CLOUDSTACK-4875) VMWARE:SYSTEM VM: Unable to create deployment for VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799332#comment-13799332
]
Parth Jagirdar commented on CLOUDSTACK-4875:
Yes, similar symptoms, However this one was observed on vCenter 5.5.
VMWARE:SYSTEM VM: Unable to create deployment for VM
Key: CLOUDSTACK-4875
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4875
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM, VMware
Affects Versions: 4.2.1
Environment: Master with vCenter 5.5 / ESXi 5.5
Reporter: Parth Jagirdar
Assignee: Likitha Shetty
Priority: Blocker
Fix For: 4.2.1
Attachments: catalina.out, management-server.log, VC5.5.jpg
Unable to launch system VM's
See attached logs
2013-10-15 13:31:40,061 DEBUG [cloud.storage.VolumeManagerImpl]
(consoleproxy-1:null) Unable to create
Vol[2|vm=2|ROOT]:java.lang.RuntimeException: File
[803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
2013-10-15 13:31:40,061 INFO [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Unable to contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is
unreachable: Unable to create Vol[2|vm=2|ROOT]:java.lang.RuntimeException:
File [803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
at
com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2566)
at
com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2617)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:889)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:571)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:556)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:928)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1672)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157)
at
com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
at
com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33)
at
com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81)
at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
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:679)
2013-10-15 13:31:40,068 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Cleaning up resources for the vm
VM[ConsoleProxy|v-2-VM] in Starting state
type TEMPLATE copyAsync inspecting dest type VOLUME
2013-10-15 13:33:00,630 DEBUG [agent.transport.Request] (secstorage-1:null)
Seq 1-401276957: Waiting for Seq 401276956 Scheduling: { Cmd , MgmtId:
15929225863658, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:b8766e32c0c838539a8f75c2cc62a30b,origUrl:http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova,uuid:e1eb1bf2-35c3-11e3-a10c-0e7ccfd961ea,id:8,format:OVA,accountId:1,checksum:8fde62b1089e5844a9cd3b9b953f9596,hvm:false,displayText:SystemVM
Template
[jira] [Created] (CLOUDSTACK-4894) destroyVm API: add support to force expunge the vm immediately
Alena Prokharchyk created CLOUDSTACK-4894: - Summary: destroyVm API: add support to force expunge the vm immediately Key: CLOUDSTACK-4894 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4894 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.2.1 When destroyVM API is called, the vm gets destroyed only in the DB. The actual expunge is being taken care later on by expunge thread (configured using expunge.interval and expunge.delay params). As we keep on getting the requests on adding a support for forceful expunge - when vm is expunged immediately after the call is made - it would make sense to introduce some flag to destroyVm command, controlling the behavior. So destroyVm will get new parameter - expunge (boolean, false by default). When true is passed as a value, the vm will be expunged right away. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4746) Allocation capacity of a cluster during HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799594#comment-13799594 ] ASF subversion and git services commented on CLOUDSTACK-4746: - Commit de28812addef186ad6740582d3e31b7d1609c058 in branch refs/heads/4.2 from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=de28812 ] CLOUDSTACK-4746: From functionality point of view following will be changes. - Threshold will not be applied for vms undergoing HA process (say during host going down event). - Threshold will not be applied for vms undergoing maintenance. - Threshold will apply for stop-start vm after the skip.counting.hours (time till which we reserve the capacity for the stopped vm). Reason being stop-start is a user initiated action and we are giving a time window (skip.counting.hours) till which its guaranteed to start in the same cluster. After that time, threshold check applies bcz we still want to reserve the capacity for urgent situations like HA, putting host into maintenance rather than get it consumed in such user initiated actions. Signed off by : nitin mehtanitin.me...@citrix.com Allocation capacity of a cluster during HA -- Key: CLOUDSTACK-4746 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4746 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.2.1 When the host goes down. Cloudstack will stop the VM's for which HA is not enabled. Once cloudstack marks these VM's as stopped then the capacity of these VM's is moved into the reserved capacity. If the VM's are HA enabled then cloudstack will stop and start the VM's on another host. During this time the capacity of the VM's will be moved to reserved capacity once the VM's are stopped, But when the Vm's are being started cloudstack will try to calculate what will be total allocated capacity if the VM is started again ( even though the CPU for the VM is already reserved). This is a bug in cloudstack where the CPU required for the VM is considered twice when calculating the allocated capacity. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4895) Management server fails to start because snapshot policy time zones have day light savings
Prachi Damle created CLOUDSTACK-4895: Summary: Management server fails to start because snapshot policy time zones have day light savings Key: CLOUDSTACK-4895 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4895 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Snapshot Affects Versions: 4.2.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.2.1 Server startup fails while rescheduling snapshots as per set policies: 2013-10-14 10:04:06,052 ERROR [utils.component.ComponentLocator] (main:null) Unable to load configuration for management-server from components.xml java.lang.IllegalArgumentException: HOUR_OF_DAY The issue is caused when the timezone of the policy undergoes DST changes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4896) Template store ref and template Sync
Nitin Mehta created CLOUDSTACK-4896: --- Summary: Template store ref and template Sync Key: CLOUDSTACK-4896 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4896 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nitin Mehta I observed that while registering a template if we face an error we delete the entry from template store ref and hence template is not visible in the UI. This didn't use to happen pre 4.2 and we used to show the template in UI. Also we don't retry the errored out templates as part of template sync, this again is breaking the old behavior. I guess we should fix this right ? Thoughts/Comments ? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4896) Template/Volume store ref and template Sync
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-4896: Summary: Template/Volume store ref and template Sync (was: Template store ref and template Sync) Template/Volume store ref and template Sync Key: CLOUDSTACK-4896 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4896 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Nitin Mehta I observed that while registering a template if we face an error we delete the entry from template store ref and hence template is not visible in the UI. This didn't use to happen pre 4.2 and we used to show the template in UI. Also we don't retry the errored out templates as part of template sync, this again is breaking the old behavior. I guess we should fix this right ? Thoughts/Comments ? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4896) Template store ref and template Sync
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799636#comment-13799636 ] Nitin Mehta commented on CLOUDSTACK-4896: - Its not just the admin but the end user gets affected as well with no feedback to them on the UI. He/She with the current behaviour would just start seeing their templates disappearing in case of any error on ssvm, only to dig into the logs for the real issue. Template Sync was a good mechanism to retry download for all the erred out templates once the problem on ssvm is corrected. I don’t think we are failing fast here. We used to fail similarly earlier, but there was a retry mechanism in template sync and better feedb I see that for uploaded volumes the experience is all the more bad. When someone uploads a volume, if there is an error the volume persists on the UI with no indication of error or anything(because volume_store_ref entry is removed). Instead it shows up as a normal data disk (as if added through Add Volume) and gets attached to the vm. Template store ref and template Sync - Key: CLOUDSTACK-4896 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4896 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Nitin Mehta I observed that while registering a template if we face an error we delete the entry from template store ref and hence template is not visible in the UI. This didn't use to happen pre 4.2 and we used to show the template in UI. Also we don't retry the errored out templates as part of template sync, this again is breaking the old behavior. I guess we should fix this right ? Thoughts/Comments ? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4895) Management server fails to start because snapshot policy time zones have day light savings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799669#comment-13799669 ] ASF subversion and git services commented on CLOUDSTACK-4895: - Commit a00433ff233a7597a46153abb98de1818ca01e61 in branch refs/heads/4.2 from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a00433f ] CLOUDSTACK-4895: Management server fails to start because snapshot policy time zones have day light savings Changes: - Calendar throws IllegalArgumentException when the hour of the day happens to be skipped due to DST changes. - Fix will ask Calendar to adjust the time accordingly and get the next closest time Management server fails to start because snapshot policy time zones have day light savings -- Key: CLOUDSTACK-4895 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4895 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Snapshot Affects Versions: 4.2.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.2.1 Server startup fails while rescheduling snapshots as per set policies: 2013-10-14 10:04:06,052 ERROR [utils.component.ComponentLocator] (main:null) Unable to load configuration for management-server from components.xml java.lang.IllegalArgumentException: HOUR_OF_DAY The issue is caused when the timezone of the policy undergoes DST changes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4895) Management server fails to start because snapshot policy time zones have day light savings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799703#comment-13799703 ] ASF subversion and git services commented on CLOUDSTACK-4895: - Commit 9d625405d3c322c76c6935fd7a5ab1b576d64e16 in branch refs/heads/master from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9d62540 ] CLOUDSTACK-4895: Management server fails to start because snapshot policy time zones have day light savings Changes: - Calendar throws IllegalArgumentException when the hour of the day happens to be skipped due to DST changes. - Fix will ask Calendar to adjust the time accordingly and get the next closest time Management server fails to start because snapshot policy time zones have day light savings -- Key: CLOUDSTACK-4895 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4895 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Snapshot Affects Versions: 4.2.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.2.1 Server startup fails while rescheduling snapshots as per set policies: 2013-10-14 10:04:06,052 ERROR [utils.component.ComponentLocator] (main:null) Unable to load configuration for management-server from components.xml java.lang.IllegalArgumentException: HOUR_OF_DAY The issue is caused when the timezone of the policy undergoes DST changes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-3285) UCS: Need support for HTTP redirects and HTTPS Certificate handling
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amogh Vasekar resolved CLOUDSTACK-3285. --- Resolution: Fixed Fix Version/s: 4.2.1 Committed to 4.2 branch UCS: Need support for HTTP redirects and HTTPS Certificate handling --- Key: CLOUDSTACK-3285 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3285 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UCS Affects Versions: 4.2.0 Environment: Master; Basic Bare-metal and UCS Reporter: Parth Jagirdar Assignee: Amogh Vasekar Priority: Critical Fix For: 4.2.1 By default UCS has HTTP to HTTPs redirect enabled. At which point, addUcsManager fails with following error. 2013-06-28 14:19:57,020 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) ===START=== 10.217.252.127 -- GET command=addUcsManagerzoneid=d92cc843-8c50-4f57-9c07-1041bf859f8dname=ucsmanagerurl=10.223.184.2username=adminresponse=jsonsessionkey=NiAtOI4sZHTkTJ37Y4jz0ntaeYg%3D_=1372454390205 2013-06-28 14:19:57,256 WARN [cloudstack.api.AddUcsManagerCmd] (catalina-exec-20:null) Exception: com.cloud.utils.exception.CloudRuntimeException: Cannot get cookie at com.cloud.ucs.manager.UcsManagerImpl.getCookie(UcsManagerImpl.java:174) at com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:179) at com.cloud.ucs.manager.UcsManagerImpl.discoverBlades(UcsManagerImpl.java:123) at com.cloud.ucs.manager.UcsManagerImpl.addUcsManager(UcsManagerImpl.java:154) at org.apache.cloudstack.api.AddUcsManagerCmd.execute(AddUcsManagerCmd.java:68) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:528) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:371) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268) 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:679) Caused by: com.cloud.utils.exception.CloudRuntimeException: Call failed: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title302 Found/title /headbody h1Found/h1 pThe document has moved a href=https://10.223.184.2/nuova;here/a./p /body/html at com.cloud.ucs.manager.UcsHttpClient.call(UcsHttpClient.java:50) at com.cloud.ucs.manager.UcsManagerImpl.getCookie(UcsManagerImpl.java:166) ... 26 more Caused by: com.cloud.utils.exception.CloudRuntimeException: Call failed: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title302 Found/title /headbody h1Found/h1 pThe document has moved a href=https://10.223.184.2/nuova;here/a./p /body/html at com.cloud.ucs.manager.UcsHttpClient.call(UcsHttpClient.java:41) ... 27 more 2013-06-28 14:19:57,257 INFO [cloud.api.ApiServer] (catalina-exec-20:null) Cannot get cookie 2013-06-28 14:19:57,258 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) ===END=== 10.217.252.127 -- GET
[jira] [Updated] (CLOUDSTACK-4878) KVM snapshots are failing at CentOS 6.4 in a SG enabled ADV zone
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bjoern Teipel updated CLOUDSTACK-4878:
--
Summary: KVM snapshots are failing at CentOS 6.4 in a SG enabled ADV zone
(was: KVM snapshots are failing at CentOS 6.4)
KVM snapshots are failing at CentOS 6.4 in a SG enabled ADV zone
Key: CLOUDSTACK-4878
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4878
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.2.0
Environment: Centos 6.4 x64 recent patches
primary and seconday storage are NFS
Reporter: Bjoern Teipel
2013-10-15 21:45:59,415 DEBUG [agent.transport.Request]
(AgentManager-Handler-8:null) Seq 1-621806172: Processing: { Ans: , MgmtId:
110493122496, via: 1, Ver: v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/4/5/57ef69cd-1bc8-4e47-94c1-84834befaaad,id:0}},result:true,wait:0}}]
}
2013-10-15 21:45:59,415 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-8:null) Seq 1-621806172: No more commands found
2013-10-15 21:45:59,415 DEBUG [agent.transport.Request]
(Job-Executor-2:job-40 = [ 81b303ad-acb2-483f-9571-d09064d1d086 ]) Seq
1-621806172: Received: { Ans: , MgmtId: 110493122496, via: 1, Ver: v1,
Flags: 110, { CopyCmdAnswer } }
2013-10-15 21:45:59,417 DEBUG [storage.snapshot.SnapshotServiceImpl]
(Job-Executor-2:job-40 = [ 81b303ad-acb2-483f-9571-d09064d1d086 ]) Failed to
update snapshot state
com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
com.mysql.jdbc.JDBC4PreparedStatement@79fd21d8: SELECT snapshot_store_ref.id,
snapshot_store_ref.store_id, snapshot_store_ref.store_role,
snapshot_store_ref.snapshot_id, snapshot_store_ref.created,
snapshot_store_ref.last_updated, snapshot_store_ref.size,
snapshot_store_ref.physical_size, snapshot_store_ref.parent_snapshot_id,
snapshot_store_ref.job_id, snapshot_store_ref.install_path,
snapshot_store_ref.update_count, snapshot_store_ref.updated,
snapshot_store_ref.state, snapshot_store_ref.ref_cnt,
snapshot_store_ref.volume_id FROM snapshot_store_ref WHERE
snapshot_store_ref.snapshot_id = 1 AND snapshot_store_ref.store_id = 1 AND
snapshot_store_ref.store_role = 'Image' ORDER BY RAND() LIMIT 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:414)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:349)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.utils.db.GenericDaoBase.findOneIncludingRemovedBy(GenericDaoBase.java:859)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.utils.db.GenericDaoBase.findOneBy(GenericDaoBase.java:870)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.storage.image.db.SnapshotDataStoreDaoImpl.findByStoreSnapshot(SnapshotDataStoreDaoImpl.java:178)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.storage.snapshot.SnapshotObject.processEvent(SnapshotObject.java:253)
at
org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.copySnapshotAsyncCallback(SnapshotServiceImpl.java:315)
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:616)
at
org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
at
org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26)
at
org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120)
at
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:423)
at
[jira] [Created] (CLOUDSTACK-4897) Moving VM from local to NFS storage fails on with NPE
Bjoern Teipel created CLOUDSTACK-4897:
-
Summary: Moving VM from local to NFS storage fails on with NPE
Key: CLOUDSTACK-4897
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4897
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM, Management Server, Storage Controller
Affects Versions: 4.2.0
Environment: Windows 2012sr2 instance
Local storage on CentOS 6.4 KVM Hypervisor
NFS primary storage
Reporter: Bjoern Teipel
2013-10-18 20:14:50,895 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null)
===START=== 10.19.241.55 -- GET
command=migrateVirtualMachinestorageid=e59089ba-287a-3b87-9d0a-84af52fcf274virtualmachineid=d03f92b3-87b1-4bfb-87ea-cc27ea4f2577response=jsonsessionkey=zKssDdY9qFr3jjynRyIx6akhDIg%3Dprojectid=658b8ab8-e715-4c8c-a9ec-e1484e51732e_=1382152492133
2013-10-18 20:14:50,917 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-19:null) submit async job-97 = [
9c32890b-574c-4b78-a78f-b433190d741f ], details: AsyncJobVO {id:97, userId: 3,
accountId: 3, sessionKey: null, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null,
cmdInfo:
{response:json,sessionkey:zKssDdY9qFr3jjynRyIx6akhDIg\u003d,virtualmachineid:d03f92b3-87b1-4bfb-87ea-cc27ea4f2577,cmdEventType:VM.MIGRATE,ctxUserId:3,storageid:e59089ba-287a-3b87-9d0a-84af52fcf274,httpmethod:GET,_:1382152492133,projectid:658b8ab8-e715-4c8c-a9ec-e1484e51732e,ctxAccountId:3,ctxStartEventId:442},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 110493122496,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-10-18 20:14:50,919 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-97 = [ 9c32890b-574c-4b78-a78f-b433190d741f ]) Executing
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-97 = [
9c32890b-574c-4b78-a78f-b433190d741f ]
2013-10-18 20:14:50,921 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null)
===END=== 10.19.241.55 -- GET
command=migrateVirtualMachinestorageid=e59089ba-287a-3b87-9d0a-84af52fcf274virtualmachineid=d03f92b3-87b1-4bfb-87ea-cc27ea4f2577response=jsonsessionkey=zKssDdY9qFr3jjynRyIx6akhDIg%3Dprojectid=658b8ab8-e715-4c8c-a9ec-e1484e51732e_=1382152492133
2013-10-18 20:14:50,938 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-97 = [ 9c32890b-574c-4b78-a78f-b433190d741f ]) Unexpected
exception while executing
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
java.lang.NullPointerException
at
com.cloud.vm.UserVmManagerImpl.vmStorageMigration(UserVmManagerImpl.java:3851)
at
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:149)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
2013-10-18 20:14:50,940 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-97 = [ 9c32890b-574c-4b78-a78f-b433190d741f ]) Complete
async job-97 = [ 9c32890b-574c-4b78-a78f-b433190d741f ], jobStatus: 2,
resultCode: 530, result: Error Code: 530 Error text: null
The environment is a SG enabled advanced zone
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4897) Moving VM from local to NFS storage fails with NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bjoern Teipel updated CLOUDSTACK-4897:
--
Summary: Moving VM from local to NFS storage fails with NPE (was: Moving
VM from local to NFS storage fails on with NPE)
Moving VM from local to NFS storage fails with NPE
--
Key: CLOUDSTACK-4897
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4897
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Management Server, Storage Controller
Affects Versions: 4.2.0
Environment: Windows 2012sr2 instance
Local storage on CentOS 6.4 KVM Hypervisor
NFS primary storage
Reporter: Bjoern Teipel
2013-10-18 20:14:50,895 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null)
===START=== 10.19.241.55 -- GET
command=migrateVirtualMachinestorageid=e59089ba-287a-3b87-9d0a-84af52fcf274virtualmachineid=d03f92b3-87b1-4bfb-87ea-cc27ea4f2577response=jsonsessionkey=zKssDdY9qFr3jjynRyIx6akhDIg%3Dprojectid=658b8ab8-e715-4c8c-a9ec-e1484e51732e_=1382152492133
2013-10-18 20:14:50,917 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-19:null) submit async job-97 = [
9c32890b-574c-4b78-a78f-b433190d741f ], details: AsyncJobVO {id:97, userId:
3, accountId: 3, sessionKey: null, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null,
cmdInfo:
{response:json,sessionkey:zKssDdY9qFr3jjynRyIx6akhDIg\u003d,virtualmachineid:d03f92b3-87b1-4bfb-87ea-cc27ea4f2577,cmdEventType:VM.MIGRATE,ctxUserId:3,storageid:e59089ba-287a-3b87-9d0a-84af52fcf274,httpmethod:GET,_:1382152492133,projectid:658b8ab8-e715-4c8c-a9ec-e1484e51732e,ctxAccountId:3,ctxStartEventId:442},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 110493122496,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-10-18 20:14:50,919 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-97 = [ 9c32890b-574c-4b78-a78f-b433190d741f ]) Executing
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-97 = [
9c32890b-574c-4b78-a78f-b433190d741f ]
2013-10-18 20:14:50,921 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null)
===END=== 10.19.241.55 -- GET
command=migrateVirtualMachinestorageid=e59089ba-287a-3b87-9d0a-84af52fcf274virtualmachineid=d03f92b3-87b1-4bfb-87ea-cc27ea4f2577response=jsonsessionkey=zKssDdY9qFr3jjynRyIx6akhDIg%3Dprojectid=658b8ab8-e715-4c8c-a9ec-e1484e51732e_=1382152492133
2013-10-18 20:14:50,938 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-97 = [ 9c32890b-574c-4b78-a78f-b433190d741f ]) Unexpected
exception while executing
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
java.lang.NullPointerException
at
com.cloud.vm.UserVmManagerImpl.vmStorageMigration(UserVmManagerImpl.java:3851)
at
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:149)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
2013-10-18 20:14:50,940 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-97 = [ 9c32890b-574c-4b78-a78f-b433190d741f ]) Complete
async job-97 = [ 9c32890b-574c-4b78-a78f-b433190d741f ], jobStatus: 2,
resultCode: 530, result: Error Code: 530 Error text: null
The environment is a SG enabled advanced zone
--
This message was sent by Atlassian JIRA
(v6.1#6144)
