[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 >
[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
[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=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 >
[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 >
[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
[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-tabpanelfocusedCommentId=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
version
1.0
/version
file
/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}
/file
script
/opt/cloud/bin/update_config.py ip_associations.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py staticnat_rules.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py forwarding_rules.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py network_acl.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/var/cache/cloud/vm_metadata.json
{vm_ip_address:10.1.1.194,vm_metadata:[[userdata,user-data,null],[metadata,service-offering,Tiny
[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] [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] [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
version
1.0
/version
file
/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}
/file
script
/opt/cloud/bin/update_config.py ip_associations.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py staticnat_rules.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py forwarding_rules.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py network_acl.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/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:vmdata}
/file
script
/opt/cloud/bin/update_config.py vm_metadata.json
/script
file
/var/cache/cloud/vm_metadata.json
[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
version
1.0
/version
file
/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}
/file
script
/opt/cloud/bin/update_config.py ip_associations.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py staticnat_rules.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py forwarding_rules.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py network_acl.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/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}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/var/cache/cloud/vm_metadata.json
{vm_ip_address:10.1.1.194,vm_metadata:[[userdata,user-data,null],[metadata,service-offering,Tiny
[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-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.lt;initgt;(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] [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.lt;initgt;(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
[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.lt;initgt;(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]
[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.lt;initgt;(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:1278)
[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-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-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] [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] [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] [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] [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] [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] [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=createSnapshotvolumeid=998fd155-7d60-4426-a91c-0a2f1d598021account=testdomainid=1quiescevm=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: 1, accountId: 1, instanceType: null, instanceId: null, cmd:
com.cloud.storage.VmWorkTakeVolumeSnapshot, cmdInfo:
[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=createSnapshotvolumeid=998fd155-7d60-4426-a91c-0a2f1d598021account=testdomainid=1quiescevm=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
[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-tabpanelfocusedCommentId=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=createSnapshotvolumeid=998fd155-7d60-4426-a91c-0a2f1d598021account=testdomainid=1quiescevm=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]
[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=deleteAccountresponse=jsonsessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3Did=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=deleteAccountresponse=jsonsessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3Did=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-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Seq
4-4574812796478292948: Received: { Ans: , MgmtId: 6637838401571, via: 4,
[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=deleteAccountresponse=jsonsessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3Did=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=deleteAccountresponse=jsonsessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3Did=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,
[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=deleteAccountresponse=jsonsessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3Did=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=deleteAccountresponse=jsonsessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3Did=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,
[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-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-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 | Started |
[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-10718c3a14f3 | VM.CREATE | Completed | Successfully completed starting Vm. Vm Id: 10
[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] [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] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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] [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] [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-tabpanelfocusedCommentId=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 has Failed. Waited 600s. Error is
SSH Connection Failed\n']
2014-09-09 05:37:23,166 -
[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=createDiskOfferingisMirrored=falsename=customdisplaytext=customstorageType=sharedcacheMode=noneprovisioningType=thincustomized=truedisksize=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=createVolumeresponse=jsonsessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3Dname=customzoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dddiskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873bsize=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] [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=createDiskOfferingisMirrored=falsename=customdisplaytext=customstorageType=sharedcacheMode=noneprovisioningType=thincustomized=truedisksize=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=createVolumeresponse=jsonsessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3Dname=customzoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dddiskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873bsize=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-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=listTemplatessessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3Dtemplatefilter=selfid=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa_=1410351906876 API Response: === listtemplatesresponse cloud-stack-version=4.5.0-SNAPSHOTcount1/counttemplateid550ad6ac-38d2-11e4-a56e-d4ae527ccfaa/idnameCentOS 5.6(64-bit) no GUI (XenServer)/namedisplaytextCentOS 5.6(64-bit) no GUI (XenServer)/displaytextispublictrue/ispubliccreated2014-09-10T15:59:38+0530/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonestrue/crossZonesostypeid572126ea-38d2-11e4-a56e-d4ae527ccfaa/ostypeidostypenameCentOS 5.6 (64-bit)/ostypenameaccountsystem/accountzoneid680f7c3a-a9ee-4ed3-b594-981d56f8da4b/zoneidzonenamez2/zonenamesize21474836480/sizetemplatetypeBUILTIN/templatetypehypervisorXenServer/hypervisordomainROOT/domaindomainid54e9d4e4-38d2-11e4-a56e-d4ae527ccfaa/domainidisextractabletrue/isextractablechecksum905cec879afd9c9d22ecc8036131a180/checksumsshkeyenabledfalse/sshkeyenabledisdynamicallyscalabletrue/isdynamicallyscalable/template/listtemplatesresponse 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] [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=listTemplatessessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3Dtemplatefilter=selfid=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa_=1410351906876 API Response: === listtemplatesresponse cloud-stack-version=4.5.0-SNAPSHOTcount1/counttemplateid550ad6ac-38d2-11e4-a56e-d4ae527ccfaa/idnameCentOS 5.6(64-bit) no GUI (XenServer)/namedisplaytextCentOS 5.6(64-bit) no GUI (XenServer)/displaytextispublictrue/ispubliccreated2014-09-10T15:59:38+0530/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonestrue/crossZonesostypeid572126ea-38d2-11e4-a56e-d4ae527ccfaa/ostypeidostypenameCentOS 5.6 (64-bit)/ostypenameaccountsystem/accountzoneid680f7c3a-a9ee-4ed3-b594-981d56f8da4b/zoneidzonenamez2/zonenamesize21474836480/sizetemplatetypeBUILTIN/templatetypehypervisorXenServer/hypervisordomainROOT/domaindomainid54e9d4e4-38d2-11e4-a56e-d4ae527ccfaa/domainidisextractabletrue/isextractablechecksum905cec879afd9c9d22ecc8036131a180/checksumsshkeyenabledfalse/sshkeyenabledisdynamicallyscalabletrue/isdynamicallyscalable/template/listtemplatesresponse 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-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] [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] [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-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] [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] [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] [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] [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] [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] [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=listNetworkServiceProvidersphysicalnetworkid=e58d6d73-cd77-4917-875a-695f56a4b968 listnetworkserviceprovidersresponse cloud-stack-version=4.4.0-SNAPSHOTcount4/countnetworkserviceprovidernameInternalLbVm/namephysicalnetworkide58d6d73-cd77-4917-875a-695f56a4b968/physicalnetworkidstateEnabled/stateid223a1a51-c6a0-4239-ac82-f96290520669/idservicelistLb/servicelistcanenableindividualservicetrue/canenableindividualservice/networkserviceprovidernetworkserviceprovidernameVpcVirtualRouter/namephysicalnetworkide58d6d73-cd77-4917-875a-695f56a4b968/physicalnetworkidstateEnabled/stateid641ae03f-861b-4e20-8b59-333f0848207e/idservicelistVpn/servicelistservicelistDhcp/servicelistservicelistDns/servicelistservicelistGateway/servicelistservicelistLb/servicelistservicelistSourceNat/servicelistservicelistStaticNat/servicelistservicelistPortForwarding/servicelistservicelistUserData/servicelistcanenableindividualservicetrue/canenableindividualservice/networkserviceprovidernetworkserviceprovidernameSecurityGroupProvider/namephysicalnetworkide58d6d73-cd77-4917-875a-695f56a4b968/physicalnetworkidstateDisabled/stateid2414d618-ec08-4624-b16e-fd22e2326f24/idservicelistSecurityGroup/servicelistcanenableindividualservicefalse/canenableindividualservice/networkserviceprovidernetworkserviceprovidernameVirtualRouter/namephysicalnetworkide58d6d73-cd77-4917-875a-695f56a4b968/physicalnetworkidstateEnabled/stateiddae0a4b6-24a7-4d56-91bd-8f0f4919938e/idservicelistVpn/servicelistservicelistDhcp/servicelistservicelistDns/servicelistservicelistGateway/servicelistservicelistFirewall/servicelistservicelistLb/servicelistservicelistSourceNat/servicelistservicelistStaticNat/servicelistservicelistPortForwarding/servicelistservicelistUserData/servicelistcanenableindividualservicetrue/canenableindividualservice/networkserviceprovider/listnetworkserviceprovidersresponse 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 |
[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=listNetworkServiceProvidersphysicalnetworkid=e58d6d73-cd77-4917-875a-695f56a4b968 listnetworkserviceprovidersresponse cloud-stack-version=4.4.0-SNAPSHOTcount4/countnetworkserviceprovidernameInternalLbVm/namephysicalnetworkide58d6d73-cd77-4917-875a-695f56a4b968/physicalnetworkidstateEnabled/stateid223a1a51-c6a0-4239-ac82-f96290520669/idservicelistLb/servicelistcanenableindividualservicetrue/canenableindividualservice/networkserviceprovidernetworkserviceprovidernameVpcVirtualRouter/namephysicalnetworkide58d6d73-cd77-4917-875a-695f56a4b968/physicalnetworkidstateEnabled/stateid641ae03f-861b-4e20-8b59-333f0848207e/idservicelistVpn/servicelistservicelistDhcp/servicelistservicelistDns/servicelistservicelistGateway/servicelistservicelistLb/servicelistservicelistSourceNat/servicelistservicelistStaticNat/servicelistservicelistPortForwarding/servicelistservicelistUserData/servicelistcanenableindividualservicetrue/canenableindividualservice/networkserviceprovidernetworkserviceprovidernameSecurityGroupProvider/namephysicalnetworkide58d6d73-cd77-4917-875a-695f56a4b968/physicalnetworkidstateDisabled/stateid2414d618-ec08-4624-b16e-fd22e2326f24/idservicelistSecurityGroup/servicelistcanenableindividualservicefalse/canenableindividualservice/networkserviceprovidernetworkserviceprovidernameVirtualRouter/namephysicalnetworkide58d6d73-cd77-4917-875a-695f56a4b968/physicalnetworkidstateEnabled/stateiddae0a4b6-24a7-4d56-91bd-8f0f4919938e/idservicelistVpn/servicelistservicelistDhcp/servicelistservicelistDns/servicelistservicelistGateway/servicelistservicelistFirewall/servicelistservicelistLb/servicelistservicelistSourceNat/servicelistservicelistStaticNat/servicelistservicelistPortForwarding/servicelistservicelistUserData/servicelistcanenableindividualservicetrue/canenableindividualservice/networkserviceprovider/listnetworkserviceprovidersresponse 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 |
[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,publicmanagement traffic types with tag tag1 in physical network2 add only guest traffic with tag tag2 3.create two network offerings NO1NO2 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 NIC0NIC1 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.1310.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] [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']
[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', 'bridge=xapi6', '--minimal'] 2014-06-03 05:38:56DEBUG [root] Setup_ovs_bridge completed
[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-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 | NULL | NULL|NULL | | 140 | 998 |
[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-5132f125) Xen Server network for tunnels
[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.agent.api.OvsDestroyTunnelCommand:{networkId:207,networkName:OVSTunnel992,inPortName:t992-4-1,wait:0}}]
}
[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=updateNetworkServiceProviderid=beb30cda-7e3a-44e9-b179-c1c6fd605b47state=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.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
[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=updateNetworkServiceProviderid=beb30cda-7e3a-44e9-b179-c1c6fd605b47state=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
[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-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-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
[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(ActionEventInterceptor.java:51)
at
[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] (Work-Job-Executor-47:ctx-3e2b5a9e job-122/job-123 ctx-ccbcca96) Checking if OvsElement can handle service SourceNat
[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] [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-6762) [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not added in bridge flow table
Sanjeev N created CLOUDSTACK-6762: - Summary: [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 Fix For: 4.4.0 [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:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'add-port', 'xapi3', 't983-4-1', '--', 'set', 'interface', 't983-4-1', 'type=gre', 'options:key=983', 'options:remote_ip=10.147.40.13'] 2014-05-26 08:06:14DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi3', '--minimal'] 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 'add-flow', 'xapi3', 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,actions=drop']
[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:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'add-port', 'xapi3', 't983-4-1', '--', 'set',
[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.DirectAgentAttache]
(DirectAgent-366:ctx-9fccde26) Seq
[jira] [Created] (CLOUDSTACK-6755) [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
Sanjeev N created CLOUDSTACK-6755:
-
Summary: [OVS] Can't create more than 7 GRE tunnel networks in xen
cluster
Key: CLOUDSTACK-6755
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6755
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
e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Blocker
Fix For: 4.4.0
[OVS] Can't create more than 7 GRE tunnel networks in xen cluster
Steps to reproduce:
==
1.Bring up CS in advanced zone with Xen cluster
2.Create physical network with GRE isolation
3.Create isolated network offering with virtual networking and OVS as the
service provider
4.Create 8 guest networks with above offering and deploy vms in each network
Result:
==
CS would create 7 networks successfully and deploying vm in 8th network would
fail because Tunnel network creation would fail for 8th network
Following is the log snippet from MS log:
2014-05-23 10:18:12,784 DEBUG [c.c.n.e.OvsElement]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Checking if OvsElement can
handle service Connectivity on network test1-ovs
2014-05-23 10:18:12,789 DEBUG [c.c.n.o.OvsTunnelManagerImpl]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Creating tunnels with OVS
tunnel manager
2014-05-23 10:18:12,800 DEBUG [c.c.n.o.OvsTunnelManagerImpl]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Ask host 1 to configure
bridge for network:227
2014-05-23 10:18:12,807 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 1-6553863357730929719:
Sending { Cmd , MgmtId: 7332683579487, via: 1(xen-host-13), Ver: v1, Flags:
100111,
[{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
}
2014-05-23 10:18:12,808 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 1-6553863357730929719:
Executing: { Cmd , MgmtId: 7332683579487, via: 1(xen-host-13), Ver: v1, Flags:
100111,
[{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
}
2014-05-23 10:18:12,808 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-268:ctx-46e3abbc) Seq 1-6553863357730929719: Executing request
2014-05-23 10:18:12,991 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-268:ctx-46e3abbc) Create a vif on dom0 for tunnel network for
account OVSTunnel991
2014-05-23 10:18:13,056 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-268:ctx-46e3abbc) createTunnelNetwork failed
com.cloud.utils.exception.CloudRuntimeException: Could not find available VIF
slot in VM with name: Control domain on host: xen-host-13
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getLowestAvailableVIFDeviceNum(CitrixResourceBase.java:3990)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:928)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.findOrCreateTunnelNetwork(CitrixResourceBase.java:1003)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5268)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:528)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
at
com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
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.run(FutureTask.java:262)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
[jira] [Updated] (CLOUDSTACK-6755) [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N updated CLOUDSTACK-6755:
--
Attachment: ovstunnel.log
xensource.log
management-server.rar
Attached MS log file, xensource log file ovstunnel log file
[OVS] Can't create more than 7 GRE tunnel networks in xen cluster
-
Key: CLOUDSTACK-6755
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6755
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
e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Blocker
Labels: ovs
Fix For: 4.4.0
Attachments: management-server.rar, ovstunnel.log, xensource.log
[OVS] Can't create more than 7 GRE tunnel networks in xen cluster
Steps to reproduce:
==
1.Bring up CS in advanced zone with Xen cluster
2.Create physical network with GRE isolation
3.Create isolated network offering with virtual networking and OVS as the
service provider
4.Create 8 guest networks with above offering and deploy vms in each network
Result:
==
CS would create 7 networks successfully and deploying vm in 8th network would
fail because Tunnel network creation would fail for 8th network
Following is the log snippet from MS log:
2014-05-23 10:18:12,784 DEBUG [c.c.n.e.OvsElement]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Checking if OvsElement
can handle service Connectivity on network test1-ovs
2014-05-23 10:18:12,789 DEBUG [c.c.n.o.OvsTunnelManagerImpl]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Creating tunnels with OVS
tunnel manager
2014-05-23 10:18:12,800 DEBUG [c.c.n.o.OvsTunnelManagerImpl]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Ask host 1 to configure
bridge for network:227
2014-05-23 10:18:12,807 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq
1-6553863357730929719: Sending { Cmd , MgmtId: 7332683579487, via:
1(xen-host-13), Ver: v1, Flags: 100111,
[{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
}
2014-05-23 10:18:12,808 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq
1-6553863357730929719: Executing: { Cmd , MgmtId: 7332683579487, via:
1(xen-host-13), Ver: v1, Flags: 100111,
[{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
}
2014-05-23 10:18:12,808 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-268:ctx-46e3abbc) Seq 1-6553863357730929719: Executing request
2014-05-23 10:18:12,991 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-268:ctx-46e3abbc) Create a vif on dom0 for tunnel network for
account OVSTunnel991
2014-05-23 10:18:13,056 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-268:ctx-46e3abbc) createTunnelNetwork failed
com.cloud.utils.exception.CloudRuntimeException: Could not find available VIF
slot in VM with name: Control domain on host: xen-host-13
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getLowestAvailableVIFDeviceNum(CitrixResourceBase.java:3990)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:928)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.findOrCreateTunnelNetwork(CitrixResourceBase.java:1003)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5268)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:528)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
at
com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
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)
[jira] [Created] (CLOUDSTACK-6757) [OVS] Deleting networks does not unplug nics from dom0 on xenserver
Sanjeev N created CLOUDSTACK-6757: - Summary: [OVS] Deleting networks does not unplug nics from dom0 on xenserver Key: CLOUDSTACK-6757 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6757 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 e6961fd21bb6d793302c234d0f409f66dc498072 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVS] Deleting networks does not unplug nics from dom0 on xenserver 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 virtual networking and ovs as the service provider 4.Create couple of guest networks with above network offering 5.Deploy few vms in each network 6.Delete the guest networks Expected Result: == When CS creates tunnel networks it plugs a vif on dom0 for every tunnel tunnetwork. However it does not unplug the vif from dom0 even-though the network is deleted. Observations: === We can see that bridge is getting deleted from the host bug the vif is not getting unplugged from dom0. Attaching MS log file. Please look for bridge named OVSTunnel989 in the log file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6749) [OVS] xe network-param-get with param-key=is-ovs-vpc-distributed-vr-network alway returns error
Sanjeev N created CLOUDSTACK-6749: - Summary: [OVS] xe network-param-get with param-key=is-ovs-vpc-distributed-vr-network alway returns error Key: CLOUDSTACK-6749 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6749 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 e6961fd21bb6d793302c234d0f409f66dc498072 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVS] xe network-param-get with param-key=is-ovs-vpc-distributed-vr-network alway returns error Steps to reproduce: 1.Bring up CS in advanced zone with xen cluster 2.Create physical network with GRE isolation 3.Create isolated network with virtual networking and ovs as the service provider 4.Deploy few vms in the above network 5.Observe /var/log/cloud/ovstunnel.log file on the xen hosts Result: == Everytime when the xe network-param-get commnad is executed with param-key=is-ovs-vpc-distributed-vr-network we see the errors. Following is the log snippet from xen server ovstunnel.log file: 2014-05-22 17:07:43DEBUG [root] Executing:['cat', '/etc/xensource/network.conf'] 2014-05-22 17:07:43DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'iface-to-br', 'vif29.1'] 2014-05-22 17:07:43DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi0', '--minimal'] 2014-05-22 17:07:43DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-param-get', 'uuid=a49d187f-edaa-f7f1-965c-5573f3530c50', 'param-name=other-config', 'param-key=is-ovs-tun-network', '--minimal'] 2014-05-22 17:07:43DEBUG [root] The command exited with the error code: 1 (stderr output:Error: Key is-ovs-tun-network not found in map ) 2014-05-22 17:07:43DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-param-get', 'uuid=a49d187f-edaa-f7f1-965c-5573f3530c50', 'param-name=other-config', 'param-key=is-ovs-vpc-distributed-vr-network', '--minimal'] 2014-05-22 17:07:43DEBUG [root] The command exited with the error code: 1 (stderr output:Error: Key is-ovs-vpc-distributed-vr-network not found in map ) 2014-05-22 17:07:43DEBUG [root] Executing:['cat', '/etc/xensource/network.conf'] 2014-05-22 17:07:43DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'iface-to-br', 'vif29.2'] 2014-05-22 17:07:43DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi1', '--minimal'] 2014-05-22 17:07:43DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-param-get', 'uuid=19b0e655-55aa-4937-daa7-603c289ad1d6', 'param-name=other-config', 'param-key=is-ovs-tun-network', '--minimal'] 2014-05-22 17:07:43DEBUG [root] The command exited with the error code: 1 (stderr output:Error: Key is-ovs-tun-network not found in map ) 2014-05-22 17:07:43DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-param-get', 'uuid=19b0e655-55aa-4937-daa7-603c289ad1d6', 'param-name=other-config', 'param-key=is-ovs-vpc-distributed-vr-network', '--minimal'] 2014-05-22 17:07:43DEBUG [root] The command exited with the error code: 1 (stderr output:Error: Key is-ovs-vpc-distributed-vr-network not found in map ) 2014-05-22 17:08:14DEBUG [root] Executing:['cat', '/etc/xensource/network.conf'] 2014-05-22 17:08:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'iface-to-br', 'vif30.0'] 2014-05-22 17:08:14DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi9', '--minimal'] 2014-05-22 17:08:14DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-param-get', 'uuid=46d8e2b2-1b2f-319e-7b64-8554aacb44e5', 'param-name=other-config', 'param-key=is-ovs-tun-network', '--minimal'] 2014-05-22 17:08:14DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-param-get', 'uuid=46d8e2b2-1b2f-319e-7b64-8554aacb44e5', 'param-name=other-config', 'param-key=is-ovs-vpc-distributed-vr-network', '--minimal'] 2014-05-22 17:08:14DEBUG [root] The command exited with the error code: 1 (stderr output:Error: Key is-ovs-vpc-distributed-vr-network not found in map -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6750) [OVS] With stretched network deploying vm in a ovs disabled zone does not fail
Sanjeev N created CLOUDSTACK-6750: - Summary: [OVS] With stretched network deploying vm in a ovs disabled zone does not fail Key: CLOUDSTACK-6750 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6750 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 e6961fd21bb6d793302c234d0f409f66dc498072 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVS] With stretched network deploying vm in a ovs disabled zone does not fail Steps to reproduce: 1.Bring up CS with two advanced zones say z1 z2 using xen clusters Create physical networks in both the zones with GRE isolation 2.Create network offering with virtual network and ovs as the provider and with StretchedL2Subnet enabled 3.Create guest network with above offering in zone z2 4.Deploy vm in the above network in z2 5.Disable ovs service providers in zone z1 6.Now deploy vm in z1 with stretched network created in z2 Result: == VM deployment was successful in z1 even though ovs provider was disabled. Also ovs bridge and tunnel ports were created on both the hosts in z1z2 Expected Result: == VM deployement in z1 with ovs network created in z2 should fail since ovs service provider is disabled in z1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6750) [OVS] With stretched network deploying vm in a ovs disabled zone does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6750: -- Attachment: management-server.rar Attached MS log fie. [OVS] With stretched network deploying vm in a ovs disabled zone does not fail --- Key: CLOUDSTACK-6750 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6750 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 e6961fd21bb6d793302c234d0f409f66dc498072 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Labels: ovs Fix For: 4.4.0 Attachments: management-server.rar [OVS] With stretched network deploying vm in a ovs disabled zone does not fail Steps to reproduce: 1.Bring up CS with two advanced zones say z1 z2 using xen clusters Create physical networks in both the zones with GRE isolation 2.Create network offering with virtual network and ovs as the provider and with StretchedL2Subnet enabled 3.Create guest network with above offering in zone z2 4.Deploy vm in the above network in z2 5.Disable ovs service providers in zone z1 6.Now deploy vm in z1 with stretched network created in z2 Result: == VM deployment was successful in z1 even though ovs provider was disabled. Also ovs bridge and tunnel ports were created on both the hosts in z1z2 Expected Result: == VM deployement in z1 with ovs network created in z2 should fail since ovs service provider is disabled in z1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6753) [OVS] DB Schema changes are not as per FS doc for Region Level VPC and stretechd L2 Subnet
Sanjeev N created CLOUDSTACK-6753: - Summary: [OVS] DB Schema changes are not as per FS doc for Region Level VPC and stretechd L2 Subnet Key: CLOUDSTACK-6753 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6753 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 e6961fd21bb6d793302c234d0f409f66dc498072 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 [OVS] DB Schema changes are not as per FS doc for Region Level VPC and stretechd L2 Subnet. As per the FS doc for Region level VPC and guest network spanning multiple zones support following DB Schema changes have been proposed: DB schema changes a new column span_multiple_zones shall be added to 'networks' table. when 'span_multiple_zones' is false, network in confined to a single zone and 'networks.data_center_id' shall be used to check the zone corresponding to the network. (ALTER TABLE `cloud`.`networks` ADD COLUMN 'span_multiple_zones' boolean default false) when a network is created with network offering that has 'stretchedl2subnet' capability 'span_multiple_zones' flag shall be set for the network a new table 'network_zones_map' shall be added that shall track the details of the zones a network is spanning CREATE TABLE `cloud`.'network_zones_map' ( `id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT , `network_id` BIGINT(20) UNSIGNED NULL , `data_center_id` bigint(20) unsigned NOT NULL) a new column 'region_level_vpc' shall be added to the vpc table, when 'region_level_vpc' is false, VPC in confined to a single zone and 'vpc.zone_id' shall be used to check the zone corresponding to the VPC. when a VPC is created with offering that has 'regionlevelvpc' capability, 'region_level_vpc' column for the VPC shall be set to true a new table 'vpc_zones_map' shall be added that shall track the details of the zones a VPC is spanning CREATE TABLE `cloud`.'vpc_zones_map' ( `id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT , `vpc_id` BIGINT(20) UNSIGNED NULL , `data_center_id` bigint(20) unsigned NOT NULL) Issues: == #1 networks table has new column called streched_l2 but FS says span_multiple_zones #2 network_zones_map vpc_zones_map tables are not present in Cloud DB. Following is the db schema for netowrks table: mysql desc networks; +---+-+--+-+-++ | Field | Type| Null | Key | Default | Extra | +---+-+--+-+-++ | id| bigint(20) unsigned | NO | PRI | NULL| auto_increment | | name | varchar(255)| YES | | NULL| | | uuid | varchar(40) | YES | UNI | NULL| | | display_text | varchar(255)| YES | | NULL| | | traffic_type | varchar(32) | NO | | NULL| | | broadcast_domain_type | varchar(32) | NO | | NULL| | | broadcast_uri | varchar(255)| YES | | NULL| | | gateway | varchar(15) | YES | | NULL| | | cidr | varchar(18) | YES | | NULL| | | mode | varchar(32) | YES | | NULL| | | network_offering_id | bigint(20) unsigned | NO | MUL | NULL| | | physical_network_id | bigint(20) unsigned | YES | | NULL| | | data_center_id| bigint(20) unsigned | NO | MUL | NULL| | | guru_name | varchar(255)| NO | | NULL| | | state | varchar(32) | NO | | NULL| | | related | bigint(20) unsigned | NO | MUL | NULL| | | domain_id | bigint(20) unsigned | NO | MUL | NULL| | | account_id| bigint(20) unsigned | NO | MUL | NULL| | | dns1 | varchar(255)| YES | | NULL| | | dns2 | varchar(255)| YES | | NULL| | | guru_data | varchar(1024) | YES | | NULL|
[jira] [Updated] (CLOUDSTACK-6732) [OVS][UI] Network Service Providers page displays two ovs providers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6732: -- Attachment: issue2.PNG issue1.PNG Attached screen shots to describe the issues. [OVS][UI] Network Service Providers page displays two ovs providers --- Key: CLOUDSTACK-6732 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6732 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 branch with commit e6961fd21bb6d793302c234d0f409f66dc498072 Reporter: Sanjeev N Assignee: Gabor Apati-Nagy Labels: ovs, ui Fix For: 4.4.0 Attachments: issue1.PNG, issue2.PNG [OVS][UI] Network Service Providers page displays two ovs providers if there two zones and physical networks created with GRE isolation in both the zones. Steps to reproduce: 1.Bring up CS with two advanced zones using xen clusters 2.Create physical networks in both the zones using GRE isolation 3.From UI naviagate to Home-Infrastructure- Zones-Adv-Physical Network 1-Network Service Providers UI displays two OVS providers in enabled state one with name Ovs and another one with name OVS. Clicking on Ovs provider shows details of it whereas clicking on provider with name OVS gives java script issue and UI becomes unresponsive: TypeError: listViewArgs.onActionComplete is undefined detailViewArgs.data.onActionComplete = listViewArgs.onActionComplete; Attaching screen shots to describe both the issues. -- This message was sent by Atlassian JIRA (v6.2#6252)
