[jira] [Commented] (CLOUDSTACK-9595) Transactions are not getting retried in case of database deadlock errors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672955#comment-15672955 ] ASF GitHub Bot commented on CLOUDSTACK-9595: Github user jburwell commented on the issue: https://github.com/apache/cloudstack/pull/1762 Due to the previous discussion, I am -1 on merging this PR. > Transactions are not getting retried in case of database deadlock errors > > > Key: CLOUDSTACK-9595 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9595 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.8.0 >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Customer is seeing occasional error 'Deadlock found when trying to get lock; > try restarting transaction' messages in their management server logs. It > happens regularly at least once a day. The following is the error seen > 2015-12-09 19:23:19,450 ERROR [cloud.api.ApiServer] > (catalina-exec-3:ctx-f05c58fc ctx-39c17156 ctx-7becdf6e) unhandled exception > executing api command: [Ljava.lang.String;@230a6e7f > com.cloud.utils.exception.CloudRuntimeException: DB Exception on: > com.mysql.jdbc.JDBC4PreparedStatement@74f134e3: DELETE FROM > instance_group_vm_map WHERE instance_group_vm_map.instance_id = 941374 > at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1209) > at sun.reflect.GeneratedMethodAccessor360.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy237.expunge(Unknown Source) > at > com.cloud.vm.UserVmManagerImpl$2.doInTransactionWithoutResult(UserVmManagerImpl.java:2593) > at > com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) > at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at com.cloud.utils.db.Transaction.execute(Transaction.java:54) > at > com.cloud.vm.UserVmManagerImpl.addInstanceToGroup(UserVmManagerImpl.java:2575) > at > com.cloud.vm.UserVmManagerImpl.updateVirtualMachine(UserVmManagerImpl.java:2332) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672867#comment-15672867 ] ASF GitHub Bot commented on CLOUDSTACK-9503: Github user jburwell commented on the issue: https://github.com/apache/cloudstack/pull/1745 @rhtyd where do we stand determining the root cause of the test failures? > The router script times out resulting in failure of deployment > -- > > Key: CLOUDSTACK-9503 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.0 > Environment: KVM, Xen >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > > When starting the virtual router in a shared network in advance zone the > scripts on router time out. This happen as there are several sub-commands > that are consolidated in a single command. The default timeout of 2 minutes > is short. > 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) > (logid:8aedea66) process hasn't exited > 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) > (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting > virtual router > 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) > (logid:8aedea66) The guru did not like the answers so stopping > VM[DomainRouter|r-3445-VM] > — -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672862#comment-15672862 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit 22d074607c0f43ed6b1232da3d7be0e2fc66e481 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=22d0746 ] Merge release branch 4.8 to 4.9 * 4.8: CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672861#comment-15672861 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit 8c3ca15995a9a435be2bebb7040877310b4982b8 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8c3ca15 ] Merge pull request #1674 from shapeblue/master_db_timout_4_8 CLOUDSTACK-9460: For long running transactions, if the connection istimed out by the mysql server then refresh it * pr/1674: CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it Signed-off-by: John Burwell > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672859#comment-15672859 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit a813baed49e50c014fa22df81fc6bc8bc9095213 in cloudstack's branch refs/heads/master from [~abhi_shapeblue] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a813bae ] CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672858#comment-15672858 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit 22d074607c0f43ed6b1232da3d7be0e2fc66e481 in cloudstack's branch refs/heads/4.9 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=22d0746 ] Merge release branch 4.8 to 4.9 * 4.8: CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672863#comment-15672863 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit 4c15cfce07cea4348509d63b7720d04df5fcfd78 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4c15cfc ] Merge release branch 4.9 to master * 4.9: CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672857#comment-15672857 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit 8c3ca15995a9a435be2bebb7040877310b4982b8 in cloudstack's branch refs/heads/4.9 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8c3ca15 ] Merge pull request #1674 from shapeblue/master_db_timout_4_8 CLOUDSTACK-9460: For long running transactions, if the connection istimed out by the mysql server then refresh it * pr/1674: CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it Signed-off-by: John Burwell > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672860#comment-15672860 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit 8c3ca15995a9a435be2bebb7040877310b4982b8 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8c3ca15 ] Merge pull request #1674 from shapeblue/master_db_timout_4_8 CLOUDSTACK-9460: For long running transactions, if the connection istimed out by the mysql server then refresh it * pr/1674: CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it Signed-off-by: John Burwell > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672856#comment-15672856 ] ASF GitHub Bot commented on CLOUDSTACK-9460: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1674 > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672854#comment-15672854 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit 8c3ca15995a9a435be2bebb7040877310b4982b8 in cloudstack's branch refs/heads/4.9 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8c3ca15 ] Merge pull request #1674 from shapeblue/master_db_timout_4_8 CLOUDSTACK-9460: For long running transactions, if the connection istimed out by the mysql server then refresh it * pr/1674: CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it Signed-off-by: John Burwell > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672853#comment-15672853 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit a813baed49e50c014fa22df81fc6bc8bc9095213 in cloudstack's branch refs/heads/4.9 from [~abhi_shapeblue] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a813bae ] CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672851#comment-15672851 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit a813baed49e50c014fa22df81fc6bc8bc9095213 in cloudstack's branch refs/heads/4.8 from [~abhi_shapeblue] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a813bae ] CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672852#comment-15672852 ] ASF subversion and git services commented on CLOUDSTACK-9460: - Commit 8c3ca15995a9a435be2bebb7040877310b4982b8 in cloudstack's branch refs/heads/4.8 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8c3ca15 ] Merge pull request #1674 from shapeblue/master_db_timout_4_8 CLOUDSTACK-9460: For long running transactions, if the connection istimed out by the mysql server then refresh it * pr/1674: CLOUDSTACK-9460: For long running transactions, if the connection is timed out by the mysql server then refresh it Signed-off-by: John Burwell > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672847#comment-15672847 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit ad0c25fbc407893a25aa611e5fd0e9b4f6eabf48 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ad0c25f ] Merge release branch 4.9 to master * 4.9: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672845#comment-15672845 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit dc1a7b4338b37bb4ca9b3e4288bca0439969c1c0 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dc1a7b4 ] Merge release branch 4.8 to 4.9 * 4.8: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672842#comment-15672842 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit 293ec4f3fc4b4cb6b238e34dce38770fc49f3aa2 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=293ec4f ] Merge pull request #1673 from wido/CLOUDSTACK-9071 CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollectorBoth host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. * pr/1673: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Signed-off-by: John Burwell > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672841#comment-15672841 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit c1997a1705278d4ba39d64102e7ce76894f1e30d in cloudstack's branch refs/heads/master from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c1997a1 ] CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Both host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. Signed-off-by: Wido den Hollander Conflicts: server/src/com/cloud/server/StatsCollector.java > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672843#comment-15672843 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit 293ec4f3fc4b4cb6b238e34dce38770fc49f3aa2 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=293ec4f ] Merge pull request #1673 from wido/CLOUDSTACK-9071 CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollectorBoth host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. * pr/1673: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Signed-off-by: John Burwell > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672830#comment-15672830 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit c1997a1705278d4ba39d64102e7ce76894f1e30d in cloudstack's branch refs/heads/4.8 from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c1997a1 ] CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Both host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. Signed-off-by: Wido den Hollander Conflicts: server/src/com/cloud/server/StatsCollector.java > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672832#comment-15672832 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit 293ec4f3fc4b4cb6b238e34dce38770fc49f3aa2 in cloudstack's branch refs/heads/4.8 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=293ec4f ] Merge pull request #1673 from wido/CLOUDSTACK-9071 CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollectorBoth host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. * pr/1673: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Signed-off-by: John Burwell > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672840#comment-15672840 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit dc1a7b4338b37bb4ca9b3e4288bca0439969c1c0 in cloudstack's branch refs/heads/4.9 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dc1a7b4 ] Merge release branch 4.8 to 4.9 * 4.8: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672834#comment-15672834 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit c1997a1705278d4ba39d64102e7ce76894f1e30d in cloudstack's branch refs/heads/4.9 from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c1997a1 ] CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Both host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. Signed-off-by: Wido den Hollander Conflicts: server/src/com/cloud/server/StatsCollector.java > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672833#comment-15672833 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit 293ec4f3fc4b4cb6b238e34dce38770fc49f3aa2 in cloudstack's branch refs/heads/4.8 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=293ec4f ] Merge pull request #1673 from wido/CLOUDSTACK-9071 CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollectorBoth host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. * pr/1673: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Signed-off-by: John Burwell > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672844#comment-15672844 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit 293ec4f3fc4b4cb6b238e34dce38770fc49f3aa2 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=293ec4f ] Merge pull request #1673 from wido/CLOUDSTACK-9071 CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollectorBoth host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. * pr/1673: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Signed-off-by: John Burwell > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672837#comment-15672837 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit 293ec4f3fc4b4cb6b238e34dce38770fc49f3aa2 in cloudstack's branch refs/heads/4.9 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=293ec4f ] Merge pull request #1673 from wido/CLOUDSTACK-9071 CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollectorBoth host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. * pr/1673: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Signed-off-by: John Burwell > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672838#comment-15672838 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit 293ec4f3fc4b4cb6b238e34dce38770fc49f3aa2 in cloudstack's branch refs/heads/4.9 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=293ec4f ] Merge pull request #1673 from wido/CLOUDSTACK-9071 CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollectorBoth host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. * pr/1673: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Signed-off-by: John Burwell > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672831#comment-15672831 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit 293ec4f3fc4b4cb6b238e34dce38770fc49f3aa2 in cloudstack's branch refs/heads/4.8 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=293ec4f ] Merge pull request #1673 from wido/CLOUDSTACK-9071 CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollectorBoth host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. * pr/1673: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Signed-off-by: John Burwell > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672839#comment-15672839 ] ASF GitHub Bot commented on CLOUDSTACK-9071: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1673 > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672836#comment-15672836 ] ASF subversion and git services commented on CLOUDSTACK-9071: - Commit 293ec4f3fc4b4cb6b238e34dce38770fc49f3aa2 in cloudstack's branch refs/heads/4.9 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=293ec4f ] Merge pull request #1673 from wido/CLOUDSTACK-9071 CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollectorBoth host and path could have been NULL which causes the StatsCollector no to start properly. By checking if the Strings are not Empty or Null we make sure the StatsCollector always runs and does not prevent the Management Server from starting. * pr/1673: CLOUDSTACK-9071: Properly parse stats.output.uri in StatsCollector Signed-off-by: John Burwell > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672819#comment-15672819 ] ASF GitHub Bot commented on CLOUDSTACK-9071: Github user jburwell commented on the issue: https://github.com/apache/cloudstack/pull/1673 @wido we are seeing these errors on other PRs. Based on the fact that they are occurring on other PRs and change does not impact these tests, I am LGTM for tests. > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672814#comment-15672814
]
ASF GitHub Bot commented on CLOUDSTACK-9489:
Github user jburwell commented on the issue:
https://github.com/apache/cloudstack/pull/1684
@pdion891 I don't care for the idea of potentially ignoring a custom
security configuration as it may unexpectedly reduce a user's security. By
default, we should take the most conservative path when setting security
defaults.
/cc @PaulAngus
> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied
> when upgrading to post 4.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9491) Vmware resource: incorrect parsing of device list to find ethener index of plugged nic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672809#comment-15672809 ] ASF GitHub Bot commented on CLOUDSTACK-9491: Github user jburwell commented on the issue: https://github.com/apache/cloudstack/pull/1681 @murali-reddy have you had a chance to investigate the [test failures](https://github.com/apache/cloudstack/pull/1681#issuecomment-257717551)? > Vmware resource: incorrect parsing of device list to find ethener index of > plugged nic > -- > > Key: CLOUDSTACK-9491 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9491 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0 > > > In VmwareResource.java, there is logic ( in findRouterEthDeviceIndex) to find > ethernet interface a mac address is associated with. > After NIC in plugged in to a Vm through vSphere, it takes some time for the > device to show up in the guest VM. > Logic loops through the device list obtained from /proc/sys/net/ipv4/conf > from the VM, and matched againest mac. > However '/proc/sys/net/ipv4/conf' is not refreshed, heve logic loops through > old device list always. > In addition there is no exception thrown and error is maked by sending -1. > Eventually, VR scripts are getting -1 as device number causing failure in > processing the scripts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672804#comment-15672804 ] ASF GitHub Bot commented on CLOUDSTACK-9583: Github user jburwell commented on the issue: https://github.com/apache/cloudstack/pull/1757 @rhtyd @swill @abhinandanprateek @karuturi could you review the test results/perform further testing for a second LGTM? I would like to get this PR into 4.8.2.0/4.9.1.0/4.10.0.0 as it greatly improves the performance of VR configuration. > VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1 > - > > Key: CLOUDSTACK-9583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Murali Reddy > Fix For: 4.9.1.0 > > > It is observed that 'ip route flush' was timing out after 20 seconds with > the error that can't resolve the name of the vrouter. Since this is done for > each rule for a router with a lot of rules, adding the entry to hosts file > fixes it and the router provisioning is observed faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672800#comment-15672800 ] ASF GitHub Bot commented on CLOUDSTACK-9502: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1676 > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672798#comment-15672798 ] ASF subversion and git services commented on CLOUDSTACK-9502: - Commit 20b43767d72672119e56b04a2e5c2e6c54e40ad5 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20b4376 ] Merge pull request #1676 from nvazquez/dstemplates49 CLOUDSTACK-9502: DS template copies dont get deleted in VMware ESXi with multiple clusters and zone wide storage (include CLOUDSTACK-9386 into 4.9 release branch)Include #1560 into 4.9 release branch * pr/1676: CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with multiple clusters and zone wide storage Signed-off-by: John Burwell > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672796#comment-15672796 ] ASF subversion and git services commented on CLOUDSTACK-9502: - Commit 20b43767d72672119e56b04a2e5c2e6c54e40ad5 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20b4376 ] Merge pull request #1676 from nvazquez/dstemplates49 CLOUDSTACK-9502: DS template copies dont get deleted in VMware ESXi with multiple clusters and zone wide storage (include CLOUDSTACK-9386 into 4.9 release branch)Include #1560 into 4.9 release branch * pr/1676: CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with multiple clusters and zone wide storage Signed-off-by: John Burwell > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672795#comment-15672795 ] ASF subversion and git services commented on CLOUDSTACK-9502: - Commit 4104cea300504fe18445dfc3f0d1ac877baf66b6 in cloudstack's branch refs/heads/master from [~nvazquez] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4104cea ] CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with multiple clusters and zone wide storage > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672794#comment-15672794 ] ASF subversion and git services commented on CLOUDSTACK-9502: - Commit 20b43767d72672119e56b04a2e5c2e6c54e40ad5 in cloudstack's branch refs/heads/4.9 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20b4376 ] Merge pull request #1676 from nvazquez/dstemplates49 CLOUDSTACK-9502: DS template copies dont get deleted in VMware ESXi with multiple clusters and zone wide storage (include CLOUDSTACK-9386 into 4.9 release branch)Include #1560 into 4.9 release branch * pr/1676: CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with multiple clusters and zone wide storage Signed-off-by: John Burwell > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672799#comment-15672799 ] ASF subversion and git services commented on CLOUDSTACK-9502: - Commit c66cf1c60d78c44ba8a8402056e317bfff5c4283 in cloudstack's branch refs/heads/master from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c66cf1c ] Merge release branch 4.9 to master * 4.9: CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with multiple clusters and zone wide storage > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9386) DS template copies don’t get deleted in VMware ESXi with multiple clusters and zone wide storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672792#comment-15672792
]
ASF subversion and git services commented on CLOUDSTACK-9386:
-
Commit 20b43767d72672119e56b04a2e5c2e6c54e40ad5 in cloudstack's branch
refs/heads/4.9 from [~jburwell]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20b4376 ]
Merge pull request #1676 from nvazquez/dstemplates49
CLOUDSTACK-9502: DS template copies dont get deleted in VMware ESXi with
multiple clusters and zone wide storage (include CLOUDSTACK-9386 into 4.9
release branch)Include #1560 into 4.9 release branch
* pr/1676:
CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with
multiple clusters and zone wide storage
Signed-off-by: John Burwell
> DS template copies don’t get deleted in VMware ESXi with multiple clusters
> and zone wide storage
>
>
> Key: CLOUDSTACK-9386
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9386
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0, 4.9.2.0
>
>
> h3. Introduction
> In some production environments with multiple clusters it was noticed that
> unused templates were consuming too much storage. It was discovered that
> template cleanup was not deleting marked templates on ESXi.
> h3. Description of the problem
> Suppose we have multiple clusters {{(c1, c2,...,cN)}} on a data center and
> template {{T}} from which we deploy vms on {{c1}}.
> Suppose now that we expunge those vms, and there's no other vm instance from
> template {{T}}, so this was the actual workflow:
> # CloudStack marks template for cleanup after {{storage.cleanup.interval}}
> seconds, by setting {{marked_for_gc = 1}} on {{template_spool_ref}} table,
> for that template.
> # After another {{storage.cleanup.interval}} seconds a {{DestroyCommand}}
> will be sent, to delete template from primary storage
> # On {{VmwareResource}}, command is processed, and it first picks up a random
> cluster, say {{ci != c1}} to look for vm template (using volume's path) and
> destroy it. But, as template was on {{c1}} it cannot be found, so it won't be
> deleted. Entry on {{template_spool_ref}} is deleted but not the actual
> template on hypervisor side.
> h3. Proposed solution
> We propose a way to attack problem shown in point 3, by not picking up a
> random cluster to look for vm but using vSphere data center. This way we make
> sure vm template will be deleted in every case, and not depending on random
> cluster selection
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9386) DS template copies don’t get deleted in VMware ESXi with multiple clusters and zone wide storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672797#comment-15672797
]
ASF subversion and git services commented on CLOUDSTACK-9386:
-
Commit 20b43767d72672119e56b04a2e5c2e6c54e40ad5 in cloudstack's branch
refs/heads/master from [~jburwell]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20b4376 ]
Merge pull request #1676 from nvazquez/dstemplates49
CLOUDSTACK-9502: DS template copies dont get deleted in VMware ESXi with
multiple clusters and zone wide storage (include CLOUDSTACK-9386 into 4.9
release branch)Include #1560 into 4.9 release branch
* pr/1676:
CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with
multiple clusters and zone wide storage
Signed-off-by: John Burwell
> DS template copies don’t get deleted in VMware ESXi with multiple clusters
> and zone wide storage
>
>
> Key: CLOUDSTACK-9386
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9386
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0, 4.9.2.0
>
>
> h3. Introduction
> In some production environments with multiple clusters it was noticed that
> unused templates were consuming too much storage. It was discovered that
> template cleanup was not deleting marked templates on ESXi.
> h3. Description of the problem
> Suppose we have multiple clusters {{(c1, c2,...,cN)}} on a data center and
> template {{T}} from which we deploy vms on {{c1}}.
> Suppose now that we expunge those vms, and there's no other vm instance from
> template {{T}}, so this was the actual workflow:
> # CloudStack marks template for cleanup after {{storage.cleanup.interval}}
> seconds, by setting {{marked_for_gc = 1}} on {{template_spool_ref}} table,
> for that template.
> # After another {{storage.cleanup.interval}} seconds a {{DestroyCommand}}
> will be sent, to delete template from primary storage
> # On {{VmwareResource}}, command is processed, and it first picks up a random
> cluster, say {{ci != c1}} to look for vm template (using volume's path) and
> destroy it. But, as template was on {{c1}} it cannot be found, so it won't be
> deleted. Entry on {{template_spool_ref}} is deleted but not the actual
> template on hypervisor side.
> h3. Proposed solution
> We propose a way to attack problem shown in point 3, by not picking up a
> random cluster to look for vm but using vSphere data center. This way we make
> sure vm template will be deleted in every case, and not depending on random
> cluster selection
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672791#comment-15672791 ] ASF subversion and git services commented on CLOUDSTACK-9502: - Commit 20b43767d72672119e56b04a2e5c2e6c54e40ad5 in cloudstack's branch refs/heads/4.9 from [~jburwell] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20b4376 ] Merge pull request #1676 from nvazquez/dstemplates49 CLOUDSTACK-9502: DS template copies dont get deleted in VMware ESXi with multiple clusters and zone wide storage (include CLOUDSTACK-9386 into 4.9 release branch)Include #1560 into 4.9 release branch * pr/1676: CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with multiple clusters and zone wide storage Signed-off-by: John Burwell > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672790#comment-15672790 ] ASF subversion and git services commented on CLOUDSTACK-9502: - Commit 4104cea300504fe18445dfc3f0d1ac877baf66b6 in cloudstack's branch refs/heads/4.9 from [~nvazquez] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4104cea ] CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with multiple clusters and zone wide storage > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9402) Nuage VSP Plugin : Support for underlay features (Source & Static NAT to underlay) including Marvin test coverage on master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672529#comment-15672529 ] ASF GitHub Bot commented on CLOUDSTACK-9402: Github user jburwell commented on the issue: https://github.com/apache/cloudstack/pull/1580 @prashanthvarma #1578 has been merged. Can you rebase this PR and squash the commits? Once that is done and Jenkins and Travis are green, I will kick regression tests via blueorganutan. > Nuage VSP Plugin : Support for underlay features (Source & Static NAT to > underlay) including Marvin test coverage on master > --- > > Key: CLOUDSTACK-9402 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9402 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Affects Versions: 4.10.0.0 >Reporter: Mani Prashanth Varma Manthena >Assignee: Nick Livens > > Support for underlay features (Source & Static NAT to underlay) with Nuage > VSP SDN Plugin including Marvin test coverage for corresponding Source & > Static NAT features on master. Moreover, our Marvin tests are written in such > a way that they can validate our supported feature set with both Nuage VSP > SDN platform's overlay and underlay infra. > PR contents: > 1) Support for Source NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 2) Support for Static NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 3) Marvin test coverage for Source & Static NAT to underlay on master with > Nuage VSP SDN Plugin. > 4) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 5) PEP8 & PyFlakes compliance with our Marvin test code. > Our Marvin test code PEP8 & PyFlakes compliance: > CloudStack$ > CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py > CloudStack$ > CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py > CloudStack$ > Validations: > 1) Underlay infra (Source & Static NAT to underlay) > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_source_nat.py > Test results: > Test Nuage VSP Isolated networks with different combinations of Source NAT > service providers ... === TestName: test_01_nuage_SourceNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Source NAT service > providers ... === TestName: test_02_nuage_SourceNAT_vpc_networks | Status : > SUCCESS === > ok > Test Nuage VSP Source NAT functionality for Isolated network by performing > (wget) traffic tests to the ... === TestName: > test_03_nuage_SourceNAT_isolated_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality for VPC network by performing (wget) > traffic tests to the Internet ... === TestName: > test_04_nuage_SourceNAT_vpc_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with different Egress > Firewall/Network ACL rules by performing (wget) ... === TestName: > test_05_nuage_SourceNAT_acl_rules_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM NIC operations by performing > (wget) traffic tests to the ... === TestName: > test_06_nuage_SourceNAT_vm_nic_operations_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM migration by performing > (wget) traffic tests to the Internet ... === TestName: > test_07_nuage_SourceNAT_vm_migration_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with network restarts by performing > (wget) traffic tests to the ... === TestName: > test_08_nuage_SourceNAT_network_restarts_traffic | Status : SUCCESS === > ok > -- > Ran 8 tests in 13360.858s > OK > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_static_nat.py > Test results: > Test Nuage VSP Public IP Range creation and deletion ... === TestName: > test_01_nuage_StaticNAT_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Nuage Underlay (underlay networking) enabled Public IP Range > creation and deletion ... === TestName: > test_02_nuage_StaticNAT_underlay_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Isolated networks with different combinations of Static NAT > service providers ... === TestName: test_03_nuage_StaticNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Static NAT service > providers ... === TestName: test_04_nuage_Static
[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672527#comment-15672527 ] ASF GitHub Bot commented on CLOUDSTACK-9403: Github user jburwell commented on the issue: https://github.com/apache/cloudstack/pull/1579 @prashanthvarma #1578 has been merged. Can you rebase this PR and squash the commits? Once that is done and Jenkins and Travis are green, I will kick regression tests via blueorganutan. > Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin > test coverage > > > Key: CLOUDSTACK-9403 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Reporter: Rahul Singal >Assignee: Nick Livens > > This is first phase of support of Shared Network in cloudstack through > NuageVsp Network Plugin. A shared network is a type of virtual network that > is shared between multiple accounts i.e. a shared network can be accessed by > virtual machines that belong to many different accounts. This basic > functionality will be supported with the below common use case: > - shared network can be used for monitoring purposes. A shared network can be > assigned to a domain and can be used for monitoring VMs belonging to all > accounts in that domain. > - Public accessible of shared Network. > With the current implementation with NuageVsp plugin, It support over-lapping > of Ip address, Public Access and also adding Ip ranges in shared Network. > In VSD, it is implemented in below manner: > - In order to have tenant isolation for shared networks, we will have to > create a Shared L3 Subnet for each shared network, and instantiate it across > the relevant enterprises. A shared network will only exist under an > enterprise when it is needed, so when the first VM is spinned under that ACS > domain inside that shared network. > - For public shared Network it will also create a floating ip subnet pool in > VSD along with all the things mentioned in above point. > PR contents: > 1) Support for shared networks with tenant isolation on master with Nuage VSP > SDN Plugin. > 2) Support of shared network with publicly accessible ip ranges. > 2) Marvin test coverage for shared networks on master with Nuage VSP SDN > Plugin. > 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 4) PEP8 & PyFlakes compliance with our Marvin test code. > Test Results are:- > Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain > in a shared network with ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a > shared network with ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | > Status : SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same > domain but in a ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | > Status : SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for user in the same > domain but in a different ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for regular user in a shared > network with scope=account ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_user | Status : SUCCESS > === > ok > Valiate that ROOT admin is able to deploy a VM for user in ROOT domain in a > shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_ROOTuser | Status : SUCCESS > === > ok > Valiate that ROOT admin is able to deploy a VM for a domain admin users in a > shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_domainadminuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for other users in a shared > network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_domainuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for admin user in a domain in > a shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainadminuser | Status > : SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for any user in a subdomain in > a shared network with scope=all ... === TestName: > test_depl
[jira] [Commented] (CLOUDSTACK-9321) Multiple Internal LB rules (more than one Internal LB rule with same source IP address) are not getting resolved in the corresponding InternalLbVm instance's hapro
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672518#comment-15672518 ] ASF GitHub Bot commented on CLOUDSTACK-9321: Github user jburwell commented on the issue: https://github.com/apache/cloudstack/pull/1577 @prashanthvarma @nlivens can you please investigate the Jenkins failures? Once Jenkins and Travis go green, I will kick blueorangutan to regression test this PR. > Multiple Internal LB rules (more than one Internal LB rule with same source > IP address) are not getting resolved in the corresponding InternalLbVm > instance's haproxy.cfg file > -- > > Key: CLOUDSTACK-9321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9321 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Reporter: Mani Prashanth Varma Manthena >Assignee: Nick Livens >Priority: Critical > Fix For: 4.9.1.0 > > > Multiple Internal LB rules (more than one Internal LB rule with same source > IP address) are not getting resolved in the corresponding InternalLbVm > instance's haproxy.cfg file. Moreover, each time a new Internal LB rule is > added to the corresponding InternalLbVm instance, it replaces the existing > one. Thus, traffic corresponding to these un-resolved (old) Internal LB rules > are getting dropped by the InternalLbVm instance. > PR contents: > 1) Fix for this bug. > 2) Marvin test coverage for Internal LB feature on master with native ACS > setup (component directory) including validations for this bug fix. > 3) Enhancements on our exiting Internal LB Marvin test code (nuagevsp plugins > directory) to validate this bug fix. > 4) PEP8 & PyFlakes compliance with the added Marvin test code. > Added Marvin test code PEP8 & PyFlakes compliance: > CloudStack$ > CloudStack$ pep8 --max-line-length=150 > test/integration/component/test_vpc_network_internal_lbrules.py > CloudStack$ > CloudStack$ pyflakes > test/integration/component/test_vpc_network_internal_lbrules.py > CloudStack$ > CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py > CloudStack$ > CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py > CloudStack$ > Validations: > 1) Made sure that we didn't break any Public LB (VpcVirtualRouter) > functionality. > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > test/integration/component/test_vpc_network_lbrules.py > Test results: > Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... > === TestName: test_01_VPC_LBRulesListing | Status : SUCCESS === > ok > Test Create LB rules for 1 network which is part of a two/multiple virtual > networks of a ... === TestName: test_02_VPC_CreateLBRuleInMultipleNetworks | > Status : SUCCESS === > ok > Test case no 222 : Create LB rules for a two/multiple virtual networks of a > ... === TestName: test_03_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | > Status : SUCCESS === > ok > Test case no 222 : Create LB rules for a two/multiple virtual networks of a > ... === TestName: test_04_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | > Status : SUCCESS === > ok > Test case no 214 : Delete few(not all) LB rules for a single virtual network > of a ... === TestName: test_05_VPC_CreateAndDeleteLBRule | Status : SUCCESS > === > ok > Test Delete few(not all) LB rules for a single virtual network of ... === > TestName: test_06_VPC_CreateAndDeleteLBRuleVRStopppedState | Status : SUCCESS > === > ok > Test Delete all LB rules for a single virtual network of a ... === TestName: > test_07_VPC_CreateAndDeleteAllLBRule | Status : SUCCESS === > ok > Test Delete all LB rules for a single virtual network of a ... === TestName: > test_08_VPC_CreateAndDeleteAllLBRuleVRStoppedState | Status : SUCCESS === > ok > Test User should not be allowed to create a LB rule for a VM that belongs to > a different VPC. ... === TestName: test_09_VPC_LBRuleCreateFailMultipleVPC | > Status : SUCCESS === > ok > Test User should not be allowed to create a LB rule for a VM that does not > belong to any VPC. ... === TestName: > test_10_VPC_FailedToCreateLBRuleNonVPCNetwork | Status : SUCCESS === > ok > Test case no 217 and 236: User should not be allowed to create a LB rule for > a ... === TestName: test_11_VPC_LBRuleCreateNotAllowed | Status : SUCCESS === > ok > Test User should not be allowed to create a LB rule on an Ipaddress that > Source Nat enabled. ... === TestName: test_12_VPC_LBRuleCreateFailForRouterIP > | Status : SUCCESS === > ok > Test
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672510#comment-15672510
]
ASF GitHub Bot commented on CLOUDSTACK-8715:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1545#discussion_r88378575
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
---
@@ -1209,25 +1209,95 @@ public String toString() {
}
}
-public static class VirtioSerialDef {
-private final String _name;
-private String _path;
+public static class ChannelDef {
+enum ChannelType {
+UNIX("unix"), SERIAL("serial");
+String type;
-public VirtioSerialDef(String name, String path) {
-_name = name;
-_path = path;
+ChannelType(String type) {
+this.type = type;
+}
+
+@Override
+public String toString() {
+return this.type;
+}
+}
+
+enum ChannelState {
+DISCONNECTED("disconnected"), CONNECTED("connected");
+String type;
+
+ChannelState(String type) {
+this.type = type;
+}
+
+@Override
+public String toString() {
+return type;
+}
+}
+
+private String name;
+private String path;
+private ChannelType type;
+private ChannelState state;
+
+public ChannelDef(String name, ChannelType type) {
+this.name = name;
+this.type = type;
--- End diff --
@wido have you had a chance to consider this comment?
> Add support for qemu-guest-agent to libvirt provider
>
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
> Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite
> a lot of useful functionality, which can only be provided by having an agent
> on the VM. This includes things like freezing/thawing filesystems (for
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM
> virtual machines,:
>
>
>
>
> This provides the communication channel between libvirt and the agent on the
> host. All in all a pretty simple change to LibvirtComputingResource.java /
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm
> template.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672512#comment-15672512 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user jburwell commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1545#discussion_r88378111 --- Diff: plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java --- @@ -252,6 +253,8 @@ protected String _rngPath = "/dev/random"; protected int _rngRatePeriod = 1000; protected int _rngRateBytes = 2048; +protected File _qemuSocketsPath; --- End diff -- Why is this attribute declared `protected` rather than `private`? > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672509#comment-15672509
]
ASF GitHub Bot commented on CLOUDSTACK-8715:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1545#discussion_r88378673
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
---
@@ -1209,25 +1209,95 @@ public String toString() {
}
}
-public static class VirtioSerialDef {
-private final String _name;
-private String _path;
+public static class ChannelDef {
+enum ChannelType {
+UNIX("unix"), SERIAL("serial");
+String type;
-public VirtioSerialDef(String name, String path) {
-_name = name;
-_path = path;
+ChannelType(String type) {
+this.type = type;
+}
+
+@Override
+public String toString() {
+return this.type;
+}
+}
+
+enum ChannelState {
+DISCONNECTED("disconnected"), CONNECTED("connected");
+String type;
+
+ChannelState(String type) {
+this.type = type;
+}
+
+@Override
+public String toString() {
+return type;
+}
+}
+
+private String name;
+private String path;
+private ChannelType type;
+private ChannelState state;
+
+public ChannelDef(String name, ChannelType type) {
+this.name = name;
+this.type = type;
+}
+
+public ChannelDef(String name, ChannelType type, String path) {
+this.name = name;
+this.path = path;
+this.type = type;
+}
+
+public ChannelDef(String name, ChannelType type, ChannelState
state) {
+this.name = name;
+this.state = state;
+this.type = type;
+}
+
+public ChannelDef(String name, ChannelType type, ChannelState
state, String path) {
+this.name = name;
+this.path = path;
+this.state = state;
+this.type = type;
+}
+
+public ChannelType getChannelType() {
+return type;
+}
+
+public ChannelState getChannelState() {
+return state;
+}
+
+public String getName() {
+return name;
+}
+
+public String getPath() {
+return path;
}
@Override
public String toString() {
StringBuilder virtioSerialBuilder = new StringBuilder();
-if (_path == null) {
-_path = "/var/lib/libvirt/qemu";
+virtioSerialBuilder.append("\n");
--- End diff --
@wido have you had a chance to consider this comment?
> Add support for qemu-guest-agent to libvirt provider
>
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
> Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite
> a lot of useful functionality, which can only be provided by having an agent
> on the VM. This includes things like freezing/thawing filesystems (for
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM
> virtual machines,:
>
>
>
>
> This provides the communication channel between libvirt and the agent on the
> host. All in all a pretty simple change to LibvirtComputingResource.java /
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm
> template.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672506#comment-15672506
]
ASF GitHub Bot commented on CLOUDSTACK-8715:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1545#discussion_r88378602
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
---
@@ -1209,25 +1209,95 @@ public String toString() {
}
}
-public static class VirtioSerialDef {
-private final String _name;
-private String _path;
+public static class ChannelDef {
+enum ChannelType {
+UNIX("unix"), SERIAL("serial");
+String type;
-public VirtioSerialDef(String name, String path) {
-_name = name;
-_path = path;
+ChannelType(String type) {
+this.type = type;
+}
+
+@Override
+public String toString() {
+return this.type;
+}
+}
+
+enum ChannelState {
+DISCONNECTED("disconnected"), CONNECTED("connected");
+String type;
+
+ChannelState(String type) {
+this.type = type;
+}
+
+@Override
+public String toString() {
+return type;
+}
+}
+
+private String name;
+private String path;
+private ChannelType type;
+private ChannelState state;
+
+public ChannelDef(String name, ChannelType type) {
+this.name = name;
+this.type = type;
+}
+
+public ChannelDef(String name, ChannelType type, String path) {
+this.name = name;
+this.path = path;
+this.type = type;
+}
+
+public ChannelDef(String name, ChannelType type, ChannelState
state) {
--- End diff --
@wido have you had a chance to review this commit?
> Add support for qemu-guest-agent to libvirt provider
>
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
> Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite
> a lot of useful functionality, which can only be provided by having an agent
> on the VM. This includes things like freezing/thawing filesystems (for
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM
> virtual machines,:
>
>
>
>
> This provides the communication channel between libvirt and the agent on the
> host. All in all a pretty simple change to LibvirtComputingResource.java /
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm
> template.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672508#comment-15672508 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user jburwell commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1545#discussion_r88378255 --- Diff: plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java --- @@ -252,6 +253,8 @@ protected String _rngPath = "/dev/random"; protected int _rngRatePeriod = 1000; protected int _rngRateBytes = 2048; +protected File _qemuSocketsPath; +private String _qemuGuestAgentSocketName = "org.qemu.guest_agent.0"; --- End diff -- `_qemuGuestAgentSocketName` appears to be a constant value. If so, please consider declaring it as a 'private static final`. > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672507#comment-15672507
]
ASF GitHub Bot commented on CLOUDSTACK-8715:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1545#discussion_r88377937
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtDomainXMLParser.java
---
@@ -175,6 +180,26 @@ public boolean parseDomainXML(String domXML) {
interfaces.add(def);
}
+NodeList ports = devices.getElementsByTagName("channel");
+for (int i = 0; i < ports.getLength(); i++) {
+Element channel = (Element)ports.item(i);
+
+String type = channel.getAttribute("type");
+String path = getAttrValue("source", "path", channel);
+String name = getAttrValue("target", "name", channel);
+String state = getAttrValue("target", "state", channel);
+
+ChannelDef def = null;
+if (!StringUtils.isNotBlank(state)) {
--- End diff --
Minor nit: Performing a logical not operation on the result
`StringUtils.isNotBlank` seems a bit awkward. Please consider refactoring to
`if (StringUtlis.isBlank(state))`.
> Add support for qemu-guest-agent to libvirt provider
>
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
> Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite
> a lot of useful functionality, which can only be provided by having an agent
> on the VM. This includes things like freezing/thawing filesystems (for
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM
> virtual machines,:
>
>
>
>
> This provides the communication channel between libvirt and the agent on the
> host. All in all a pretty simple change to LibvirtComputingResource.java /
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm
> template.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672511#comment-15672511
]
ASF GitHub Bot commented on CLOUDSTACK-8715:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1545#discussion_r88378691
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
---
@@ -1209,25 +1209,95 @@ public String toString() {
}
}
-public static class VirtioSerialDef {
-private final String _name;
-private String _path;
+public static class ChannelDef {
+enum ChannelType {
+UNIX("unix"), SERIAL("serial");
+String type;
-public VirtioSerialDef(String name, String path) {
-_name = name;
-_path = path;
+ChannelType(String type) {
+this.type = type;
+}
+
+@Override
+public String toString() {
+return this.type;
+}
+}
+
+enum ChannelState {
+DISCONNECTED("disconnected"), CONNECTED("connected");
+String type;
+
+ChannelState(String type) {
+this.type = type;
+}
+
+@Override
+public String toString() {
+return type;
+}
+}
+
+private String name;
+private String path;
+private ChannelType type;
+private ChannelState state;
+
+public ChannelDef(String name, ChannelType type) {
+this.name = name;
+this.type = type;
+}
+
+public ChannelDef(String name, ChannelType type, String path) {
+this.name = name;
+this.path = path;
+this.type = type;
+}
+
+public ChannelDef(String name, ChannelType type, ChannelState
state) {
+this.name = name;
+this.state = state;
+this.type = type;
+}
+
+public ChannelDef(String name, ChannelType type, ChannelState
state, String path) {
+this.name = name;
+this.path = path;
+this.state = state;
+this.type = type;
+}
+
+public ChannelType getChannelType() {
+return type;
+}
+
+public ChannelState getChannelState() {
+return state;
+}
+
+public String getName() {
+return name;
+}
+
+public String getPath() {
+return path;
}
@Override
public String toString() {
StringBuilder virtioSerialBuilder = new StringBuilder();
-if (_path == null) {
-_path = "/var/lib/libvirt/qemu";
+virtioSerialBuilder.append("\n");
+if (path == null) {
+virtioSerialBuilder.append("\n");
+} else {
+virtioSerialBuilder.append("\n");
}
-virtioSerialBuilder.append("\n");
-virtioSerialBuilder.append("\n");
-virtioSerialBuilder.append("\n");
virtioSerialBuilder.append("\n");
+if (state == null) {
+virtioSerialBuilder.append("\n");
+} else {
+virtioSerialBuilder.append("\n");
+}
--- End diff --
@wido have you had a chance to review this comment?
> Add support for qemu-guest-agent to libvirt provider
>
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
> Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite
> a lot of useful functionality, which can only be provided by having an agent
> on the VM. This includes things like freezing/thawing filesystems (for
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/e
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672513#comment-15672513
]
ASF GitHub Bot commented on CLOUDSTACK-8715:
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1545#discussion_r88378451
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
---
@@ -776,6 +779,13 @@ public boolean configure(final String name, final
Map params) th
_localStoragePath = "/var/lib/libvirt/images/";
}
+/* Directory to use for Qemu sockets like for the Qemu Guest Agent
*/
+_qemuSocketsPath = new File("/var/lib/libvirt/qemu");
+String _qemuSocketsPathVar =
(String)params.get("qemu.sockets.path");
+if (!StringUtils.isNotBlank(_qemuSocketsPathVar)) {
--- End diff --
Minor not: A logical not perform on `StringUtils.isNotBlank` is a awkward.
Please consider refactoring to `if (StringUtils.isBlank(_qemuSocketsPathVar)`.
> Add support for qemu-guest-agent to libvirt provider
>
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
> Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite
> a lot of useful functionality, which can only be provided by having an agent
> on the VM. This includes things like freezing/thawing filesystems (for
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM
> virtual machines,:
>
>
>
>
> This provides the communication channel between libvirt and the agent on the
> host. All in all a pretty simple change to LibvirtComputingResource.java /
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm
> template.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672472#comment-15672472
]
ASF GitHub Bot commented on CLOUDSTACK-9379:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1542
@jburwell a Trillian-Jenkins test job (centos7 mgmt + vmware-55u3) has been
kicked to run smoke tests
> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware
> hypervisor. Current behaviour supports enabling/desabling global nested
> virtualization by modifying global config {{'vmware.nested.virtualization'}}.
> It is wished to improve this feature, having control at VM level instead of a
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present,
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672469#comment-15672469
]
ASF GitHub Bot commented on CLOUDSTACK-9379:
Github user jburwell commented on the issue:
https://github.com/apache/cloudstack/pull/1542
@blueorangutan test centos7 vmware-55u3 test_nested_virtualization.py
> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware
> hypervisor. Current behaviour supports enabling/desabling global nested
> virtualization by modifying global config {{'vmware.nested.virtualization'}}.
> It is wished to improve this feature, having control at VM level instead of a
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present,
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672275#comment-15672275 ] ASF GitHub Bot commented on CLOUDSTACK-9502: Github user serg38 commented on the issue: https://github.com/apache/cloudstack/pull/1676 @jburwell @rhtyd @karuturi This PR also seems to be ready for merging . > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672270#comment-15672270
]
ASF GitHub Bot commented on CLOUDSTACK-9379:
Github user serg38 commented on the issue:
https://github.com/apache/cloudstack/pull/1542
@karuturi @jburwell As per @rhtyd we can run additional tests with
blueorangutan . Can we execute them and merge this PR since it passes the
standard test suite just fine?
> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware
> hypervisor. Current behaviour supports enabling/desabling global nested
> virtualization by modifying global config {{'vmware.nested.virtualization'}}.
> It is wished to improve this feature, having control at VM level instead of a
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present,
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671280#comment-15671280
]
ASF GitHub Bot commented on CLOUDSTACK-9500:
Github user remibergsma commented on the issue:
https://github.com/apache/cloudstack/pull/1706
@pdion891 Sorry for being late to the party. We've seen this issue too and
resolved it in a different way. Removing the ip from the databag probably won't
work too well, as it is used to deprovision the old ip address from the router.
This is what works well for us instead:
https://github.com/MissionCriticalCloud/cosmic/pull/114/files
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9600) listVirtualMachines: return vpcid if VM is in VPC.
René Moser created CLOUDSTACK-9600: -- Summary: listVirtualMachines: return vpcid if VM is in VPC. Key: CLOUDSTACK-9600 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9600 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: API, VPC Reporter: René Moser Fix For: Future listVirtualMachines API does not return vpcid for VMs in VPCs. There is no easy way to find out if VM is in not in a VPC. This is a requirement for ansible modules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9589) vmName entries from host_details table for the VM's whose state is Expunging should be deleted during upgrade from older versions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670721#comment-15670721 ] ASF GitHub Bot commented on CLOUDSTACK-9589: Github user cloudmonger commented on the issue: https://github.com/apache/cloudstack/pull/1759 ### ACS CI BVT Run **Sumarry:** Build Number 137 Hypervisor xenserver NetworkType Advanced Passed=102 Failed=3 Skipped=6 _Link to logs Folder (search by build_no):_ https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0 **Failed tests:** * test_network.py * test_delete_account Failed * test_deploy_vm_iso.py * test_deploy_vm_from_iso Failing since 21 runs * test_vm_life_cycle.py * test_10_attachAndDetach_iso Failing since 22 runs **Skipped tests:** test_01_test_vm_volume_snapshot test_vm_nic_adapter_vmxnet3 test_static_role_account_acls test_11_ss_nfs_version_on_ssvm test_3d_gpu_support test_deploy_vgpu_enabled_vm **Passed test suits:** test_deploy_vm_with_userdata.py test_affinity_groups_projects.py test_portable_publicip.py test_over_provisioning.py test_global_settings.py test_scale_vm.py test_service_offerings.py test_routers_iptables_default_policy.py test_loadbalance.py test_routers.py test_reset_vm_on_reboot.py test_snapshots.py test_deploy_vms_with_varied_deploymentplanners.py test_router_dns.py test_non_contigiousvlan.py test_login.py test_list_ids_parameter.py test_public_ip_range.py test_multipleips_per_nic.py test_regions.py test_affinity_groups.py test_network_acl.py test_pvlan.py test_volumes.py test_nic.py test_deploy_vm_root_resize.py test_resource_detail.py test_secondary_storage.py test_routers_network_ops.py test_disk_offerings.py > vmName entries from host_details table for the VM's whose state is Expunging > should be deleted during upgrade from older versions > - > > Key: CLOUDSTACK-9589 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9589 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Baremetal >Affects Versions: 4.4.4 > Environment: Baremetal zone >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Having vmName entries for VMs in 'expunging' states would cause with > deploying VMs with matching host tags fail. So removing them during upgrade -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670596#comment-15670596
]
ASF GitHub Bot commented on CLOUDSTACK-8830:
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/1677
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl]
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local,
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878:
> Response Received:
> 2015-07-24 08:20:55,525 DEBUG [c.c.a.t.Request] (DirectAgent-66:ctx-5fbdccd8)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Processing: { Ans: , MgmtId:
> 345051
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670595#comment-15670595
]
ASF GitHub Bot commented on CLOUDSTACK-8830:
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/798
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl]
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local,
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878:
> Response Received:
> 2015-07-24 08:20:55,525 DEBUG [c.c.a.t.Request] (DirectAgent-66:ctx-5fbdccd8)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Processing: { Ans: , MgmtId:
> 3450515
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670591#comment-15670591
]
ASF subversion and git services commented on CLOUDSTACK-8830:
-
Commit 94222b135680aad674b826888017056c4bbe0ea6 in cloudstack's branch
refs/heads/4.9 from [~nvazquez]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=94222b1 ]
CLOUDSTACK-8830: Fix for vm snapshots in Vmware, could not create vm snapshot
until 12 minutes after vm creation due to vCenter sent null name on snpashot
recent task
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl]
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local,
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAg
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670586#comment-15670586
]
ASF subversion and git services commented on CLOUDSTACK-8830:
-
Commit 94222b135680aad674b826888017056c4bbe0ea6 in cloudstack's branch
refs/heads/master from [~nvazquez]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=94222b1 ]
CLOUDSTACK-8830: Fix for vm snapshots in Vmware, could not create vm snapshot
until 12 minutes after vm creation due to vCenter sent null name on snpashot
recent task
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl]
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local,
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.Direc
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670588#comment-15670588
]
ASF subversion and git services commented on CLOUDSTACK-8830:
-
Commit 74639b305f275b59225b3b496f154515617684ce in cloudstack's branch
refs/heads/master from [~jburwell]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=74639b3 ]
Merge pull request #1677 from nvazquez/vmsnapshot12min
CLOUDSTACK-8830 - [Vmware] VM snapshot fails for 12 min after instance creation
(Targeted for 4.9)Continuing work by @maneesha-p in #798
This closes #798
* pr/1677:
CLOUDSTACK-8830: Fix for vm snapshots in Vmware, could not create vm snapshot
until 12 minutes after vm creation due to vCenter sent null name on snpashot
recent task
Signed-off-by: John Burwell
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageM
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670592#comment-15670592
]
ASF subversion and git services commented on CLOUDSTACK-8830:
-
Commit 74639b305f275b59225b3b496f154515617684ce in cloudstack's branch
refs/heads/4.9 from [~jburwell]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=74639b3 ]
Merge pull request #1677 from nvazquez/vmsnapshot12min
CLOUDSTACK-8830 - [Vmware] VM snapshot fails for 12 min after instance creation
(Targeted for 4.9)Continuing work by @maneesha-p in #798
This closes #798
* pr/1677:
CLOUDSTACK-8830: Fix for vm snapshots in Vmware, could not create vm snapshot
until 12 minutes after vm creation due to vCenter sent null name on snpashot
recent task
Signed-off-by: John Burwell
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageMana
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670587#comment-15670587
]
ASF subversion and git services commented on CLOUDSTACK-8830:
-
Commit 74639b305f275b59225b3b496f154515617684ce in cloudstack's branch
refs/heads/master from [~jburwell]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=74639b3 ]
Merge pull request #1677 from nvazquez/vmsnapshot12min
CLOUDSTACK-8830 - [Vmware] VM snapshot fails for 12 min after instance creation
(Targeted for 4.9)Continuing work by @maneesha-p in #798
This closes #798
* pr/1677:
CLOUDSTACK-8830: Fix for vm snapshots in Vmware, could not create vm snapshot
until 12 minutes after vm creation due to vCenter sent null name on snpashot
recent task
Signed-off-by: John Burwell
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageM
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670593#comment-15670593
]
ASF subversion and git services commented on CLOUDSTACK-8830:
-
Commit 74639b305f275b59225b3b496f154515617684ce in cloudstack's branch
refs/heads/4.9 from [~jburwell]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=74639b3 ]
Merge pull request #1677 from nvazquez/vmsnapshot12min
CLOUDSTACK-8830 - [Vmware] VM snapshot fails for 12 min after instance creation
(Targeted for 4.9)Continuing work by @maneesha-p in #798
This closes #798
* pr/1677:
CLOUDSTACK-8830: Fix for vm snapshots in Vmware, could not create vm snapshot
until 12 minutes after vm creation due to vCenter sent null name on snpashot
recent task
Signed-off-by: John Burwell
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageMana
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670590#comment-15670590
]
ASF subversion and git services commented on CLOUDSTACK-8830:
-
Commit becec33c2e79e2863e557f207c08f21bc0099652 in cloudstack's branch
refs/heads/master from [~jburwell]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=becec33 ]
Merge release branch 4.9 to master
* 4.9:
CLOUDSTACK-8830: Fix for vm snapshots in Vmware, could not create vm snapshot
until 12 minutes after vm creation due to vCenter sent null name on snpashot
recent task
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl]
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local,
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to
> create snapshot for vm:i-84987-16119-VM due to null
>
[jira] [Updated] (CLOUDSTACK-9599) UpdateTemplate Response is Missing "isdynamicallyscalable" Field
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Burwell updated CLOUDSTACK-9599:
-
Description:
The response for the UpdateTemplate command does not include the
"isdynamicallyscalable" field. The following is a sample of the output from a
call to a 4.6 management server:
{code}
cloudmonkey> update template id=7a6c263c-1e16-49dc-866e-7189f3f49052
passwordenabled=false
{
"template": {
"account": "admin",
"bootable": true,
"created": "2016-11-01T15:21:07+",
"crossZones": false,
"details": {
"dataDiskController": "osdefault",
"nicAdapter": "Vmxnet3",
"rootDiskController": "osdefault"
},
"displaytext": "Windows2012R2",
"domain": "ROOT",
"domainid": "80ed2086-a02e-11e6-8900-005056aa4c21",
"format": "OVA",
"hypervisor": "VMware",
"id": "7a6c263c-1e16-49dc-866e-7189f3f49052",
"isfeatured": false,
"ispublic": true,
"isready": false,
"name": "Windows2012R2",
"ostypeid": "0c1e7989-a034-11e6-8900-005056aa4c21",
"ostypename": "Windows Server 2012 R2 (64-bit)",
"tags": [],
"templatetype": "USER"
}
}
{code}
was:
The response for the UpdateTemplate command does not include the
"isdynamicallyscalable" field. The following is a sample of the output from a
call to a 4.6 management server:
cloudmonkey> update template id=7a6c263c-1e16-49dc-866e-7189f3f49052
passwordenabled=false
{
"template": {
"account": "admin",
"bootable": true,
"created": "2016-11-01T15:21:07+",
"crossZones": false,
"details": {
"dataDiskController": "osdefault",
"nicAdapter": "Vmxnet3",
"rootDiskController": "osdefault"
},
"displaytext": "Windows2012R2",
"domain": "ROOT",
"domainid": "80ed2086-a02e-11e6-8900-005056aa4c21",
"format": "OVA",
"hypervisor": "VMware",
"id": "7a6c263c-1e16-49dc-866e-7189f3f49052",
"isfeatured": false,
"ispublic": true,
"isready": false,
"name": "Windows2012R2",
"ostypeid": "0c1e7989-a034-11e6-8900-005056aa4c21",
"ostypename": "Windows Server 2012 R2 (64-bit)",
"tags": [],
"templatetype": "USER"
}
}
> UpdateTemplate Response is Missing "isdynamicallyscalable" Field
>
>
> Key: CLOUDSTACK-9599
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9599
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.1
>Reporter: John Burwell
>Priority: Minor
> Fix For: 4.9.2.0, 4.10.1.0, 4.11.0.0
>
>
> The response for the UpdateTemplate command does not include the
> "isdynamicallyscalable" field. The following is a sample of the output from
> a call to a 4.6 management server:
> {code}
> cloudmonkey> update template id=7a6c263c-1e16-49dc-866e-7189f3f49052
> passwordenabled=false
> {
> "template": {
> "account": "admin",
> "bootable": true,
> "created": "2016-11-01T15:21:07+",
> "crossZones": false,
> "details": {
> "dataDiskController": "osdefault",
> "nicAdapter": "Vmxnet3",
> "rootDiskController": "osdefault"
> },
> "displaytext": "Windows2012R2",
> "domain": "ROOT",
> "domainid": "80ed2086-a02e-11e6-8900-005056aa4c21",
> "format": "OVA",
> "hypervisor": "VMware",
> "id": "7a6c263c-1e16-49dc-866e-7189f3f49052",
> "isfeatured": false,
> "ispublic": true,
> "isready": false,
> "name": "Windows2012R2",
> "ostypeid": "0c1e7989-a034-11e6-8900-005056aa4c21",
> "ostypename": "Windows Server 2012 R2 (64-bit)",
> "tags": [],
> "templatetype": "USER"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9599) UpdateTemplate Response is Missing "isdynamicallyscalable" Field
John Burwell created CLOUDSTACK-9599:
Summary: UpdateTemplate Response is Missing
"isdynamicallyscalable" Field
Key: CLOUDSTACK-9599
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9599
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Affects Versions: 4.6.1
Reporter: John Burwell
Priority: Minor
The response for the UpdateTemplate command does not include the
"isdynamicallyscalable" field. The following is a sample of the output from a
call to a 4.6 management server:
cloudmonkey> update template id=7a6c263c-1e16-49dc-866e-7189f3f49052
passwordenabled=false
{
"template": {
"account": "admin",
"bootable": true,
"created": "2016-11-01T15:21:07+",
"crossZones": false,
"details": {
"dataDiskController": "osdefault",
"nicAdapter": "Vmxnet3",
"rootDiskController": "osdefault"
},
"displaytext": "Windows2012R2",
"domain": "ROOT",
"domainid": "80ed2086-a02e-11e6-8900-005056aa4c21",
"format": "OVA",
"hypervisor": "VMware",
"id": "7a6c263c-1e16-49dc-866e-7189f3f49052",
"isfeatured": false,
"ispublic": true,
"isready": false,
"name": "Windows2012R2",
"ostypeid": "0c1e7989-a034-11e6-8900-005056aa4c21",
"ostypename": "Windows Server 2012 R2 (64-bit)",
"tags": [],
"templatetype": "USER"
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9599) UpdateTemplate Response is Missing "isdynamicallyscalable" Field
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Burwell updated CLOUDSTACK-9599:
-
Fix Version/s: 4.11.0.0
4.10.1.0
4.9.2.0
> UpdateTemplate Response is Missing "isdynamicallyscalable" Field
>
>
> Key: CLOUDSTACK-9599
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9599
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.1
>Reporter: John Burwell
>Priority: Minor
> Fix For: 4.9.2.0, 4.10.1.0, 4.11.0.0
>
>
> The response for the UpdateTemplate command does not include the
> "isdynamicallyscalable" field. The following is a sample of the output from
> a call to a 4.6 management server:
> cloudmonkey> update template id=7a6c263c-1e16-49dc-866e-7189f3f49052
> passwordenabled=false
> {
> "template": {
> "account": "admin",
> "bootable": true,
> "created": "2016-11-01T15:21:07+",
> "crossZones": false,
> "details": {
> "dataDiskController": "osdefault",
> "nicAdapter": "Vmxnet3",
> "rootDiskController": "osdefault"
> },
> "displaytext": "Windows2012R2",
> "domain": "ROOT",
> "domainid": "80ed2086-a02e-11e6-8900-005056aa4c21",
> "format": "OVA",
> "hypervisor": "VMware",
> "id": "7a6c263c-1e16-49dc-866e-7189f3f49052",
> "isfeatured": false,
> "ispublic": true,
> "isready": false,
> "name": "Windows2012R2",
> "ostypeid": "0c1e7989-a034-11e6-8900-005056aa4c21",
> "ostypename": "Windows Server 2012 R2 (64-bit)",
> "tags": [],
> "templatetype": "USER"
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-9401) Nuage VSP Plugin : Support for InternalDns including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Singal closed CLOUDSTACK-9401. > Nuage VSP Plugin : Support for InternalDns including Marvin test coverage > - > > Key: CLOUDSTACK-9401 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9401 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Reporter: Rahul Singal >Assignee: Nick Livens > Fix For: 4.10.0.0 > > > Supporting Internal Dns by using Dns service provider as Virtual Router but > Dhcp provider will be NuageVsp. The idea is here is to keep using Internal > Dns service of cloudstack when network provider is some other vendor. > A sample network offering will be like below one:- > Service Provider > DHCP NuageVsp > DNSVirtualRouter/VpcVirtualRouter > UserDataVirtualRouter/VpcVirtualRouter > Virtual Networking NuageVsp > SourceNat NuageVsp > StaticNat NuageVsp > NetworkAcl/FirewallNuageVsp > Testrun:- > Verify InternalDns on Isolated Network ... === TestName: > test_01_Isolated_Network_with_zone | Status : SUCCESS === > ok > Verify InternalDns on Isolated Network with ping by hostname ... === > TestName: test_02_Isolated_Network | Status : SUCCESS === > ok > Verify update NetworkDomain for InternalDns on Isolated Network ... === > TestName: test_03_Update_Network_with_Domain | Status : SUCCESS === > ok > Verify update NetworkDomain for InternalDns on Isolated Network with ping VM > ... === TestName: test_04_Update_Network_with_Domain | Status : SUCCESS === > ok > Verify InternalDns on VPC Network ... === TestName: > test_05_VPC_Network_With_InternalDns | Status : SUCCESS === > ok > Verify InternalDns on VPC Network by ping with hostname ... === TestName: > test_06_VPC_Network_With_InternalDns | Status : SUCCESS === > ok > -- > Ran 6 tests in 5736.562s > OK > cloudstack$ pep8 --max-line-length=150 test_internal_dns.py > cloudstack$ pyflakes test_internal_dns.py > cloudstack$ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9592) Empty responses from site to site connection status are not handled propertly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670121#comment-15670121
]
ASF GitHub Bot commented on CLOUDSTACK-9592:
Github user cloudmonger commented on the issue:
https://github.com/apache/cloudstack/pull/1761
### ACS CI BVT Run
**Sumarry:**
Build Number 136
Hypervisor xenserver
NetworkType Advanced
Passed=103
Failed=2
Skipped=6
_Link to logs Folder (search by build_no):_
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0
**Failed tests:**
* test_deploy_vm_iso.py
* test_deploy_vm_from_iso Failing since 20 runs
* test_vm_life_cycle.py
* test_10_attachAndDetach_iso Failing since 21 runs
**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_3d_gpu_support
test_deploy_vgpu_enabled_vm
**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_over_provisioning.py
test_global_settings.py
test_scale_vm.py
test_service_offerings.py
test_routers_iptables_default_policy.py
test_loadbalance.py
test_routers.py
test_reset_vm_on_reboot.py
test_snapshots.py
test_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_routers_network_ops.py
test_disk_offerings.py
> Empty responses from site to site connection status are not handled propertly
> -
>
> Key: CLOUDSTACK-9592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9592
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.8.0
> Environment: Any Hypervisor
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> vpn connection status gives responses like the below sometimes
> Processing: { Ans: , MgmtId: 7203499016310, via: 1(10.147.28.37), Ver: v1,
> Flags: 110,
> [{"com.cloud.agent.api.CheckS2SVpnConnectionsAnswer":{"ipToConnected":{},"ipToDetail":{},"details":"","result":true,"wait":0}}]
> }
> 2016-09-27 08:52:19,211 DEBUG [c.c.a.t.Request]
> (RouterStatusMonitor-1:ctx-c20f391d) (logid:c217239d) Seq
> 1-2315413158421863581: Received: { Ans: , MgmtId: 7203499016310, via:
> 1(10.147.28.37), Ver: v1, Flags: 110,
> { CheckS2SVpnConnectionsAnswer }
> In the above scenario, the bug in the processing of this response assumes the
> connection is disconnected even though it is not disconnected and there would
> be two consecutive alerts in logs as well as emails even though there is not
> actual disconnection and reconnection
> Site-to-site Vpn Connection XYZ-VPN on router r-197-VM(id: 197) just switch
> from Disconnected to Connected
> Site-to-site Vpn Connection to D1 site to site VPN on router r-372-VM(id:
> 372) just switch from Connected to Disconnected
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9401) Nuage VSP Plugin : Support for InternalDns including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670089#comment-15670089 ] ASF GitHub Bot commented on CLOUDSTACK-9401: Github user krissterckx commented on the issue: https://github.com/apache/cloudstack/pull/1578 Thanks @karuturi Kris > Nuage VSP Plugin : Support for InternalDns including Marvin test coverage > - > > Key: CLOUDSTACK-9401 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9401 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Reporter: Rahul Singal >Assignee: Nick Livens > Fix For: 4.10.0.0 > > > Supporting Internal Dns by using Dns service provider as Virtual Router but > Dhcp provider will be NuageVsp. The idea is here is to keep using Internal > Dns service of cloudstack when network provider is some other vendor. > A sample network offering will be like below one:- > Service Provider > DHCP NuageVsp > DNSVirtualRouter/VpcVirtualRouter > UserDataVirtualRouter/VpcVirtualRouter > Virtual Networking NuageVsp > SourceNat NuageVsp > StaticNat NuageVsp > NetworkAcl/FirewallNuageVsp > Testrun:- > Verify InternalDns on Isolated Network ... === TestName: > test_01_Isolated_Network_with_zone | Status : SUCCESS === > ok > Verify InternalDns on Isolated Network with ping by hostname ... === > TestName: test_02_Isolated_Network | Status : SUCCESS === > ok > Verify update NetworkDomain for InternalDns on Isolated Network ... === > TestName: test_03_Update_Network_with_Domain | Status : SUCCESS === > ok > Verify update NetworkDomain for InternalDns on Isolated Network with ping VM > ... === TestName: test_04_Update_Network_with_Domain | Status : SUCCESS === > ok > Verify InternalDns on VPC Network ... === TestName: > test_05_VPC_Network_With_InternalDns | Status : SUCCESS === > ok > Verify InternalDns on VPC Network by ping with hostname ... === TestName: > test_06_VPC_Network_With_InternalDns | Status : SUCCESS === > ok > -- > Ran 6 tests in 5736.562s > OK > cloudstack$ pep8 --max-line-length=150 test_internal_dns.py > cloudstack$ pyflakes test_internal_dns.py > cloudstack$ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9586) When using local storage with Xenserver prepareTemplate does not work with multiple primary store
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670061#comment-15670061
]
Abhinandan Prateek commented on CLOUDSTACK-9586:
https://github.com/apache/cloudstack/pull/1765
> When using local storage with Xenserver prepareTemplate does not work with
> multiple primary store
> -
>
> Key: CLOUDSTACK-9586
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9586
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage, XenServer
>Affects Versions: 4.5.2
> Environment: XenServer 6.5 SP1
> Local Storage
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> 2016-11-09 15:05:15,876 DEBUG [c.c.h.x.r.XenServerStorageProcessor]
> (DirectAgent-29:ctx-8d890b55) Failed to destroy pbd
> SR_BACKEND_FAILURE_40The SR scan failed [opterr=['INTERNAL_ERROR',
> 'Db_exn.Uniqueness_constraint_violation("VDI", "uuid",
> "703f59ca-6e5e-38d3-bbef-707b5b14c704")']]
> at com.xensource.xenapi.Types.checkResponse(Types.java:2021)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
> at
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:462)
> at com.xensource.xenapi.SR.scan(SR.java:1257)
> at
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSR(Xenserver625StorageProcessor.java:113)
> at
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSr(Xenserver625StorageProcessor.java:139)
> at
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.copyTemplateToPrimaryStorage(Xenserver625StorageProcessor.java:173)
> Root Cause: CloudPlatform creates a SR on each host, which points to the
> template location on the secondary storage
> (secondary_Storage/template/tmpl//). This causes the
> database unique constraint violation when each XenServer tries to scan the SR
> created on each host. The host that scans the SR last, throws the exception
> because VDI was recognized already from the SR scan of the first host.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-9586) When using local storage with Xenserver prepareTemplate does not work with multiple primary store
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek reopened CLOUDSTACK-9586:
> When using local storage with Xenserver prepareTemplate does not work with
> multiple primary store
> -
>
> Key: CLOUDSTACK-9586
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9586
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage, XenServer
>Affects Versions: 4.5.2
> Environment: XenServer 6.5 SP1
> Local Storage
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> 2016-11-09 15:05:15,876 DEBUG [c.c.h.x.r.XenServerStorageProcessor]
> (DirectAgent-29:ctx-8d890b55) Failed to destroy pbd
> SR_BACKEND_FAILURE_40The SR scan failed [opterr=['INTERNAL_ERROR',
> 'Db_exn.Uniqueness_constraint_violation("VDI", "uuid",
> "703f59ca-6e5e-38d3-bbef-707b5b14c704")']]
> at com.xensource.xenapi.Types.checkResponse(Types.java:2021)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
> at
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:462)
> at com.xensource.xenapi.SR.scan(SR.java:1257)
> at
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSR(Xenserver625StorageProcessor.java:113)
> at
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSr(Xenserver625StorageProcessor.java:139)
> at
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.copyTemplateToPrimaryStorage(Xenserver625StorageProcessor.java:173)
> Root Cause: CloudPlatform creates a SR on each host, which points to the
> template location on the secondary storage
> (secondary_Storage/template/tmpl//). This causes the
> database unique constraint violation when each XenServer tries to scan the SR
> created on each host. The host that scans the SR last, throws the exception
> because VDI was recognized already from the SR scan of the first host.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9586) When using local storage with Xenserver prepareTemplate does not work with multiple primary store
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek resolved CLOUDSTACK-9586.
Resolution: Fixed
> When using local storage with Xenserver prepareTemplate does not work with
> multiple primary store
> -
>
> Key: CLOUDSTACK-9586
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9586
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage, XenServer
>Affects Versions: 4.5.2
> Environment: XenServer 6.5 SP1
> Local Storage
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> 2016-11-09 15:05:15,876 DEBUG [c.c.h.x.r.XenServerStorageProcessor]
> (DirectAgent-29:ctx-8d890b55) Failed to destroy pbd
> SR_BACKEND_FAILURE_40The SR scan failed [opterr=['INTERNAL_ERROR',
> 'Db_exn.Uniqueness_constraint_violation("VDI", "uuid",
> "703f59ca-6e5e-38d3-bbef-707b5b14c704")']]
> at com.xensource.xenapi.Types.checkResponse(Types.java:2021)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
> at
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:462)
> at com.xensource.xenapi.SR.scan(SR.java:1257)
> at
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSR(Xenserver625StorageProcessor.java:113)
> at
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSr(Xenserver625StorageProcessor.java:139)
> at
> com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.copyTemplateToPrimaryStorage(Xenserver625StorageProcessor.java:173)
> Root Cause: CloudPlatform creates a SR on each host, which points to the
> template location on the secondary storage
> (secondary_Storage/template/tmpl//). This causes the
> database unique constraint violation when each XenServer tries to scan the SR
> created on each host. The host that scans the SR last, throws the exception
> because VDI was recognized already from the SR scan of the first host.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9598) wrong defaut gateway in guest VM with nics in isolated and a shared network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670027#comment-15670027
]
Wei Zhou commented on CLOUDSTACK-9598:
--
is that a Windows vm ?
if yes, I have a fix for it.
> wrong defaut gateway in guest VM with nics in isolated and a shared network
> ---
>
> Key: CLOUDSTACK-9598
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9598
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.1.0
>
>
> When a guest instance is created with nic's in a isolated network and a
> shared network (with just DHCP and DNS), with isolated network as default
> network, DHCP lease on shared network from the shared network VR has wrong
> gateway. gateway is pointed to the virtual router IP.
> /etc/cloudstack/dhcpentry.json in shared network VR will have default gateway
> set to 0.0.0.0
> root@r-11-VM:~# cat /etc/cloudstack/dhcpentry.json
> {
> "10.6.9.165": {
> "default_entry": false,
> "default_gateway": "0.0.0.0",
> "dns_adresses": "10.1.1.1",
> "host_name": "VM-fce34d73-dc99-4559-b077-64711509907a",
> "ipv4_adress": "10.6.9.165",
> "ipv6_duid": "00:03:00:01:06:5a:da:00:00:6a",
> "mac_address": "06:5a:da:00:00:6a",
> "type": "dhcpentry"
> },
> "id": "dhcpentry"
> DhcpCommand network element command sent from the management server is like
> below with "defaultRouter":"0.0.0.0"
> 2016-11-15 19:15:29,319 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-25:ctx-a9aca0bb job-69/job-70 ctx-82c3fd7e)
> (logid:6ca37cdb) Seq 2-4650811040190170578: Sending { Cmd , MgmtId:
> 7150818625286, via: 2(trl-202-k-cs49-mreddy-kvm2), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.routing.DhcpEntryCommand":{"vmMac":"06:5a:da:00:00:6a","vmIpAddress":"10.6.9.165","vmName":"VM-fce34d73-dc99-4559-b077-64711509907a","defaultRouter":"0.0.0.0","defaultDns":"10.1.1.1","duid":"00:03:00:01:06:5a:da:00:00:6a","isDefault":false,"executeInSequence":false,"accessDetails":{"zone.network.type":"Advanced","router.guest.ip":"10.6.9.164","router.ip":"169.254.2.18","router.name":"r-11-VM"},"wait":0}}]
> }
> NIC details in the DB for the nic in the shared network has correct gateway.
> Gateway is set to 0.0.0.0, for every non-default nic [1]
> In case where shared network is non default network, then guest VM will end
> up treating VR in the shared network as gateway instead of actual shared
> network gateway.
> [1]
> https://github.com/apache/cloudstack/blob/4.9/server/src/com/cloud/network/router/CommandSetupHelper.java#L224
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15669962#comment-15669962 ] ASF GitHub Bot commented on CLOUDSTACK-9359: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1700 @karuturi a Trillian-Jenkins matrix job (centos6 mgmt + xs65sp1, centos7 mgmt + vmware55u3, centos7 mgmt + kvmcentos7) has been kicked to run smoke tests > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15669960#comment-15669960 ] ASF GitHub Bot commented on CLOUDSTACK-9359: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1700 @blueorangutan test matrix > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
