[jira] [Updated] (CLOUDSTACK-9390) Dettaching data volume from a running vm created with root and data disk fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-9390: -- Attachment: vmops.log.rar xensource.log.19 Attached vmops.log and xensource log file for reference. > Dettaching data volume from a running vm created with root and data disk fails > -- > > Key: CLOUDSTACK-9390 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9390 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.9.0 > Environment: Latest build from ACS master. > Hypervisor: Xenserver >Reporter: Sanjeev N >Priority: Critical > Attachments: vmops.log.rar, xensource.log.19 > > > Detaching data volume from a running vm created with root and data disk fails > Steps to reproduce: > === > 1.Bring up CS in advanced zone with xen cluster and shared primary storage > 2.Create a guest vm with both root and data disks > 3.Try to dettach the data disk from the vm > Result: > == > CS through exception while detaching the disk. However, it is succeeded from > xenserver. > Following is the output from xensource.log file : > May 25 01:09:56 xen1 xapi: [ info|xen1.automation.hyd.com|309333 > storage_unix||storage_impl] VDI.attach dbg:attach_and_activate > dp:vbd/285/xvdb sr:73956015-2176-3f64-6451-8e68c2914ed8 > vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 read_write:true > May 25 01:09:56 xen1 xapi: [debug|xen1.automation.hyd.com|309333 > storage_unix||dummytaskhelper] task VDI.attach D:3357ac7da502 created by task > attach_and_activate > May 25 01:09:56 xen1 xapi: [debug|xen1.automation.hyd.com|309333 > storage_unix|VDI.attach D:3357ac7da502|sm] SM nfs vdi_attach > sr=OpaqueRef:8bf61b69-294a-e5ce-b357-a4338b3531cc > vdi=OpaqueRef:7d021423-59ce-5fcd-8490-d8a9c975ac90 writable=true > May 25 01:09:57 xen1 xapi: [debug|xen1.automation.hyd.com|309333 > storage_unix||storage_impl] dbg:attach_and_activate dp:vbd/285/xvdb > sr:73956015-2176-3f64-6451-8e68c2914ed8 > vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:attached RW > May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 > storage_unix||storage_impl] dbg:dp_destroy dp:vbd/285/xvdb > sr:73956015-2176-3f64-6451-8e68c2914ed8 > vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:attached RW > May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 > storage_unix||dummytaskhelper] task VDI.detach D:620b12ae30f1 created by task > dp_destroy > May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 > storage_unix|VDI.detach D:620b12ae30f1|sm] SM nfs vdi_detach > sr=OpaqueRef:8bf61b69-294a-e5ce-b357-a4338b3531cc > vdi=OpaqueRef:7d021423-59ce-5fcd-8490-d8a9c975ac90 > May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 > storage_unix||storage_impl] dbg:dp_destroy dp:vbd/285/xvdb > sr:73956015-2176-3f64-6451-8e68c2914ed8 > vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:detached > Following is the exception from CS: > > com.cloud.utils.exception.CloudRuntimeException: Failed to detach volume > DATA-573 from VM VM-6e1e614d-e6a3-47c0-ab26-91fb94ba0361; Failed dettach > volume: 8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9, due to The server failed to > handle your request, due to an internal error. The given message may give > details useful for debugging the problem. > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:1846) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:2910) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2941) > at sun.reflect.GeneratedMethodAccessor602.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.ReflectiveMetho
[jira] [Created] (CLOUDSTACK-9390) Dettaching data volume from a running vm created with root and data disk fails
Sanjeev N created CLOUDSTACK-9390: - Summary: Dettaching data volume from a running vm created with root and data disk fails Key: CLOUDSTACK-9390 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9390 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.9.0 Environment: Latest build from ACS master. Hypervisor: Xenserver Reporter: Sanjeev N Priority: Critical Detaching data volume from a running vm created with root and data disk fails Steps to reproduce: === 1.Bring up CS in advanced zone with xen cluster and shared primary storage 2.Create a guest vm with both root and data disks 3.Try to dettach the data disk from the vm Result: == CS through exception while detaching the disk. However, it is succeeded from xenserver. Following is the output from xensource.log file : May 25 01:09:56 xen1 xapi: [ info|xen1.automation.hyd.com|309333 storage_unix||storage_impl] VDI.attach dbg:attach_and_activate dp:vbd/285/xvdb sr:73956015-2176-3f64-6451-8e68c2914ed8 vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 read_write:true May 25 01:09:56 xen1 xapi: [debug|xen1.automation.hyd.com|309333 storage_unix||dummytaskhelper] task VDI.attach D:3357ac7da502 created by task attach_and_activate May 25 01:09:56 xen1 xapi: [debug|xen1.automation.hyd.com|309333 storage_unix|VDI.attach D:3357ac7da502|sm] SM nfs vdi_attach sr=OpaqueRef:8bf61b69-294a-e5ce-b357-a4338b3531cc vdi=OpaqueRef:7d021423-59ce-5fcd-8490-d8a9c975ac90 writable=true May 25 01:09:57 xen1 xapi: [debug|xen1.automation.hyd.com|309333 storage_unix||storage_impl] dbg:attach_and_activate dp:vbd/285/xvdb sr:73956015-2176-3f64-6451-8e68c2914ed8 vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:attached RW May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 storage_unix||storage_impl] dbg:dp_destroy dp:vbd/285/xvdb sr:73956015-2176-3f64-6451-8e68c2914ed8 vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:attached RW May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 storage_unix||dummytaskhelper] task VDI.detach D:620b12ae30f1 created by task dp_destroy May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 storage_unix|VDI.detach D:620b12ae30f1|sm] SM nfs vdi_detach sr=OpaqueRef:8bf61b69-294a-e5ce-b357-a4338b3531cc vdi=OpaqueRef:7d021423-59ce-5fcd-8490-d8a9c975ac90 May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 storage_unix||storage_impl] dbg:dp_destroy dp:vbd/285/xvdb sr:73956015-2176-3f64-6451-8e68c2914ed8 vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:detached Following is the exception from CS: com.cloud.utils.exception.CloudRuntimeException: Failed to detach volume DATA-573 from VM VM-6e1e614d-e6a3-47c0-ab26-91fb94ba0361; Failed dettach volume: 8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9, due to The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. at com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:1846) at com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:2910) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2941) at sun.reflect.GeneratedMethodAccessor602.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy165.handleVmWorkJob(Unknown Source) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobD
[jira] [Created] (CLOUDSTACK-9387) Remove string convertion in Assertion statement
Sanjeev N created CLOUDSTACK-9387: - Summary: Remove string convertion in Assertion statement Key: CLOUDSTACK-9387 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9387 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Remove string convertion in Assertion statement, since the start port parameter in listFirewallAPI response is of type integer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9388) Remove string convertion in Assertion statement
Sanjeev N created CLOUDSTACK-9388: - Summary: Remove string convertion in Assertion statement Key: CLOUDSTACK-9388 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9388 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Remove string convertion in Assertion statement, since the start port parameter in listFirewallAPI response is of type integer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9380) listDomains API returns NPE if there is a failure in deleting domains
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15286523#comment-15286523 ] Sanjeev N commented on CLOUDSTACK-9380: --- Most of the tests in Regression test suite are failing because of this issue and we are not able to validate the functionalities by running regression. Can somebody please pick this and fix as early as possible? > listDomains API returns NPE if there is a failure in deleting domains > - > > Key: CLOUDSTACK-9380 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9380 > 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 > Environment: Latest build from master >Reporter: Sanjeev N >Priority: Critical > Attachments: cloud.sql, vmops.log > > > listDomains API returns NPE if there is a failure in deleting domains > Steps to Reproduce: > > 1.Create few domains under root domain and create one or two accounts in each > domain > 2.Create few vms, volumes, snapshots with those accounts. > 3.Now delete the domains and for one of the domains simulate the domain > deletion failure > 4.Try to list the domains using listDomains api without any domain id paramter > Result: > == > listDomains API returns error code 530 and in the management server log we > see following NPE: > 2016-05-16 08:53:09,273 ERROR [c.c.a.ApiServer] > (qtp237306958-12297:ctx-8f28bbf4 ctx-fdb614d0 ctx-6466fb85) (logid:d17482a8) > unhandled exception executing api command: [Ljava.lang.String;@652d471e > java.lang.NullPointerException > at > com.cloud.api.query.dao.DomainJoinDaoImpl.setResourceLimits(DomainJoinDaoImpl.java:113) > at > com.cloud.api.query.dao.DomainJoinDaoImpl.newDomainResponse(DomainJoinDaoImpl.java:76) > at sun.reflect.GeneratedMethodAccessor351.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.$Proxy272.newDomainResponse(Unknown Source) > at com.cloud.api.ApiDBUtils.newDomainResponse(ApiDBUtils.java:1834) > at > com.cloud.api.query.ViewResponseHelper.createDomainResponse(ViewResponseHelper.java:354) > at > com.cloud.api.query.QueryManagerImpl.searchForDomains(QueryManagerImpl.java:1880) > at > org.apache.cloudstack.api.command.admin.domain.ListDomainsCmd.execute(ListDomainsCmd.java:87) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:705) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:299) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:88) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587) > at > org.eclipse.jetty.s
[jira] [Updated] (CLOUDSTACK-9380) listDomains API returns NPE if there is a failure in deleting domains
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-9380: -- Attachment: vmops.log cloud.sql Attached vmops.log file and cloud db. > listDomains API returns NPE if there is a failure in deleting domains > - > > Key: CLOUDSTACK-9380 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9380 > 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 > Environment: Latest build from master >Reporter: Sanjeev N >Priority: Critical > Attachments: cloud.sql, vmops.log > > > listDomains API returns NPE if there is a failure in deleting domains > Steps to Reproduce: > > 1.Create few domains under root domain and create one or two accounts in each > domain > 2.Create few vms, volumes, snapshots with those accounts. > 3.Now delete the domains and for one of the domains simulate the domain > deletion failure > 4.Try to list the domains using listDomains api without any domain id paramter > Result: > == > listDomains API returns error code 530 and in the management server log we > see following NPE: > 2016-05-16 08:53:09,273 ERROR [c.c.a.ApiServer] > (qtp237306958-12297:ctx-8f28bbf4 ctx-fdb614d0 ctx-6466fb85) (logid:d17482a8) > unhandled exception executing api command: [Ljava.lang.String;@652d471e > java.lang.NullPointerException > at > com.cloud.api.query.dao.DomainJoinDaoImpl.setResourceLimits(DomainJoinDaoImpl.java:113) > at > com.cloud.api.query.dao.DomainJoinDaoImpl.newDomainResponse(DomainJoinDaoImpl.java:76) > at sun.reflect.GeneratedMethodAccessor351.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.$Proxy272.newDomainResponse(Unknown Source) > at com.cloud.api.ApiDBUtils.newDomainResponse(ApiDBUtils.java:1834) > at > com.cloud.api.query.ViewResponseHelper.createDomainResponse(ViewResponseHelper.java:354) > at > com.cloud.api.query.QueryManagerImpl.searchForDomains(QueryManagerImpl.java:1880) > at > org.apache.cloudstack.api.command.admin.domain.ListDomainsCmd.execute(ListDomainsCmd.java:87) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:705) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:299) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:88) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.j
[jira] [Created] (CLOUDSTACK-9380) listDomains API returns NPE if there is a failure in deleting domains
Sanjeev N created CLOUDSTACK-9380: - Summary: listDomains API returns NPE if there is a failure in deleting domains Key: CLOUDSTACK-9380 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9380 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 Environment: Latest build from master Reporter: Sanjeev N Priority: Critical listDomains API returns NPE if there is a failure in deleting domains Steps to Reproduce: 1.Create few domains under root domain and create one or two accounts in each domain 2.Create few vms, volumes, snapshots with those accounts. 3.Now delete the domains and for one of the domains simulate the domain deletion failure 4.Try to list the domains using listDomains api without any domain id paramter Result: == listDomains API returns error code 530 and in the management server log we see following NPE: 2016-05-16 08:53:09,273 ERROR [c.c.a.ApiServer] (qtp237306958-12297:ctx-8f28bbf4 ctx-fdb614d0 ctx-6466fb85) (logid:d17482a8) unhandled exception executing api command: [Ljava.lang.String;@652d471e java.lang.NullPointerException at com.cloud.api.query.dao.DomainJoinDaoImpl.setResourceLimits(DomainJoinDaoImpl.java:113) at com.cloud.api.query.dao.DomainJoinDaoImpl.newDomainResponse(DomainJoinDaoImpl.java:76) at sun.reflect.GeneratedMethodAccessor351.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.$Proxy272.newDomainResponse(Unknown Source) at com.cloud.api.ApiDBUtils.newDomainResponse(ApiDBUtils.java:1834) at com.cloud.api.query.ViewResponseHelper.createDomainResponse(ViewResponseHelper.java:354) at com.cloud.api.query.QueryManagerImpl.searchForDomains(QueryManagerImpl.java:1880) at org.apache.cloudstack.api.command.admin.domain.ListDomainsCmd.execute(ListDomainsCmd.java:87) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:705) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:299) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:88) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.
[jira] [Created] (CLOUDSTACK-9337) [CI] Enhance vcenter library to add datacenter programmatically
Sanjeev N created CLOUDSTACK-9337: - Summary: [CI] Enhance vcenter library to add datacenter programmatically Key: CLOUDSTACK-9337 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9337 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Enhance vcenter.py to create data centers in vCenter server automatically by reading the configuration from a json file. Added few methods to create data center, cluster and hosts in it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9328) Fix vlan issues from test suite test_privategw_acl.py in BVT
Sanjeev N created CLOUDSTACK-9328: - Summary: Fix vlan issues from test suite test_privategw_acl.py in BVT Key: CLOUDSTACK-9328 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9328 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: Sanjeev N Assignee: Sanjeev N Fix vlan issues from test suite test_privategw_acl.py in BVT Currently the tests reads the vlans from the physical network and takes the first vlan from the list of vlans and uses it. However, this approach might not work when the tests run in parallel. E.g. in CI we run test suits in parallel and the first vlan may not be available and tests would fail if we try to use the vlan which is already in use. Made changes to the script so that it will get the free vlan list from the DB and uses the first vlan from the available pool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9306) Replace people.apache.org with home.apache.org in test_data
Sanjeev N created CLOUDSTACK-9306: - Summary: Replace people.apache.org with home.apache.org in test_data Key: CLOUDSTACK-9306 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9306 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Replace people.apache.org with home.apache.org in test_data and test files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9219) Test to verify vmstart aftre nic removal and attachment
Sanjeev N created CLOUDSTACK-9219: - Summary: Test to verify vmstart aftre nic removal and attachment Key: CLOUDSTACK-9219 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9219 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Adding new marvin test to verify starting vm after removing NIC and reattaching. Steps to verify: == 1.Create vm with three networks (e.g. #0,#1,#2) 2.Stop the vm 3.Remove one nic from vm (e.g.: #1) 4.Add nic to vm from the removed network again 5.Start VM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9218) Test to verify restart network after master VR destroyed
Sanjeev N created CLOUDSTACK-9218: - Summary: Test to verify restart network after master VR destroyed Key: CLOUDSTACK-9218 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9218 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Adding new marvin test to verify restarting network after destroying master router in RVR Steps followed: 1.Create network offering with RVR enabled 2.Create an isolated network and deploy guest vm in it 3.Destory(stop and destroy) master VR 4.Verify that backup VR switches to master 5.Restart network without cleanup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9215) Marvin test to check vm deployment in vpc tier if nic type is vmxnet3
Sanjeev N created CLOUDSTACK-9215: - Summary: Marvin test to check vm deployment in vpc tier if nic type is vmxnet3 Key: CLOUDSTACK-9215 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9215 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Reporter: Sanjeev N Assignee: Sanjeev N Marvin test to check vm deployment in vpc tier if nic type is vmxnet3. If sytemvm nic type is vmxnet3, debian os takes little more time to discover the nic after hot plugin compared to nic type E1000. So vm deployment fails. Adding new test to validate this functionality with nic type vmxnet3. Steps followed in the test: 1.Set systemvm.nic.type to Vmxnet3 and restart MS 2.Create VPC 3.Create Tier 4.Deploy one guest vm and make sure no issues in vm deployment 5.Reset the nic type to old value -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9207) Test to verify if additional ipaddress on vpcVR is removed if the network is restarted with cleanup
Sanjeev N created CLOUDSTACK-9207: - Summary: Test to verify if additional ipaddress on vpcVR is removed if the network is restarted with cleanup Key: CLOUDSTACK-9207 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9207 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Test to check restarting vpc network (tier) with cleanup does not delete the secondary ip address from the VR. Steps followed: 1.Create VPC, tier and deploy vm in the tier 2.Acquire additional IP address and configure StaticNAT with vm created in step1 3.Restart vpc network with clean up Expected Result: == Secondary ip address (IP configured on VPC VR's public interface) should not be deleted ( or it should be configured on vr) after network restart with cleanup. RootCause: = As part of clean up, CS deletes all the network configuration from the VR and it configures again. However, the reconfiguration did not include the additional ip addresses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9117) Add marvin test to verify adding some TCP ports in vpn won't fail
Sanjeev N created CLOUDSTACK-9117: - Summary: Add marvin test to verify adding some TCP ports in vpn won't fail Key: CLOUDSTACK-9117 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9117 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Add marvin test to verify adding some TCP ports in vpn won't fail Steps to follow: In an advanced zone 1.Create Remote access vpn on SourceNAT IP address 2.Create PortForwarding rules on the same ip address with TCP ports 500,4500 and 1701. This is to make sure that VPN ports (UDP ports 500,4500 and 1701) won't give conflict when configuring PF with TCP ports. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9102) Resolve issues with test_vpc_vpn.py test suite file
Sanjeev N created CLOUDSTACK-9102: - Summary: Resolve issues with test_vpc_vpn.py test suite file Key: CLOUDSTACK-9102 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9102 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Following issues are found in test_vpc_vpn.py file: 1. UnboundLocalError: This is because we are using some variables before assignment. This is related to python syntax and requires a code change 2. Template registration based on the hypervisor: The functionality in this test is nothing to do with template registration. So remove template registration part and make it generic for all the hypervisors 3. Getting default vpc offering from the list of vpc offerings: Test was listing default vpc offerings and taking the first one from the list. Hoever, cloudstack provides three default vpc offerings and first one in the list is always the Nuage VPC offering. So if we try to create vpc with this offering it will fail because we would not have the Nuage service provider in the physical network. So need to change the way we get the default vpc offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9084) Domain Admin should be able to delet the public IP Address Tags
Sanjeev N created CLOUDSTACK-9084: - Summary: Domain Admin should be able to delet the public IP Address Tags Key: CLOUDSTACK-9084 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9084 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Sanjeev N Assignee: Sanjeev N Adding marvin test to verify that domain admin can delete the resource tags created on Public IP Address. Steps to perform this test: 1.Create sub domain under root domain 2.Add admin account in the domain created 3.Create network 4.Acquire public IP address 5.Add and remove tag on IP Address acquired above Perform steps 3-5 using domain admin account created in steps 1 and 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9016) Fail to create VM instance within VPC
Sanjeev N created CLOUDSTACK-9016: - Summary: Fail to create VM instance within VPC Key: CLOUDSTACK-9016 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9016 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Sanjeev N Priority: Critical REPRO STEPS == 1. Create a VPC with i) Super CIDR for Guest Networks: 192.168.1.0/24 2. Create network "HTTP Server" i) Network Offering: DefaultIsolatedNetworkOfferingForVPCNetworks" ii) Gateway: 192.168.1.6 iiI) Netmask: 255.255.255.248 3. Deploy 4 VM instance succeed, unable to create 5th vm. If we set Gateway to 192.168.1.1, it works fine. Root Cause: === CS is not allocating the first IP address in the CIDR to guest vm. It treats that IP address as gateway IP address. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8960) Remove Citrix Resources from test_data.py
Sanjeev N created CLOUDSTACK-8960: - Summary: Remove Citrix Resources from test_data.py Key: CLOUDSTACK-8960 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8960 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N In test_data.py we have templates and iso's with urls pointing to Citrix web servers. This servers are not accessible to community outside of Citrix. This bug is to replace those URLs with the web server locations accessible to everybody in the community. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8893) test_vm_snapshots.py requires modification since we support volume snapshot on a vm with vm snapshot
Sanjeev N created CLOUDSTACK-8893: - Summary: test_vm_snapshots.py requires modification since we support volume snapshot on a vm with vm snapshot Key: CLOUDSTACK-8893 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8893 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.6.0 Reporter: Sanjeev N Assignee: Sanjeev N test_vm_snapshots.py requires modification since we support volume snapshot on a vm with vm snapshot test_01_test_vm_volume_snapshot test from test_vm_snapshots.py expects exception when we try to create volume snapshot on a vm with vm snapshot. We need to modify this since we are supporting volume snapshot an a vm with vm snapshots . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8720) Handle corner case in remove nic from vm
Sanjeev N created CLOUDSTACK-8720: - Summary: Handle corner case in remove nic from vm Key: CLOUDSTACK-8720 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8720 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Adding test to cover the following scenario: 1) Deploy vm v1 in two networks say n1 and n2. 2) Check the IP of the nic in n2 say ip1 3) Deploy vm v2 in another network say n3 with same IP address as ip1 using 'deployVirtualMachine' api with 'ipaddress' as one of the parameters. 4) Acquire public IP in n3 network. 5) Configure PF on the acquired IP 6) Choose destination vm as v2. 7) Try to remove nic of v1 in n2 network. Removing nic from v1 in n2 network should not be blocked because of the same ip addresses from vms v1 and v2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8685) [VPC_VR] Default route is not configured on VPC VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651773#comment-14651773 ] Sanjeev N commented on CLOUDSTACK-8685: --- [~wilder.rodrigues] Can you please fix if possible, since you are already working on CLOUDSTACK-8688 ? > [VPC_VR] Default route is not configured on VPC VR > -- > > Key: CLOUDSTACK-8685 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8685 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 > Environment: Advanced zone with VPC. Latest build from ACS master. >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.6.0 > > Attachments: management-server.zip > > > [VPC_VR] Default route is not configured on VPC VR > Steps to reproduce: > > 1.Bring up CS in advanced zone > 2.Create VPC and wait for the VR to come into running state > 3.Connect to VR and verify route table information > Result: > == > Default route is not configured on VPC VR. > root@r-9-VM:/var/cache/cloud# route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > 10.1.1.00.0.0.0 255.255.255.0 U 0 00 eth2 > 10.1.2.00.0.0.0 255.255.255.0 U 0 00 eth3 > 10.220.128.00.0.0.0 255.255.224.0 U 0 00 eth1 > 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0 > root@r-9-VM:/var/cache/cloud# > Observations: > === > When vr boots up, we run cloud-early-config. This will clean if there is any > default route exists on VR. Then we execute vpc_ipassoc.sh to configure > public nic and default route via public nic. However, in the latest ACS > master we are not executing vpc_ipassoc.sh. > For any configuration on VR , we are creating configuration file and applying > it with update_config.py. > Looks like adding default route is missing in the confguration file. > Following is the configuration file genearted on VR : > 015-07-29 05:20:39,132 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-402:ctx-83549002) VR Config file > VR-d3b73941-7b3d-489a-bcc6-47c6a777c950.cfg got created in VR, ip > 169.254.0.54 with content > #Apache CloudStack Virtual Router Config File > > 1.0 > > > /var/cache/cloud/ip_associations.json > {"ip_address":[{"public_ip":"10.220.135.97","source_nat":false,"add":true,"one_to_one_nat":false,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false},{"public_ip":"10.220.135.99","source_nat":false,"add":true,"one_to_one_nat":true,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false}],"type":"ips"} > > > /opt/cloud/bin/update_config.py ip_associations.json > > > /var/cache/cloud/staticnat_rules.json > {"rules":[{"revoke":false,"source_ip_address":"10.220.135.99","source_port_range":"0:0","destination_ip_address":"10.1.1.36"}],"type":"staticnatrules"} > > > /opt/cloud/bin/update_config.py staticnat_rules.json > > > /var/cache/cloud/forwarding_rules.json > {"rules":[{"revoke":false,"protocol":"tcp","source_ip_address":"10.220.135.97","source_port_range":"22:22","destination_ip_address":"10.1.1.194","destination_port_range":"22:22"}],"type":"forwardrules"} > > > /opt/cloud/bin/update_config.py forwarding_rules.json > > > /var/cache/cloud/network_acl.json > {"device":"eth2","mac_address":"02:00:7c:a8:00:02","private_gateway_acl":false,"nic_ip":"10.1.1.1","nic_netmask":"24","ingress_rules":[{"type":"tcp","first_port":22,"last_port":22,"cidr":"0.0.0.0/0","allowed":true}],"egress_rules":[{"type":"icmp","icmp_type":-1,"icmp_code":-1,"cidr":"0.0.0.0/0","allowed":true}],"type":"networkacl"} > > > /opt/cloud/bin/update_config.py network_acl.json > > > /var/cache/cloud/vm_dhcp_entry.json > {"host_name":"VM-403a0536-ba54-404f-a664-1b14d039497c","mac_address":"02:00:10:ca:00:01","ipv4_adress":"10.1.1.194","ipv6_duid":"00:03:00:01:02:00:10:ca:00:01","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"} > > > /opt/cloud/bin/update_config.py vm_dhcp_entry.json > > > /var/cache/cloud/vm_dhcp_entry.json > {"host_name":"VM-4c5e69ab-65dd-4315-b8fb-702f5599ede0","mac_address":"02:00:0f:22:00:03","ipv4_adress":"10.1.1.36","ipv6_duid":"00:03:00:01:02:00:0f:22:00:03","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"} > > > /opt/cloud/bin/update_config.py vm_dhcp_entry.json > > > /var/cache/cloud/vm_metadata.json > {"vm_ip_address":"10.1.1.194","vm_metadata":[["userdata
[jira] [Created] (CLOUDSTACK-8688) Defualt policy for INPUT and FORWARD chain is ACCEPT in VR filter table
Sanjeev N created CLOUDSTACK-8688: - Summary: Defualt policy for INPUT and FORWARD chain is ACCEPT in VR filter table Key: CLOUDSTACK-8688 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8688 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.6.0 Environment: Latest build from ACS master. Zone type: Advanced Reporter: Sanjeev N Priority: Blocker Defualt policy for INPUT and FORWARD chain is ACCEPT in VR filter table Steps to reproduce the issue: === 1.Bring up CS in advanced zone with any supported hypervisor (e.g. Xenserver) 2.Create an isolated network with Network Offering "DefaultIsolatedNetworkOfferingWithSourceNatService" 3.Deploy one guest vm within that network Result: === IP tables rules on the VR created are as follows: root@r-7-VM:~# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination NETWORK_STATS all -- anywhere anywhere ACCEPT all -- anywhere vrrp.mcast.net ACCEPT all -- anywhere 225.0.0.50 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere vrrp.mcast.net ACCEPT all -- anywhere 225.0.0.50 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT udp -- anywhere anywhere udp dpt:bootps ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW ACCEPT tcp -- anywhere anywhere tcp dpt:http-alt state NEW Chain FORWARD (policy ACCEPT) target prot opt source destination NETWORK_STATS all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere state NEW ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT) target prot opt source destination NETWORK_STATS all -- anywhere anywhere Chain NETWORK_STATS (3 references) target prot opt source destination all -- anywhere anywhere all -- anywhere anywhere tcp -- anywhere anywhere tcp -- anywhere anywhere But the Default policy for INPUT and FORWARD chain should be DROP instead of ACCEPT. Otherwise all the traffic would be allowed to VR. Same is the case with VPC and Shared network as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8685) [VPC_VR] Default route is not configured on VPC VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-8685: -- Attachment: management-server.zip > [VPC_VR] Default route is not configured on VPC VR > -- > > Key: CLOUDSTACK-8685 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8685 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 > Environment: Advanced zone with VPC. Latest build from ACS master. >Reporter: Sanjeev N >Priority: Critical > Attachments: management-server.zip > > > [VPC_VR] Default route is not configured on VPC VR > Steps to reproduce: > > 1.Bring up CS in advanced zone > 2.Create VPC and wait for the VR to come into running state > 3.Connect to VR and verify route table information > Result: > == > Default route is not configured on VPC VR. > root@r-9-VM:/var/cache/cloud# route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > 10.1.1.00.0.0.0 255.255.255.0 U 0 00 eth2 > 10.1.2.00.0.0.0 255.255.255.0 U 0 00 eth3 > 10.220.128.00.0.0.0 255.255.224.0 U 0 00 eth1 > 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0 > root@r-9-VM:/var/cache/cloud# > Observations: > === > When vr boots up, we run cloud-early-config. This will clean if there is any > default route exists on VR. Then we execute vpc_ipassoc.sh to configure > public nic and default route via public nic. However, in the latest ACS > master we are not executing vpc_ipassoc.sh. > For any configuration on VR , we are creating configuration file and applying > it with update_config.py. > Looks like adding default route is missing in the confguration file. > Following is the configuration file genearted on VR : > 015-07-29 05:20:39,132 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-402:ctx-83549002) VR Config file > VR-d3b73941-7b3d-489a-bcc6-47c6a777c950.cfg got created in VR, ip > 169.254.0.54 with content > #Apache CloudStack Virtual Router Config File > > 1.0 > > > /var/cache/cloud/ip_associations.json > {"ip_address":[{"public_ip":"10.220.135.97","source_nat":false,"add":true,"one_to_one_nat":false,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false},{"public_ip":"10.220.135.99","source_nat":false,"add":true,"one_to_one_nat":true,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false}],"type":"ips"} > > > /opt/cloud/bin/update_config.py ip_associations.json > > > /var/cache/cloud/staticnat_rules.json > {"rules":[{"revoke":false,"source_ip_address":"10.220.135.99","source_port_range":"0:0","destination_ip_address":"10.1.1.36"}],"type":"staticnatrules"} > > > /opt/cloud/bin/update_config.py staticnat_rules.json > > > /var/cache/cloud/forwarding_rules.json > {"rules":[{"revoke":false,"protocol":"tcp","source_ip_address":"10.220.135.97","source_port_range":"22:22","destination_ip_address":"10.1.1.194","destination_port_range":"22:22"}],"type":"forwardrules"} > > > /opt/cloud/bin/update_config.py forwarding_rules.json > > > /var/cache/cloud/network_acl.json > {"device":"eth2","mac_address":"02:00:7c:a8:00:02","private_gateway_acl":false,"nic_ip":"10.1.1.1","nic_netmask":"24","ingress_rules":[{"type":"tcp","first_port":22,"last_port":22,"cidr":"0.0.0.0/0","allowed":true}],"egress_rules":[{"type":"icmp","icmp_type":-1,"icmp_code":-1,"cidr":"0.0.0.0/0","allowed":true}],"type":"networkacl"} > > > /opt/cloud/bin/update_config.py network_acl.json > > > /var/cache/cloud/vm_dhcp_entry.json > {"host_name":"VM-403a0536-ba54-404f-a664-1b14d039497c","mac_address":"02:00:10:ca:00:01","ipv4_adress":"10.1.1.194","ipv6_duid":"00:03:00:01:02:00:10:ca:00:01","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"} > > > /opt/cloud/bin/update_config.py vm_dhcp_entry.json > > > /var/cache/cloud/vm_dhcp_entry.json > {"host_name":"VM-4c5e69ab-65dd-4315-b8fb-702f5599ede0","mac_address":"02:00:0f:22:00:03","ipv4_adress":"10.1.1.36","ipv6_duid":"00:03:00:01:02:00:0f:22:00:03","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"} > > > /opt/cloud/bin/update_config.py vm_dhcp_entry.json > > > /var/cache/cloud/vm_metadata.json > {"vm_ip_address":"10.1.1.194","vm_metadata":[["userdata","user-data",null],["metadata","service-offering","Tiny > > Instance"],["metadata","availability-zone","XenRT-Zone-0"],["metadata","local-ipv4","10.1.1.
[jira] [Created] (CLOUDSTACK-8685) [VPC_VR] Default route is not configured on VPC VR
Sanjeev N created CLOUDSTACK-8685: - Summary: [VPC_VR] Default route is not configured on VPC VR Key: CLOUDSTACK-8685 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8685 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Advanced zone with VPC. Latest build from ACS master. Reporter: Sanjeev N Priority: Critical [VPC_VR] Default route is not configured on VPC VR Steps to reproduce: 1.Bring up CS in advanced zone 2.Create VPC and wait for the VR to come into running state 3.Connect to VR and verify route table information Result: == Default route is not configured on VPC VR. root@r-9-VM:/var/cache/cloud# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 10.1.1.00.0.0.0 255.255.255.0 U 0 00 eth2 10.1.2.00.0.0.0 255.255.255.0 U 0 00 eth3 10.220.128.00.0.0.0 255.255.224.0 U 0 00 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0 root@r-9-VM:/var/cache/cloud# Observations: === When vr boots up, we run cloud-early-config. This will clean if there is any default route exists on VR. Then we execute vpc_ipassoc.sh to configure public nic and default route via public nic. However, in the latest ACS master we are not executing vpc_ipassoc.sh. For any configuration on VR , we are creating configuration file and applying it with update_config.py. Looks like adding default route is missing in the confguration file. Following is the configuration file genearted on VR : 015-07-29 05:20:39,132 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-402:ctx-83549002) VR Config file VR-d3b73941-7b3d-489a-bcc6-47c6a777c950.cfg got created in VR, ip 169.254.0.54 with content #Apache CloudStack Virtual Router Config File 1.0 /var/cache/cloud/ip_associations.json {"ip_address":[{"public_ip":"10.220.135.97","source_nat":false,"add":true,"one_to_one_nat":false,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false},{"public_ip":"10.220.135.99","source_nat":false,"add":true,"one_to_one_nat":true,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false}],"type":"ips"} /opt/cloud/bin/update_config.py ip_associations.json /var/cache/cloud/staticnat_rules.json {"rules":[{"revoke":false,"source_ip_address":"10.220.135.99","source_port_range":"0:0","destination_ip_address":"10.1.1.36"}],"type":"staticnatrules"} /opt/cloud/bin/update_config.py staticnat_rules.json /var/cache/cloud/forwarding_rules.json {"rules":[{"revoke":false,"protocol":"tcp","source_ip_address":"10.220.135.97","source_port_range":"22:22","destination_ip_address":"10.1.1.194","destination_port_range":"22:22"}],"type":"forwardrules"} /opt/cloud/bin/update_config.py forwarding_rules.json /var/cache/cloud/network_acl.json {"device":"eth2","mac_address":"02:00:7c:a8:00:02","private_gateway_acl":false,"nic_ip":"10.1.1.1","nic_netmask":"24","ingress_rules":[{"type":"tcp","first_port":22,"last_port":22,"cidr":"0.0.0.0/0","allowed":true}],"egress_rules":[{"type":"icmp","icmp_type":-1,"icmp_code":-1,"cidr":"0.0.0.0/0","allowed":true}],"type":"networkacl"} /opt/cloud/bin/update_config.py network_acl.json /var/cache/cloud/vm_dhcp_entry.json {"host_name":"VM-403a0536-ba54-404f-a664-1b14d039497c","mac_address":"02:00:10:ca:00:01","ipv4_adress":"10.1.1.194","ipv6_duid":"00:03:00:01:02:00:10:ca:00:01","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"} /opt/cloud/bin/update_config.py vm_dhcp_entry.json /var/cache/cloud/vm_dhcp_entry.json {"host_name":"VM-4c5e69ab-65dd-4315-b8fb-702f5599ede0","mac_address":"02:00:0f:22:00:03","ipv4_adress":"10.1.1.36","ipv6_duid":"00:03:00:01:02:00:0f:22:00:03","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"} /opt/cloud/bin/update_config.py vm_dhcp_entry.json /var/cache/cloud/vm_metadata.json {"vm_ip_address":"10.1.1.194","vm_metadata":[["userdata","user-data",null],["metadata","service-offering","Tiny Instance"],["metadata","availability-zone","XenRT-Zone-0"],["metadata","local-ipv4","10.1.1.194"],["metadata","local-hostname","VM-403a0536-ba54-404f-a664-1b14d039497c"],["metadata","public-ipv4","10.220.135.96"],["metadata","public-hostname","10.220.135.96"],["metadata","instance-id","403a0536-ba54-404f-a664-1b14d039497c"],["metadata","vm-id","403a0536-ba54-404f-a664-1b14d039497c"],["metadata","public-keys",null],["metadata","cloud-identifier","CloudStack-{5bcd0291-2ac9-4d68-9887-bda6ae6596c2}"]],"type":"vmda
[jira] [Created] (CLOUDSTACK-8681) [Egress_Rules] CS does not honor the default deny egress policy in isolated network
Sanjeev N created CLOUDSTACK-8681: - Summary: [Egress_Rules] CS does not honor the default deny egress policy in isolated network Key: CLOUDSTACK-8681 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8681 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from master with commit ac9c2a224a78f413945e25fd7cf23364fbef00b5 Zone: Advanced Reporter: Sanjeev N Priority: Critical [Egress_Rules] CS does not honor the default deny egress policy in isolated network Steps to reproduce: = 1.Bring up CS in advanced zone with any of the supported hypervisors 2.Create an isolated network with network offering "DefaultIsolatedNetworkOfferingWithSourceNatService" so that defaul egress policy would be "deny all" 3.Deploy one guest vm in that network Expected Result: = VR forward chain in filter table should have the defualt DROP policy. Actual Result: === Following is the FORWARD chain from the VR: Chain FORWARD (policy ACCEPT 10282 packets, 1743K bytes) pkts bytes target prot opt in out source destination 46405 27M NETWORK_STATS all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 state NEW 27468 25M ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 2 104 ACCEPT tcp -- eth2 eth00.0.0.0/00.0.0.0/0 tcp dpt:22 state NEW It should be in the following way: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 NETWORK_STATS all -- * * 0.0.0.0/00.0.0.0/ 0 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 state NEW 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 FW_OUTBOUND all -- eth0 eth20.0.0.0/00.0.0.0/0 Chain FW_EGRESS_RULES (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 Chain FW_OUTBOUND (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 FW_EGRESS_RULES all -- * * 0.0.0.0/00.0.0. 0/0 Looks like now we are loading ip tables from "/etc/iptables/router_rules.v4" . But the base for this file should be "/etc/iptables/rules.v4" to persist the default behavior. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8671) [VMWare] VM deployment from iso fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-8671: -- Attachment: management-server.zip Please look for job-322 in the attached MS log file for vm deployment failure. > [VMWare] VM deployment from iso fails > - > > Key: CLOUDSTACK-8671 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8671 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, VMware >Affects Versions: 4.6.0 > Environment: Latest build from ACS master with commit > 2984acca83fff03c2ad8bdd28c097e797d4ce087 > Hypervisor: VMWare >Reporter: Sanjeev N >Priority: Critical > Attachments: management-server.zip > > > Failed to deploy vm from ISO > Steps to reproduce: > > 1.Bring up CS in advanced zone with vmware cluster > 2.Register one bootable iso > 3.Try to deploy vm using that iso > Result: > == > VM Deployment failed due to failure in creating volume: > 2015-07-23 16:48:29,712 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-196:ctx-18de08d8 10.81.28.111, job-322/job-323, cmd: > CreateObjectCommand) create volume failed due to Exception: > java.lang.NullPointerException > Message: charsetName > java.lang.NullPointerException: charsetName > at java.io.InputStreamReader.(InputStreamReader.java:99) > at > com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486) > at > com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217) > at > com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2015-07-23 16:48:29,713 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Response Received: > 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] > (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Processing: { Ans: > , MgmtId: 187822473365406, via: 2, Ver: v1, Flags: 10, > [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException: > charsetName","wait":0}}] } > 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] > (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Seq > 2-8089027880710832600: Received: { Ans: , MgmtId: 187822473365406, via: 2, > Ver: v1, Flags: 10, { CreateObjectAnswer } } > 2015-07-23 16:48:29,720 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl] > (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unsupported > data object (VOLUME, > org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@392f6f34), no > need to delete from object in store ref table > 2015-07-23 16:48:29,720 DEBUG [o.a.c.e.o.VolumeOrchestrator] > (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to > create Vol[55|vm=50|ROOT]:java.lang.Null
[jira] [Created] (CLOUDSTACK-8671) [VMWare] VM deployment from iso fails
Sanjeev N created CLOUDSTACK-8671: - Summary: [VMWare] VM deployment from iso fails Key: CLOUDSTACK-8671 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8671 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: ISO, VMware Affects Versions: 4.6.0 Environment: Latest build from ACS master with commit 2984acca83fff03c2ad8bdd28c097e797d4ce087 Hypervisor: VMWare Reporter: Sanjeev N Priority: Critical Failed to deploy vm from ISO Steps to reproduce: 1.Bring up CS in advanced zone with vmware cluster 2.Register one bootable iso 3.Try to deploy vm using that iso Result: == VM Deployment failed due to failure in creating volume: 2015-07-23 16:48:29,712 ERROR [c.c.s.r.VmwareStorageProcessor] (DirectAgent-196:ctx-18de08d8 10.81.28.111, job-322/job-323, cmd: CreateObjectCommand) create volume failed due to Exception: java.lang.NullPointerException Message: charsetName java.lang.NullPointerException: charsetName at java.io.InputStreamReader.(InputStreamReader.java:99) at com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486) at com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217) at com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) 2015-07-23 16:48:29,713 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Response Received: 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Processing: { Ans: , MgmtId: 187822473365406, via: 2, Ver: v1, Flags: 10, [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException: charsetName","wait":0}}] } 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Seq 2-8089027880710832600: Received: { Ans: , MgmtId: 187822473365406, via: 2, Ver: v1, Flags: 10, { CreateObjectAnswer } } 2015-07-23 16:48:29,720 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl] (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unsupported data object (VOLUME, org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@392f6f34), no need to delete from object in store ref table 2015-07-23 16:48:29,720 DEBUG [o.a.c.e.o.VolumeOrchestrator] (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to create Vol[55|vm=50|ROOT]:java.lang.NullPointerException: charsetName 2015-07-23 16:48:29,720 INFO [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to contact resource. com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is unreachable: Unable to create Vol[55|vm=50|ROOT]:java.lang.NullPointerException: charsetName at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:12
[jira] [Updated] (CLOUDSTACK-8669) [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-8669: -- Attachment: management-server.zip Attached management server log file. Please look for job-48 for the sequence of events in case of attach volume. > [VMWare] create volume failed due to Exception: > java.lang.NullPointerException Message: charsetName > --- > > Key: CLOUDSTACK-8669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.6.0 > Environment: Latest build from ACS master with commit > 2984acca83fff03c2ad8bdd28c097e797d4ce087 > Hypervisor: VMWares >Reporter: Sanjeev N >Priority: Critical > Attachments: management-server.zip > > > [VMWare] create volume failed due to Exception: > java.lang.NullPointerException Message: charsetName > Steps to reproduce: > > 1.Bring up CS in advanced zone with vmware cluster > 2.Deploy one guest vm using default cent os template > 3.Create one data disk with shared disk offering > 4.Attach the data disk to the vm created in step 2 > Result: > = > Attach volume failed with NPE: > 2015-07-23 16:06:58,103 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-64:ctx-6becb596 10.81.28.111, job-48/job-49, cmd: > CreateObjectCommand) create volume failed due to Exception: > java.lang.NullPointerException > Message: charsetName > java.lang.NullPointerException: charsetName > at java.io.InputStreamReader.(InputStreamReader.java:99) > at > com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486) > at > com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217) > at > com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2015-07-23 16:06:58,104 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Response Received: > 2015-07-23 16:06:58,104 DEBUG [c.c.a.t.Request] (DirectAgent-64:ctx-6becb596) > Seq 2-8089027880710832216: Processing: { Ans: , MgmtId: 187822473365406, > via: 2, Ver: v1, Flags: 10, > [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException: > charsetName","wait":0}}] } > 2015-07-23 16:06:58,105 DEBUG [c.c.a.t.Request] > (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Seq > 2-8089027880710832216: Received: { Ans: , MgmtId: 187822473365406, via: 2, > Ver: v1, Flags: 10, { CreateObjectAnswer } } > 2015-07-23 16:06:58,112 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl] > (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Unsupported > data object (VOLUME, > org.apache.cloudstack.
[jira] [Created] (CLOUDSTACK-8669) [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName
Sanjeev N created CLOUDSTACK-8669: - Summary: [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName Key: CLOUDSTACK-8669 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8669 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.6.0 Environment: Latest build from ACS master with commit 2984acca83fff03c2ad8bdd28c097e797d4ce087 Hypervisor: VMWares Reporter: Sanjeev N Priority: Critical [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName Steps to reproduce: 1.Bring up CS in advanced zone with vmware cluster 2.Deploy one guest vm using default cent os template 3.Create one data disk with shared disk offering 4.Attach the data disk to the vm created in step 2 Result: = Attach volume failed with NPE: 2015-07-23 16:06:58,103 ERROR [c.c.s.r.VmwareStorageProcessor] (DirectAgent-64:ctx-6becb596 10.81.28.111, job-48/job-49, cmd: CreateObjectCommand) create volume failed due to Exception: java.lang.NullPointerException Message: charsetName java.lang.NullPointerException: charsetName at java.io.InputStreamReader.(InputStreamReader.java:99) at com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486) at com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217) at com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) 2015-07-23 16:06:58,104 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Response Received: 2015-07-23 16:06:58,104 DEBUG [c.c.a.t.Request] (DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Processing: { Ans: , MgmtId: 187822473365406, via: 2, Ver: v1, Flags: 10, [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException: charsetName","wait":0}}] } 2015-07-23 16:06:58,105 DEBUG [c.c.a.t.Request] (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Seq 2-8089027880710832216: Received: { Ans: , MgmtId: 187822473365406, via: 2, Ver: v1, Flags: 10, { CreateObjectAnswer } } 2015-07-23 16:06:58,112 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl] (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Unsupported data object (VOLUME, org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@58dd2323), no need to delete from object in store ref table Please look for job-48 in the attached Management server log file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
Sanjeev N created CLOUDSTACK-8668: - Summary: VR does not start in basic zone since ip address are not being configured on it Key: CLOUDSTACK-8668 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from ACS master Reporter: Sanjeev N Priority: Blocker VR does not start in basic zone since ip address are not being configured on it Steps to reproduce: 1.Bring up CS in basic zone with xen server cluster 2.Try to deploy one guest vm using default cent os template Expected Result: == VR should come up as part of vm deployment and vm deployment should be successfull Actual Result: VR creation failed since the IP addresses not are getting assigned to VR's guest and link local interfaces. Observations: === 1.During vr boot time, cloud-early-config ran successfully and VR console output showed that ping to gateway was successful. However, after VR boot we don't see any ip addresses on the VRs guest and link local ip address. 2. If we run cloud-early-config manually from VR , ip addresses will be assigned and persistent. Impact: = VM deployments will fail since VR remains in stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8634) Make changes to test_security_group.py test suite to support EIP
Sanjeev N created CLOUDSTACK-8634: - Summary: Make changes to test_security_group.py test suite to support EIP Key: CLOUDSTACK-8634 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8634 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Make changes to test_security_group.py test suite to support EIP 1. In case of a basic zone with EIP/ELB capability vm will have two ip addresses one from public ip range and another one from guest ip range. vm creation method in base.py returns vm ip address which is part of guest ip range as the vm.ssh.ipaddress if we don't pass mode to it. So access to vms with that ip address would not be successful. Made changes to handle this 2.vm public address is associated with Netscaler. So even if we don't allow ping traffic in security groups applied to vm, ping will be successful. Skipping ping test in case the zone is enabled with EIP/ELB 3.Removing default rules from security groups except what is needed for that test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8617) Remove duplicate data from test_data.py file
Sanjeev N created CLOUDSTACK-8617: - Summary: Remove duplicate data from test_data.py file Key: CLOUDSTACK-8617 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8617 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: Sanjeev N Assignee: Sanjeev N -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8509) Skip snapshot tests for LXC
Sanjeev N created CLOUDSTACK-8509: - Summary: Skip snapshot tests for LXC Key: CLOUDSTACK-8509 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8509 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Volume snapshots are not supported on LXC. So skip snapshot related tests from test_assign_vm.py in regression -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8508) Install wget package inside LXC vm
Sanjeev N created CLOUDSTACK-8508: - Summary: Install wget package inside LXC vm Key: CLOUDSTACK-8508 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8508 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Install wget inside LXC vm. Default cent os template provided for LXC does not have wget package installed. Need script changes to test_vpc_vm_lifecycle.py in regression. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8507) fix httpd installation issues in test_vpc_network_pfrules.py test suite
Sanjeev N created CLOUDSTACK-8507: - Summary: fix httpd installation issues in test_vpc_network_pfrules.py test suite Key: CLOUDSTACK-8507 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8507 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N check_wget_from_vm() method in test_vpc_network_pfrules.py does not check whether httpd service is installed or not. Before starting the service install the package and start it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8504) Remove creating network with RVR by default
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N resolved CLOUDSTACK-8504. --- Resolution: Fixed > Remove creating network with RVR by default > --- > > Key: CLOUDSTACK-8504 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8504 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sanjeev N >Assignee: Sanjeev N > > test_egress_fw_rules.py tests in regression suite creates isolated networks > with RVR by default. > Remove RVR by default since creating network with RVR is taken care in the > tests wherever needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8504) Remove creating network with RVR by default
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-8504. - > Remove creating network with RVR by default > --- > > Key: CLOUDSTACK-8504 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8504 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sanjeev N >Assignee: Sanjeev N > > test_egress_fw_rules.py tests in regression suite creates isolated networks > with RVR by default. > Remove RVR by default since creating network with RVR is taken care in the > tests wherever needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8504) Remove creating network with RVR by default
Sanjeev N created CLOUDSTACK-8504: - Summary: Remove creating network with RVR by default Key: CLOUDSTACK-8504 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8504 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N test_egress_fw_rules.py tests in regression suite creates isolated networks with RVR by default. Remove RVR by default since creating network with RVR is taken care in the tests wherever needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8406) Don't allow creating shared network offering with userdata service and VR as the provider without DHCP service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-8406: -- Affects Version/s: 4.5.1 > Don't allow creating shared network offering with userdata service and VR as > the provider without DHCP service > -- > > Key: CLOUDSTACK-8406 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8406 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1 >Reporter: Sanjeev N > > Don't allow creating network offering with userdata service and VR as the > provider without DHCP service. > If we create shared network offering without DHCP service and with VR as the > userdata service provider then user vm will not be able to access the > userdata from VR since it gets the IP address from the external dhcp server. > VM and VR might be in a different network so VM would not be able to access > VR to fetch the userdata from VR. > So it would be better not to allow this combination while creating network > offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8406) Don't allow creating shared network offering with userdata service and VR as the provider without DHCP service
Sanjeev N created CLOUDSTACK-8406: - Summary: Don't allow creating shared network offering with userdata service and VR as the provider without DHCP service Key: CLOUDSTACK-8406 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8406 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Sanjeev N Don't allow creating network offering with userdata service and VR as the provider without DHCP service. If we create shared network offering without DHCP service and with VR as the userdata service provider then user vm will not be able to access the userdata from VR since it gets the IP address from the external dhcp server. VM and VR might be in a different network so VM would not be able to access VR to fetch the userdata from VR. So it would be better not to allow this combination while creating network offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7799) [Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7799: -- Attachment: cloud.dmp management-server.rar Attached MS log file cloud db dump. > [Accounts] Account deletion failed to remove all the entities related to it > in case of failure in deleting one entity > - > > Key: CLOUDSTACK-7799 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7799 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# > cloudstack-sccs > 385c4f673dfbd1fd326e539625e2c06db4cdc27d >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > Attachments: cloud.dmp, management-server.rar > > > [Critical][Accounts] Account deletion failed to remove all the entities > related to it in case of failure in deleting one entity > Steps to Reproduce: > > 1.Bring up CS in advanced zone with one vmware cluster > 2.Create a user account > 3.With the user account deploy few (4-5) vms > 4.Take snapshots on all of the vms root disks > 5.Deploy another vm and simulate snapshot failure operation(In my case I > tried snapshot operation with quiesce option set to true) so that snapshot > will be in "Allocated" state > 6.Delete this user account > Expected Behavior: > == > Whatever may the state of the snapshot account deletion shall clean all the > objects related that account > Actual Behavior: > = > Account deletion started deleting snapshots. Since one of the snapshots is in > Allocated state it failed to delete that snapshot and the Account clean up > job ended there. So vms and networks related to the accounts are still there > but the account was deleted. > Here is the log snippet: > = > 2014-10-28 15:16:38,822 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-1c16bc72) ===START=== 10.252.193.8 -- GET > command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367 > 2014-10-28 15:16:38,974 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) submit async job-53, details: > AsyncJobVO {id:53, userId: 2, accountId: 2, instanceType: Account, > instanceId: null, cmd: > org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: > {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-10-28 15:16:38,978 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) ===END=== 10.252.193.8 -- GET > command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367 > 2014-10-28 15:16:38,996 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (API-Job-Executor-30:ctx-0b9151e2 job-53) Add job-53 into job monitoring > 2014-10-28 15:16:38,996 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (API-Job-Executor-30:ctx-0b9151e2 job-53) Executing AsyncJobVO {id:53, > userId: 2, accountId: 2, instanceType: Account, instanceId: null, cmd: > org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: > {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-10-28 15:16:39,153 DEBUG [c.c.u.AccountManagerImpl] > (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Removed account 4 > 2014-10-28 15:16:39,287 DEBUG [c.c.a.t.Request] > (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Seq > 4-4574812796478292948: Sending { Cmd , MgmtId: 6637838401571, via: > 4(s-2-QA), Ver: v1, Flags: 1001
[jira] [Updated] (CLOUDSTACK-7799) [Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7799: -- Summary: [Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity (was: [Critical][Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity) > [Accounts] Account deletion failed to remove all the entities related to it > in case of failure in deleting one entity > - > > Key: CLOUDSTACK-7799 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7799 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# > cloudstack-sccs > 385c4f673dfbd1fd326e539625e2c06db4cdc27d >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > > [Critical][Accounts] Account deletion failed to remove all the entities > related to it in case of failure in deleting one entity > Steps to Reproduce: > > 1.Bring up CS in advanced zone with one vmware cluster > 2.Create a user account > 3.With the user account deploy few (4-5) vms > 4.Take snapshots on all of the vms root disks > 5.Deploy another vm and simulate snapshot failure operation(In my case I > tried snapshot operation with quiesce option set to true) so that snapshot > will be in "Allocated" state > 6.Delete this user account > Expected Behavior: > == > Whatever may the state of the snapshot account deletion shall clean all the > objects related that account > Actual Behavior: > = > Account deletion started deleting snapshots. Since one of the snapshots is in > Allocated state it failed to delete that snapshot and the Account clean up > job ended there. So vms and networks related to the accounts are still there > but the account was deleted. > Here is the log snippet: > = > 2014-10-28 15:16:38,822 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-1c16bc72) ===START=== 10.252.193.8 -- GET > command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367 > 2014-10-28 15:16:38,974 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) submit async job-53, details: > AsyncJobVO {id:53, userId: 2, accountId: 2, instanceType: Account, > instanceId: null, cmd: > org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: > {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-10-28 15:16:38,978 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) ===END=== 10.252.193.8 -- GET > command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367 > 2014-10-28 15:16:38,996 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (API-Job-Executor-30:ctx-0b9151e2 job-53) Add job-53 into job monitoring > 2014-10-28 15:16:38,996 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (API-Job-Executor-30:ctx-0b9151e2 job-53) Executing AsyncJobVO {id:53, > userId: 2, accountId: 2, instanceType: Account, instanceId: null, cmd: > org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: > {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-10-28 15:16:39,153 DEBUG [c.c.u.AccountManagerImpl] > (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Removed account 4 > 2014-10-28 15:16:39,287 DEBUG [c.c.a.t.Request] > (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24
[jira] [Created] (CLOUDSTACK-7799) [Critical][Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity
Sanjeev N created CLOUDSTACK-7799: - Summary: [Critical][Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity Key: CLOUDSTACK-7799 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7799 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# cloudstack-sccs 385c4f673dfbd1fd326e539625e2c06db4cdc27d Reporter: Sanjeev N Priority: Critical Fix For: 4.5.0 [Critical][Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity Steps to Reproduce: 1.Bring up CS in advanced zone with one vmware cluster 2.Create a user account 3.With the user account deploy few (4-5) vms 4.Take snapshots on all of the vms root disks 5.Deploy another vm and simulate snapshot failure operation(In my case I tried snapshot operation with quiesce option set to true) so that snapshot will be in "Allocated" state 6.Delete this user account Expected Behavior: == Whatever may the state of the snapshot account deletion shall clean all the objects related that account Actual Behavior: = Account deletion started deleting snapshots. Since one of the snapshots is in Allocated state it failed to delete that snapshot and the Account clean up job ended there. So vms and networks related to the accounts are still there but the account was deleted. Here is the log snippet: = 2014-10-28 15:16:38,822 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-1c16bc72) ===START=== 10.252.193.8 -- GET command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367 2014-10-28 15:16:38,974 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) submit async job-53, details: AsyncJobVO {id:53, userId: 2, accountId: 2, instanceType: Account, instanceId: null, cmd: org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-10-28 15:16:38,978 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) ===END=== 10.252.193.8 -- GET command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367 2014-10-28 15:16:38,996 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-30:ctx-0b9151e2 job-53) Add job-53 into job monitoring 2014-10-28 15:16:38,996 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-30:ctx-0b9151e2 job-53) Executing AsyncJobVO {id:53, userId: 2, accountId: 2, instanceType: Account, instanceId: null, cmd: org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-10-28 15:16:39,153 DEBUG [c.c.u.AccountManagerImpl] (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Removed account 4 2014-10-28 15:16:39,287 DEBUG [c.c.a.t.Request] (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Seq 4-4574812796478292948: Sending { Cmd , MgmtId: 6637838401571, via: 4(s-2-QA), Ver: v1, Flags: 100111, [{"com.cloud.agent.api.DeleteSnapshotsDirCommand":{"store":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/sanjeev/sec_45","_role":"Image"}},"directory":"snapshots/4/5","wait":0}}] } 2014-10-28 15:16:40,556 DEBUG [c.c.a.t.Request] (AgentManager-Handler-12:null) Seq 4-4574812796478292948: Processing: { Ans: , MgmtId: 6637838401571, via: 4, Ver: v1, Flags: 110, [{"com.cloud.agent.api.Answer":{"result":true,"wait":0}}] } 2014-10-28 15:16:40,556 DEBUG [c.c.a.t.Request] (API-
[jira] [Commented] (CLOUDSTACK-7793) [Snapshots]Create Snaphot with "quiesce" option set to true fails with "InvalidParameterValueException: can't handle quiescevm equal true for volume snapshot"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185060#comment-14185060 ] Sanjeev N commented on CLOUDSTACK-7793: --- Snapshot operation failed. However, there was a snapshot entry in the cloud db with state as "Allocated" mysql> select * from snapshots where id=13\G *** 1. row *** id: 13 data_center_id: 3 account_id: 4 domain_id: 1 volume_id: 16 disk_offering_id: 1 status: Allocated path: NULL name: t1_ROOT-14_20141027124059 uuid: 7668446f-667a-4398-a623-23d87067a9f4 snapshot_type: 0 type_description: MANUAL size: 2147483648 created: 2014-10-27 12:40:59 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL 1 row in set (0.00 sec) > [Snapshots]Create Snaphot with "quiesce" option set to true fails with > "InvalidParameterValueException: can't handle quiescevm equal true for volume > snapshot" > -- > > Key: CLOUDSTACK-7793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7793 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.5.0 > Environment: Latest build from 4.5 >Reporter: Sanjeev N >Priority: Critical > Attachments: management-server.rar > > > [Snapshots]Create Snaphot with "quiesce" option set to true fails with > "InvalidParameterValueException: can't handle quiescevm equal true for volume > snapshot" > Steps to Reproduce: > === > 1.Bring up CS in advanced zone with vmware cluster > 2.Deploy guest vm using default cent os template > 3.Try to create snapshot on root disk with "quiesce" option set to true: > http://10.147.38.153:8096/client/api?command=createSnapshot&volumeid=998fd155-7d60-4426-a91c-0a2f1d598021&account=test&domainid=1&quiescevm=true > Expected Result: > > quiescevm is implemented only for NetApp Plugin with VMWare. If this is not > implemented the API should simply ignore the option > Actual Result: > == > API didn't ignore this option. Instead it failed with following exception: > 2014-10-27 18:10:59,861 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (ApiServer-7:ctx-2f20ab36 ctx-a7e2aa42) submit async job-147, details: > AsyncJobVO {id:147, userId: 1, accountId: 1, instanceType: Snapshot, > instanceId: 13, cmd: > org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: > {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-10-27 18:10:59,880 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (API-Job-Executor-44:ctx-15935b7b job-147) Add job-147 into job monitoring > 2014-10-27 18:10:59,881 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (API-Job-Executor-44:ctx-15935b7b job-147) Executing AsyncJobVO {id:147, > userId: 1, accountId: 1, instanceType: Snapshot, instanceId: 13, cmd: > org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: > {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-10-27 18:10:59,955 INFO [o.a.c.a.c.u.s.CreateSnapshotCmd] > (API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) VOLSS: > createSnapshotCmd starts:1414413659955 > 2014-10-27 18:10:59,978 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (API-Job-Exec
[jira] [Updated] (CLOUDSTACK-7793) [Snapshots]Create Snaphot with "quiesce" option set to true fails with "InvalidParameterValueException: can't handle quiescevm equal true for volume snapshot"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7793: -- Attachment: management-server.rar Attached MS log file > [Snapshots]Create Snaphot with "quiesce" option set to true fails with > "InvalidParameterValueException: can't handle quiescevm equal true for volume > snapshot" > -- > > Key: CLOUDSTACK-7793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7793 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.5.0 > Environment: Latest build from 4.5 >Reporter: Sanjeev N >Priority: Critical > Attachments: management-server.rar > > > [Snapshots]Create Snaphot with "quiesce" option set to true fails with > "InvalidParameterValueException: can't handle quiescevm equal true for volume > snapshot" > Steps to Reproduce: > === > 1.Bring up CS in advanced zone with vmware cluster > 2.Deploy guest vm using default cent os template > 3.Try to create snapshot on root disk with "quiesce" option set to true: > http://10.147.38.153:8096/client/api?command=createSnapshot&volumeid=998fd155-7d60-4426-a91c-0a2f1d598021&account=test&domainid=1&quiescevm=true > Expected Result: > > quiescevm is implemented only for NetApp Plugin with VMWare. If this is not > implemented the API should simply ignore the option > Actual Result: > == > API didn't ignore this option. Instead it failed with following exception: > 2014-10-27 18:10:59,861 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (ApiServer-7:ctx-2f20ab36 ctx-a7e2aa42) submit async job-147, details: > AsyncJobVO {id:147, userId: 1, accountId: 1, instanceType: Snapshot, > instanceId: 13, cmd: > org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: > {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-10-27 18:10:59,880 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (API-Job-Executor-44:ctx-15935b7b job-147) Add job-147 into job monitoring > 2014-10-27 18:10:59,881 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (API-Job-Executor-44:ctx-15935b7b job-147) Executing AsyncJobVO {id:147, > userId: 1, accountId: 1, instanceType: Snapshot, instanceId: 13, cmd: > org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: > {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-10-27 18:10:59,955 INFO [o.a.c.a.c.u.s.CreateSnapshotCmd] > (API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) VOLSS: > createSnapshotCmd starts:1414413659955 > 2014-10-27 18:10:59,978 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) Sync job-148 > execution on object VmWorkJobQueue.14 > 2014-10-27 18:11:00,456 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f35c279c) Found 2 routers to update status. > 2014-10-27 18:11:00,458 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f35c279c) Found 0 networks to update RvR status. > 2014-10-27 18:11:00,526 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (AsyncJobMgr-Heartbeat-1:ctx-473efbed) Execute sync-queue item: > SyncQueueItemVO {id:52, queueId: 34, contentType: AsyncJob, contentId: 148, > lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null, > created: Mon Oct 27 18:10:59 IST 2014} > 2014-10-27 18:11:00,529 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (Asyn
[jira] [Created] (CLOUDSTACK-7793) [Snapshots]Create Snaphot with "quiesce" option set to true fails with "InvalidParameterValueException: can't handle quiescevm equal true for volume snapshot"
Sanjeev N created CLOUDSTACK-7793: - Summary: [Snapshots]Create Snaphot with "quiesce" option set to true fails with "InvalidParameterValueException: can't handle quiescevm equal true for volume snapshot" Key: CLOUDSTACK-7793 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7793 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.5.0 Environment: Latest build from 4.5 Reporter: Sanjeev N Priority: Critical [Snapshots]Create Snaphot with "quiesce" option set to true fails with "InvalidParameterValueException: can't handle quiescevm equal true for volume snapshot" Steps to Reproduce: === 1.Bring up CS in advanced zone with vmware cluster 2.Deploy guest vm using default cent os template 3.Try to create snapshot on root disk with "quiesce" option set to true: http://10.147.38.153:8096/client/api?command=createSnapshot&volumeid=998fd155-7d60-4426-a91c-0a2f1d598021&account=test&domainid=1&quiescevm=true Expected Result: quiescevm is implemented only for NetApp Plugin with VMWare. If this is not implemented the API should simply ignore the option Actual Result: == API didn't ignore this option. Instead it failed with following exception: 2014-10-27 18:10:59,861 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (ApiServer-7:ctx-2f20ab36 ctx-a7e2aa42) submit async job-147, details: AsyncJobVO {id:147, userId: 1, accountId: 1, instanceType: Snapshot, instanceId: 13, cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-10-27 18:10:59,880 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-44:ctx-15935b7b job-147) Add job-147 into job monitoring 2014-10-27 18:10:59,881 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-44:ctx-15935b7b job-147) Executing AsyncJobVO {id:147, userId: 1, accountId: 1, instanceType: Snapshot, instanceId: 13, cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-10-27 18:10:59,955 INFO [o.a.c.a.c.u.s.CreateSnapshotCmd] (API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) VOLSS: createSnapshotCmd starts:1414413659955 2014-10-27 18:10:59,978 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) Sync job-148 execution on object VmWorkJobQueue.14 2014-10-27 18:11:00,456 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-f35c279c) Found 2 routers to update status. 2014-10-27 18:11:00,458 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-f35c279c) Found 0 networks to update RvR status. 2014-10-27 18:11:00,526 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-473efbed) Execute sync-queue item: SyncQueueItemVO {id:52, queueId: 34, contentType: AsyncJob, contentId: 148, lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null, created: Mon Oct 27 18:10:59 IST 2014} 2014-10-27 18:11:00,529 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-473efbed) Schedule queued job-148 2014-10-27 18:11:00,561 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-8dfe1318) Begin cleanup expired async-jobs 2014-10-27 18:11:00,562 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-31:ctx-ee1a398a job-147/job-148) Add job-148 into job monitoring 2014-10-27 18:11:00,563 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Work-Job-Executor-31:ctx-ee1a398a job-147/job-148) Executing AsyncJobVO {id:148, userId:
[jira] [Updated] (CLOUDSTACK-7791) [Snapshots] State transition in snapshot objects when snapshot is taken on Root/Data disk is not proper
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7791: -- Attachment: management-server.rar > [Snapshots] State transition in snapshot objects when snapshot is taken on > Root/Data disk is not proper > --- > > Key: CLOUDSTACK-7791 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7791 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, VMware >Affects Versions: 4.5.0 > Environment: Latest build from 4.5 >Reporter: Sanjeev N > Labels: snapshots > Fix For: 4.5.0 > > Attachments: management-server.rar > > > [Snapshots] State transition in snapshot objects when snapshot is taken on > Root/Data disk is not proper > Steps to Reproduce: > > 1.Bring up CS with latest build using vmware cluster > 2.Deploy one guest vm using default cent os template > 3.Create a snapshot on the root disk of the vm > Expected Behavior: > == > Snapshot operation should go through the following states: > Creating->CreatedOnPrimary->BackingUp->BackedUp > Actual Result: > === > We only see two states: Backingup->Backedup > As and when the snapshot is triggered it goes to backing up state and remains > in that state until the snapshot is copied to secondary storage and then goes > to Backedup state. > This is easy to reproduce. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7791) [Snapshots] State transition in snapshot objects when snapshot is taken on Root/Data disk is not proper
Sanjeev N created CLOUDSTACK-7791: - Summary: [Snapshots] State transition in snapshot objects when snapshot is taken on Root/Data disk is not proper Key: CLOUDSTACK-7791 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7791 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Snapshot, VMware Affects Versions: 4.5.0 Environment: Latest build from 4.5 Reporter: Sanjeev N Fix For: 4.5.0 [Snapshots] State transition in snapshot objects when snapshot is taken on Root/Data disk is not proper Steps to Reproduce: 1.Bring up CS with latest build using vmware cluster 2.Deploy one guest vm using default cent os template 3.Create a snapshot on the root disk of the vm Expected Behavior: == Snapshot operation should go through the following states: Creating->CreatedOnPrimary->BackingUp->BackedUp Actual Result: === We only see two states: Backingup->Backedup As and when the snapshot is triggered it goes to backing up state and remains in that state until the snapshot is copied to secondary storage and then goes to Backedup state. This is easy to reproduce. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7767) [Events] All events are not generated for snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7767: -- Attachment: cloud.dmp management-server.rar Attached MS log and cloud db dump. > [Events] All events are not generated for snapshot creation > --- > > Key: CLOUDSTACK-7767 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7767 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.5.0 > Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# > cloudstack-sccs > 562c89544e80dcd61ae5fd179eb8546de2598b33 >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > Attachments: cloud.dmp, management-server.rar > > > [Events] All events are not generated for snapshot creation > Steps to Reproduce: > === > 1.Bring up CS with latest build from 4.5 > 2.Deploy a vm using cent os template > 3.Take a snapshot on the root disk of the vm > 4.Verify the cloud.events table for the snapshot events > We could see events with states "created,sheduled,started and completed" for > vm,volume and template whereas there is only one event with state "scheduled" > for snapshot creation. > So by looking at the events user will not be able to find out whether the > snaphot creation is completed of not. > Following is the DB snippet: > mysql> select id,uuid,type,state,description from event where type in > ("SNAPSHOT.CREATE","VM.CREATE","VOLUME.CREATE","TEMPLATE.CREATE"); > +-+--+-+---++ > | id | uuid | type| state | > description > | > +-+--+-+---++ > | 189 | 1f48cbef-648e-4728-9eb1-5178bea3b4fd | SNAPSHOT.CREATE | Scheduled | > creating snapshot for volume: 10 > | > | 207 | 9162ed93-bd6c-4e78-8f4a-1836859f5009 | SNAPSHOT.CREATE | Scheduled | > creating snapshot for volume: 15 > | > | 208 | 261b95a7-0a4d-45cd-9922-3cde8640ab02 | SNAPSHOT.CREATE | Scheduled | > creating snapshot for volume: 15 > | > | 212 | e80e1383-944b-4ac9-bc86-70511de86c94 | SNAPSHOT.CREATE | Scheduled | > creating snapshot for volume: 15 > | > | 168 | 518e4ae7-e506-4b93-a8b5-696777b91706 | TEMPLATE.CREATE | Completed | > Successfully completed creating template. Id: 202 name: cent53 > | > | 193 | 3d20409e-a9e5-438a-9a00-2deb23ee87fe | TEMPLATE.CREATE | Created | > Successfully created entity for creating template > | > | 194 | 528f823e-b817-4b9a-8935-2f57ac5a4c9b | TEMPLATE.CREATE | Scheduled | > creating template: fromSnapRoot10 > | > | 195 | 9ab1d914-9f30-4a3d-8070-1fdce6827f6d | TEMPLATE.CREATE | Started | > creating template. Template Id: 203 from snapshot Id: 1 > | > | 196 | d2676d55-84c8-4486-9aca-0f3eda74a4a7 | TEMPLATE.CREATE | Completed | > Successfully completed creating template. Template Id: 203 from snapshot Id: > 1 | > | 154 | 3b9207d6-d120-4762-b9e3-423f849870d6 | VM.CREATE | Created | > Successfully created entity for deploying Vm. Vm Id: 8 > | > | 155 | 7c47beb2-e105-478f-9575-e3ab1b2709ec | VM.CREATE | Scheduled | > starting Vm. Vm Id: 8 > | > | 156 | 27718b57-b679-412b-b983-0f9cf7757930 | VM.CREATE | Started | > starting Vm. Vm Id: 8 > | > | 159 | 6b5bece5-bfab-41c0-906e-8fbec2ddd2bf | VM.CREATE | Completed | > Successfully completed starting Vm. Vm Id: 8 > | > | 170 | 66412dc3-fc03-4a2d-b796-807bd6ec096f | VM.CREATE | Created | > Successfully created entity for deploying Vm. Vm Id: 10 > | > | 171 | a6c91812-9218-451c-a801-60652089ba7b | VM.CREATE | Scheduled | > starting Vm. Vm Id: 10 > | > | 172 | 3f0cd706-ac3d-48a5-b4f9-a51d96e95dca | VM.CREATE | Started | > starting Vm. Vm Id: 10 > | > | 175 | dde1bff2-5f68-43a9-a090-10718c3a14f
[jira] [Created] (CLOUDSTACK-7767) [Events] All events are not generated for snapshot creation
Sanjeev N created CLOUDSTACK-7767: - Summary: [Events] All events are not generated for snapshot creation Key: CLOUDSTACK-7767 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7767 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.5.0 Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# cloudstack-sccs 562c89544e80dcd61ae5fd179eb8546de2598b33 Reporter: Sanjeev N Priority: Critical Fix For: 4.5.0 [Events] All events are not generated for snapshot creation Steps to Reproduce: === 1.Bring up CS with latest build from 4.5 2.Deploy a vm using cent os template 3.Take a snapshot on the root disk of the vm 4.Verify the cloud.events table for the snapshot events We could see events with states "created,sheduled,started and completed" for vm,volume and template whereas there is only one event with state "scheduled" for snapshot creation. So by looking at the events user will not be able to find out whether the snaphot creation is completed of not. Following is the DB snippet: mysql> select id,uuid,type,state,description from event where type in ("SNAPSHOT.CREATE","VM.CREATE","VOLUME.CREATE","TEMPLATE.CREATE"); +-+--+-+---++ | id | uuid | type| state | description| +-+--+-+---++ | 189 | 1f48cbef-648e-4728-9eb1-5178bea3b4fd | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 10 | | 207 | 9162ed93-bd6c-4e78-8f4a-1836859f5009 | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 15 | | 208 | 261b95a7-0a4d-45cd-9922-3cde8640ab02 | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 15 | | 212 | e80e1383-944b-4ac9-bc86-70511de86c94 | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 15 | | 168 | 518e4ae7-e506-4b93-a8b5-696777b91706 | TEMPLATE.CREATE | Completed | Successfully completed creating template. Id: 202 name: cent53 | | 193 | 3d20409e-a9e5-438a-9a00-2deb23ee87fe | TEMPLATE.CREATE | Created | Successfully created entity for creating template | | 194 | 528f823e-b817-4b9a-8935-2f57ac5a4c9b | TEMPLATE.CREATE | Scheduled | creating template: fromSnapRoot10 | | 195 | 9ab1d914-9f30-4a3d-8070-1fdce6827f6d | TEMPLATE.CREATE | Started | creating template. Template Id: 203 from snapshot Id: 1| | 196 | d2676d55-84c8-4486-9aca-0f3eda74a4a7 | TEMPLATE.CREATE | Completed | Successfully completed creating template. Template Id: 203 from snapshot Id: 1 | | 154 | 3b9207d6-d120-4762-b9e3-423f849870d6 | VM.CREATE | Created | Successfully created entity for deploying Vm. Vm Id: 8 | | 155 | 7c47beb2-e105-478f-9575-e3ab1b2709ec | VM.CREATE | Scheduled | starting Vm. Vm Id: 8 | | 156 | 27718b57-b679-412b-b983-0f9cf7757930 | VM.CREATE | Started | starting Vm. Vm Id: 8 | | 159 | 6b5bece5-bfab-41c0-906e-8fbec2ddd2bf | VM.CREATE | Completed | Successfully completed starting Vm. Vm Id: 8 | | 170 | 66412dc3-fc03-4a2d-b796-807bd6ec096f | VM.CREATE | Created | Successfully created entity for deploying Vm. Vm Id: 10| | 171 | a6c91812-9218-451c-a801-60652089ba7b | VM.CREATE | Scheduled | starting Vm. Vm Id: 10 | | 172 | 3f0cd706-ac3d-48a5-b4f9-a51d96e95dca | VM.CREATE | Started | starting Vm. Vm Id: 10 | | 175 | dde1bff2-5f68-43a9-a090-10718c3a14f3 | VM.CREATE | Completed | Successfully completed starting Vm. Vm Id: 10 | | 180 | 9102d743-3b96-4611-93ab-1fa722170e90 | VM.CREATE | Created | Successfully created entity for deploying Vm. Vm Id: 12| | 181 | fd01696d-4f6d-453c-a43c-81ef7e796579 | VM.CREATE | Scheduled | starting Vm. Vm Id: 12 | | 182 | 3173d69e-b39e-450b-abcb-e3568e86b647 | VM.CREATE | S
[jira] [Updated] (CLOUDSTACK-7759) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7759: -- Attachment: management-server.rar Attached MS log > [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start > > > Key: CLOUDSTACK-7759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Latest build from 4.5 >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > Attachments: management-server.rar > > > [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start > Steps to Reproduce: > === > 1.Create CS 4.5 setup using vmware cluster > 2.Wait for the system vms to come up > Observations: > == > During system vms start up we see lot of > javax.xml.ws.soap.SOAPFaultExceptions in the MS log file > 2014-10-21 21:17:28,104 WARN [c.c.h.v.m.HttpNfcLeaseMO] (Thread-29:null) > Unexpected exception > javax.xml.ws.soap.SOAPFaultException: A specified parameter was not correct. > percent > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129) > at $Proxy413.httpNfcLeaseProgress(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO.updateLeaseProgress(HttpNfcLeaseMO.java:104) > at > com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO$ProgressReporter.run(HttpNfcLeaseMO.java:163) > But these exceptions disappear when the system vms are up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7759) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start
Sanjeev N created CLOUDSTACK-7759: - Summary: [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Key: CLOUDSTACK-7759 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7759 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Latest build from 4.5 Reporter: Sanjeev N Priority: Critical Fix For: 4.5.0 [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Steps to Reproduce: === 1.Create CS 4.5 setup using vmware cluster 2.Wait for the system vms to come up Observations: == During system vms start up we see lot of javax.xml.ws.soap.SOAPFaultExceptions in the MS log file 2014-10-21 21:17:28,104 WARN [c.c.h.v.m.HttpNfcLeaseMO] (Thread-29:null) Unexpected exception javax.xml.ws.soap.SOAPFaultException: A specified parameter was not correct. percent at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129) at $Proxy413.httpNfcLeaseProgress(Unknown Source) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO.updateLeaseProgress(HttpNfcLeaseMO.java:104) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO$ProgressReporter.run(HttpNfcLeaseMO.java:163) But these exceptions disappear when the system vms are up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7496) [Automation][HyperV] Unable to ssh into the System VMs after Reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N resolved CLOUDSTACK-7496. --- Resolution: Fixed commit 5bddebb8fc6eb85753a030f1d71fe2303969325b Author: sanjeev Date: Mon Sep 22 16:27:44 2014 +0530 In case of Hyper-v ssvm/cpvm reboot takes time so made changes to handle this > [Automation][HyperV] Unable to ssh into the System VMs after Reboot > --- > > Key: CLOUDSTACK-7496 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7496 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Sowmya Krishnan >Priority: Critical > Fix For: 4.5.0 > > Attachments: runinfo.zip > > > I attached the Automation client log information to this bug report. It shows > that the System VMs could not be accessed via ssh after reboot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146109#comment-14146109 ] Sanjeev N commented on CLOUDSTACK-7621: --- Observed this even on the simulator environment. > Database schema not getting upgraded > > > Key: CLOUDSTACK-7621 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.log > > > After installing management server , the process is stuck at database schema > update. The update doesn't progress ahead from 4.0.0 > mysql> select * from version; > ++-+-+--+ > | id | version | updated | step | > ++-+-+--+ > | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | > ++-+-+--+ > 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7552) [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - TestCreateVolume.test_01_create_volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N resolved CLOUDSTACK-7552. --- Resolution: Fixed > [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - > TestCreateVolume.test_01_create_volume > --- > > Key: CLOUDSTACK-7552 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7552 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > > Test Case at > *integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume* > failed on HyperV due to querying for wrong disk on the Guest VM. Instead of > */dev/sdb*, Query has been made for */dev/sda* -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7552) [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - TestCreateVolume.test_01_create_volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7552: -- Status: Reviewable (was: In Progress) > [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - > TestCreateVolume.test_01_create_volume > --- > > Key: CLOUDSTACK-7552 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7552 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > > Test Case at > *integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume* > failed on HyperV due to querying for wrong disk on the Guest VM. Instead of > */dev/sdb*, Query has been made for */dev/sda* -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7552) [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - TestCreateVolume.test_01_create_volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7552: -- Assignee: Sanjeev N (was: Chandan Purushothama) > [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - > TestCreateVolume.test_01_create_volume > --- > > Key: CLOUDSTACK-7552 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7552 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > > Test Case at > *integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume* > failed on HyperV due to querying for wrong disk on the Guest VM. Instead of > */dev/sdb*, Query has been made for */dev/sda* -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7541) Volume gets created with the size mentioned in the custom disk offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7541: -- Attachment: cloud.dmp management-server.rar Attache MS log file and cloud db dump. > Volume gets created with the size mentioned in the custom disk offering > > > Key: CLOUDSTACK-7541 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7541 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.5.0 > Environment: latest build from 4.5 with commit > 932ea253eb8c65821503ab9db301073cdb2a413e >Reporter: Sanjeev N >Priority: Critical > Attachments: cloud.dmp, management-server.rar > > > Volume gets created with the size mentioned in the custom disk offering > Steps to reproduce: > == > 1.Bring up cs with latest build > 2.Create custom disk offering with disk size say 2 > 3.Create data disk using this offering and provide disk size as 1 while > creating data disk > Expected Result: > == > Since the disk offering is of type custom , volume should be created with > size given during volume creation instead of taking it from the disk offering. > If the disk offering is custom then the volume creation must ignore the size > given in the offering and should create volume with size provide while > creating volume. > Actual Result: > === > Disk got created with size mentioned in disk offering rather than the size > given during volume creation time. > Observations: > === > http://10.147.38.153:8096/client/api?command=createDiskOffering&isMirrored=false&name=custom&displaytext=custom&storageType=shared&cacheMode=none&provisioningType=thin&customized=true&disksize=2 > { "creatediskofferingresponse" : { "diskoffering" : > {"id":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","name":"custom","displaytext":"custom","disksize":2,"created":"2014-09-12T23:33:24+0530","iscustomized":true,"storagetype":"shared","provisioningtype":"thin","displayoffering":true} > } } > http://10.147.38.153:8080/client/api?command=createVolume&response=json&sessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3D&name=custom&zoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dd&diskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873b&size=1&_=1410525928417 > { "queryasyncjobresultresponse" : > {"accountid":"638d4e82-341f-11e4-a4c9-06097e23","userid":"638d5ddc-341f-11e4-a4c9-06097e23","cmd":"org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"volume":{"id":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","name":"custom","zoneid":"2c67c83e-b8c3-42d0-a37b-b37287ac84dd","zonename":"zone1","type":"DATADISK","provisioningtype":"thin","size":2147483648,"created":"2014-09-12T23:34:32+0530","state":"Allocated","account":"admin","domainid":"2caca782-341f-11e4-a4c9-06097e23","domain":"ROOT","storagetype":"shared","hypervisor":"None","diskofferingid":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","diskofferingname":"custom","diskofferingdisplaytext":"custom","destroyed":false,"isextractable":true,"tags":[],"displayvolume":true,"quiescevm":false,"jobid":"edf1a066-63b0-400b-bf15-4f77bf659206","jobstatus":0}},"jobinstancetype":"Volume","jobinstanceid":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","created":"2014-09-12T23:34:32+0530","jobid":"edf1a066-63b0-400b-bf15-4f77bf659206"} > } -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7541) Volume gets created with the size mentioned in the custom disk offering
Sanjeev N created CLOUDSTACK-7541: - Summary: Volume gets created with the size mentioned in the custom disk offering Key: CLOUDSTACK-7541 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7541 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.5.0 Environment: latest build from 4.5 with commit 932ea253eb8c65821503ab9db301073cdb2a413e Reporter: Sanjeev N Priority: Critical Volume gets created with the size mentioned in the custom disk offering Steps to reproduce: == 1.Bring up cs with latest build 2.Create custom disk offering with disk size say 2 3.Create data disk using this offering and provide disk size as 1 while creating data disk Expected Result: == Since the disk offering is of type custom , volume should be created with size given during volume creation instead of taking it from the disk offering. If the disk offering is custom then the volume creation must ignore the size given in the offering and should create volume with size provide while creating volume. Actual Result: === Disk got created with size mentioned in disk offering rather than the size given during volume creation time. Observations: === http://10.147.38.153:8096/client/api?command=createDiskOffering&isMirrored=false&name=custom&displaytext=custom&storageType=shared&cacheMode=none&provisioningType=thin&customized=true&disksize=2 { "creatediskofferingresponse" : { "diskoffering" : {"id":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","name":"custom","displaytext":"custom","disksize":2,"created":"2014-09-12T23:33:24+0530","iscustomized":true,"storagetype":"shared","provisioningtype":"thin","displayoffering":true} } } http://10.147.38.153:8080/client/api?command=createVolume&response=json&sessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3D&name=custom&zoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dd&diskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873b&size=1&_=1410525928417 { "queryasyncjobresultresponse" : {"accountid":"638d4e82-341f-11e4-a4c9-06097e23","userid":"638d5ddc-341f-11e4-a4c9-06097e23","cmd":"org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"volume":{"id":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","name":"custom","zoneid":"2c67c83e-b8c3-42d0-a37b-b37287ac84dd","zonename":"zone1","type":"DATADISK","provisioningtype":"thin","size":2147483648,"created":"2014-09-12T23:34:32+0530","state":"Allocated","account":"admin","domainid":"2caca782-341f-11e4-a4c9-06097e23","domain":"ROOT","storagetype":"shared","hypervisor":"None","diskofferingid":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","diskofferingname":"custom","diskofferingdisplaytext":"custom","destroyed":false,"isextractable":true,"tags":[],"displayvolume":true,"quiescevm":false,"jobid":"edf1a066-63b0-400b-bf15-4f77bf659206","jobstatus":0}},"jobinstancetype":"Volume","jobinstanceid":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","created":"2014-09-12T23:34:32+0530","jobid":"edf1a066-63b0-400b-bf15-4f77bf659206"} } -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7535) [Automation][HyperV] SSH Client tries to connect to the private Guest IP Address instead of Public IP Address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131155#comment-14131155 ] Sanjeev N commented on CLOUDSTACK-7535: --- Hi Chandan, Script is trying to ssh to the public IP address but inside the script while printing the error message in case of ssh failure it is using VM's nic ip address instead of ssh ip address . try: ssh_client = self.virtual_machine.get_ssh_client() except Exception as e: self.fail("SSH failed for virtual machine: %s - %s" % (self.virtual_machine.ipaddress, e)) In self.fail method vm ipaddress is being used insted of nat ip address. > [Automation][HyperV] SSH Client tries to connect to the private Guest IP > Address instead of Public IP Address > - > > Key: CLOUDSTACK-7535 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7535 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > > Following two BVT Testcases in two different test suites fail with the same > root cause: > 1. test_04_change_offering_small in test_service_offerings.py > 2. test_10_attachAndDetach_iso > {noformat} > 2014-09-09 05:33:30,778 - DEBUG - Sending GET Cmd : > listVirtualMachines=== > 2014-09-09 05:33:30,807 - DEBUG - Response : [{domain : u'ROOT', domainid : > u'9df0ddd4-37d3-11e4-a979-ba3c937e668f', haenable : False, templatename : > u'CentOS 6.4(64-bit) GUI (Hyperv)', securitygroup : [], zoneid : > u'd41a93cd-7b6c-432b-9ad4-eb89d8b6e95c', cpunumber : 1, ostypeid : 182, > passwordenabled : False, instancename : u'i-23-43-VM', id : > u'21ca01e4-e737-4a06-a560-5c558387acb0', networkkbswrite : 1, hostname : > u'10.220.163.50', displayvm : True, state : u'Running', guestosid : > u'9e0ec9f2-37d3-11e4-a979-ba3c937e668f', cpuused : u'9%', memory : 256, > serviceofferingid : u'a178853a-56fb-484a-992c-30af0d3ef72b', zonename : > u'XenRT-Zone-0', isdynamicallyscalable : False, displayname : u'testserver', > tags : [], nic : [{networkid : u'e46b21a7-e4a3-4a10-ae1b-bce7a9d1d90e', > macaddress : u'02:00:34:f7:00:01', isolationuri : u'vlan://3027', type : > u'Isolated', broadcasturi : u'vlan://3027', traffictype : u'Guest', netmask : > u'255.255.255.0', ipaddress : u'192.168.200.120', id : > u'970f3e6a-c36c-485d-a891-c89cc743f969', networkname : > u'test-a-TestServiceOfferings-test_01_create_service_offering-MSR9BE-network', > gateway : u'192.168.200.1', isdefault : True}], cpuspeed : 100, templateid : > u'9df665f6-37d3-11e4-a979-ba3c937e668f', affinitygroup : [], account : > u'test-a-TestServiceOfferings-test_01_create_service_offering-MSR9BE', hostid > : u'e0e128e6-3efc-4080-8d50-c710d33854b8', name : > u'VM-21ca01e4-e737-4a06-a560-5c558387acb0', networkkbsread : 1, created : > u'2014-09-09T05:27:17+', hypervisor : u'Hyperv', rootdevicetype : > u'ROOT', rootdeviceid : 0, serviceofferingname : u'Small Instance', > templatedisplaytext : u'CentOS 6.4 (64-bit) GUI (Hyperv)'}] > 2014-09-09 05:33:30,807 - DEBUG - VM state: Running > 2014-09-09 05:44:34,402 - CRITICAL - FAILED: test_04_change_offering_small: > ['Traceback (most recent call last):\n', ' File > "/usr/lib/python2.7/unittest/case.py", line 332, in run\ntestMethod()\n', > ' File "/root/cloudstack/test/integration/smoke/test_service_offerings.py", > line 326, in test_04_change_offering_small\n > (self.medium_virtual_machine.ipaddress, e)\n', ' File > "/usr/lib/python2.7/unittest/case.py", line 413, in fail\nraise > self.failureException(msg)\n', 'AssertionError: SSH Access failed for > *192.168.200.120: SSH connection has Failed.* Waited 600s. Error is SSH > Connection Failed\n'] > 2014-09-09 05:44:34,412 - DEBUG - TestCaseName: > test_04_change_offering_small; Time Taken: 678 Seconds; StartTime: Tue Sep 9 > 05:33:15 2014; EndTime: Tue Sep 9 05:44:34 2014; Result: FAILED > {noformat} > {noformat} > 014-09-09 05:37:23,158 - CRITICAL - FAILED: test_10_attachAndDetach_iso: > ['Traceback (most recent call last):\n', ' File > "/usr/lib/python2.7/unittest/case.py", line 332, in run\ntestMethod()\n', > ' File "/root/cloudstack/test/integration/smoke/test_vm_life_cycle.py", line > 692, in test_10_attachAndDetach_iso\n(self.virtual_machine.ipaddress, > e))\n', ' File "/usr/lib/python2.7/unittest/case.py", line 413, in fail\n > raise self.failureException(msg)\n', 'AssertionError: SSH failed for virtual > machine: 192.168.200.149 - SSH connection h
[jira] [Updated] (CLOUDSTACK-7532) [Templates] Template status is not shown in UI/API response for non-default account users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7532: -- Attachment: template_status.PNG Attached screenshot to describe the issue. > [Templates] Template status is not shown in UI/API response for non-default > account users > - > > Key: CLOUDSTACK-7532 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7532 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Template >Affects Versions: 4.5.0 > Environment: Latest build from master with commit: > c33fea2cd27664db32c1173e98511470bf0a0724 >Reporter: Sanjeev N >Priority: Critical > Labels: api, templates > Attachments: template_status.PNG > > > [Templates] Template status is not shown in UI/API response for non-default > account users > Steps to Reproduce: > === > 1.Bring up CS with latest build > 2.Create one account under root domain > 3.Register template using the account created above > 4.After the template download is completed verify the template status using > the account created at step2 > Expected Result: > == > In UI/API response status field should be there and it should be set to > "Download Complete" after the successful template download. > Actual Behavior: > > Status is shown only for the default admin user. But it is not showed to > other account users. > Impact: > == > Marvin tests which use template register would fail because of the status > filed missing. > Following is the code from base.py where the tests are failing: > elif 'Downloaded' in template.status: > time.sleep(interval) > becasue template.status is NoneType > API: > > http://10.147.40.10:8080/client/api?command=listTemplates&sessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3D&templatefilter=self&id=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa&_=1410351906876 > API Response: > === > cloud-stack-version="4.5.0-SNAPSHOT">1550ad6ac-38d2-11e4-a56e-d4ae527ccfaaCentOS > 5.6(64-bit) no GUI (XenServer)CentOS 5.6(64-bit) no GUI > (XenServer)true2014-09-10T15:59:38+0530truefalseVHDtruetrue572126ea-38d2-11e4-a56e-d4ae527ccfaaCentOS > 5.6 > (64-bit)system680f7c3a-a9ee-4ed3-b594-981d56f8da4bz221474836480BUILTINXenServerROOT54e9d4e4-38d2-11e4-a56e-d4ae527ccfaatrue905cec879afd9c9d22ecc8036131a180falsetrue > In the above API response status field is missing. > This bug is easily reproducible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7532) [Templates] Template status is not shown in UI/API response for non-default account users
Sanjeev N created CLOUDSTACK-7532: - Summary: [Templates] Template status is not shown in UI/API response for non-default account users Key: CLOUDSTACK-7532 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7532 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Template Affects Versions: 4.5.0 Environment: Latest build from master with commit: c33fea2cd27664db32c1173e98511470bf0a0724 Reporter: Sanjeev N Priority: Critical [Templates] Template status is not shown in UI/API response for non-default account users Steps to Reproduce: === 1.Bring up CS with latest build 2.Create one account under root domain 3.Register template using the account created above 4.After the template download is completed verify the template status using the account created at step2 Expected Result: == In UI/API response status field should be there and it should be set to "Download Complete" after the successful template download. Actual Behavior: Status is shown only for the default admin user. But it is not showed to other account users. Impact: == Marvin tests which use template register would fail because of the status filed missing. Following is the code from base.py where the tests are failing: elif 'Downloaded' in template.status: time.sleep(interval) becasue template.status is NoneType API: http://10.147.40.10:8080/client/api?command=listTemplates&sessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3D&templatefilter=self&id=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa&_=1410351906876 API Response: === 1550ad6ac-38d2-11e4-a56e-d4ae527ccfaaCentOS 5.6(64-bit) no GUI (XenServer)CentOS 5.6(64-bit) no GUI (XenServer)true2014-09-10T15:59:38+0530truefalseVHDtruetrue572126ea-38d2-11e4-a56e-d4ae527ccfaaCentOS 5.6 (64-bit)system680f7c3a-a9ee-4ed3-b594-981d56f8da4bz221474836480BUILTINXenServerROOT54e9d4e4-38d2-11e4-a56e-d4ae527ccfaatrue905cec879afd9c9d22ecc8036131a180falsetrue In the above API response status field is missing. This bug is easily reproducible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-7508. - > [Automation] Duplicate entries in test_data.py for network offering > "nw_off_persistent_VPCVR_NoLB" > -- > > Key: CLOUDSTACK-7508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: Latest build from master >Reporter: Sanjeev N >Assignee: Sanjeev N > Labels: automation > > [Automation] Duplicate entried in test_data.py for network offering > "nw_off_persistent_VPCVR_NoLB" > test_data.py in marvin has two dictionaries with name > "nw_off_persistent_VPCVR_NoLB" one with ispersistent set to True and another > one with ispersistent set to False. > Tests would fail if the test picks the one with ispersistent set to False. So > we should delete the one with ispersistent set to False. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N resolved CLOUDSTACK-7508. --- Resolution: Fixed commit 535e7a667049e37d6a03c7a3e2e5c9645e6ce1f6 Author: sanjeev Date: Mon Sep 8 17:21:11 2014 +0530 CLOUDSTACK-7508: Remove duplicate network offerings from test_data.py > [Automation] Duplicate entries in test_data.py for network offering > "nw_off_persistent_VPCVR_NoLB" > -- > > Key: CLOUDSTACK-7508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: Latest build from master >Reporter: Sanjeev N >Assignee: Sanjeev N > Labels: automation > > [Automation] Duplicate entried in test_data.py for network offering > "nw_off_persistent_VPCVR_NoLB" > test_data.py in marvin has two dictionaries with name > "nw_off_persistent_VPCVR_NoLB" one with ispersistent set to True and another > one with ispersistent set to False. > Tests would fail if the test picks the one with ispersistent set to False. So > we should delete the one with ispersistent set to False. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"
Sanjeev N created CLOUDSTACK-7508: - Summary: [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB" Key: CLOUDSTACK-7508 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7508 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Environment: Latest build from master Reporter: Sanjeev N Assignee: Sanjeev N [Automation] Duplicate entried in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB" test_data.py in marvin has two dictionaries with name "nw_off_persistent_VPCVR_NoLB" one with ispersistent set to True and another one with ispersistent set to False. Tests would fail if the test picks the one with ispersistent set to False. So we should delete the one with ispersistent set to False. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7188) [Automation]Add hyper-v support for test_ssvm.py suite in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-7188. - Resolution: Fixed This issue has been fixed in CS-7190 > [Automation]Add hyper-v support for test_ssvm.py suite in BVT > - > > Key: CLOUDSTACK-7188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: Latest master build >Reporter: Sanjeev N > Labels: automation > > [Automation]Add hyper-v support for test_ssvm.py suite in BVT > 1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests > require ssh access to ssvm/cpvm. Right now the tests have ssh access > mechanism supported only for vmware,xen and kvm. > This bug is to add ssh access support for Hyper-v as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-7189) [Automation]Add hyper-v support for test_routers.py suite in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-7189. - Resolution: Fixed This issue has been fixed in CS-7190 > [Automation]Add hyper-v support for test_routers.py suite in BVT > > > Key: CLOUDSTACK-7189 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7189 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: Latest build from master >Reporter: Sanjeev N > Labels: automation > > [Automation]Add hyper-v support for test_routers.py suite in BVT > Few tests in test_routers.py suite file require ssh access to VR. Need to add > support for hyper-v similar to vmware in accessing VR via ssh. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7189) [Automation]Add hyper-v support for test_routers.py suite in BVT
Sanjeev N created CLOUDSTACK-7189: - Summary: [Automation]Add hyper-v support for test_routers.py suite in BVT Key: CLOUDSTACK-7189 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7189 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Environment: Latest build from master Reporter: Sanjeev N [Automation]Add hyper-v support for test_routers.py suite in BVT Few tests in test_routers.py suite file require ssh access to VR. Need to add support for hyper-v similar to vmware in accessing VR via ssh. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7188) [Automation]Add hyper-v support for test_ssvm.py suite in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7188: -- Issue Type: Test (was: Bug) > [Automation]Add hyper-v support for test_ssvm.py suite in BVT > - > > Key: CLOUDSTACK-7188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: Latest master build >Reporter: Sanjeev N > Labels: automation > > [Automation]Add hyper-v support for test_ssvm.py suite in BVT > 1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests > require ssh access to ssvm/cpvm. Right now the tests have ssh access > mechanism supported only for vmware,xen and kvm. > This bug is to add ssh access support for Hyper-v as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7188) [Automation]Add hyper-v support for test_ssvm.py suite in BVT
Sanjeev N created CLOUDSTACK-7188: - Summary: [Automation]Add hyper-v support for test_ssvm.py suite in BVT Key: CLOUDSTACK-7188 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Environment: Latest master build Reporter: Sanjeev N [Automation]Add hyper-v support for test_ssvm.py suite in BVT 1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests require ssh access to ssvm/cpvm. Right now the tests have ssh access mechanism supported only for vmware,xen and kvm. This bug is to add ssh access support for Hyper-v as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-6992. - Verified the fix on my local setup before submitting patch. Works fine. > [Portable_IP] All tests failed from advanced regression suite > test_portable_ip.py > - > > Key: CLOUDSTACK-6992 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 >Reporter: Sanjeev N >Assignee: Sanjeev N >Priority: Critical > Labels: automation > Fix For: 4.4.0 > > > [Portable_IP] All tests failed from advanced regression suite > test_portable_ip.py > In this test_portable_ip.py file every test method has the following line: > portable_ip_range_services = getPortableIpRangeServices(self.config) > However self.config is not defined. So we are seeing following error from the > test run: > 'NoneType' object has no attribute 'startip' > >> begin captured stdout << - > === TestName: test_associate_ip_address | Status : EXCEPTION === > test_associate_ip_address > (integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: > STARTED : TC: test_associate_ip_address ::: > test_associate_ip_address > (integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: > EXCEPTION: test_associate_ip_address: ['Traceback (most recent call > last):\n', ' File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n > self.setUp()\n', ' File > "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py", > line 639, in setUp\nportable_ip_range_services = > getPortableIpRangeServices(self.config)\n', ' File > "/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py", > line 1198, in getPortableIpRangeServices\nif > config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no > attribute 'startip'\n"] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N resolved CLOUDSTACK-6992. --- Resolution: Fixed > [Portable_IP] All tests failed from advanced regression suite > test_portable_ip.py > - > > Key: CLOUDSTACK-6992 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 >Reporter: Sanjeev N >Assignee: Sanjeev N >Priority: Critical > Labels: automation > Fix For: 4.4.0 > > > [Portable_IP] All tests failed from advanced regression suite > test_portable_ip.py > In this test_portable_ip.py file every test method has the following line: > portable_ip_range_services = getPortableIpRangeServices(self.config) > However self.config is not defined. So we are seeing following error from the > test run: > 'NoneType' object has no attribute 'startip' > >> begin captured stdout << - > === TestName: test_associate_ip_address | Status : EXCEPTION === > test_associate_ip_address > (integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: > STARTED : TC: test_associate_ip_address ::: > test_associate_ip_address > (integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: > EXCEPTION: test_associate_ip_address: ['Traceback (most recent call > last):\n', ' File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n > self.setUp()\n', ' File > "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py", > line 639, in setUp\nportable_ip_range_services = > getPortableIpRangeServices(self.config)\n', ' File > "/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py", > line 1198, in getPortableIpRangeServices\nif > config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no > attribute 'startip'\n"] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6992: -- Status: Reviewable (was: In Progress) > [Portable_IP] All tests failed from advanced regression suite > test_portable_ip.py > - > > Key: CLOUDSTACK-6992 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 >Reporter: Sanjeev N >Assignee: Sanjeev N >Priority: Critical > Labels: automation > Fix For: 4.4.0 > > > [Portable_IP] All tests failed from advanced regression suite > test_portable_ip.py > In this test_portable_ip.py file every test method has the following line: > portable_ip_range_services = getPortableIpRangeServices(self.config) > However self.config is not defined. So we are seeing following error from the > test run: > 'NoneType' object has no attribute 'startip' > >> begin captured stdout << - > === TestName: test_associate_ip_address | Status : EXCEPTION === > test_associate_ip_address > (integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: > STARTED : TC: test_associate_ip_address ::: > test_associate_ip_address > (integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: > EXCEPTION: test_associate_ip_address: ['Traceback (most recent call > last):\n', ' File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n > self.setUp()\n', ' File > "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py", > line 639, in setUp\nportable_ip_range_services = > getPortableIpRangeServices(self.config)\n', ' File > "/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py", > line 1198, in getPortableIpRangeServices\nif > config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no > attribute 'startip'\n"] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N reassigned CLOUDSTACK-6992: - Assignee: Sanjeev N > [Portable_IP] All tests failed from advanced regression suite > test_portable_ip.py > - > > Key: CLOUDSTACK-6992 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 >Reporter: Sanjeev N >Assignee: Sanjeev N >Priority: Critical > Labels: automation > Fix For: 4.4.0 > > > [Portable_IP] All tests failed from advanced regression suite > test_portable_ip.py > In this test_portable_ip.py file every test method has the following line: > portable_ip_range_services = getPortableIpRangeServices(self.config) > However self.config is not defined. So we are seeing following error from the > test run: > 'NoneType' object has no attribute 'startip' > >> begin captured stdout << - > === TestName: test_associate_ip_address | Status : EXCEPTION === > test_associate_ip_address > (integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: > STARTED : TC: test_associate_ip_address ::: > test_associate_ip_address > (integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: > EXCEPTION: test_associate_ip_address: ['Traceback (most recent call > last):\n', ' File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n > self.setUp()\n', ' File > "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py", > line 639, in setUp\nportable_ip_range_services = > getPortableIpRangeServices(self.config)\n', ' File > "/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py", > line 1198, in getPortableIpRangeServices\nif > config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no > attribute 'startip'\n"] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py
Sanjeev N created CLOUDSTACK-6992: - Summary: [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py Key: CLOUDSTACK-6992 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Environment: Latest build from 4.4 Reporter: Sanjeev N Priority: Critical Fix For: 4.4.0 [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py In this test_portable_ip.py file every test method has the following line: portable_ip_range_services = getPortableIpRangeServices(self.config) However self.config is not defined. So we are seeing following error from the test run: 'NoneType' object has no attribute 'startip' >> begin captured stdout << - === TestName: test_associate_ip_address | Status : EXCEPTION === test_associate_ip_address (integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: STARTED : TC: test_associate_ip_address ::: test_associate_ip_address (integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: EXCEPTION: test_associate_ip_address: ['Traceback (most recent call last):\n', ' File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n self.setUp()\n', ' File "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py", line 639, in setUp\nportable_ip_range_services = getPortableIpRangeServices(self.config)\n', ' File "/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py", line 1198, in getPortableIpRangeServices\nif config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no attribute 'startip'\n"] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6841) [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6841: -- Attachment: cloud-44.dmp ovstunnel-host14.log ovstunnel-host13.log management-server.rar > [OVS] Remote_ips for tunnel ports are not configured properly in case of > multipel physical networks > > > Key: CLOUDSTACK-6841 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6841 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Critical > Labels: ovs > Fix For: 4.4.0 > > Attachments: cloud-44.dmp, management-server.rar, > ovstunnel-host13.log, ovstunnel-host14.log > > > [OVS] Remote_ips for tunnel ports are not configured properly in case of > multipel physical networks > Steps to reproduce: > == > 1.Bring up CS in advanced zone with xen cluster with min of two hosts > and two nics on both the hosts > 2.Create two physical networks with GRE isolation during zone creation: > in physical network1 add guest,public&management traffic types with tag "tag1" > in physical network2 add only guest traffic with tag "tag2" > 3.create two network offerings NO1&NO2 with virtual networking and ovs as the > connectivity service provider and user taggings tag1 & tag2 in NO1 & NO2 > respectively > 4.Create isolated networks nw1 & nw2 using NO1 & NO2 > 5.Deploy vms in both the netwoks and make sure that both the networks are > spread across both the hosts in the cluster > 6.Verify tunnel ports remote_ips on both the hosts > On xenservers used NIC0 for physical network1(by using traffic labels) and > NIC1 for physical network2 > NIC0&NIC1 both have routable IP addresses. > Result: > = > Remote_ips for all the tunnel ports created in the above networks are set to > NIC1 ip addresses. But tunnel ports in network created on physical network1 > should have NIC0 ip address as remote_ip and NIC1 ip address for the tunnel > ports in other network. > mysql> select * from ovs_tunnel_interface; > ++--+---+---+-++ > | id | ip | netmask | mac | host_id | label > | > ++--+---+---+-++ > | 1 | 0| 0 | 0 | 0 | lock > | > | 2 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab | 1 | > management | > | 3 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d | 2 | > management | > | 4 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab | 1 | gre > | > | 5 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d | 2 | gre > | > ++--+---+---+-++ > 5 rows in set (0.00 sec) > Here management label is on NIC0 and gre is on NIC1 and > 10.147.42.13&10.147.42.14 are assigned to NIC1 on the hosts. > But in the above table we are using same ip address against bot the labels. > So tunnel ports for both the networks are created with same remote_ip address. > Host details are as follows: > mysql> select > id,name,private_ip_address,public_ip_address,data_center_id,cluster_id from > host where id in (1,2); > ++-++---+++ > | id | name| private_ip_address | public_ip_address | > data_center_id | cluster_id | > ++-++---+++ > | 1 | Rack1Pod1Host13 | 10.147.40.13 | 10.147.40.13 | > 1 | 1 | > | 2 | Rack1Pod1Host14 | 10.147.40.14 | 10.147.40.14 | > 1 | 1 | > ++-++---+++ > 2 rows in set (0.00 sec) > 10.147.40.13& 10.147.40.14 ip addresses are management addresses assigned to > NIC0 on both the hosts. > Tunnel ports details on the hosts are: > system@xapi16: > lookups: hit:11752 missed:3227 lost:0 > flows: 4 > port 0: xapi16 (internal) > port 1: t4018-2-1 (gre: key=4018, remote_ip=10.147.42.13) > port 2: vif26.0 > system@xapi15: > lookups: hit:4359 missed:167 lost:0 > flows: 0 > port 0: xapi15 (internal) > port 1: t992-2-1 (gre: key=992
[jira] [Created] (CLOUDSTACK-6841) [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks
Sanjeev N created CLOUDSTACK-6841: - Summary: [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks Key: CLOUDSTACK-6841 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6841 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks Steps to reproduce: == 1.Bring up CS in advanced zone with xen cluster with min of two hosts and two nics on both the hosts 2.Create two physical networks with GRE isolation during zone creation: in physical network1 add guest,public&management traffic types with tag "tag1" in physical network2 add only guest traffic with tag "tag2" 3.create two network offerings NO1&NO2 with virtual networking and ovs as the connectivity service provider and user taggings tag1 & tag2 in NO1 & NO2 respectively 4.Create isolated networks nw1 & nw2 using NO1 & NO2 5.Deploy vms in both the netwoks and make sure that both the networks are spread across both the hosts in the cluster 6.Verify tunnel ports remote_ips on both the hosts On xenservers used NIC0 for physical network1(by using traffic labels) and NIC1 for physical network2 NIC0&NIC1 both have routable IP addresses. Result: = Remote_ips for all the tunnel ports created in the above networks are set to NIC1 ip addresses. But tunnel ports in network created on physical network1 should have NIC0 ip address as remote_ip and NIC1 ip address for the tunnel ports in other network. mysql> select * from ovs_tunnel_interface; ++--+---+---+-++ | id | ip | netmask | mac | host_id | label | ++--+---+---+-++ | 1 | 0| 0 | 0 | 0 | lock | | 2 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab | 1 | management | | 3 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d | 2 | management | | 4 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab | 1 | gre| | 5 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d | 2 | gre| ++--+---+---+-++ 5 rows in set (0.00 sec) Here management label is on NIC0 and gre is on NIC1 and 10.147.42.13&10.147.42.14 are assigned to NIC1 on the hosts. But in the above table we are using same ip address against bot the labels. So tunnel ports for both the networks are created with same remote_ip address. Host details are as follows: mysql> select id,name,private_ip_address,public_ip_address,data_center_id,cluster_id from host where id in (1,2); ++-++---+++ | id | name| private_ip_address | public_ip_address | data_center_id | cluster_id | ++-++---+++ | 1 | Rack1Pod1Host13 | 10.147.40.13 | 10.147.40.13 | 1 | 1 | | 2 | Rack1Pod1Host14 | 10.147.40.14 | 10.147.40.14 | 1 | 1 | ++-++---+++ 2 rows in set (0.00 sec) 10.147.40.13& 10.147.40.14 ip addresses are management addresses assigned to NIC0 on both the hosts. Tunnel ports details on the hosts are: system@xapi16: lookups: hit:11752 missed:3227 lost:0 flows: 4 port 0: xapi16 (internal) port 1: t4018-2-1 (gre: key=4018, remote_ip=10.147.42.13) port 2: vif26.0 system@xapi15: lookups: hit:4359 missed:167 lost:0 flows: 0 port 0: xapi15 (internal) port 1: t992-2-1 (gre: key=992, remote_ip=10.147.42.13) port 2: vif25.0 Attaching MS log file, cloud DB and ovstunnel log files. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6840) [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if the physical network isolation type is VLAN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6840: -- Attachment: ovs_vlan.PNG Attached screenshot to describe the issue. > [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if > the physical network isolation type is VLAN > > > Key: CLOUDSTACK-6840 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6840 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 > Environment: Latest build from 4.4. with commit > 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 >Reporter: Sanjeev N >Assignee: Gabor Apati-Nagy >Priority: Critical > Labels: ovs > Fix For: 4.4.0 > > Attachments: ovs_vlan.PNG > > > [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if > the physical network isolation type is VLAN > Steps to reproduce: > == > 1.Bring up CS in advanced zone with xen cluster > 2.While creating physical network during zone creation choose VLAN as the > isolation type > 3.From UI navigate to Home->Infrastructure->Zones->CS-GRE->Physical Network > 1->Network Service Providers > Result: > == > NetworkServiceProviders page shows OVS as one of the providers and by default > is in disabled state. Whereas API does not show OVS as one of the providers. > Following is the API response: > http://10.147.59.119:8096/client/api?command=listNetworkServiceProviders&physicalnetworkid=e58d6d73-cd77-4917-875a-695f56a4b968 > cloud-stack-version="4.4.0-SNAPSHOT">4InternalLbVme58d6d73-cd77-4917-875a-695f56a4b968Enabled223a1a51-c6a0-4239-ac82-f96290520669LbtrueVpcVirtualRoutere58d6d73-cd77-4917-875a-695f56a4b968Enabled641ae03f-861b-4e20-8b59-333f0848207eVpnDhcpDnsGatewayLbSourceNatStaticNatPortForwardingUserDatatrueSecurityGroupProvidere58d6d73-cd77-4917-875a-695f56a4b968Disabled2414d618-ec08-4624-b16e-fd22e2326f24SecurityGroupfalseVirtualRoutere58d6d73-cd77-4917-875a-695f56a4b968Enableddae0a4b6-24a7-4d56-91bd-8f0f4919938eVpnDhcpDnsGatewayFirewallLbSourceNatStaticNatPortForwardingUserDatatrue > DB entries from cloud db are as follows: > mysql> select * from physical_network_service_providers where > physical_network_id=202; > ++--+-+---+--+-+--+---+--+--+---+-+---+-+--++-+-+-+ > | id | uuid | physical_network_id | > provider_name | state| destination_physical_network_id | > vpn_service_provided | dhcp_service_provided | dns_service_provided | > gateway_service_provided | firewall_service_provided | > source_nat_service_provided | load_balance_service_provided | > static_nat_service_provided | port_forwarding_service_provided | > user_data_service_provided | security_group_service_provided | > networkacl_service_provided | removed | > ++--+-+---+--+-+--+---+--+--+---+-+---+-+--++-+-+-+ > | 11 | dae0a4b6-24a7-4d56-91bd-8f0f4919938e | 202 | > VirtualRouter | Enabled | 0 | > 1 | 1 |1 | > 1 | 1 | 1 | > 1 | 1 | > 1 | 1 | 0 | > 0 | NULL| > | 12 | 2414d618-ec08-4624-b16e-fd22e2326f24 | 202 | > SecurityGroupProvider | Disabled | 0 | > 0 | 0 |0 | > 0 | 0 | 0 | > 0 |
[jira] [Created] (CLOUDSTACK-6840) [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if the physical network isolation type is VLAN
Sanjeev N created CLOUDSTACK-6840: - Summary: [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if the physical network isolation type is VLAN Key: CLOUDSTACK-6840 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6840 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Environment: Latest build from 4.4. with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Assignee: Gabor Apati-Nagy Priority: Critical Fix For: 4.4.0 [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if the physical network isolation type is VLAN Steps to reproduce: == 1.Bring up CS in advanced zone with xen cluster 2.While creating physical network during zone creation choose VLAN as the isolation type 3.From UI navigate to Home->Infrastructure->Zones->CS-GRE->Physical Network 1->Network Service Providers Result: == NetworkServiceProviders page shows OVS as one of the providers and by default is in disabled state. Whereas API does not show OVS as one of the providers. Following is the API response: http://10.147.59.119:8096/client/api?command=listNetworkServiceProviders&physicalnetworkid=e58d6d73-cd77-4917-875a-695f56a4b968 4InternalLbVme58d6d73-cd77-4917-875a-695f56a4b968Enabled223a1a51-c6a0-4239-ac82-f96290520669LbtrueVpcVirtualRoutere58d6d73-cd77-4917-875a-695f56a4b968Enabled641ae03f-861b-4e20-8b59-333f0848207eVpnDhcpDnsGatewayLbSourceNatStaticNatPortForwardingUserDatatrueSecurityGroupProvidere58d6d73-cd77-4917-875a-695f56a4b968Disabled2414d618-ec08-4624-b16e-fd22e2326f24SecurityGroupfalseVirtualRoutere58d6d73-cd77-4917-875a-695f56a4b968Enableddae0a4b6-24a7-4d56-91bd-8f0f4919938eVpnDhcpDnsGatewayFirewallLbSourceNatStaticNatPortForwardingUserDatatrue DB entries from cloud db are as follows: mysql> select * from physical_network_service_providers where physical_network_id=202; ++--+-+---+--+-+--+---+--+--+---+-+---+-+--++-+-+-+ | id | uuid | physical_network_id | provider_name | state| destination_physical_network_id | vpn_service_provided | dhcp_service_provided | dns_service_provided | gateway_service_provided | firewall_service_provided | source_nat_service_provided | load_balance_service_provided | static_nat_service_provided | port_forwarding_service_provided | user_data_service_provided | security_group_service_provided | networkacl_service_provided | removed | ++--+-+---+--+-+--+---+--+--+---+-+---+-+--++-+-+-+ | 11 | dae0a4b6-24a7-4d56-91bd-8f0f4919938e | 202 | VirtualRouter | Enabled | 0 | 1 | 1 |1 | 1 | 1 | 1 | 1 | 1 |1 | 1 | 0 | 0 | NULL| | 12 | 2414d618-ec08-4624-b16e-fd22e2326f24 | 202 | SecurityGroupProvider | Disabled | 0 | 0 | 0 |0 | 0 | 0 | 0 | 0 | 0 |0 | 0 | 1 | 0 | NULL| | 13 | 641ae03f-861b-4e20-8b59-333f0848207e | 202 | VpcVirtualRouter | Enabled | 0 | 1 | 1 |1 | 1 | 0 | 1 | 1 | 1 |
[jira] [Updated] (CLOUDSTACK-6832) [OVS]vnet is not released even the network is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6832: -- Attachment: management-server.rar > [OVS]vnet is not released even the network is deleted > - > > Key: CLOUDSTACK-6832 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6832 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Critical > Labels: ovs > Fix For: 4.4.0 > > Attachments: management-server.rar > > > [OVS]vnet is not released even the network is deleted > Steps to reproduce: > === > 1.Bring up CS in advanced zone with xen cluster > 2.Create physical network with GRE isolation and specify some VNIs as GRE > keys for guest traffic > 3.Create network offering with virtual networking and OVS as the service > provider > 4.Deploy few vms with the above network > 5.Delete the network after expunging all the vms > Result: > = > Network deletion was successful but the vnet allocated for the network was > not released. > VNI range specified for the guest traffic was 981-1000 and 992 was taken for > the implemented network. But the vnet id 992 was not released back to the > pool even after deleting the network. > mysql> select * from op_dc_vnet_alloc; > +-+--+-++--++-+-+ > | id | vnet | physical_network_id | data_center_id | reservation_id > | account_id | taken | account_vnet_map_id | > +-+--+-++--++-+-+ > | 122 | 989 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 123 | 988 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 124 | 987 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 125 | 982 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 126 | 981 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 127 | 986 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 128 | 985 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 129 | 984 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 130 | 983 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 131 | 996 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 132 | 997 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 133 | 994 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 134 | 995 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 135 | 992 | 203 | 2 | > 8edad56a-a59d-4477-8741-9e91a8ef9052 | 2 | 2014-06-03 15:12:55 | >NULL | > | 136 | 993 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 137 | 990 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 138 | 991 | 203 | 2 | NULL > | NULL | NULL|NULL | > | 139 | 1000 | 203 | 2 | NULL > | NU
[jira] [Created] (CLOUDSTACK-6832) [OVS]vnet is not released even the network is deleted
Sanjeev N created CLOUDSTACK-6832: - Summary: [OVS]vnet is not released even the network is deleted Key: CLOUDSTACK-6832 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6832 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVS]vnet is not released even the network is deleted Steps to reproduce: === 1.Bring up CS in advanced zone with xen cluster 2.Create physical network with GRE isolation and specify some VNIs as GRE keys for guest traffic 3.Create network offering with virtual networking and OVS as the service provider 4.Deploy few vms with the above network 5.Delete the network after expunging all the vms Result: = Network deletion was successful but the vnet allocated for the network was not released. VNI range specified for the guest traffic was 981-1000 and 992 was taken for the implemented network. But the vnet id 992 was not released back to the pool even after deleting the network. mysql> select * from op_dc_vnet_alloc; +-+--+-++--++-+-+ | id | vnet | physical_network_id | data_center_id | reservation_id | account_id | taken | account_vnet_map_id | +-+--+-++--++-+-+ | 122 | 989 | 203 | 2 | NULL | NULL | NULL|NULL | | 123 | 988 | 203 | 2 | NULL | NULL | NULL|NULL | | 124 | 987 | 203 | 2 | NULL | NULL | NULL|NULL | | 125 | 982 | 203 | 2 | NULL | NULL | NULL|NULL | | 126 | 981 | 203 | 2 | NULL | NULL | NULL|NULL | | 127 | 986 | 203 | 2 | NULL | NULL | NULL|NULL | | 128 | 985 | 203 | 2 | NULL | NULL | NULL|NULL | | 129 | 984 | 203 | 2 | NULL | NULL | NULL|NULL | | 130 | 983 | 203 | 2 | NULL | NULL | NULL|NULL | | 131 | 996 | 203 | 2 | NULL | NULL | NULL|NULL | | 132 | 997 | 203 | 2 | NULL | NULL | NULL|NULL | | 133 | 994 | 203 | 2 | NULL | NULL | NULL|NULL | | 134 | 995 | 203 | 2 | NULL | NULL | NULL|NULL | | 135 | 992 | 203 | 2 | 8edad56a-a59d-4477-8741-9e91a8ef9052 | 2 | 2014-06-03 15:12:55 | NULL | | 136 | 993 | 203 | 2 | NULL | NULL | NULL|NULL | | 137 | 990 | 203 | 2 | NULL | NULL | NULL|NULL | | 138 | 991 | 203 | 2 | NULL | NULL | NULL|NULL | | 139 | 1000 | 203 | 2 | NULL | NULL | NULL|NULL | | 140 | 998 | 203 | 2 | NULL | NULL | NULL|NULL | | 141 | 999 | 203 | 2 | NULL | NULL | NULL|NULL | +-+--+-++--
[jira] [Updated] (CLOUDSTACK-6828) [OVS] Tunnel ports are not getting deleted even failure in vm deployment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6828: -- Attachment: ovstunnel-host14.log ovstunnel-host13.log management-server.rar > [OVS] Tunnel ports are not getting deleted even failure in vm deployment > > > Key: CLOUDSTACK-6828 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6828 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Critical > Labels: ovs > Fix For: 4.4.0 > > Attachments: management-server.rar, ovstunnel-host13.log, > ovstunnel-host14.log > > > [OVS] Tunnel ports are not getting deleted even failure in vm deployment > Steps to Reproduce: > > 1.Bringup CS in advanced zone with Xen cluster > 2.Create physical network with GRE isolation > 3.Create network offering with virtual networking and ovs as the connectivity > service provider. > 4.Deploy vm with above offering and simulate vm failure > (In my case I was trying with multiple physical networks scenario and because > of some configuration issues network implement failed so failure in vm > deployment) > Result: > = > During vm deployment ovs bridge and tunnel ports were created between the two > hosts. But after the failure there was no clean up of the ovs-bridge and the > tunnel ports. > Observations: > == > xapi7 and xapi6 were the bridges created for the network. > Following is the log snippet from ovstunnel log from both the hosts: > [root@Rack1Pod1Host14 ~]# ovs-vsctl list-ports xapi7 > t10016-4-1 > [root@Rack1Pod1Host14 ~]# grep xapi7 /var/log/cloud/ovstunnel.log > 2014-06-03 05:38:46DEBUG [root] About to manually create the bridge:xapi7 > 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', > '--may-exist', 'add-br', 'xapi7', '--', 'set', 'bridge', 'xapi7', > 'other_config:gre_key=OVSTunnel10016'] > 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', > 'Bridge', 'xapi7', > 'external_ids:xs-network-uuid=127de5bb-a423-2774-98b6-ce1827d261d7'] > 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', > 'Bridge', 'xapi7', 'stp_enable=true'] > 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', > 'bridge', 'xapi7', 'other_config:gre_key'] > 2014-06-03 05:38:46DEBUG [root] Executing:['/opt/xensource/bin/xe', > 'network-list', 'bridge=xapi7', '--minimal'] > 2014-06-03 05:38:46DEBUG [root] Setup_ovs_bridge completed with > result:SUCCESS:xapi7 > 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', > '--timeout=30', 'wait-until', 'bridge', 'xapi7', '--', 'get', 'bridge', > 'xapi7', 'name'] > 2014-06-03 05:38:50DEBUG [root] bridge xapi7 for creating tunnel - > VERIFIED > 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', > 'add-port', 'xapi7', 't10016-4-1', '--', 'set', 'interface', 't10016-4-1', > 'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.13'] > 2014-06-03 05:38:50DEBUG [root] Executing:['/opt/xensource/bin/xe', > 'network-list', 'bridge=xapi7', '--minimal'] > 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', > 'add-flow', 'xapi7', > 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,actions=drop'] > 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', > 'add-flow', 'xapi7', > 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,ip,nw_dst=224.0.0.0/24,actions=drop'] > [root@Rack1Pod1Host13 ~]# ovs-vsctl list-ports xapi6 > t10016-1-4 > [root@Rack1Pod1Host13 ~]# grep xapi6 /var/log/cloud/ovstunnel.log > 2014-06-03 05:38:56DEBUG [root] About to manually create the bridge:xapi6 > 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', > '--may-exist', 'add-br', 'xapi6', '--', 'set', 'bridge', 'xapi6', > 'other_config:gre_key=OVSTunnel10016'] > 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', > 'Bridge', 'xapi6', > 'external_ids:xs-network-uuid=ae6fe450-3399-7dad-b972-aa45755c2803'] > 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', > 'Bridge', 'xapi6', 'stp_enable=true'] > 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', > 'bridge', 'xapi6', 'other_config:gre_key'] > 2014-06-03 05:38:56DEBUG [root] Executing:['/opt/xensource/bin/xe', > 'network-list', 'bri
[jira] [Created] (CLOUDSTACK-6828) [OVS] Tunnel ports are not getting deleted even failure in vm deployment
Sanjeev N created CLOUDSTACK-6828: - Summary: [OVS] Tunnel ports are not getting deleted even failure in vm deployment Key: CLOUDSTACK-6828 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6828 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVS] Tunnel ports are not getting deleted even failure in vm deployment Steps to Reproduce: 1.Bringup CS in advanced zone with Xen cluster 2.Create physical network with GRE isolation 3.Create network offering with virtual networking and ovs as the connectivity service provider. 4.Deploy vm with above offering and simulate vm failure (In my case I was trying with multiple physical networks scenario and because of some configuration issues network implement failed so failure in vm deployment) Result: = During vm deployment ovs bridge and tunnel ports were created between the two hosts. But after the failure there was no clean up of the ovs-bridge and the tunnel ports. Observations: == xapi7 and xapi6 were the bridges created for the network. Following is the log snippet from ovstunnel log from both the hosts: [root@Rack1Pod1Host14 ~]# ovs-vsctl list-ports xapi7 t10016-4-1 [root@Rack1Pod1Host14 ~]# grep xapi7 /var/log/cloud/ovstunnel.log 2014-06-03 05:38:46DEBUG [root] About to manually create the bridge:xapi7 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', '--may-exist', 'add-br', 'xapi7', '--', 'set', 'bridge', 'xapi7', 'other_config:gre_key=OVSTunnel10016'] 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi7', 'external_ids:xs-network-uuid=127de5bb-a423-2774-98b6-ce1827d261d7'] 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi7', 'stp_enable=true'] 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 'bridge', 'xapi7', 'other_config:gre_key'] 2014-06-03 05:38:46DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi7', '--minimal'] 2014-06-03 05:38:46DEBUG [root] Setup_ovs_bridge completed with result:SUCCESS:xapi7 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--timeout=30', 'wait-until', 'bridge', 'xapi7', '--', 'get', 'bridge', 'xapi7', 'name'] 2014-06-03 05:38:50DEBUG [root] bridge xapi7 for creating tunnel - VERIFIED 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'add-port', 'xapi7', 't10016-4-1', '--', 'set', 'interface', 't10016-4-1', 'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.13'] 2014-06-03 05:38:50DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi7', '--minimal'] 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 'add-flow', 'xapi7', 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,actions=drop'] 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 'add-flow', 'xapi7', 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,ip,nw_dst=224.0.0.0/24,actions=drop'] [root@Rack1Pod1Host13 ~]# ovs-vsctl list-ports xapi6 t10016-1-4 [root@Rack1Pod1Host13 ~]# grep xapi6 /var/log/cloud/ovstunnel.log 2014-06-03 05:38:56DEBUG [root] About to manually create the bridge:xapi6 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', '--may-exist', 'add-br', 'xapi6', '--', 'set', 'bridge', 'xapi6', 'other_config:gre_key=OVSTunnel10016'] 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi6', 'external_ids:xs-network-uuid=ae6fe450-3399-7dad-b972-aa45755c2803'] 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi6', 'stp_enable=true'] 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 'bridge', 'xapi6', 'other_config:gre_key'] 2014-06-03 05:38:56DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi6', '--minimal'] 2014-06-03 05:38:56DEBUG [root] Setup_ovs_bridge completed with result:SUCCESS:xapi6 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--timeout=30', 'wait-until', 'bridge', 'xapi6', '--', 'get', 'bridge', 'xapi6', 'name'] 2014-06-03 05:38:56DEBUG [root] bridge xapi6 for creating tunnel - VERIFIED 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'add-port', 'xapi6', 't10016-1-4', '--', 'set', 'interface', 't10016-1-4', 'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.14'] 2014-06
[jira] [Updated] (CLOUDSTACK-6827) Can't enable VR service provider in case of multiple physical networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6827: -- Attachment: management-server.rar > Can't enable VR service provider in case of multiple physical networks > -- > > Key: CLOUDSTACK-6827 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6827 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.rar > > > Can't enable VR service provider in case of multiple physical networks > Steps to reproduce: > == > 1.Bring up CS in advanced zone with xen cluster > 2.Once the system is up disable the zone and add another physical network and > add only guest traffic into it. > 3.Go to network service providers in the physical network > 4.All the providers are disabled by default. Try to enable Virtual Router > http://10.147.59.119:8096/client/api?command=updateNetworkServiceProvider&id=beb30cda-7e3a-44e9-b179-c1c6fd605b47&state=Enabled > Result: > = > Enabling VR service provider failed and observed following exception: > 2014-06-03 06:13:54,846 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (ApiServer-8:ctx-8602d969 ctx-e30c2238) submit async job-82, details: > AsyncJobVO {id:82, userId: 1, accountId: 1, instanceType: > PhysicalNetworkServiceProvider, instanceId: null, cmd: > org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd, > cmdInfo: > {"id":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxDetails":"{\"PhysicalNetworkServiceProvider\":\"beb30cda-7e3a-44e9-b179-c1c6fd605b47\",\"com.cloud.network.PhysicalNetworkServiceProvider\":6}","cmdEventType":"SERVICE.PROVIDER.UPDATE","ctxUserId":"1","state":"Enabled","httpmethod":"GET","uuid":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxAccountId":"1","ctxStartEventId":"218"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-06-03 06:13:54,853 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (API-Job-Executor-45:ctx-4f22f44a job-82) Add job-82 into job monitoring > 2014-06-03 06:13:54,853 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (API-Job-Executor-45:ctx-4f22f44a job-82) Executing AsyncJobVO {id:82, > userId: 1, accountId: 1, instanceType: PhysicalNetworkServiceProvider, > instanceId: null, cmd: > org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd, > cmdInfo: > {"id":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxDetails":"{\"PhysicalNetworkServiceProvider\":\"beb30cda-7e3a-44e9-b179-c1c6fd605b47\",\"com.cloud.network.PhysicalNetworkServiceProvider\":6}","cmdEventType":"SERVICE.PROVIDER.UPDATE","ctxUserId":"1","state":"Enabled","httpmethod":"GET","uuid":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxAccountId":"1","ctxStartEventId":"218"}, > cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: > null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null, > lastPolled: null, created: null} > 2014-06-03 06:13:54,860 WARN [c.c.a.d.ParamGenericValidationWorker] > (API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) Received unknown > parameters for command updateNetworkServiceProvider. Unknown parameters : > ctxdetails > 2014-06-03 06:13:54,871 DEBUG [c.c.n.NetworkServiceImpl] > (API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) trying to update the > state of the service provider id=6 on physical network: 201 to state: Enabled > 2014-06-03 06:13:54,878 DEBUG [c.c.s.StatsCollector] > (StatsCollector-2:ctx-e6a2a82e) HostStatsCollector is running... > 2014-06-03 06:13:54,885 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-45:ctx-4f22f44a job-82) Unexpected exception while > executing > org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd > com.cloud.utils.exception.CloudRuntimeException: Provider is not ready, > cannot Enable the provider, please configure the provider first > at > com.cloud.network.NetworkServiceImpl.updateNetworkServiceProvider(NetworkServiceImpl.java:3425) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at >
[jira] [Created] (CLOUDSTACK-6827) Can't enable VR service provider in case of multiple physical networks
Sanjeev N created CLOUDSTACK-6827: - Summary: Can't enable VR service provider in case of multiple physical networks Key: CLOUDSTACK-6827 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6827 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Priority: Critical Fix For: 4.4.0 Can't enable VR service provider in case of multiple physical networks Steps to reproduce: == 1.Bring up CS in advanced zone with xen cluster 2.Once the system is up disable the zone and add another physical network and add only guest traffic into it. 3.Go to network service providers in the physical network 4.All the providers are disabled by default. Try to enable Virtual Router http://10.147.59.119:8096/client/api?command=updateNetworkServiceProvider&id=beb30cda-7e3a-44e9-b179-c1c6fd605b47&state=Enabled Result: = Enabling VR service provider failed and observed following exception: 2014-06-03 06:13:54,846 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (ApiServer-8:ctx-8602d969 ctx-e30c2238) submit async job-82, details: AsyncJobVO {id:82, userId: 1, accountId: 1, instanceType: PhysicalNetworkServiceProvider, instanceId: null, cmd: org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd, cmdInfo: {"id":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxDetails":"{\"PhysicalNetworkServiceProvider\":\"beb30cda-7e3a-44e9-b179-c1c6fd605b47\",\"com.cloud.network.PhysicalNetworkServiceProvider\":6}","cmdEventType":"SERVICE.PROVIDER.UPDATE","ctxUserId":"1","state":"Enabled","httpmethod":"GET","uuid":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxAccountId":"1","ctxStartEventId":"218"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-06-03 06:13:54,853 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-45:ctx-4f22f44a job-82) Add job-82 into job monitoring 2014-06-03 06:13:54,853 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-45:ctx-4f22f44a job-82) Executing AsyncJobVO {id:82, userId: 1, accountId: 1, instanceType: PhysicalNetworkServiceProvider, instanceId: null, cmd: org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd, cmdInfo: {"id":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxDetails":"{\"PhysicalNetworkServiceProvider\":\"beb30cda-7e3a-44e9-b179-c1c6fd605b47\",\"com.cloud.network.PhysicalNetworkServiceProvider\":6}","cmdEventType":"SERVICE.PROVIDER.UPDATE","ctxUserId":"1","state":"Enabled","httpmethod":"GET","uuid":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxAccountId":"1","ctxStartEventId":"218"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-06-03 06:13:54,860 WARN [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) Received unknown parameters for command updateNetworkServiceProvider. Unknown parameters : ctxdetails 2014-06-03 06:13:54,871 DEBUG [c.c.n.NetworkServiceImpl] (API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) trying to update the state of the service provider id=6 on physical network: 201 to state: Enabled 2014-06-03 06:13:54,878 DEBUG [c.c.s.StatsCollector] (StatsCollector-2:ctx-e6a2a82e) HostStatsCollector is running... 2014-06-03 06:13:54,885 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-45:ctx-4f22f44a job-82) Unexpected exception while executing org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd com.cloud.utils.exception.CloudRuntimeException: Provider is not ready, cannot Enable the provider, please configure the provider first at com.cloud.network.NetworkServiceImpl.updateNetworkServiceProvider(NetworkServiceImpl.java:3425) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventU
[jira] [Updated] (CLOUDSTACK-6819) [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6819: -- Attachment: ovstunnel-host14.log ovstunnel-host13.log management-server.rar > [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host > > > Key: CLOUDSTACK-6819 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6819 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Critical > Labels: ovs > Fix For: 4.4.0 > > Attachments: management-server.rar, ovstunnel-host13.log, > ovstunnel-host14.log > > > [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host > even though the network spanned more than one host > Steps to reproduce: > === > 1.Bring up CS in advanced zone with multiple clusters(2-3 clusters with 1 > host in each cluster) > 2.Create network offering with connectivity service and OVS as the service > provider > 3.Add one guest account and deploy few vms with this new account > 4.Use host tags to deploy vms in all the clusters to make sure that network > is spanned accross all the clusters > 5.Delete the account > Result: > = > Account deletion was successful and also ovs bridges were deleted from both > the hosts but the ovsTunnel porr(vif) for this network was unplugged only > from one host's dom0(the host to which OvsDestroyBridgeCommand was sent) but > not from the other host's dom0 > Observations: > === > Following is the log snippet from MS log file during account deletion: > Network was snapped across two hosts Rack1Pod1Host14 and Rack1Pod1Host13 but > OvsDestroyBridgeCommand was sent only to Rack1Pod1Host13 > 2014-06-02 07:11:19,838 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (Work-Job-Executor-18:ctx-c73e49f0 job-56/job-57 ctx-e2515de4) Asking Ovs to > release NicProfile[26-16-2e06143e-28bd-4b43-ae0b-23a71bf0ed35-10.1.1.197-null > 2014-06-02 07:11:19,839 DEBUG [c.c.n.e.OvsElement] > (Work-Job-Executor-18:ctx-c73e49f0 job-56/job-57 ctx-e2515de4) Checking if > OvsElement can handle service Connectivity on network acc2-cs-gre > 2014-06-02 07:11:45,654 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Asking Ovs to > release NicProfile[30-18-273ebec1-867a-4081-8607-cb19af4c133d-10.1.1.52-null > 2014-06-02 07:11:45,655 DEBUG [c.c.n.e.OvsElement] > (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Checking if > OvsElement can handle service Connectivity on network acc2-cs-gre > 2014-06-02 07:11:45,665 DEBUG [c.c.n.o.OvsTunnelManagerImpl] > (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroying > bridge for network 207 on host:1 > 2014-06-02 07:11:45,670 DEBUG [c.c.a.t.Request] > (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq > 1-8504203471359062600: Sending { Cmd , MgmtId: 7332683579487, via: > 1(Rack1Pod1Host13), Ver: v1, Flags: 100111, > [{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":207,"name":"OVSTunnel992","hostId":1,"wait":0}}] > } > 2014-06-02 07:11:45,670 DEBUG [c.c.a.t.Request] > (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq > 1-8504203471359062600: Executing: { Cmd , MgmtId: 7332683579487, via: > 1(Rack1Pod1Host13), Ver: v1, Flags: 100111, > [{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":207,"name":"OVSTunnel992","hostId":1,"wait":0}}] > } > 2014-06-02 07:11:45,761 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-148:ctx-0a89d399) Xen Server network for tunnels > found:OVSTunnel992 > 2014-06-02 07:11:45,807 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-148:ctx-0a89d399) Destroy temp dom0 vifOVSTunnel992 success > 2014-06-02 07:11:46,127 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-148:ctx-0a89d399) OVS Bridge destroyed > 2014-06-02 07:11:46,232 DEBUG [c.c.n.o.OvsTunnelManagerImpl] > (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroy bridge > fornetwork 207 successful > 2014-06-02 07:11:46,234 DEBUG [c.c.n.o.OvsTunnelManagerImpl] > (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroying > tunnel to 1 from 4 > 2014-06-02 07:11:46,239 DEBUG [c.c.a.t.Request] > (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq > 4-8413287053881512061: Sending { Cmd , MgmtId: 7332683579487, via: > 4(Rack1Pod1Host14), Ver: v1, Flags: 100111, > [{"com.cloud
[jira] [Created] (CLOUDSTACK-6819) [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host
Sanjeev N created CLOUDSTACK-6819: - Summary: [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host Key: CLOUDSTACK-6819 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6819 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host even though the network spanned more than one host Steps to reproduce: === 1.Bring up CS in advanced zone with multiple clusters(2-3 clusters with 1 host in each cluster) 2.Create network offering with connectivity service and OVS as the service provider 3.Add one guest account and deploy few vms with this new account 4.Use host tags to deploy vms in all the clusters to make sure that network is spanned accross all the clusters 5.Delete the account Result: = Account deletion was successful and also ovs bridges were deleted from both the hosts but the ovsTunnel porr(vif) for this network was unplugged only from one host's dom0(the host to which OvsDestroyBridgeCommand was sent) but not from the other host's dom0 Observations: === Following is the log snippet from MS log file during account deletion: Network was snapped across two hosts Rack1Pod1Host14 and Rack1Pod1Host13 but OvsDestroyBridgeCommand was sent only to Rack1Pod1Host13 2014-06-02 07:11:19,838 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Work-Job-Executor-18:ctx-c73e49f0 job-56/job-57 ctx-e2515de4) Asking Ovs to release NicProfile[26-16-2e06143e-28bd-4b43-ae0b-23a71bf0ed35-10.1.1.197-null 2014-06-02 07:11:19,839 DEBUG [c.c.n.e.OvsElement] (Work-Job-Executor-18:ctx-c73e49f0 job-56/job-57 ctx-e2515de4) Checking if OvsElement can handle service Connectivity on network acc2-cs-gre 2014-06-02 07:11:45,654 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Asking Ovs to release NicProfile[30-18-273ebec1-867a-4081-8607-cb19af4c133d-10.1.1.52-null 2014-06-02 07:11:45,655 DEBUG [c.c.n.e.OvsElement] (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Checking if OvsElement can handle service Connectivity on network acc2-cs-gre 2014-06-02 07:11:45,665 DEBUG [c.c.n.o.OvsTunnelManagerImpl] (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroying bridge for network 207 on host:1 2014-06-02 07:11:45,670 DEBUG [c.c.a.t.Request] (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 1-8504203471359062600: Sending { Cmd , MgmtId: 7332683579487, via: 1(Rack1Pod1Host13), Ver: v1, Flags: 100111, [{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":207,"name":"OVSTunnel992","hostId":1,"wait":0}}] } 2014-06-02 07:11:45,670 DEBUG [c.c.a.t.Request] (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 1-8504203471359062600: Executing: { Cmd , MgmtId: 7332683579487, via: 1(Rack1Pod1Host13), Ver: v1, Flags: 100111, [{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":207,"name":"OVSTunnel992","hostId":1,"wait":0}}] } 2014-06-02 07:11:45,761 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-148:ctx-0a89d399) Xen Server network for tunnels found:OVSTunnel992 2014-06-02 07:11:45,807 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-148:ctx-0a89d399) Destroy temp dom0 vifOVSTunnel992 success 2014-06-02 07:11:46,127 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-148:ctx-0a89d399) OVS Bridge destroyed 2014-06-02 07:11:46,232 DEBUG [c.c.n.o.OvsTunnelManagerImpl] (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroy bridge fornetwork 207 successful 2014-06-02 07:11:46,234 DEBUG [c.c.n.o.OvsTunnelManagerImpl] (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroying tunnel to 1 from 4 2014-06-02 07:11:46,239 DEBUG [c.c.a.t.Request] (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 4-8413287053881512061: Sending { Cmd , MgmtId: 7332683579487, via: 4(Rack1Pod1Host14), Ver: v1, Flags: 100111, [{"com.cloud.agent.api.OvsDestroyTunnelCommand":{"networkId":207,"networkName":"OVSTunnel992","inPortName":"t992-4-1","wait":0}}] } 2014-06-02 07:11:46,239 DEBUG [c.c.a.t.Request] (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 4-8413287053881512061: Executing: { Cmd , MgmtId: 7332683579487, via: 4(Rack1Pod1Host14), Ver: v1, Flags: 100111, [{"com.cloud.agent.api.OvsDestroyTunnelCommand":{"networkId":207,"networkName":"OVSTunnel992","inPortName":"t992-4-1","wait":0}}] } 2014-06-02 07:11:46,324 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-296:ctx-5132
[jira] [Updated] (CLOUDSTACK-6813) vhd-util is not available on xen servers after adding them to CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6813: -- Attachment: management-server.rar > vhd-util is not available on xen servers after adding them to CS > > > Key: CLOUDSTACK-6813 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6813 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.4.0 > Environment: Any build from 4.4 branch > Hypervisor: Xenserver >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.rar > > > vhd-util is not available on xen servers after adding them to CS. > 1.Fresh install Xenserver with 6.2 > 2.Fresh install MS with build from 4.4 branch > 3.Create a zone > When host is added to CS , as part of host addition CS pushes scripts to > Xenserver. However it is not copying vhd-util. > So all the volume creations would fail. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6813) vhd-util is not available on xen servers after adding them to CS
Sanjeev N created CLOUDSTACK-6813: - Summary: vhd-util is not available on xen servers after adding them to CS Key: CLOUDSTACK-6813 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6813 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.4.0 Environment: Any build from 4.4 branch Hypervisor: Xenserver Reporter: Sanjeev N Priority: Critical Fix For: 4.4.0 vhd-util is not available on xen servers after adding them to CS. 1.Fresh install Xenserver with 6.2 2.Fresh install MS with build from 4.4 branch 3.Create a zone When host is added to CS , as part of host addition CS pushes scripts to Xenserver. However it is not copying vhd-util. So all the volume creations would fail. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6798) [OVS] Network update from OVS to vlan does not implement the network properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6798: -- Attachment: management-server.rar Attached MS log file. > [OVS] Network update from OVS to vlan does not implement the network properly > - > > Key: CLOUDSTACK-6798 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6798 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > d130530bd3e1cd6d8249d5045e00e4e4e2201521 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Critical > Labels: ovs > Fix For: 4.4.0 > > Attachments: management-server.rar > > > [OVS] Network update from OVS to vlan does not implement the network properly > Steps to Reproduce: > == > 1.Bring up CS in advanced zone with Xen cluster > 2.Create physical network with GRE isolation > 3.Create network offering with virtualnetworking and OVS as the connectivity > service provider > 4.Create one guest network with above offering > 5.Deploy few vms in the above network > 6.Stop all the vms and update network to default isolated network offering > "Offering for Isolated networks with Source Nat service" > 7.Deploy one vm in the network after network update > Result: > == > 1.Network update was successful but the network is not implemented propertly. > Network did not get any vlan ID. Broadcast uri for the network still remains > as vs://985 instead of vlan://985. > 2.So the guest vms would not get any ip addresses. > 3.Network is of no use. On Xenserver cluster CS is not creating network with > VLAN 985. Deploying new vms or starting the existing vms are plugging vifs to > the existing tunnel bridge but tunnel ports not not getting created between > the hosts since the offering does not have the OVS provider. > Following are the network details from db after network update: > mysql> select * from networks where id=207\G; > *** 1. row *** >id: 207 > name: Admin-ovs > uuid: c545e326-218d-49ba-8fb8-4dabd9ab612f > display_text: Admin-ovs > traffic_type: Guest > broadcast_domain_type: Vswitch > broadcast_uri: vs://985 > gateway: 10.1.1.1 > cidr: 10.1.1.0/24 > mode: Dhcp > network_offering_id: 8 > physical_network_id: 200 >data_center_id: 1 > guru_name: OvsGuestNetworkGuru > state: Implemented > related: 207 > domain_id: 1 >account_id: 2 > dns1: NULL > dns2: NULL > guru_data: NULL >set_fields: 0 > acl_type: Account >network_domain: cs2cloud.internal >reservation_id: 8b9fa583-35a7-4b43-a023-08efc44b88ee >guest_type: Isolated > restart_required: 0 > created: 2014-05-27 09:42:15 > removed: NULL > specify_ip_ranges: 0 >vpc_id: NULL > ip6_gateway: NULL > ip6_cidr: NULL > network_cidr: NULL > display_network: 1 >network_acl_id: NULL > streched_l2: 0 > 1 row in set (0.00 sec) > mysql> select * from network_offerings where id=8\G; > *** 1. row *** >id: 8 > name: DefaultIsolatedNetworkOfferingWithSourceNatService > uuid: d82a97f9-366a-491b-9f18-ef96aac732bc > unique_name: DefaultIsolatedNetworkOfferingWithSourceNatService > display_text: Offering for Isolated networks with Source Nat > service enabled > nw_rate: NULL > mc_rate: NULL > traffic_type: Guest > tags: NULL > system_only: 0 > specify_vlan: 0 > service_offering_id: NULL > conserve_mode: 1 > created: 2014-05-26 11:21:39 > removed: NULL > default: 1 > availability: Required > dedicated_lb_service: 1 > shared_source_nat_service: 0 > sort_key: 0 > redundant_router_service: 0 > state: Enabled >guest_type: Isolated >elastic_ip_service: 0 > eip_associate_public_ip: 1 >elastic_lb_service: 0 > specify_ip_ranges: 0 >inline: 0 > is_persistent: 0 > internal_lb: 0
[jira] [Created] (CLOUDSTACK-6798) [OVS] Network update from OVS to vlan does not implement the network properly
Sanjeev N created CLOUDSTACK-6798: - Summary: [OVS] Network update from OVS to vlan does not implement the network properly Key: CLOUDSTACK-6798 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6798 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit d130530bd3e1cd6d8249d5045e00e4e4e2201521 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVS] Network update from OVS to vlan does not implement the network properly Steps to Reproduce: == 1.Bring up CS in advanced zone with Xen cluster 2.Create physical network with GRE isolation 3.Create network offering with virtualnetworking and OVS as the connectivity service provider 4.Create one guest network with above offering 5.Deploy few vms in the above network 6.Stop all the vms and update network to default isolated network offering "Offering for Isolated networks with Source Nat service" 7.Deploy one vm in the network after network update Result: == 1.Network update was successful but the network is not implemented propertly. Network did not get any vlan ID. Broadcast uri for the network still remains as vs://985 instead of vlan://985. 2.So the guest vms would not get any ip addresses. 3.Network is of no use. On Xenserver cluster CS is not creating network with VLAN 985. Deploying new vms or starting the existing vms are plugging vifs to the existing tunnel bridge but tunnel ports not not getting created between the hosts since the offering does not have the OVS provider. Following are the network details from db after network update: mysql> select * from networks where id=207\G; *** 1. row *** id: 207 name: Admin-ovs uuid: c545e326-218d-49ba-8fb8-4dabd9ab612f display_text: Admin-ovs traffic_type: Guest broadcast_domain_type: Vswitch broadcast_uri: vs://985 gateway: 10.1.1.1 cidr: 10.1.1.0/24 mode: Dhcp network_offering_id: 8 physical_network_id: 200 data_center_id: 1 guru_name: OvsGuestNetworkGuru state: Implemented related: 207 domain_id: 1 account_id: 2 dns1: NULL dns2: NULL guru_data: NULL set_fields: 0 acl_type: Account network_domain: cs2cloud.internal reservation_id: 8b9fa583-35a7-4b43-a023-08efc44b88ee guest_type: Isolated restart_required: 0 created: 2014-05-27 09:42:15 removed: NULL specify_ip_ranges: 0 vpc_id: NULL ip6_gateway: NULL ip6_cidr: NULL network_cidr: NULL display_network: 1 network_acl_id: NULL streched_l2: 0 1 row in set (0.00 sec) mysql> select * from network_offerings where id=8\G; *** 1. row *** id: 8 name: DefaultIsolatedNetworkOfferingWithSourceNatService uuid: d82a97f9-366a-491b-9f18-ef96aac732bc unique_name: DefaultIsolatedNetworkOfferingWithSourceNatService display_text: Offering for Isolated networks with Source Nat service enabled nw_rate: NULL mc_rate: NULL traffic_type: Guest tags: NULL system_only: 0 specify_vlan: 0 service_offering_id: NULL conserve_mode: 1 created: 2014-05-26 11:21:39 removed: NULL default: 1 availability: Required dedicated_lb_service: 1 shared_source_nat_service: 0 sort_key: 0 redundant_router_service: 0 state: Enabled guest_type: Isolated elastic_ip_service: 0 eip_associate_public_ip: 1 elastic_lb_service: 0 specify_ip_ranges: 0 inline: 0 is_persistent: 0 internal_lb: 0 public_lb: 1 egress_default_policy: 0 concurrent_connections: NULL keep_alive_enabled: 0 supports_streched_l2: 0 1 row in set (0.00 sec) Please look for job-133 in the attached MS log file for the sequence of events happened during update network. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6796) [OVS]Failure in network update does not change network offering to original offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6796: -- Attachment: management-server.rar Attached MS log file > [OVS]Failure in network update does not change network offering to original > offering > > > Key: CLOUDSTACK-6796 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6796 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > d130530bd3e1cd6d8249d5045e00e4e4e2201521 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Critical > Labels: ovs > Fix For: 4.4.0 > > Attachments: management-server.rar > > > [OVS]Failure in network update does not change network offering to original > offering hence starting vms would fail in the network > Steps to Reproduce: > === > 1.Bring up CS in advanced zone with xen cluster > 2.Create physical network with GRE isolation > 3.Create network with default offering > "DefaultIsolatedNetworkOfferingWithSourceNatService" > 4.Deploy few vms in the above netwrok > 5.Create another network offering with virtual networking service and OVS as > the connectivity service provider > 6.Stop all the vms in the network > 7.Update network with new offering created at step5 > Results: > == > Network update will fail from vlan isolation to connectivity service due to > bug CS-6795. However the network offering id for the network is changing to > new network offering. It is not setting back to default isolated network > offering. > mysql> select * from ntwk_offering_service_map where network_offering_id=15; > ++-++---+-+ > | id | network_offering_id | service| provider | created > | > ++-++---+-+ > | 60 | 15 | Connectivity | Ovs | 2014-05-26 > 12:51:34 | > | 55 | 15 | Dhcp | VirtualRouter | 2014-05-26 > 12:51:34 | > | 54 | 15 | Dns| VirtualRouter | 2014-05-26 > 12:51:34 | > | 61 | 15 | Firewall | VirtualRouter | 2014-05-26 > 12:51:34 | > | 58 | 15 | Lb | VirtualRouter | 2014-05-26 > 12:51:34 | > | 57 | 15 | PortForwarding | VirtualRouter | 2014-05-26 > 12:51:34 | > | 56 | 15 | SourceNat | VirtualRouter | 2014-05-26 > 12:51:34 | > | 59 | 15 | StaticNat | VirtualRouter | 2014-05-26 > 12:51:34 | > | 53 | 15 | UserData | VirtualRouter | 2014-05-26 > 12:51:34 | > ++-++---+-+ > 9 rows in set (0.00 sec) > Following is the network created with default isolated network offering but > after network update failure the offering still shows the new offering: > mysql> select * from networks where id=211\G; > *** 1. row *** >id: 211 > name: vlan1 > uuid: f803e17f-b59b-4229-9e70-5bb4fcfc2570 > display_text: vlan1 > traffic_type: Guest > broadcast_domain_type: Vlan > broadcast_uri: vlan://986 > gateway: 10.1.1.1 > cidr: 10.1.1.0/24 > mode: Dhcp > network_offering_id: 15 > physical_network_id: 200 >data_center_id: 1 > guru_name: ExternalGuestNetworkGuru > state: Shutdown > related: 211 > domain_id: 1 >account_id: 2 > dns1: NULL > dns2: NULL > guru_data: NULL >set_fields: 0 > acl_type: Account >network_domain: cs2cloud.internal >reservation_id: c2b3cb64-adfd-4722-9aed-8d2d7710e32f >guest_type: Isolated > restart_required: 0 > created: 2014-05-28 11:09:16 > removed: NULL > specify_ip_ranges: 0 >vpc_id: NULL > ip6_gateway: NULL > ip6_cidr: NULL > network_cidr: NULL > display_network: 1 >network_acl_id: NULL > streched_l2: 0 > 1 row in set (0.00 sec) > ERROR: > No query specified > Impact of this: > === > Since the network offering is with connectivity service , CS is failed to > implement the network and vm start is failing. > 2014-05-28 07:52:28,188 DEBUG [c.c.n.e.OvsElement] >
[jira] [Created] (CLOUDSTACK-6796) [OVS]Failure in network update does not change network offering to original offering
Sanjeev N created CLOUDSTACK-6796: - Summary: [OVS]Failure in network update does not change network offering to original offering Key: CLOUDSTACK-6796 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6796 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit d130530bd3e1cd6d8249d5045e00e4e4e2201521 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 Attachments: management-server.rar [OVS]Failure in network update does not change network offering to original offering hence starting vms would fail in the network Steps to Reproduce: === 1.Bring up CS in advanced zone with xen cluster 2.Create physical network with GRE isolation 3.Create network with default offering "DefaultIsolatedNetworkOfferingWithSourceNatService" 4.Deploy few vms in the above netwrok 5.Create another network offering with virtual networking service and OVS as the connectivity service provider 6.Stop all the vms in the network 7.Update network with new offering created at step5 Results: == Network update will fail from vlan isolation to connectivity service due to bug CS-6795. However the network offering id for the network is changing to new network offering. It is not setting back to default isolated network offering. mysql> select * from ntwk_offering_service_map where network_offering_id=15; ++-++---+-+ | id | network_offering_id | service| provider | created | ++-++---+-+ | 60 | 15 | Connectivity | Ovs | 2014-05-26 12:51:34 | | 55 | 15 | Dhcp | VirtualRouter | 2014-05-26 12:51:34 | | 54 | 15 | Dns| VirtualRouter | 2014-05-26 12:51:34 | | 61 | 15 | Firewall | VirtualRouter | 2014-05-26 12:51:34 | | 58 | 15 | Lb | VirtualRouter | 2014-05-26 12:51:34 | | 57 | 15 | PortForwarding | VirtualRouter | 2014-05-26 12:51:34 | | 56 | 15 | SourceNat | VirtualRouter | 2014-05-26 12:51:34 | | 59 | 15 | StaticNat | VirtualRouter | 2014-05-26 12:51:34 | | 53 | 15 | UserData | VirtualRouter | 2014-05-26 12:51:34 | ++-++---+-+ 9 rows in set (0.00 sec) Following is the network created with default isolated network offering but after network update failure the offering still shows the new offering: mysql> select * from networks where id=211\G; *** 1. row *** id: 211 name: vlan1 uuid: f803e17f-b59b-4229-9e70-5bb4fcfc2570 display_text: vlan1 traffic_type: Guest broadcast_domain_type: Vlan broadcast_uri: vlan://986 gateway: 10.1.1.1 cidr: 10.1.1.0/24 mode: Dhcp network_offering_id: 15 physical_network_id: 200 data_center_id: 1 guru_name: ExternalGuestNetworkGuru state: Shutdown related: 211 domain_id: 1 account_id: 2 dns1: NULL dns2: NULL guru_data: NULL set_fields: 0 acl_type: Account network_domain: cs2cloud.internal reservation_id: c2b3cb64-adfd-4722-9aed-8d2d7710e32f guest_type: Isolated restart_required: 0 created: 2014-05-28 11:09:16 removed: NULL specify_ip_ranges: 0 vpc_id: NULL ip6_gateway: NULL ip6_cidr: NULL network_cidr: NULL display_network: 1 network_acl_id: NULL streched_l2: 0 1 row in set (0.00 sec) ERROR: No query specified Impact of this: === Since the network offering is with connectivity service , CS is failed to implement the network and vm start is failing. 2014-05-28 07:52:28,188 DEBUG [c.c.n.e.OvsElement] (Work-Job-Executor-47:ctx-3e2b5a9e job-122/job-123 ctx-ccbcca96) Checking if OvsElement can handle service SourceNat on network vlan1 2014-05-28 07:52:28,189 DEBUG [c.c.n.e.OvsElement] (Work-Job-Executor-47:ctx-3e2b5a9e job-122/job-123 ctx-ccbcca96) Virtual router element doesn't need to associate ip addresses on the backend; virtual router doesn't exist in the network 211 2014-05-28 07:52:28,193 DEBUG [c.c.n.e.VirtualRouterElement] (Work-Job-Executor-47:ctx-3e2b5a9e job-122/job-12
[jira] [Created] (CLOUDSTACK-6795) [OVS]Faile to upgrade network from vlan isolation to network with ovs provider
Sanjeev N created CLOUDSTACK-6795: - Summary: [OVS]Faile to upgrade network from vlan isolation to network with ovs provider Key: CLOUDSTACK-6795 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6795 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit d130530bd3e1cd6d8249d5045e00e4e4e2201521 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 Attachments: management-server.rar [OVS]Faile to upgrade network from vlan isolation to network with ovs provider Steps to reproduce: == 1.Bring up CS in advanced zone with xen cluster 2.Create physical network with GRE isolation 3.Create an isolated network offering with default offering "DefaultIsolatedNetworkOfferingWithSourceNatService" 4.Deploy one vm using above network offering 5.Create another guest network with Virtual networking and OVS as the connectivity service provider 6.Stop the vm and upgrade network with above network offering Result: = Failed to upgrade network with the offering which has connectivity service and ovs as the provider Observations: == Following is the log snippet from MS log: 2014-05-28 07:27:28,419 DEBUG [c.c.a.t.Request] (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Seq 4-1333065489701674831: Received: { Ans: , MgmtId: 7332683579487, via: 4, Ver: v1, Flags: 10, { Answer } } 2014-05-28 07:27:28,429 INFO [o.a.c.s.v.VolumeServiceImpl] (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Volume 26 is not referred anywhere, remove it from volumes table 2014-05-28 07:27:28,435 DEBUG [c.c.v.VirtualMachineManagerImpl] (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Expunged VM[DomainRouter|r-26-VM] 2014-05-28 07:27:28,458 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-b2ec9be1) Zone 1 is ready to launch console proxy 2014-05-28 07:27:28,480 DEBUG [c.c.n.NetworkServiceImpl] (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Implementing the network Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] elements and resources as a part of network update 2014-05-28 07:27:28,486 DEBUG [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Asking Ovs to implemenet Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] 2014-05-28 07:27:28,486 DEBUG [c.c.n.e.OvsElement] (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) entering OvsElement implement function for network vlan1 (state Implemented) 2014-05-28 07:27:28,486 DEBUG [c.c.n.e.OvsElement] (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Checking if OvsElement can handle service Connectivity on network vlan1 2014-05-28 07:27:28,487 WARN [c.c.n.NetworkServiceImpl] (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Failed to implement network Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] elements and resources as a part of network update due to com.cloud.utils.exception.CloudRuntimeException: Failed to implement provider Ovs for network with specified id at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1081) at com.cloud.network.NetworkServiceImpl.updateGuestNetwork(NetworkServiceImpl.java:2303) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy
[jira] [Updated] (CLOUDSTACK-6795) [OVS]Faile to upgrade network from vlan isolation to network with ovs provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6795: -- Attachment: management-server.rar Attached MS log file > [OVS]Faile to upgrade network from vlan isolation to network with ovs provider > -- > > Key: CLOUDSTACK-6795 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6795 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > d130530bd3e1cd6d8249d5045e00e4e4e2201521 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Critical > Labels: ovs > Fix For: 4.4.0 > > Attachments: management-server.rar > > > [OVS]Faile to upgrade network from vlan isolation to network with ovs provider > Steps to reproduce: > == > 1.Bring up CS in advanced zone with xen cluster > 2.Create physical network with GRE isolation > 3.Create an isolated network offering with default offering > "DefaultIsolatedNetworkOfferingWithSourceNatService" > 4.Deploy one vm using above network offering > 5.Create another guest network with Virtual networking and OVS as the > connectivity service provider > 6.Stop the vm and upgrade network with above network offering > Result: > = > Failed to upgrade network with the offering which has connectivity service > and ovs as the provider > Observations: > == > Following is the log snippet from MS log: > 2014-05-28 07:27:28,419 DEBUG [c.c.a.t.Request] > (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Seq > 4-1333065489701674831: Received: { Ans: , MgmtId: 7332683579487, via: 4, > Ver: v1, Flags: 10, { Answer } } > 2014-05-28 07:27:28,429 INFO [o.a.c.s.v.VolumeServiceImpl] > (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Volume 26 is not > referred anywhere, remove it from volumes table > 2014-05-28 07:27:28,435 DEBUG [c.c.v.VirtualMachineManagerImpl] > (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Expunged > VM[DomainRouter|r-26-VM] > 2014-05-28 07:27:28,458 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-b2ec9be1) Zone 1 is ready to launch console proxy > 2014-05-28 07:27:28,480 DEBUG [c.c.n.NetworkServiceImpl] > (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Implementing the > network Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] elements and > resources as a part of network update > 2014-05-28 07:27:28,486 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Asking Ovs to > implemenet Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] > 2014-05-28 07:27:28,486 DEBUG [c.c.n.e.OvsElement] > (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) entering OvsElement > implement function for network vlan1 (state Implemented) > 2014-05-28 07:27:28,486 DEBUG [c.c.n.e.OvsElement] > (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Checking if > OvsElement can handle service Connectivity on network vlan1 > 2014-05-28 07:27:28,487 WARN [c.c.n.NetworkServiceImpl] > (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Failed to implement > network Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] elements and > resources as a part of network update due to > com.cloud.utils.exception.CloudRuntimeException: Failed to implement provider > Ovs for network with specified id > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1081) > at > com.cloud.network.NetworkServiceImpl.updateGuestNetwork(NetworkServiceImpl.java:2303) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEven
[jira] [Updated] (CLOUDSTACK-6779) [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6779: -- Attachment: ovstunnel.log_host14 ovstunnel.log_host13 management-server.rar Attached log files from MS, ovstunnel files from both the hosts inside the cluster. > [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow > table > -- > > Key: CLOUDSTACK-6779 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6779 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > d130530bd3e1cd6d8249d5045e00e4e4e2201521 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Blocker > Labels: ovs > Fix For: 4.4.0 > > Attachments: management-server.rar, ovstunnel.log_host13, > ovstunnel.log_host14 > > > [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow > table > Steps to reproduce: > > 1.Bring up CS in advanced zone with min of 2 xen hosts in a cluster > 2.Add physical network with GRE isolation > 3.Create network offering with connectivity service and OVS as the provider > 4.Create an isolated network with above offering and deploy few vms (4-5) in > that network and make sure that vms are spanned across both the hosts > 5.After this verify flow table rules on the ovs bridge > 6.Expunge one of the vms created at step4 > 7.Again verify flow table rules on the host from where vm was deleted > Result: > = > All the flow table rules were deleted from the OVS bridge. Only default flow > rule is present. > Attaching management server log file and ovstunnel log files from both the > hosts. > Please look for xapi5 and xapi7 in ovstunnel log files. > Flow table rules before destroy the vm: > [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5 > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=374.111s, table=0, n_packets=4, n_bytes=768, > priority=1100,dl_dst=ff:ff:ff:ff:ff:ff > actions=output:1,output:2,output:3,output:4,output:5 > cookie=0x0, duration=300.162s, table=0, n_packets=0, n_bytes=0, > priority=1000,ip,in_port=6,nw_dst=224.0.0.0/24 actions=drop > cookie=0x0, duration=374.122s, table=0, n_packets=0, n_bytes=0, > priority=1200,ip,in_port=5,nw_dst=224.0.0.0/24 actions=NORMAL > cookie=0x0, duration=5350.811s, table=0, n_packets=0, n_bytes=0, > priority=1200,ip,in_port=4,nw_dst=224.0.0.0/24 actions=NORMAL > cookie=0x0, duration=6016.913s, table=0, n_packets=0, n_bytes=0, > priority=1200,ip,in_port=3,nw_dst=224.0.0.0/24 actions=NORMAL > cookie=0x0, duration=6753.464s, table=0, n_packets=0, n_bytes=0, > priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL > cookie=0x0, duration=6890.423s, table=0, n_packets=7594, n_bytes=6858309, > priority=0 actions=NORMAL > cookie=0x0, duration=374.1s, table=0, n_packets=0, n_bytes=0, > priority=1100,ip,nw_dst=224.0.0.0/24 > actions=output:1,output:2,output:3,output:4,output:5 > cookie=0x0, duration=374.132s, table=0, n_packets=5, n_bytes=810, > priority=1200,in_port=5,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL > cookie=0x0, duration=5350.823s, table=0, n_packets=8, n_bytes=1236, > priority=1200,in_port=4,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL > cookie=0x0, duration=300.173s, table=0, n_packets=0, n_bytes=0, > priority=1000,in_port=6,dl_dst=ff:ff:ff:ff:ff:ff actions=drop > cookie=0x0, duration=6016.924s, table=0, n_packets=8, n_bytes=1236, > priority=1200,in_port=3,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL > cookie=0x0, duration=6753.474s, table=0, n_packets=6, n_bytes=852, > priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL > After destroying the vm: > [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5 > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=877.901s, table=0, n_packets=46, n_bytes=9748, > priority=0 actions=NORMAL > [root@Rack1Pod1Host13 ~]# -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6779) [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table
Sanjeev N created CLOUDSTACK-6779: - Summary: [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table Key: CLOUDSTACK-6779 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6779 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit d130530bd3e1cd6d8249d5045e00e4e4e2201521 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Blocker Fix For: 4.4.0 [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table Steps to reproduce: 1.Bring up CS in advanced zone with min of 2 xen hosts in a cluster 2.Add physical network with GRE isolation 3.Create network offering with connectivity service and OVS as the provider 4.Create an isolated network with above offering and deploy few vms (4-5) in that network and make sure that vms are spanned across both the hosts 5.After this verify flow table rules on the ovs bridge 6.Expunge one of the vms created at step4 7.Again verify flow table rules on the host from where vm was deleted Result: = All the flow table rules were deleted from the OVS bridge. Only default flow rule is present. Attaching management server log file and ovstunnel log files from both the hosts. Please look for xapi5 and xapi7 in ovstunnel log files. Flow table rules before destroy the vm: [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=374.111s, table=0, n_packets=4, n_bytes=768, priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:1,output:2,output:3,output:4,output:5 cookie=0x0, duration=300.162s, table=0, n_packets=0, n_bytes=0, priority=1000,ip,in_port=6,nw_dst=224.0.0.0/24 actions=drop cookie=0x0, duration=374.122s, table=0, n_packets=0, n_bytes=0, priority=1200,ip,in_port=5,nw_dst=224.0.0.0/24 actions=NORMAL cookie=0x0, duration=5350.811s, table=0, n_packets=0, n_bytes=0, priority=1200,ip,in_port=4,nw_dst=224.0.0.0/24 actions=NORMAL cookie=0x0, duration=6016.913s, table=0, n_packets=0, n_bytes=0, priority=1200,ip,in_port=3,nw_dst=224.0.0.0/24 actions=NORMAL cookie=0x0, duration=6753.464s, table=0, n_packets=0, n_bytes=0, priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL cookie=0x0, duration=6890.423s, table=0, n_packets=7594, n_bytes=6858309, priority=0 actions=NORMAL cookie=0x0, duration=374.1s, table=0, n_packets=0, n_bytes=0, priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:1,output:2,output:3,output:4,output:5 cookie=0x0, duration=374.132s, table=0, n_packets=5, n_bytes=810, priority=1200,in_port=5,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL cookie=0x0, duration=5350.823s, table=0, n_packets=8, n_bytes=1236, priority=1200,in_port=4,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL cookie=0x0, duration=300.173s, table=0, n_packets=0, n_bytes=0, priority=1000,in_port=6,dl_dst=ff:ff:ff:ff:ff:ff actions=drop cookie=0x0, duration=6016.924s, table=0, n_packets=8, n_bytes=1236, priority=1200,in_port=3,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL cookie=0x0, duration=6753.474s, table=0, n_packets=6, n_bytes=852, priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL After destroying the vm: [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=877.901s, table=0, n_packets=46, n_bytes=9748, priority=0 actions=NORMAL [root@Rack1Pod1Host13 ~]# -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6763) [OVS] Deleting one ovs bridge deletes flow table entries for other bridge as well
Sanjeev N created CLOUDSTACK-6763: - Summary: [OVS] Deleting one ovs bridge deletes flow table entries for other bridge as well Key: CLOUDSTACK-6763 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6763 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller, XenServer Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit d130530bd3e1cd6d8249d5045e00e4e4e2201521 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVS] Deleting one ovs bridge deletes flow table entries for other bridge as well Steps to Reproduce: = 1.Bring up CS in advanced zone with two hosts in a xen cluster 2.Create physical network with GRE isolation 3.Create network offering with connectivity service and OVS as the provider 4.Create a user account and deploy few vms with above network offering (make sure vms are spanned across the hosts) 5.Create another user account and repeat step4 6.Destroy all vms in account2 7.Verify flow table rules for the ovs bridge created for account1 network Result: === After deleting account2 vms ovs bridge for this network was destroyed from both the hosts and also the flow table rules for account1 network were also deleted from both the hosts Observations: === xapi3 is the bridge created for account2 network and xapi2 is for account1 network. xapi3 is for network: OVSTunnel983 xapi2 is for network: OVSTunnel984 Following is the log snippet from MS log file for deleting OVS Bridge: 2014-05-26 12:08:59,334 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Asking Ovs to release NicProfile[15-8-038ca005-deeb-4146-addf-5f8f96436e68-10.1.1.11-null 2014-05-26 12:08:59,335 DEBUG [c.c.n.e.OvsElement] (Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Checking if OvsElement can handle service Connectivity on network test2-ovs 2014-05-26 12:08:59,344 DEBUG [c.c.n.o.OvsTunnelManagerImpl] (Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Destroying bridge for network 206 on host:1 2014-05-26 12:08:59,350 DEBUG [c.c.a.t.Request] (Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Seq 1-8670555182595048072: Sending { Cmd , MgmtId: 7332683579487, via: 1(Rack1Pod1Host13), Ver: v1, Flags: 100111, [{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":206,"name":"OVSTunnel983","hostId":1,"wait":0}}] } 2014-05-26 12:08:59,350 DEBUG [c.c.a.t.Request] (Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Seq 1-8670555182595048072: Executing: { Cmd , MgmtId: 7332683579487, via: 1(Rack1Pod1Host13), Ver: v1, Flags: 100111, [{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":206,"name":"OVSTunnel983","hostId":1,"wait":0}}] } 2014-05-26 12:08:59,350 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-183:ctx-51a7921b) Seq 1-8670555182595048072: Executing request 2014-05-26 12:08:59,395 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-183:ctx-51a7921b) A VIF for dom0 has already been found - No need to create one 2014-05-26 12:08:59,414 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-183:ctx-51a7921b) Xen Server network for tunnels found:OVSTunnel983 2014-05-26 12:08:59,451 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-183:ctx-51a7921b) A VIF in dom0 for the network is found - so destroy the vif 2014-05-26 12:08:59,455 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-183:ctx-51a7921b) Destroy temp dom0 vifOVSTunnel983 success 2014-05-26 12:08:59,816 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-183:ctx-51a7921b) OVS Bridge destroyed 2014-05-26 12:08:59,828 DEBUG [c.c.n.o.OvsTunnelManagerImpl] (Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Destroy bridge fornetwork 206 successful 2014-05-26 12:08:59,830 DEBUG [c.c.n.o.OvsTunnelManagerImpl] (Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Destroying tunnel to 1 from 4 2014-05-26 12:08:59,835 DEBUG [c.c.a.t.Request] (Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Seq 4-1333065489701667402: Sending { Cmd , MgmtId: 7332683579487, via: 4(Rack1Pod1Host14), Ver: v1, Flags: 100111, [{"com.cloud.agent.api.OvsDestroyTunnelCommand":{"networkId":206,"networkName":"OVSTunnel983","inPortName":"t983-4-1","wait":0}}] } 2014-05-26 12:08:59,835 DEBUG [c.c.a.t.Request] (Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Seq 4-1333065489701667402: Executing: { Cmd , MgmtId: 7332683579487, via: 4(Rack1Pod1Host14), Ver: v1, Flags: 100111, [{"com.cloud.agent.api.OvsDestroyTunnelCommand":{"networkId":206,"networkName":"OVSTunnel983","inPortName":"t983-4-1","wait":0}}] } 2014-05-26 12:08:59,836 DEBUG [c.c.a.m.DirectAgentA
[jira] [Updated] (CLOUDSTACK-6762) [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not added in bridge flow table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6762: -- Attachment: management-server.rar > [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not > added in bridge flow table > --- > > Key: CLOUDSTACK-6762 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6762 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 with commit > d130530bd3e1cd6d8249d5045e00e4e4e2201521 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Critical > Labels: ovs > Fix For: 4.4.0 > > Attachments: management-server.rar > > > [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not > added in bridge flow table > Steps to reproduce: > > 1.Bring up CS in advanced zone with two hosts in xen cluster > 2.Add physical network with isolation type GRE > 3.Create an isolated network offering with connectivity service and OVS asc > the provider > 4.Create a user account and deploy one vm with above network offering and > make sure that vm comes on host1 and VR comes on host2 > 5.Verify the flow table on the ovs bridge created for this network > Result: > == > flow table rules to drop multicast and broacast traffic on tunnel ports are > not added on the host where VR is running but the same rules are added on the > host where vm is running > VR is running on the following host: > [root@Rack1Pod1Host14 ~]# ovs-ofctl dump-flows xapi3 > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=988.459s, table=0, n_packets=5, n_bytes=810, > priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2 > cookie=0x0, duration=988.469s, table=0, n_packets=0, n_bytes=0, > priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL > cookie=0x0, duration=1011.44s, table=0, n_packets=20, n_bytes=2354, > priority=0 actions=NORMAL > cookie=0x0, duration=988.45s, table=0, n_packets=0, n_bytes=0, > priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2 > cookie=0x0, duration=988.479s, table=0, n_packets=0, n_bytes=0, > priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL > [root@Rack1Pod1Host14 ~]# > VM is running on the following host: > > [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi3 > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=456.937s, table=0, n_packets=0, n_bytes=0, > priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2 > cookie=0x0, duration=456.951s, table=0, n_packets=0, n_bytes=0, > priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL > cookie=0x0, duration=551.614s, table=0, n_packets=0, n_bytes=0, > priority=1000,ip,in_port=1,nw_dst=224.0.0.0/24 actions=drop > cookie=0x0, duration=551.932s, table=0, n_packets=15, n_bytes=1836, > priority=0 actions=NORMAL > cookie=0x0, duration=456.926s, table=0, n_packets=0, n_bytes=0, > priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2 > cookie=0x0, duration=551.624s, table=0, n_packets=0, n_bytes=0, > priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=drop > cookie=0x0, duration=456.962s, table=0, n_packets=9, n_bytes=2178, > priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL > On both the hosts port 1 is tunnel port and port 2 is vif. > Following is the log snippet for xapi3 from host where VR is running: > 2014-05-26 08:06:14DEBUG [root] About to manually create the bridge:xapi3 > 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', > '--may-exist', 'add-br', 'xapi3', '--', 'set', 'bridge', 'xapi3', > 'other_config:gre_key=OVSTunnel983'] > 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', > 'Bridge', 'xapi3', > 'external_ids:xs-network-uuid=9d7ff1a3-342a-b206-ca09-7fbe8bcabfd0'] > 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', > 'Bridge', 'xapi3', 'stp_enable=true'] > 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', > 'bridge', 'xapi3', 'other_config:gre_key'] > 2014-05-26 08:06:14DEBUG [root] Executing:['/opt/xensource/bin/xe', > 'network-list', 'bridge=xapi3', '--minimal'] > 2014-05-26 08:06:14DEBUG [root] Setup_ovs_bridge completed with > result:SUCCESS:xapi3 > 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', > '--timeout=30', 'wait-until', 'bridge', 'xapi3', '--', 'get', 'bridge', > 'xapi3', 'name'] > 2014-05-26 08:06:14DEBUG [root] bridge xapi3 for creating tunnel - > VERIFIED > 2014-05-26 08:06:14DEBU