[jira] [Updated] (CLOUDSTACK-9390) Dettaching data volume from a running vm created with root and data disk fails

2016-05-26 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-9390:
--
Attachment: vmops.log.rar
xensource.log.19

Attached vmops.log and xensource log file for reference.

> Dettaching data volume from a running vm created with root and data disk fails
> --
>
> Key: CLOUDSTACK-9390
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9390
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.9.0
> Environment: Latest build from ACS master.
> Hypervisor: Xenserver
>Reporter: Sanjeev N
>Priority: Critical
> Attachments: vmops.log.rar, xensource.log.19
>
>
> Detaching data volume from a running vm created with root and data disk fails
> Steps to reproduce:
> ===
> 1.Bring up CS in advanced zone with xen cluster and shared primary storage
> 2.Create a guest vm with both root and data disks
> 3.Try to dettach the data disk from the vm
> Result:
> ==
> CS through exception while detaching the disk. However, it is succeeded from 
> xenserver.
> Following is the output from xensource.log file :
> May 25 01:09:56 xen1 xapi: [ info|xen1.automation.hyd.com|309333 
> storage_unix||storage_impl] VDI.attach dbg:attach_and_activate 
> dp:vbd/285/xvdb sr:73956015-2176-3f64-6451-8e68c2914ed8 
> vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 read_write:true
> May 25 01:09:56 xen1 xapi: [debug|xen1.automation.hyd.com|309333 
> storage_unix||dummytaskhelper] task VDI.attach D:3357ac7da502 created by task 
> attach_and_activate
> May 25 01:09:56 xen1 xapi: [debug|xen1.automation.hyd.com|309333 
> storage_unix|VDI.attach D:3357ac7da502|sm] SM nfs vdi_attach 
> sr=OpaqueRef:8bf61b69-294a-e5ce-b357-a4338b3531cc 
> vdi=OpaqueRef:7d021423-59ce-5fcd-8490-d8a9c975ac90 writable=true
> May 25 01:09:57 xen1 xapi: [debug|xen1.automation.hyd.com|309333 
> storage_unix||storage_impl] dbg:attach_and_activate dp:vbd/285/xvdb 
> sr:73956015-2176-3f64-6451-8e68c2914ed8 
> vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:attached  RW
> May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 
> storage_unix||storage_impl] dbg:dp_destroy dp:vbd/285/xvdb 
> sr:73956015-2176-3f64-6451-8e68c2914ed8 
> vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:attached  RW
> May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 
> storage_unix||dummytaskhelper] task VDI.detach D:620b12ae30f1 created by task 
> dp_destroy
> May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 
> storage_unix|VDI.detach D:620b12ae30f1|sm] SM nfs vdi_detach 
> sr=OpaqueRef:8bf61b69-294a-e5ce-b357-a4338b3531cc 
> vdi=OpaqueRef:7d021423-59ce-5fcd-8490-d8a9c975ac90
> May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 
> storage_unix||storage_impl] dbg:dp_destroy dp:vbd/285/xvdb 
> sr:73956015-2176-3f64-6451-8e68c2914ed8 
> vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:detached
> Following is the exception from CS:
>  
> com.cloud.utils.exception.CloudRuntimeException: Failed to detach volume 
> DATA-573 from VM VM-6e1e614d-e6a3-47c0-ab26-91fb94ba0361; Failed dettach 
> volume: 8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9, due to The server failed to 
> handle your request, due to an internal error.  The given message may give 
> details useful for debugging the problem.
> at 
> com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:1846)
> at 
> com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:2910)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at 
> com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2941)
> at sun.reflect.GeneratedMethodAccessor602.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMetho

[jira] [Created] (CLOUDSTACK-9390) Dettaching data volume from a running vm created with root and data disk fails

2016-05-26 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-9390:
-

 Summary: Dettaching data volume from a running vm created with 
root and data disk fails
 Key: CLOUDSTACK-9390
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9390
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Volumes
Affects Versions: 4.9.0
 Environment: Latest build from ACS master.
Hypervisor: Xenserver
Reporter: Sanjeev N
Priority: Critical


Detaching data volume from a running vm created with root and data disk fails

Steps to reproduce:
===
1.Bring up CS in advanced zone with xen cluster and shared primary storage
2.Create a guest vm with both root and data disks
3.Try to dettach the data disk from the vm

Result:
==
CS through exception while detaching the disk. However, it is succeeded from 
xenserver.

Following is the output from xensource.log file :
May 25 01:09:56 xen1 xapi: [ info|xen1.automation.hyd.com|309333 
storage_unix||storage_impl] VDI.attach dbg:attach_and_activate dp:vbd/285/xvdb 
sr:73956015-2176-3f64-6451-8e68c2914ed8 
vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 read_write:true
May 25 01:09:56 xen1 xapi: [debug|xen1.automation.hyd.com|309333 
storage_unix||dummytaskhelper] task VDI.attach D:3357ac7da502 created by task 
attach_and_activate
May 25 01:09:56 xen1 xapi: [debug|xen1.automation.hyd.com|309333 
storage_unix|VDI.attach D:3357ac7da502|sm] SM nfs vdi_attach 
sr=OpaqueRef:8bf61b69-294a-e5ce-b357-a4338b3531cc 
vdi=OpaqueRef:7d021423-59ce-5fcd-8490-d8a9c975ac90 writable=true
May 25 01:09:57 xen1 xapi: [debug|xen1.automation.hyd.com|309333 
storage_unix||storage_impl] dbg:attach_and_activate dp:vbd/285/xvdb 
sr:73956015-2176-3f64-6451-8e68c2914ed8 
vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:attached  RW

May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 
storage_unix||storage_impl] dbg:dp_destroy dp:vbd/285/xvdb 
sr:73956015-2176-3f64-6451-8e68c2914ed8 
vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:attached  RW
May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 
storage_unix||dummytaskhelper] task VDI.detach D:620b12ae30f1 created by task 
dp_destroy
May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 
storage_unix|VDI.detach D:620b12ae30f1|sm] SM nfs vdi_detach 
sr=OpaqueRef:8bf61b69-294a-e5ce-b357-a4338b3531cc 
vdi=OpaqueRef:7d021423-59ce-5fcd-8490-d8a9c975ac90
May 25 01:15:29 xen1 xapi: [debug|xen1.automation.hyd.com|310468 
storage_unix||storage_impl] dbg:dp_destroy dp:vbd/285/xvdb 
sr:73956015-2176-3f64-6451-8e68c2914ed8 
vdi:8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9 superstate:detached

Following is the exception from CS:
 
com.cloud.utils.exception.CloudRuntimeException: Failed to detach volume 
DATA-573 from VM VM-6e1e614d-e6a3-47c0-ab26-91fb94ba0361; Failed dettach 
volume: 8f9bb5f7-fca7-4ace-a6f4-d1fc825183a9, due to The server failed to 
handle your request, due to an internal error.  The given message may give 
details useful for debugging the problem.
at 
com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:1846)
at 
com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:2910)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at 
com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2941)
at sun.reflect.GeneratedMethodAccessor602.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy165.handleVmWorkJob(Unknown Source)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobD

[jira] [Created] (CLOUDSTACK-9387) Remove string convertion in Assertion statement

2016-05-25 Thread Sanjeev N (JIRA)
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

2016-05-25 Thread Sanjeev N (JIRA)
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

2016-05-17 Thread Sanjeev N (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15286523#comment-15286523
 ] 

Sanjeev N commented on CLOUDSTACK-9380:
---

Most of the tests in Regression test suite are failing because of this issue 
and we are not able to validate the functionalities by running regression.
Can somebody please pick this and fix as early as possible?

> listDomains API returns NPE if there is a failure in deleting domains
> -
>
> Key: CLOUDSTACK-9380
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9380
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
> Environment: Latest build from master
>Reporter: Sanjeev N
>Priority: Critical
> Attachments: cloud.sql, vmops.log
>
>
> listDomains API returns NPE if there is a failure in deleting domains
> Steps to Reproduce:
> 
> 1.Create few domains under root domain and create one or two accounts in each 
> domain
> 2.Create few vms, volumes, snapshots with those accounts.
> 3.Now delete the domains and for one of the domains simulate the domain 
> deletion failure
> 4.Try to list the domains using listDomains api without any domain id paramter
> Result:
> ==
> listDomains API returns error code 530 and in the management server log we 
> see following NPE:
> 2016-05-16 08:53:09,273 ERROR [c.c.a.ApiServer] 
> (qtp237306958-12297:ctx-8f28bbf4 ctx-fdb614d0 ctx-6466fb85) (logid:d17482a8) 
> unhandled exception executing api command: [Ljava.lang.String;@652d471e
> java.lang.NullPointerException
> at 
> com.cloud.api.query.dao.DomainJoinDaoImpl.setResourceLimits(DomainJoinDaoImpl.java:113)
> at 
> com.cloud.api.query.dao.DomainJoinDaoImpl.newDomainResponse(DomainJoinDaoImpl.java:76)
> at sun.reflect.GeneratedMethodAccessor351.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy272.newDomainResponse(Unknown Source)
> at com.cloud.api.ApiDBUtils.newDomainResponse(ApiDBUtils.java:1834)
> at 
> com.cloud.api.query.ViewResponseHelper.createDomainResponse(ViewResponseHelper.java:354)
> at 
> com.cloud.api.query.QueryManagerImpl.searchForDomains(QueryManagerImpl.java:1880)
> at 
> org.apache.cloudstack.api.command.admin.domain.ListDomainsCmd.execute(ListDomainsCmd.java:87)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:705)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
> at 
> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:299)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:88)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at 
> org.eclipse.jetty.s

[jira] [Updated] (CLOUDSTACK-9380) listDomains API returns NPE if there is a failure in deleting domains

2016-05-17 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-9380:
--
Attachment: vmops.log
cloud.sql

Attached vmops.log file and cloud db.

> listDomains API returns NPE if there is a failure in deleting domains
> -
>
> Key: CLOUDSTACK-9380
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9380
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
> Environment: Latest build from master
>Reporter: Sanjeev N
>Priority: Critical
> Attachments: cloud.sql, vmops.log
>
>
> listDomains API returns NPE if there is a failure in deleting domains
> Steps to Reproduce:
> 
> 1.Create few domains under root domain and create one or two accounts in each 
> domain
> 2.Create few vms, volumes, snapshots with those accounts.
> 3.Now delete the domains and for one of the domains simulate the domain 
> deletion failure
> 4.Try to list the domains using listDomains api without any domain id paramter
> Result:
> ==
> listDomains API returns error code 530 and in the management server log we 
> see following NPE:
> 2016-05-16 08:53:09,273 ERROR [c.c.a.ApiServer] 
> (qtp237306958-12297:ctx-8f28bbf4 ctx-fdb614d0 ctx-6466fb85) (logid:d17482a8) 
> unhandled exception executing api command: [Ljava.lang.String;@652d471e
> java.lang.NullPointerException
> at 
> com.cloud.api.query.dao.DomainJoinDaoImpl.setResourceLimits(DomainJoinDaoImpl.java:113)
> at 
> com.cloud.api.query.dao.DomainJoinDaoImpl.newDomainResponse(DomainJoinDaoImpl.java:76)
> at sun.reflect.GeneratedMethodAccessor351.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy272.newDomainResponse(Unknown Source)
> at com.cloud.api.ApiDBUtils.newDomainResponse(ApiDBUtils.java:1834)
> at 
> com.cloud.api.query.ViewResponseHelper.createDomainResponse(ViewResponseHelper.java:354)
> at 
> com.cloud.api.query.QueryManagerImpl.searchForDomains(QueryManagerImpl.java:1880)
> at 
> org.apache.cloudstack.api.command.admin.domain.ListDomainsCmd.execute(ListDomainsCmd.java:87)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:705)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
> at 
> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:299)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:88)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.j

[jira] [Created] (CLOUDSTACK-9380) listDomains API returns NPE if there is a failure in deleting domains

2016-05-17 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-9380:
-

 Summary: listDomains API returns NPE if there is a failure in 
deleting domains
 Key: CLOUDSTACK-9380
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9380
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.9.0
 Environment: Latest build from master
Reporter: Sanjeev N
Priority: Critical


listDomains API returns NPE if there is a failure in deleting domains

Steps to Reproduce:

1.Create few domains under root domain and create one or two accounts in each 
domain
2.Create few vms, volumes, snapshots with those accounts.
3.Now delete the domains and for one of the domains simulate the domain 
deletion failure
4.Try to list the domains using listDomains api without any domain id paramter

Result:
==
listDomains API returns error code 530 and in the management server log we see 
following NPE:
2016-05-16 08:53:09,273 ERROR [c.c.a.ApiServer] 
(qtp237306958-12297:ctx-8f28bbf4 ctx-fdb614d0 ctx-6466fb85) (logid:d17482a8) 
unhandled exception executing api command: [Ljava.lang.String;@652d471e
java.lang.NullPointerException
at 
com.cloud.api.query.dao.DomainJoinDaoImpl.setResourceLimits(DomainJoinDaoImpl.java:113)
at 
com.cloud.api.query.dao.DomainJoinDaoImpl.newDomainResponse(DomainJoinDaoImpl.java:76)
at sun.reflect.GeneratedMethodAccessor351.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy272.newDomainResponse(Unknown Source)
at com.cloud.api.ApiDBUtils.newDomainResponse(ApiDBUtils.java:1834)
at 
com.cloud.api.query.ViewResponseHelper.createDomainResponse(ViewResponseHelper.java:354)
at 
com.cloud.api.query.QueryManagerImpl.searchForDomains(QueryManagerImpl.java:1880)
at 
org.apache.cloudstack.api.command.admin.domain.ListDomainsCmd.execute(ListDomainsCmd.java:87)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:705)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:299)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:88)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at 
org.eclipse.jetty.server.handler.

[jira] [Created] (CLOUDSTACK-9337) [CI] Enhance vcenter library to add datacenter programmatically

2016-04-05 Thread Sanjeev N (JIRA)
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

2016-03-28 Thread Sanjeev N (JIRA)
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

2016-03-10 Thread Sanjeev N (JIRA)
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

2016-01-09 Thread Sanjeev N (JIRA)
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

2016-01-08 Thread Sanjeev N (JIRA)
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

2016-01-06 Thread Sanjeev N (JIRA)
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

2016-01-04 Thread Sanjeev N (JIRA)
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

2015-12-07 Thread Sanjeev N (JIRA)
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

2015-12-03 Thread Sanjeev N (JIRA)
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

2015-11-25 Thread Sanjeev N (JIRA)
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

2015-11-01 Thread Sanjeev N (JIRA)
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

2015-10-17 Thread Sanjeev N (JIRA)
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

2015-09-21 Thread Sanjeev N (JIRA)
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

2015-08-10 Thread Sanjeev N (JIRA)
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

2015-08-03 Thread Sanjeev N (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651773#comment-14651773
 ] 

Sanjeev N commented on CLOUDSTACK-8685:
---

[~wilder.rodrigues]
Can you please fix if possible, since you are already working on 
CLOUDSTACK-8688 ?

> [VPC_VR] Default route is not configured on VPC VR
> --
>
> Key: CLOUDSTACK-8685
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8685
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
> Environment: Advanced zone with VPC. Latest build from ACS master.
>Reporter: Sanjeev N
>Priority: Critical
> Fix For: 4.6.0
>
> Attachments: management-server.zip
>
>
> [VPC_VR] Default route is not configured on VPC VR
> Steps to reproduce:
> 
> 1.Bring up CS in advanced zone 
> 2.Create VPC and wait for the VR to come into running state
> 3.Connect  to VR and verify route table information
> Result:
> ==
> Default route is not configured on VPC VR.
> root@r-9-VM:/var/cache/cloud# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse Iface
> 10.1.1.00.0.0.0 255.255.255.0   U 0  00 eth2
> 10.1.2.00.0.0.0 255.255.255.0   U 0  00 eth3
> 10.220.128.00.0.0.0 255.255.224.0   U 0  00 eth1
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
> root@r-9-VM:/var/cache/cloud#
> Observations:
> ===
> When vr boots up, we run cloud-early-config. This will clean if there is any 
> default route exists on VR. Then we execute vpc_ipassoc.sh to configure 
> public nic and default route via public nic. However, in the latest ACS 
> master we are not executing vpc_ipassoc.sh.
> For any configuration on VR , we are creating configuration file and applying 
> it with update_config.py. 
> Looks like adding default route is missing in the confguration file.
> Following is the configuration file genearted on VR :
> 015-07-29 05:20:39,132 DEBUG [c.c.h.x.r.CitrixResourceBase] 
> (DirectAgent-402:ctx-83549002) VR Config file 
> VR-d3b73941-7b3d-489a-bcc6-47c6a777c950.cfg got created in VR, ip 
> 169.254.0.54 with content
> #Apache CloudStack Virtual Router Config File
> 
> 1.0
> 
> 
> /var/cache/cloud/ip_associations.json
> {"ip_address":[{"public_ip":"10.220.135.97","source_nat":false,"add":true,"one_to_one_nat":false,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false},{"public_ip":"10.220.135.99","source_nat":false,"add":true,"one_to_one_nat":true,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false}],"type":"ips"}
> 
> 
> /opt/cloud/bin/update_config.py ip_associations.json
> 
> 
> /var/cache/cloud/staticnat_rules.json
> {"rules":[{"revoke":false,"source_ip_address":"10.220.135.99","source_port_range":"0:0","destination_ip_address":"10.1.1.36"}],"type":"staticnatrules"}
> 
> 
> /opt/cloud/bin/update_config.py staticnat_rules.json
> 
> 
> /var/cache/cloud/forwarding_rules.json
> {"rules":[{"revoke":false,"protocol":"tcp","source_ip_address":"10.220.135.97","source_port_range":"22:22","destination_ip_address":"10.1.1.194","destination_port_range":"22:22"}],"type":"forwardrules"}
> 
> 
> /opt/cloud/bin/update_config.py forwarding_rules.json
> 
> 
> /var/cache/cloud/network_acl.json
> {"device":"eth2","mac_address":"02:00:7c:a8:00:02","private_gateway_acl":false,"nic_ip":"10.1.1.1","nic_netmask":"24","ingress_rules":[{"type":"tcp","first_port":22,"last_port":22,"cidr":"0.0.0.0/0","allowed":true}],"egress_rules":[{"type":"icmp","icmp_type":-1,"icmp_code":-1,"cidr":"0.0.0.0/0","allowed":true}],"type":"networkacl"}
> 
> 
> /opt/cloud/bin/update_config.py network_acl.json
> 
> 
> /var/cache/cloud/vm_dhcp_entry.json
> {"host_name":"VM-403a0536-ba54-404f-a664-1b14d039497c","mac_address":"02:00:10:ca:00:01","ipv4_adress":"10.1.1.194","ipv6_duid":"00:03:00:01:02:00:10:ca:00:01","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"}
> 
> 
> /opt/cloud/bin/update_config.py vm_dhcp_entry.json
> 
> 
> /var/cache/cloud/vm_dhcp_entry.json
> {"host_name":"VM-4c5e69ab-65dd-4315-b8fb-702f5599ede0","mac_address":"02:00:0f:22:00:03","ipv4_adress":"10.1.1.36","ipv6_duid":"00:03:00:01:02:00:0f:22:00:03","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"}
> 
> 
> /opt/cloud/bin/update_config.py vm_dhcp_entry.json
> 
> 
> /var/cache/cloud/vm_metadata.json
> {"vm_ip_address":"10.1.1.194","vm_metadata":[["userdata

[jira] [Created] (CLOUDSTACK-8688) Defualt policy for INPUT and FORWARD chain is ACCEPT in VR filter table

2015-07-29 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8688:
-

 Summary: Defualt policy for INPUT and FORWARD chain is ACCEPT in 
VR filter table
 Key: CLOUDSTACK-8688
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8688
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.6.0
 Environment: Latest build from ACS master.
Zone type: Advanced
Reporter: Sanjeev N
Priority: Blocker


Defualt policy for INPUT and FORWARD chain is ACCEPT in VR filter table

Steps to reproduce the issue:
===
1.Bring up CS in advanced zone with any supported hypervisor (e.g. Xenserver)
2.Create an isolated network with Network Offering 
"DefaultIsolatedNetworkOfferingWithSourceNatService"
3.Deploy one guest vm within that network

Result:
===
IP tables rules on the VR created are as follows:
root@r-7-VM:~# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source   destination
NETWORK_STATS  all  --  anywhere anywhere
ACCEPT all  --  anywhere vrrp.mcast.net
ACCEPT all  --  anywhere 225.0.0.50
ACCEPT all  --  anywhere anywhere state 
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere vrrp.mcast.net
ACCEPT all  --  anywhere 225.0.0.50
ACCEPT all  --  anywhere anywhere state 
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT udp  --  anywhere anywhere udp dpt:bootps
ACCEPT udp  --  anywhere anywhere udp dpt:domain
ACCEPT tcp  --  anywhere anywhere tcp dpt:domain
ACCEPT tcp  --  anywhere anywhere tcp dpt:http 
state NEW
ACCEPT tcp  --  anywhere anywhere tcp dpt:http-alt 
state NEW

Chain FORWARD (policy ACCEPT)
target prot opt source   destination
NETWORK_STATS  all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere state 
RELATED,ESTABLISHED
ACCEPT all  --  anywhere anywhere state NEW
ACCEPT all  --  anywhere anywhere state 
RELATED,ESTABLISHED
ACCEPT all  --  anywhere anywhere state 
RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
NETWORK_STATS  all  --  anywhere anywhere

Chain NETWORK_STATS (3 references)
target prot opt source   destination
   all  --  anywhere anywhere
   all  --  anywhere anywhere
   tcp  --  anywhere anywhere
   tcp  --  anywhere anywhere

But the Default policy for INPUT and FORWARD chain should be DROP instead of 
ACCEPT. Otherwise all the traffic would be allowed to VR.

Same is the case with VPC and Shared network as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-8685) [VPC_VR] Default route is not configured on VPC VR

2015-07-28 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-8685:
--
Attachment: management-server.zip

> [VPC_VR] Default route is not configured on VPC VR
> --
>
> Key: CLOUDSTACK-8685
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8685
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
> Environment: Advanced zone with VPC. Latest build from ACS master.
>Reporter: Sanjeev N
>Priority: Critical
> Attachments: management-server.zip
>
>
> [VPC_VR] Default route is not configured on VPC VR
> Steps to reproduce:
> 
> 1.Bring up CS in advanced zone 
> 2.Create VPC and wait for the VR to come into running state
> 3.Connect  to VR and verify route table information
> Result:
> ==
> Default route is not configured on VPC VR.
> root@r-9-VM:/var/cache/cloud# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse Iface
> 10.1.1.00.0.0.0 255.255.255.0   U 0  00 eth2
> 10.1.2.00.0.0.0 255.255.255.0   U 0  00 eth3
> 10.220.128.00.0.0.0 255.255.224.0   U 0  00 eth1
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
> root@r-9-VM:/var/cache/cloud#
> Observations:
> ===
> When vr boots up, we run cloud-early-config. This will clean if there is any 
> default route exists on VR. Then we execute vpc_ipassoc.sh to configure 
> public nic and default route via public nic. However, in the latest ACS 
> master we are not executing vpc_ipassoc.sh.
> For any configuration on VR , we are creating configuration file and applying 
> it with update_config.py. 
> Looks like adding default route is missing in the confguration file.
> Following is the configuration file genearted on VR :
> 015-07-29 05:20:39,132 DEBUG [c.c.h.x.r.CitrixResourceBase] 
> (DirectAgent-402:ctx-83549002) VR Config file 
> VR-d3b73941-7b3d-489a-bcc6-47c6a777c950.cfg got created in VR, ip 
> 169.254.0.54 with content
> #Apache CloudStack Virtual Router Config File
> 
> 1.0
> 
> 
> /var/cache/cloud/ip_associations.json
> {"ip_address":[{"public_ip":"10.220.135.97","source_nat":false,"add":true,"one_to_one_nat":false,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false},{"public_ip":"10.220.135.99","source_nat":false,"add":true,"one_to_one_nat":true,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false}],"type":"ips"}
> 
> 
> /opt/cloud/bin/update_config.py ip_associations.json
> 
> 
> /var/cache/cloud/staticnat_rules.json
> {"rules":[{"revoke":false,"source_ip_address":"10.220.135.99","source_port_range":"0:0","destination_ip_address":"10.1.1.36"}],"type":"staticnatrules"}
> 
> 
> /opt/cloud/bin/update_config.py staticnat_rules.json
> 
> 
> /var/cache/cloud/forwarding_rules.json
> {"rules":[{"revoke":false,"protocol":"tcp","source_ip_address":"10.220.135.97","source_port_range":"22:22","destination_ip_address":"10.1.1.194","destination_port_range":"22:22"}],"type":"forwardrules"}
> 
> 
> /opt/cloud/bin/update_config.py forwarding_rules.json
> 
> 
> /var/cache/cloud/network_acl.json
> {"device":"eth2","mac_address":"02:00:7c:a8:00:02","private_gateway_acl":false,"nic_ip":"10.1.1.1","nic_netmask":"24","ingress_rules":[{"type":"tcp","first_port":22,"last_port":22,"cidr":"0.0.0.0/0","allowed":true}],"egress_rules":[{"type":"icmp","icmp_type":-1,"icmp_code":-1,"cidr":"0.0.0.0/0","allowed":true}],"type":"networkacl"}
> 
> 
> /opt/cloud/bin/update_config.py network_acl.json
> 
> 
> /var/cache/cloud/vm_dhcp_entry.json
> {"host_name":"VM-403a0536-ba54-404f-a664-1b14d039497c","mac_address":"02:00:10:ca:00:01","ipv4_adress":"10.1.1.194","ipv6_duid":"00:03:00:01:02:00:10:ca:00:01","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"}
> 
> 
> /opt/cloud/bin/update_config.py vm_dhcp_entry.json
> 
> 
> /var/cache/cloud/vm_dhcp_entry.json
> {"host_name":"VM-4c5e69ab-65dd-4315-b8fb-702f5599ede0","mac_address":"02:00:0f:22:00:03","ipv4_adress":"10.1.1.36","ipv6_duid":"00:03:00:01:02:00:0f:22:00:03","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"}
> 
> 
> /opt/cloud/bin/update_config.py vm_dhcp_entry.json
> 
> 
> /var/cache/cloud/vm_metadata.json
> {"vm_ip_address":"10.1.1.194","vm_metadata":[["userdata","user-data",null],["metadata","service-offering","Tiny
>  
> Instance"],["metadata","availability-zone","XenRT-Zone-0"],["metadata","local-ipv4","10.1.1.

[jira] [Created] (CLOUDSTACK-8685) [VPC_VR] Default route is not configured on VPC VR

2015-07-28 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8685:
-

 Summary: [VPC_VR] Default route is not configured on VPC VR
 Key: CLOUDSTACK-8685
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8685
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Advanced zone with VPC. Latest build from ACS master.
Reporter: Sanjeev N
Priority: Critical


[VPC_VR] Default route is not configured on VPC VR

Steps to reproduce:

1.Bring up CS in advanced zone 
2.Create VPC and wait for the VR to come into running state
3.Connect  to VR and verify route table information

Result:
==
Default route is not configured on VPC VR.
root@r-9-VM:/var/cache/cloud# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
10.1.1.00.0.0.0 255.255.255.0   U 0  00 eth2
10.1.2.00.0.0.0 255.255.255.0   U 0  00 eth3
10.220.128.00.0.0.0 255.255.224.0   U 0  00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
root@r-9-VM:/var/cache/cloud#

Observations:
===
When vr boots up, we run cloud-early-config. This will clean if there is any 
default route exists on VR. Then we execute vpc_ipassoc.sh to configure public 
nic and default route via public nic. However, in the latest ACS master we are 
not executing vpc_ipassoc.sh.
For any configuration on VR , we are creating configuration file and applying 
it with update_config.py. 
Looks like adding default route is missing in the confguration file.

Following is the configuration file genearted on VR :
015-07-29 05:20:39,132 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-402:ctx-83549002) VR Config file 
VR-d3b73941-7b3d-489a-bcc6-47c6a777c950.cfg got created in VR, ip 169.254.0.54 
with content
#Apache CloudStack Virtual Router Config File

1.0


/var/cache/cloud/ip_associations.json
{"ip_address":[{"public_ip":"10.220.135.97","source_nat":false,"add":true,"one_to_one_nat":false,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false},{"public_ip":"10.220.135.99","source_nat":false,"add":true,"one_to_one_nat":true,"first_i_p":false,"gateway":"10.220.128.1","netmask":"255.255.224.0","vif_mac_address":"06:dd:e0:00:00:0e","nic_dev_id":1,"new_nic":false}],"type":"ips"}


/opt/cloud/bin/update_config.py ip_associations.json


/var/cache/cloud/staticnat_rules.json
{"rules":[{"revoke":false,"source_ip_address":"10.220.135.99","source_port_range":"0:0","destination_ip_address":"10.1.1.36"}],"type":"staticnatrules"}


/opt/cloud/bin/update_config.py staticnat_rules.json


/var/cache/cloud/forwarding_rules.json
{"rules":[{"revoke":false,"protocol":"tcp","source_ip_address":"10.220.135.97","source_port_range":"22:22","destination_ip_address":"10.1.1.194","destination_port_range":"22:22"}],"type":"forwardrules"}


/opt/cloud/bin/update_config.py forwarding_rules.json


/var/cache/cloud/network_acl.json
{"device":"eth2","mac_address":"02:00:7c:a8:00:02","private_gateway_acl":false,"nic_ip":"10.1.1.1","nic_netmask":"24","ingress_rules":[{"type":"tcp","first_port":22,"last_port":22,"cidr":"0.0.0.0/0","allowed":true}],"egress_rules":[{"type":"icmp","icmp_type":-1,"icmp_code":-1,"cidr":"0.0.0.0/0","allowed":true}],"type":"networkacl"}


/opt/cloud/bin/update_config.py network_acl.json


/var/cache/cloud/vm_dhcp_entry.json
{"host_name":"VM-403a0536-ba54-404f-a664-1b14d039497c","mac_address":"02:00:10:ca:00:01","ipv4_adress":"10.1.1.194","ipv6_duid":"00:03:00:01:02:00:10:ca:00:01","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"}


/opt/cloud/bin/update_config.py vm_dhcp_entry.json


/var/cache/cloud/vm_dhcp_entry.json
{"host_name":"VM-4c5e69ab-65dd-4315-b8fb-702f5599ede0","mac_address":"02:00:0f:22:00:03","ipv4_adress":"10.1.1.36","ipv6_duid":"00:03:00:01:02:00:0f:22:00:03","default_gateway":"10.1.1.1","default_entry":true,"type":"dhcpentry"}


/opt/cloud/bin/update_config.py vm_dhcp_entry.json


/var/cache/cloud/vm_metadata.json
{"vm_ip_address":"10.1.1.194","vm_metadata":[["userdata","user-data",null],["metadata","service-offering","Tiny
 
Instance"],["metadata","availability-zone","XenRT-Zone-0"],["metadata","local-ipv4","10.1.1.194"],["metadata","local-hostname","VM-403a0536-ba54-404f-a664-1b14d039497c"],["metadata","public-ipv4","10.220.135.96"],["metadata","public-hostname","10.220.135.96"],["metadata","instance-id","403a0536-ba54-404f-a664-1b14d039497c"],["metadata","vm-id","403a0536-ba54-404f-a664-1b14d039497c"],["metadata","public-keys",null],["metadata","cloud-identifier","CloudStack-{5bcd0291-2ac9-4d68-9887-bda6ae6596c2}"]],"type":"vmda

[jira] [Created] (CLOUDSTACK-8681) [Egress_Rules] CS does not honor the default deny egress policy in isolated network

2015-07-28 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8681:
-

 Summary: [Egress_Rules] CS does not honor the default deny egress 
policy in isolated network
 Key: CLOUDSTACK-8681
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8681
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from master with commit 
ac9c2a224a78f413945e25fd7cf23364fbef00b5 
Zone: Advanced
Reporter: Sanjeev N
Priority: Critical


[Egress_Rules] CS does not honor the default deny egress policy in isolated 
network

Steps to reproduce:
=
1.Bring up CS in advanced zone with any of the supported hypervisors
2.Create an isolated network with network offering 
"DefaultIsolatedNetworkOfferingWithSourceNatService" so that defaul egress 
policy would be "deny all"
3.Deploy one guest vm in that network

Expected Result:
=
VR forward chain in filter table should have the defualt DROP policy.

Actual Result:
===
Following is the FORWARD chain from the VR:
Chain FORWARD (policy ACCEPT 10282 packets, 1743K bytes)
 pkts bytes target prot opt in out source   destination
46405   27M NETWORK_STATS  all  --  *  *   0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0   
 state NEW
27468   25M ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED
2   104 ACCEPT tcp  --  eth2   eth00.0.0.0/00.0.0.0/0   
 tcp dpt:22 state NEW

It should be in the following way:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 NETWORK_STATS  all  --  *  *   0.0.0.0/00.0.0.0/
0   
0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0   
 state NEW
0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED
0 0 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/00.0.0.0/0 
  
Chain FW_EGRESS_RULES (1 references)
 pkts bytes target prot opt in out source   destination 

0 0 DROP   all  --  *  *   0.0.0.0/00.0.0.0/0   


Chain FW_OUTBOUND (1 references)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED
0 0 FW_EGRESS_RULES  all  --  *  *   0.0.0.0/00.0.0.
0/0   


Looks like now we are loading ip tables from "/etc/iptables/router_rules.v4" . 
But the base for this file should be "/etc/iptables/rules.v4" to persist the 
default behavior.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-8671) [VMWare] VM deployment from iso fails

2015-07-24 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-8671:
--
Attachment: management-server.zip

Please look for job-322 in the attached MS log file for vm deployment failure.



> [VMWare] VM deployment from iso fails
> -
>
> Key: CLOUDSTACK-8671
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8671
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, VMware
>Affects Versions: 4.6.0
> Environment: Latest build from ACS master with commit 
> 2984acca83fff03c2ad8bdd28c097e797d4ce087 
> Hypervisor: VMWare
>Reporter: Sanjeev N
>Priority: Critical
> Attachments: management-server.zip
>
>
> Failed to deploy vm from ISO
> Steps to reproduce:
> 
> 1.Bring up CS in advanced zone with vmware cluster
> 2.Register one bootable iso
> 3.Try to deploy vm using that iso
> Result:
> ==
> VM Deployment failed due to failure in creating volume:
> 2015-07-23 16:48:29,712 ERROR [c.c.s.r.VmwareStorageProcessor] 
> (DirectAgent-196:ctx-18de08d8 10.81.28.111, job-322/job-323, cmd: 
> CreateObjectCommand) create volume failed due to Exception: 
> java.lang.NullPointerException
> Message: charsetName
> java.lang.NullPointerException: charsetName
> at java.io.InputStreamReader.(InputStreamReader.java:99)
> at 
> com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486)
> at 
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217)
> at 
> com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2015-07-23 16:48:29,713 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Response Received:
> 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] 
> (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Processing:  { Ans: 
> , MgmtId: 187822473365406, via: 2, Ver: v1, Flags: 10, 
> [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException:
>  charsetName","wait":0}}] }
> 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Seq 
> 2-8089027880710832600: Received:  { Ans: , MgmtId: 187822473365406, via: 2, 
> Ver: v1, Flags: 10, { CreateObjectAnswer } }
> 2015-07-23 16:48:29,720 WARN  [o.a.c.s.d.ObjectInDataStoreManagerImpl] 
> (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unsupported 
> data object (VOLUME, 
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@392f6f34), no 
> need to delete from object in store ref table
> 2015-07-23 16:48:29,720 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
> (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to 
> create Vol[55|vm=50|ROOT]:java.lang.Null

[jira] [Created] (CLOUDSTACK-8671) [VMWare] VM deployment from iso fails

2015-07-24 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8671:
-

 Summary: [VMWare] VM deployment from iso fails
 Key: CLOUDSTACK-8671
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8671
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: ISO, VMware
Affects Versions: 4.6.0
 Environment: Latest build from ACS master with commit 
2984acca83fff03c2ad8bdd28c097e797d4ce087 
Hypervisor: VMWare
Reporter: Sanjeev N
Priority: Critical


Failed to deploy vm from ISO

Steps to reproduce:

1.Bring up CS in advanced zone with vmware cluster
2.Register one bootable iso
3.Try to deploy vm using that iso

Result:
==
VM Deployment failed due to failure in creating volume:
2015-07-23 16:48:29,712 ERROR [c.c.s.r.VmwareStorageProcessor] 
(DirectAgent-196:ctx-18de08d8 10.81.28.111, job-322/job-323, cmd: 
CreateObjectCommand) create volume failed due to Exception: 
java.lang.NullPointerException
Message: charsetName

java.lang.NullPointerException: charsetName
at java.io.InputStreamReader.(InputStreamReader.java:99)
at 
com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486)
at 
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217)
at 
com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545)
at 
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113)
at 
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2015-07-23 16:48:29,713 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Response Received:
2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] (DirectAgent-196:ctx-18de08d8) 
Seq 2-8089027880710832600: Processing:  { Ans: , MgmtId: 187822473365406, via: 
2, Ver: v1, Flags: 10, 
[{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException:
 charsetName","wait":0}}] }
2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Seq 
2-8089027880710832600: Received:  { Ans: , MgmtId: 187822473365406, via: 2, 
Ver: v1, Flags: 10, { CreateObjectAnswer } }
2015-07-23 16:48:29,720 WARN  [o.a.c.s.d.ObjectInDataStoreManagerImpl] 
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unsupported 
data object (VOLUME, 
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@392f6f34), no need 
to delete from object in store ref table
2015-07-23 16:48:29,720 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to 
create Vol[55|vm=50|ROOT]:java.lang.NullPointerException: charsetName
2015-07-23 16:48:29,720 INFO  [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to 
contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is 
unreachable: Unable to create 
Vol[55|vm=50|ROOT]:java.lang.NullPointerException: charsetName
at 
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:12

[jira] [Updated] (CLOUDSTACK-8669) [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName

2015-07-24 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-8669:
--
Attachment: management-server.zip

Attached management server log file. Please look for job-48 for the sequence of 
events in case of attach volume.

> [VMWare] create volume failed due to Exception: 
> java.lang.NullPointerException Message: charsetName
> ---
>
> Key: CLOUDSTACK-8669
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8669
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.6.0
> Environment: Latest build from ACS master with commit 
> 2984acca83fff03c2ad8bdd28c097e797d4ce087 
> Hypervisor: VMWares
>Reporter: Sanjeev N
>Priority: Critical
> Attachments: management-server.zip
>
>
> [VMWare] create volume failed due to Exception: 
> java.lang.NullPointerException Message: charsetName
> Steps to reproduce:
> 
> 1.Bring up CS in advanced zone with vmware cluster
> 2.Deploy one guest vm using default cent os template
> 3.Create one data disk with shared disk offering
> 4.Attach the data disk to the vm created in step 2
> Result:
> =
> Attach volume failed with NPE:
> 2015-07-23 16:06:58,103 ERROR [c.c.s.r.VmwareStorageProcessor] 
> (DirectAgent-64:ctx-6becb596 10.81.28.111, job-48/job-49, cmd: 
> CreateObjectCommand) create volume failed due to Exception: 
> java.lang.NullPointerException
> Message: charsetName
> java.lang.NullPointerException: charsetName
> at java.io.InputStreamReader.(InputStreamReader.java:99)
> at 
> com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486)
> at 
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217)
> at 
> com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2015-07-23 16:06:58,104 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Response Received:
> 2015-07-23 16:06:58,104 DEBUG [c.c.a.t.Request] (DirectAgent-64:ctx-6becb596) 
> Seq 2-8089027880710832216: Processing:  { Ans: , MgmtId: 187822473365406, 
> via: 2, Ver: v1, Flags: 10, 
> [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException:
>  charsetName","wait":0}}] }
> 2015-07-23 16:06:58,105 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Seq 
> 2-8089027880710832216: Received:  { Ans: , MgmtId: 187822473365406, via: 2, 
> Ver: v1, Flags: 10, { CreateObjectAnswer } }
> 2015-07-23 16:06:58,112 WARN  [o.a.c.s.d.ObjectInDataStoreManagerImpl] 
> (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Unsupported 
> data object (VOLUME, 
> org.apache.cloudstack.

[jira] [Created] (CLOUDSTACK-8669) [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName

2015-07-24 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8669:
-

 Summary: [VMWare] create volume failed due to Exception: 
java.lang.NullPointerException Message: charsetName
 Key: CLOUDSTACK-8669
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8669
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Volumes
Affects Versions: 4.6.0
 Environment: Latest build from ACS master with commit 
2984acca83fff03c2ad8bdd28c097e797d4ce087 
Hypervisor: VMWares
Reporter: Sanjeev N
Priority: Critical


[VMWare] create volume failed due to Exception: java.lang.NullPointerException 
Message: charsetName

Steps to reproduce:

1.Bring up CS in advanced zone with vmware cluster
2.Deploy one guest vm using default cent os template
3.Create one data disk with shared disk offering
4.Attach the data disk to the vm created in step 2

Result:
=
Attach volume failed with NPE:
2015-07-23 16:06:58,103 ERROR [c.c.s.r.VmwareStorageProcessor] 
(DirectAgent-64:ctx-6becb596 10.81.28.111, job-48/job-49, cmd: 
CreateObjectCommand) create volume failed due to Exception: 
java.lang.NullPointerException
Message: charsetName

java.lang.NullPointerException: charsetName
at java.io.InputStreamReader.(InputStreamReader.java:99)
at 
com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486)
at 
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217)
at 
com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545)
at 
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113)
at 
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2015-07-23 16:06:58,104 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Response Received:
2015-07-23 16:06:58,104 DEBUG [c.c.a.t.Request] (DirectAgent-64:ctx-6becb596) 
Seq 2-8089027880710832216: Processing:  { Ans: , MgmtId: 187822473365406, via: 
2, Ver: v1, Flags: 10, 
[{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException:
 charsetName","wait":0}}] }
2015-07-23 16:06:58,105 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Seq 
2-8089027880710832216: Received:  { Ans: , MgmtId: 187822473365406, via: 2, 
Ver: v1, Flags: 10, { CreateObjectAnswer } }
2015-07-23 16:06:58,112 WARN  [o.a.c.s.d.ObjectInDataStoreManagerImpl] 
(Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Unsupported data 
object (VOLUME, 
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@58dd2323), no need 
to delete from object in store ref table


Please look for job-48 in the attached Management server log file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it

2015-07-23 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8668:
-

 Summary: VR does not start in basic zone since ip address are not 
being configured on it
 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Priority: Blocker


VR does not start in basic zone since ip address are not being configured on it

Steps to reproduce:

1.Bring up CS in basic zone with xen server cluster
2.Try to deploy one guest vm using default cent os template

Expected Result:
==
VR should come up as part of vm deployment and vm deployment should be 
successfull

Actual Result:

VR creation failed since the IP addresses not are getting assigned to VR's 
guest and link local interfaces.

Observations:
===
1.During vr boot time, cloud-early-config ran successfully and VR console 
output showed that ping to gateway was successful. However, after VR boot we 
don't see any ip addresses on the VRs guest and link local ip address.
2. If we run cloud-early-config manually from VR , ip addresses will be 
assigned and persistent.

Impact:
=
VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-8634) Make changes to test_security_group.py test suite to support EIP

2015-07-14 Thread Sanjeev N (JIRA)
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

2015-07-07 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8617:
-

 Summary: Remove duplicate data from test_data.py file
 Key: CLOUDSTACK-8617
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8617
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Reporter: Sanjeev N
Assignee: Sanjeev N






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-8509) Skip snapshot tests for LXC

2015-05-25 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8509:
-

 Summary: Skip snapshot tests for LXC
 Key: CLOUDSTACK-8509
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8509
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Sanjeev N
Assignee: Sanjeev N


Volume snapshots are not supported on LXC. So skip snapshot related tests from 
test_assign_vm.py in regression



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-8508) Install wget package inside LXC vm

2015-05-25 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8508:
-

 Summary: Install wget package inside LXC vm
 Key: CLOUDSTACK-8508
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8508
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Sanjeev N
Assignee: Sanjeev N


Install wget inside LXC vm.

Default cent os template provided for LXC does not have wget package installed.
Need script changes to test_vpc_vm_lifecycle.py in regression.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-8507) fix httpd installation issues in test_vpc_network_pfrules.py test suite

2015-05-22 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8507:
-

 Summary: fix httpd installation issues in 
test_vpc_network_pfrules.py test suite
 Key: CLOUDSTACK-8507
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8507
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Sanjeev N
Assignee: Sanjeev N


check_wget_from_vm() method in test_vpc_network_pfrules.py does not check 
whether httpd service is installed or not.
Before starting the service install the package and start it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-8504) Remove creating network with RVR by default

2015-05-22 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N resolved CLOUDSTACK-8504.
---
Resolution: Fixed

> Remove creating network with RVR by default
> ---
>
> Key: CLOUDSTACK-8504
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8504
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>
> test_egress_fw_rules.py tests in regression suite creates isolated networks 
> with RVR by default. 
> Remove RVR by default since creating network with RVR is taken care in the 
> tests wherever needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (CLOUDSTACK-8504) Remove creating network with RVR by default

2015-05-22 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N closed CLOUDSTACK-8504.
-

> Remove creating network with RVR by default
> ---
>
> Key: CLOUDSTACK-8504
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8504
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>
> test_egress_fw_rules.py tests in regression suite creates isolated networks 
> with RVR by default. 
> Remove RVR by default since creating network with RVR is taken care in the 
> tests wherever needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-8504) Remove creating network with RVR by default

2015-05-21 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8504:
-

 Summary: Remove creating network with RVR by default
 Key: CLOUDSTACK-8504
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8504
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Sanjeev N
Assignee: Sanjeev N


test_egress_fw_rules.py tests in regression suite creates isolated networks 
with RVR by default. 
Remove RVR by default since creating network with RVR is taken care in the 
tests wherever needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-8406) Don't allow creating shared network offering with userdata service and VR as the provider without DHCP service

2015-04-27 Thread Sanjeev N (JIRA)

 [ 
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

2015-04-27 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-8406:
-

 Summary: Don't allow creating shared network offering with 
userdata service and VR as the provider without DHCP service
 Key: CLOUDSTACK-8406
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8406
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Reporter: Sanjeev N


Don't allow creating network offering with userdata service and VR as the 
provider without DHCP service.

If we create shared network offering without DHCP service and with VR as the 
userdata service provider then user vm will not be able to access the userdata 
from VR since it gets the IP address from the external dhcp server.
VM and VR might be in a different network so VM would not be able to access VR 
to fetch the userdata from VR.
So it would be better not to allow this combination while creating network 
offering.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7799) [Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity

2014-10-27 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7799:
--
Attachment: cloud.dmp
management-server.rar

Attached MS log file cloud db dump.

> [Accounts] Account deletion failed to remove all the entities related to it 
> in case of failure in deleting one entity
> -
>
> Key: CLOUDSTACK-7799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7799
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# 
> cloudstack-sccs
> 385c4f673dfbd1fd326e539625e2c06db4cdc27d
>Reporter: Sanjeev N
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> [Critical][Accounts] Account deletion failed to remove all the entities 
> related to it in case of failure in deleting one entity
> Steps to Reproduce:
> 
> 1.Bring up CS in advanced zone with one vmware cluster
> 2.Create a user account 
> 3.With the user account deploy few (4-5) vms 
> 4.Take snapshots on all of the vms root disks
> 5.Deploy another vm and simulate snapshot failure operation(In my case I 
> tried snapshot operation with quiesce option set to true) so that snapshot 
> will be in "Allocated" state
> 6.Delete this user account
> Expected Behavior:
> ==
> Whatever may the state of the snapshot account deletion shall clean all the 
> objects related that account
> Actual Behavior:
> =
> Account deletion started deleting snapshots. Since one of the snapshots is in 
> Allocated state it failed to delete that snapshot and the Account clean up 
> job ended there. So vms and networks related to the accounts are still there 
> but the account was deleted.
> Here is the log snippet:
> =
> 2014-10-28 15:16:38,822 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-1c16bc72) ===START===  10.252.193.8 -- GET  
> command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367
> 2014-10-28 15:16:38,974 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) submit async job-53, details: 
> AsyncJobVO {id:53, userId: 2, accountId: 2, instanceType: Account, 
> instanceId: null, cmd: 
> org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: 
> {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-10-28 15:16:38,978 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) ===END===  10.252.193.8 -- GET  
> command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367
> 2014-10-28 15:16:38,996 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-30:ctx-0b9151e2 job-53) Add job-53 into job monitoring
> 2014-10-28 15:16:38,996 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-30:ctx-0b9151e2 job-53) Executing AsyncJobVO {id:53, 
> userId: 2, accountId: 2, instanceType: Account, instanceId: null, cmd: 
> org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: 
> {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-10-28 15:16:39,153 DEBUG [c.c.u.AccountManagerImpl] 
> (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Removed account 4
> 2014-10-28 15:16:39,287 DEBUG [c.c.a.t.Request] 
> (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Seq 
> 4-4574812796478292948: Sending  { Cmd , MgmtId: 6637838401571, via: 
> 4(s-2-QA), Ver: v1, Flags: 1001

[jira] [Updated] (CLOUDSTACK-7799) [Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity

2014-10-27 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7799:
--
Summary: [Accounts] Account deletion failed to remove all the entities 
related to it in case of failure in deleting one entity  (was: 
[Critical][Accounts] Account deletion failed to remove all the entities related 
to it in case of failure in deleting one entity)

> [Accounts] Account deletion failed to remove all the entities related to it 
> in case of failure in deleting one entity
> -
>
> Key: CLOUDSTACK-7799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7799
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# 
> cloudstack-sccs
> 385c4f673dfbd1fd326e539625e2c06db4cdc27d
>Reporter: Sanjeev N
>Priority: Critical
> Fix For: 4.5.0
>
>
> [Critical][Accounts] Account deletion failed to remove all the entities 
> related to it in case of failure in deleting one entity
> Steps to Reproduce:
> 
> 1.Bring up CS in advanced zone with one vmware cluster
> 2.Create a user account 
> 3.With the user account deploy few (4-5) vms 
> 4.Take snapshots on all of the vms root disks
> 5.Deploy another vm and simulate snapshot failure operation(In my case I 
> tried snapshot operation with quiesce option set to true) so that snapshot 
> will be in "Allocated" state
> 6.Delete this user account
> Expected Behavior:
> ==
> Whatever may the state of the snapshot account deletion shall clean all the 
> objects related that account
> Actual Behavior:
> =
> Account deletion started deleting snapshots. Since one of the snapshots is in 
> Allocated state it failed to delete that snapshot and the Account clean up 
> job ended there. So vms and networks related to the accounts are still there 
> but the account was deleted.
> Here is the log snippet:
> =
> 2014-10-28 15:16:38,822 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-1c16bc72) ===START===  10.252.193.8 -- GET  
> command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367
> 2014-10-28 15:16:38,974 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) submit async job-53, details: 
> AsyncJobVO {id:53, userId: 2, accountId: 2, instanceType: Account, 
> instanceId: null, cmd: 
> org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: 
> {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-10-28 15:16:38,978 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-1c16bc72 ctx-51140d28) ===END===  10.252.193.8 -- GET  
> command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367
> 2014-10-28 15:16:38,996 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-30:ctx-0b9151e2 job-53) Add job-53 into job monitoring
> 2014-10-28 15:16:38,996 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-30:ctx-0b9151e2 job-53) Executing AsyncJobVO {id:53, 
> userId: 2, accountId: 2, instanceType: Account, instanceId: null, cmd: 
> org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: 
> {"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-10-28 15:16:39,153 DEBUG [c.c.u.AccountManagerImpl] 
> (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Removed account 4
> 2014-10-28 15:16:39,287 DEBUG [c.c.a.t.Request] 
> (API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24

[jira] [Created] (CLOUDSTACK-7799) [Critical][Accounts] Account deletion failed to remove all the entities related to it in case of failure in deleting one entity

2014-10-27 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-7799:
-

 Summary: [Critical][Accounts] Account deletion failed to remove 
all the entities related to it in case of failure in deleting one entity
 Key: CLOUDSTACK-7799
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7799
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.5.0
 Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# 
cloudstack-sccs
385c4f673dfbd1fd326e539625e2c06db4cdc27d

Reporter: Sanjeev N
Priority: Critical
 Fix For: 4.5.0


[Critical][Accounts] Account deletion failed to remove all the entities related 
to it in case of failure in deleting one entity

Steps to Reproduce:

1.Bring up CS in advanced zone with one vmware cluster
2.Create a user account 
3.With the user account deploy few (4-5) vms 
4.Take snapshots on all of the vms root disks
5.Deploy another vm and simulate snapshot failure operation(In my case I tried 
snapshot operation with quiesce option set to true) so that snapshot will be in 
"Allocated" state
6.Delete this user account

Expected Behavior:
==
Whatever may the state of the snapshot account deletion shall clean all the 
objects related that account

Actual Behavior:
=
Account deletion started deleting snapshots. Since one of the snapshots is in 
Allocated state it failed to delete that snapshot and the Account clean up job 
ended there. So vms and networks related to the accounts are still there but 
the account was deleted.

Here is the log snippet:
=
2014-10-28 15:16:38,822 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-1c16bc72) 
===START===  10.252.193.8 -- GET  
command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367
2014-10-28 15:16:38,974 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(catalina-exec-5:ctx-1c16bc72 ctx-51140d28) submit async job-53, details: 
AsyncJobVO {id:53, userId: 2, accountId: 2, instanceType: Account, instanceId: 
null, cmd: org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, 
cmdInfo: 
{"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-10-28 15:16:38,978 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-1c16bc72 
ctx-51140d28) ===END===  10.252.193.8 -- GET  
command=deleteAccount&response=json&sessionkey=EpI1EuP5ZFF0VKispQyNb9AxWF4%3D&id=83f26103-9d83-4e4e-8bcc-c282c2acb498&_=1414470667367
2014-10-28 15:16:38,996 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-30:ctx-0b9151e2 job-53) Add job-53 into job monitoring
2014-10-28 15:16:38,996 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-30:ctx-0b9151e2 job-53) Executing AsyncJobVO {id:53, userId: 
2, accountId: 2, instanceType: Account, instanceId: null, cmd: 
org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd, cmdInfo: 
{"response":"json","id":"83f26103-9d83-4e4e-8bcc-c282c2acb498","sessionkey":"EpI1EuP5ZFF0VKispQyNb9AxWF4\u003d","ctxDetails":"{\"com.cloud.user.Account\":\"83f26103-9d83-4e4e-8bcc-c282c2acb498\"}","cmdEventType":"ACCOUNT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1414470667367","uuid":"83f26103-9d83-4e4e-8bcc-c282c2acb498","ctxAccountId":"2","ctxStartEventId":"118"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-10-28 15:16:39,153 DEBUG [c.c.u.AccountManagerImpl] 
(API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Removed account 4
2014-10-28 15:16:39,287 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-30:ctx-0b9151e2 job-53 ctx-3bc74f24) Seq 
4-4574812796478292948: Sending  { Cmd , MgmtId: 6637838401571, via: 4(s-2-QA), 
Ver: v1, Flags: 100111, 
[{"com.cloud.agent.api.DeleteSnapshotsDirCommand":{"store":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/sanjeev/sec_45","_role":"Image"}},"directory":"snapshots/4/5","wait":0}}]
 }
2014-10-28 15:16:40,556 DEBUG [c.c.a.t.Request] (AgentManager-Handler-12:null) 
Seq 4-4574812796478292948: Processing:  { Ans: , MgmtId: 6637838401571, via: 4, 
Ver: v1, Flags: 110, [{"com.cloud.agent.api.Answer":{"result":true,"wait":0}}] }
2014-10-28 15:16:40,556 DEBUG [c.c.a.t.Request] 
(API-

[jira] [Commented] (CLOUDSTACK-7793) [Snapshots]Create Snaphot with "quiesce" option set to true fails with "InvalidParameterValueException: can't handle quiescevm equal true for volume snapshot"

2014-10-27 Thread Sanjeev N (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185060#comment-14185060
 ] 

Sanjeev N commented on CLOUDSTACK-7793:
---

Snapshot operation failed. However, there was a snapshot entry in the cloud db 
with state as "Allocated"
mysql> select * from snapshots where id=13\G
*** 1. row ***
  id: 13
  data_center_id: 3
  account_id: 4
   domain_id: 1
   volume_id: 16
disk_offering_id: 1
  status: Allocated
path: NULL
name: t1_ROOT-14_20141027124059
uuid: 7668446f-667a-4398-a623-23d87067a9f4
   snapshot_type: 0
type_description: MANUAL
size: 2147483648
 created: 2014-10-27 12:40:59
 removed: NULL
  backup_snap_id: NULL
swift_id: NULL
  sechost_id: NULL
prev_snap_id: NULL
 hypervisor_type: VMware
 version: 2.2
   s3_id: NULL
1 row in set (0.00 sec)


> [Snapshots]Create Snaphot with "quiesce" option set to true fails with 
> "InvalidParameterValueException: can't handle quiescevm equal true for volume 
> snapshot"
> --
>
> Key: CLOUDSTACK-7793
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7793
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.5.0
> Environment: Latest build from 4.5
>Reporter: Sanjeev N
>Priority: Critical
> Attachments: management-server.rar
>
>
> [Snapshots]Create Snaphot with "quiesce" option set to true fails with 
> "InvalidParameterValueException: can't handle quiescevm equal true for volume 
> snapshot"
> Steps to Reproduce:
> ===
> 1.Bring up CS in advanced zone with vmware cluster
> 2.Deploy guest vm using default cent os template
> 3.Try to create snapshot on root disk with "quiesce" option set to true:
> http://10.147.38.153:8096/client/api?command=createSnapshot&volumeid=998fd155-7d60-4426-a91c-0a2f1d598021&account=test&domainid=1&quiescevm=true
> Expected Result:
> 
> quiescevm is implemented only for NetApp Plugin with VMWare. If this is not 
> implemented the API should simply ignore the option
> Actual Result:
> ==
> API  didn't ignore this option. Instead it failed with following exception:
> 2014-10-27 18:10:59,861 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (ApiServer-7:ctx-2f20ab36 ctx-a7e2aa42) submit async job-147, details: 
> AsyncJobVO {id:147, userId: 1, accountId: 1, instanceType: Snapshot, 
> instanceId: 13, cmd: 
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: 
> {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-10-27 18:10:59,880 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-44:ctx-15935b7b job-147) Add job-147 into job monitoring
> 2014-10-27 18:10:59,881 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-44:ctx-15935b7b job-147) Executing AsyncJobVO {id:147, 
> userId: 1, accountId: 1, instanceType: Snapshot, instanceId: 13, cmd: 
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: 
> {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-10-27 18:10:59,955 INFO  [o.a.c.a.c.u.s.CreateSnapshotCmd] 
> (API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) VOLSS: 
> createSnapshotCmd starts:1414413659955
> 2014-10-27 18:10:59,978 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Exec

[jira] [Updated] (CLOUDSTACK-7793) [Snapshots]Create Snaphot with "quiesce" option set to true fails with "InvalidParameterValueException: can't handle quiescevm equal true for volume snapshot"

2014-10-27 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7793:
--
Attachment: management-server.rar

Attached MS log file

> [Snapshots]Create Snaphot with "quiesce" option set to true fails with 
> "InvalidParameterValueException: can't handle quiescevm equal true for volume 
> snapshot"
> --
>
> Key: CLOUDSTACK-7793
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7793
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.5.0
> Environment: Latest build from 4.5
>Reporter: Sanjeev N
>Priority: Critical
> Attachments: management-server.rar
>
>
> [Snapshots]Create Snaphot with "quiesce" option set to true fails with 
> "InvalidParameterValueException: can't handle quiescevm equal true for volume 
> snapshot"
> Steps to Reproduce:
> ===
> 1.Bring up CS in advanced zone with vmware cluster
> 2.Deploy guest vm using default cent os template
> 3.Try to create snapshot on root disk with "quiesce" option set to true:
> http://10.147.38.153:8096/client/api?command=createSnapshot&volumeid=998fd155-7d60-4426-a91c-0a2f1d598021&account=test&domainid=1&quiescevm=true
> Expected Result:
> 
> quiescevm is implemented only for NetApp Plugin with VMWare. If this is not 
> implemented the API should simply ignore the option
> Actual Result:
> ==
> API  didn't ignore this option. Instead it failed with following exception:
> 2014-10-27 18:10:59,861 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (ApiServer-7:ctx-2f20ab36 ctx-a7e2aa42) submit async job-147, details: 
> AsyncJobVO {id:147, userId: 1, accountId: 1, instanceType: Snapshot, 
> instanceId: 13, cmd: 
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: 
> {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-10-27 18:10:59,880 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-44:ctx-15935b7b job-147) Add job-147 into job monitoring
> 2014-10-27 18:10:59,881 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-44:ctx-15935b7b job-147) Executing AsyncJobVO {id:147, 
> userId: 1, accountId: 1, instanceType: Snapshot, instanceId: 13, cmd: 
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: 
> {"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-10-27 18:10:59,955 INFO  [o.a.c.a.c.u.s.CreateSnapshotCmd] 
> (API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) VOLSS: 
> createSnapshotCmd starts:1414413659955
> 2014-10-27 18:10:59,978 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) Sync job-148 
> execution on object VmWorkJobQueue.14
> 2014-10-27 18:11:00,456 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f35c279c) Found 2 routers to update status.
> 2014-10-27 18:11:00,458 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f35c279c) Found 0 networks to update RvR status.
> 2014-10-27 18:11:00,526 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-473efbed) Execute sync-queue item: 
> SyncQueueItemVO {id:52, queueId: 34, contentType: AsyncJob, contentId: 148, 
> lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null, 
> created: Mon Oct 27 18:10:59 IST 2014}
> 2014-10-27 18:11:00,529 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Asyn

[jira] [Created] (CLOUDSTACK-7793) [Snapshots]Create Snaphot with "quiesce" option set to true fails with "InvalidParameterValueException: can't handle quiescevm equal true for volume snapshot"

2014-10-27 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-7793:
-

 Summary: [Snapshots]Create Snaphot with "quiesce" option set to 
true fails with "InvalidParameterValueException: can't handle quiescevm equal 
true for volume snapshot"
 Key: CLOUDSTACK-7793
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7793
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Snapshot
Affects Versions: 4.5.0
 Environment: Latest build from 4.5
Reporter: Sanjeev N
Priority: Critical


[Snapshots]Create Snaphot with "quiesce" option set to true fails with 
"InvalidParameterValueException: can't handle quiescevm equal true for volume 
snapshot"

Steps to Reproduce:
===
1.Bring up CS in advanced zone with vmware cluster
2.Deploy guest vm using default cent os template
3.Try to create snapshot on root disk with "quiesce" option set to true:
http://10.147.38.153:8096/client/api?command=createSnapshot&volumeid=998fd155-7d60-4426-a91c-0a2f1d598021&account=test&domainid=1&quiescevm=true

Expected Result:

quiescevm is implemented only for NetApp Plugin with VMWare. If this is not 
implemented the API should simply ignore the option

Actual Result:
==
API  didn't ignore this option. Instead it failed with following exception:

2014-10-27 18:10:59,861 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(ApiServer-7:ctx-2f20ab36 ctx-a7e2aa42) submit async job-147, details: 
AsyncJobVO {id:147, userId: 1, accountId: 1, instanceType: Snapshot, 
instanceId: 13, cmd: 
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: 
{"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-10-27 18:10:59,880 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-44:ctx-15935b7b job-147) Add job-147 into job monitoring
2014-10-27 18:10:59,881 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-44:ctx-15935b7b job-147) Executing AsyncJobVO {id:147, 
userId: 1, accountId: 1, instanceType: Snapshot, instanceId: 13, cmd: 
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: 
{"id":"13","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"7668446f-667a-4398-a623-23d87067a9f4\",\"com.cloud.storage.Volume\":\"998fd155-7d60-4426-a91c-0a2f1d598021\",\"com.cloud.domain.Domain\":1}","cmdEventType":"SNAPSHOT.CREATE","ctxUserId":"1","account":"test","httpmethod":"GET","volumeid":"998fd155-7d60-4426-a91c-0a2f1d598021","domainid":"1","quiescevm":"true","uuid":"7668446f-667a-4398-a623-23d87067a9f4","ctxAccountId":"1","ctxStartEventId":"301"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 6637838401571, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-10-27 18:10:59,955 INFO  [o.a.c.a.c.u.s.CreateSnapshotCmd] 
(API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) VOLSS: 
createSnapshotCmd starts:1414413659955
2014-10-27 18:10:59,978 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-44:ctx-15935b7b job-147 ctx-9af4a710) Sync job-148 execution 
on object VmWorkJobQueue.14
2014-10-27 18:11:00,456 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(RouterStatusMonitor-1:ctx-f35c279c) Found 2 routers to update status.
2014-10-27 18:11:00,458 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(RouterStatusMonitor-1:ctx-f35c279c) Found 0 networks to update RvR status.
2014-10-27 18:11:00,526 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-473efbed) Execute sync-queue item: SyncQueueItemVO 
{id:52, queueId: 34, contentType: AsyncJob, contentId: 148, lastProcessMsid: 
null, lastprocessNumber: null, lastProcessTime: null, created: Mon Oct 27 
18:10:59 IST 2014}
2014-10-27 18:11:00,529 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-473efbed) Schedule queued job-148
2014-10-27 18:11:00,561 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-8dfe1318) Begin cleanup expired async-jobs
2014-10-27 18:11:00,562 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Work-Job-Executor-31:ctx-ee1a398a job-147/job-148) Add job-148 into job 
monitoring
2014-10-27 18:11:00,563 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-31:ctx-ee1a398a job-147/job-148) Executing AsyncJobVO 
{id:148, userId: 

[jira] [Updated] (CLOUDSTACK-7791) [Snapshots] State transition in snapshot objects when snapshot is taken on Root/Data disk is not proper

2014-10-26 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7791:
--
Attachment: management-server.rar

> [Snapshots] State transition in snapshot objects when snapshot is taken on 
> Root/Data disk is not proper
> ---
>
> Key: CLOUDSTACK-7791
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7791
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot, VMware
>Affects Versions: 4.5.0
> Environment: Latest build from 4.5
>Reporter: Sanjeev N
>  Labels: snapshots
> Fix For: 4.5.0
>
> Attachments: management-server.rar
>
>
> [Snapshots] State transition in snapshot objects when snapshot is taken on 
> Root/Data disk is not proper
> Steps to Reproduce:
> 
> 1.Bring up CS with latest build using vmware cluster
> 2.Deploy one guest vm using default cent os template
> 3.Create a snapshot on the root disk of the vm
> Expected Behavior:
> ==
> Snapshot operation should go through the following states:
> Creating->CreatedOnPrimary->BackingUp->BackedUp
> Actual Result:
> ===
> We only see two states: Backingup->Backedup
> As and when the snapshot is triggered it goes to backing up state and remains 
> in that state until the snapshot is copied to secondary storage and then goes 
> to Backedup state.
> This is easy to reproduce.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7791) [Snapshots] State transition in snapshot objects when snapshot is taken on Root/Data disk is not proper

2014-10-26 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-7791:
-

 Summary: [Snapshots] State transition in snapshot objects when 
snapshot is taken on Root/Data disk is not proper
 Key: CLOUDSTACK-7791
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7791
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Snapshot, VMware
Affects Versions: 4.5.0
 Environment: Latest build from 4.5
Reporter: Sanjeev N
 Fix For: 4.5.0


[Snapshots] State transition in snapshot objects when snapshot is taken on 
Root/Data disk is not proper

Steps to Reproduce:

1.Bring up CS with latest build using vmware cluster
2.Deploy one guest vm using default cent os template
3.Create a snapshot on the root disk of the vm

Expected Behavior:
==
Snapshot operation should go through the following states:
Creating->CreatedOnPrimary->BackingUp->BackedUp

Actual Result:
===
We only see two states: Backingup->Backedup

As and when the snapshot is triggered it goes to backing up state and remains 
in that state until the snapshot is copied to secondary storage and then goes 
to Backedup state.

This is easy to reproduce.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7767) [Events] All events are not generated for snapshot creation

2014-10-22 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7767:
--
Attachment: cloud.dmp
management-server.rar

Attached MS log and cloud db dump.

> [Events] All events are not generated for snapshot creation
> ---
>
> Key: CLOUDSTACK-7767
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7767
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.5.0
> Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# 
> cloudstack-sccs
> 562c89544e80dcd61ae5fd179eb8546de2598b33
>Reporter: Sanjeev N
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> [Events] All events are not generated for snapshot creation
> Steps to Reproduce:
> ===
> 1.Bring up CS with latest build from 4.5
> 2.Deploy a vm using cent os template
> 3.Take a snapshot on the root disk of the vm
> 4.Verify the cloud.events table for the snapshot events
> We could see events with states "created,sheduled,started and completed" for 
> vm,volume and template whereas there is only one event with state "scheduled" 
> for snapshot creation.
> So by looking at the events user will not be able to find out whether the 
> snaphot creation is completed of not.
> Following is the DB snippet:
> mysql> select id,uuid,type,state,description  from event where type in 
> ("SNAPSHOT.CREATE","VM.CREATE","VOLUME.CREATE","TEMPLATE.CREATE");
> +-+--+-+---++
> | id  | uuid | type| state | 
> description   
>  |
> +-+--+-+---++
> | 189 | 1f48cbef-648e-4728-9eb1-5178bea3b4fd | SNAPSHOT.CREATE | Scheduled | 
> creating snapshot for volume: 10  
>  |
> | 207 | 9162ed93-bd6c-4e78-8f4a-1836859f5009 | SNAPSHOT.CREATE | Scheduled | 
> creating snapshot for volume: 15  
>  |
> | 208 | 261b95a7-0a4d-45cd-9922-3cde8640ab02 | SNAPSHOT.CREATE | Scheduled | 
> creating snapshot for volume: 15  
>  |
> | 212 | e80e1383-944b-4ac9-bc86-70511de86c94 | SNAPSHOT.CREATE | Scheduled | 
> creating snapshot for volume: 15  
>  |
> | 168 | 518e4ae7-e506-4b93-a8b5-696777b91706 | TEMPLATE.CREATE | Completed | 
> Successfully completed creating template. Id: 202 name: cent53
>  |
> | 193 | 3d20409e-a9e5-438a-9a00-2deb23ee87fe | TEMPLATE.CREATE | Created   | 
> Successfully created entity for creating template 
>  |
> | 194 | 528f823e-b817-4b9a-8935-2f57ac5a4c9b | TEMPLATE.CREATE | Scheduled | 
> creating template: fromSnapRoot10 
>  |
> | 195 | 9ab1d914-9f30-4a3d-8070-1fdce6827f6d | TEMPLATE.CREATE | Started   | 
> creating template. Template Id: 203 from snapshot Id: 1   
>  |
> | 196 | d2676d55-84c8-4486-9aca-0f3eda74a4a7 | TEMPLATE.CREATE | Completed | 
> Successfully completed creating template. Template Id: 203 from snapshot Id: 
> 1 |
> | 154 | 3b9207d6-d120-4762-b9e3-423f849870d6 | VM.CREATE   | Created   | 
> Successfully created entity for deploying Vm. Vm Id: 8
>  |
> | 155 | 7c47beb2-e105-478f-9575-e3ab1b2709ec | VM.CREATE   | Scheduled | 
> starting Vm. Vm Id: 8 
>  |
> | 156 | 27718b57-b679-412b-b983-0f9cf7757930 | VM.CREATE   | Started   | 
> starting Vm. Vm Id: 8 
>  |
> | 159 | 6b5bece5-bfab-41c0-906e-8fbec2ddd2bf | VM.CREATE   | Completed | 
> Successfully completed starting Vm. Vm Id: 8  
>  |
> | 170 | 66412dc3-fc03-4a2d-b796-807bd6ec096f | VM.CREATE   | Created   | 
> Successfully created entity for deploying Vm. Vm Id: 10   
>  |
> | 171 | a6c91812-9218-451c-a801-60652089ba7b | VM.CREATE   | Scheduled | 
> starting Vm. Vm Id: 10
>  |
> | 172 | 3f0cd706-ac3d-48a5-b4f9-a51d96e95dca | VM.CREATE   | Started   | 
> starting Vm. Vm Id: 10
>  |
> | 175 | dde1bff2-5f68-43a9-a090-10718c3a14f

[jira] [Created] (CLOUDSTACK-7767) [Events] All events are not generated for snapshot creation

2014-10-22 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-7767:
-

 Summary: [Events] All events are not generated for snapshot 
creation
 Key: CLOUDSTACK-7767
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7767
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Snapshot
Affects Versions: 4.5.0
 Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# 
cloudstack-sccs
562c89544e80dcd61ae5fd179eb8546de2598b33

Reporter: Sanjeev N
Priority: Critical
 Fix For: 4.5.0


[Events] All events are not generated for snapshot creation

Steps to Reproduce:
===
1.Bring up CS with latest build from 4.5
2.Deploy a vm using cent os template
3.Take a snapshot on the root disk of the vm
4.Verify the cloud.events table for the snapshot events

We could see events with states "created,sheduled,started and completed" for 
vm,volume and template whereas there is only one event with state "scheduled" 
for snapshot creation.

So by looking at the events user will not be able to find out whether the 
snaphot creation is completed of not.

Following is the DB snippet:

mysql> select id,uuid,type,state,description  from event where type in 
("SNAPSHOT.CREATE","VM.CREATE","VOLUME.CREATE","TEMPLATE.CREATE");
+-+--+-+---++
| id  | uuid | type| state | 
description|
+-+--+-+---++
| 189 | 1f48cbef-648e-4728-9eb1-5178bea3b4fd | SNAPSHOT.CREATE | Scheduled | 
creating snapshot for volume: 10   |
| 207 | 9162ed93-bd6c-4e78-8f4a-1836859f5009 | SNAPSHOT.CREATE | Scheduled | 
creating snapshot for volume: 15   |
| 208 | 261b95a7-0a4d-45cd-9922-3cde8640ab02 | SNAPSHOT.CREATE | Scheduled | 
creating snapshot for volume: 15   |
| 212 | e80e1383-944b-4ac9-bc86-70511de86c94 | SNAPSHOT.CREATE | Scheduled | 
creating snapshot for volume: 15   |
| 168 | 518e4ae7-e506-4b93-a8b5-696777b91706 | TEMPLATE.CREATE | Completed | 
Successfully completed creating template. Id: 202 name: cent53 |
| 193 | 3d20409e-a9e5-438a-9a00-2deb23ee87fe | TEMPLATE.CREATE | Created   | 
Successfully created entity for creating template  |
| 194 | 528f823e-b817-4b9a-8935-2f57ac5a4c9b | TEMPLATE.CREATE | Scheduled | 
creating template: fromSnapRoot10  |
| 195 | 9ab1d914-9f30-4a3d-8070-1fdce6827f6d | TEMPLATE.CREATE | Started   | 
creating template. Template Id: 203 from snapshot Id: 1|
| 196 | d2676d55-84c8-4486-9aca-0f3eda74a4a7 | TEMPLATE.CREATE | Completed | 
Successfully completed creating template. Template Id: 203 from snapshot Id: 1 |
| 154 | 3b9207d6-d120-4762-b9e3-423f849870d6 | VM.CREATE   | Created   | 
Successfully created entity for deploying Vm. Vm Id: 8 |
| 155 | 7c47beb2-e105-478f-9575-e3ab1b2709ec | VM.CREATE   | Scheduled | 
starting Vm. Vm Id: 8  |
| 156 | 27718b57-b679-412b-b983-0f9cf7757930 | VM.CREATE   | Started   | 
starting Vm. Vm Id: 8  |
| 159 | 6b5bece5-bfab-41c0-906e-8fbec2ddd2bf | VM.CREATE   | Completed | 
Successfully completed starting Vm. Vm Id: 8   |
| 170 | 66412dc3-fc03-4a2d-b796-807bd6ec096f | VM.CREATE   | Created   | 
Successfully created entity for deploying Vm. Vm Id: 10|
| 171 | a6c91812-9218-451c-a801-60652089ba7b | VM.CREATE   | Scheduled | 
starting Vm. Vm Id: 10 |
| 172 | 3f0cd706-ac3d-48a5-b4f9-a51d96e95dca | VM.CREATE   | Started   | 
starting Vm. Vm Id: 10 |
| 175 | dde1bff2-5f68-43a9-a090-10718c3a14f3 | VM.CREATE   | Completed | 
Successfully completed starting Vm. Vm Id: 10  |
| 180 | 9102d743-3b96-4611-93ab-1fa722170e90 | VM.CREATE   | Created   | 
Successfully created entity for deploying Vm. Vm Id: 12|
| 181 | fd01696d-4f6d-453c-a43c-81ef7e796579 | VM.CREATE   | Scheduled | 
starting Vm. Vm Id: 12 |
| 182 | 3173d69e-b39e-450b-abcb-e3568e86b647 | VM.CREATE   | S

[jira] [Updated] (CLOUDSTACK-7759) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start

2014-10-21 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7759:
--
Attachment: management-server.rar

Attached MS log

> [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start
> 
>
> Key: CLOUDSTACK-7759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
> Environment: Latest build from 4.5
>Reporter: Sanjeev N
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.rar
>
>
> [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start
> Steps to Reproduce:
> ===
> 1.Create CS 4.5 setup using vmware cluster
> 2.Wait for the system vms to come up
> Observations:
> ==
> During system vms start up we see lot of 
> javax.xml.ws.soap.SOAPFaultExceptions in the MS log file
> 2014-10-21 21:17:28,104 WARN  [c.c.h.v.m.HttpNfcLeaseMO] (Thread-29:null) 
> Unexpected exception
> javax.xml.ws.soap.SOAPFaultException: A specified parameter was not correct.
> percent
> at 
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
> at 
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
> at 
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
> at 
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
> at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129)
> at $Proxy413.httpNfcLeaseProgress(Unknown Source)
> at 
> com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO.updateLeaseProgress(HttpNfcLeaseMO.java:104)
> at 
> com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO$ProgressReporter.run(HttpNfcLeaseMO.java:163)
> But these exceptions disappear when the system vms are up and running.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7759) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start

2014-10-21 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-7759:
-

 Summary: [VMWare]javax.xml.ws.soap.SOAPFaultException during 
system vms start
 Key: CLOUDSTACK-7759
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7759
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.5.0
 Environment: Latest build from 4.5
Reporter: Sanjeev N
Priority: Critical
 Fix For: 4.5.0


[VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start

Steps to Reproduce:
===
1.Create CS 4.5 setup using vmware cluster
2.Wait for the system vms to come up

Observations:
==
During system vms start up we see lot of javax.xml.ws.soap.SOAPFaultExceptions 
in the MS log file
2014-10-21 21:17:28,104 WARN  [c.c.h.v.m.HttpNfcLeaseMO] (Thread-29:null) 
Unexpected exception
javax.xml.ws.soap.SOAPFaultException: A specified parameter was not correct.
percent
at 
com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
at 
com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
at 
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
at 
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129)
at $Proxy413.httpNfcLeaseProgress(Unknown Source)
at 
com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO.updateLeaseProgress(HttpNfcLeaseMO.java:104)
at 
com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO$ProgressReporter.run(HttpNfcLeaseMO.java:163)

But these exceptions disappear when the system vms are up and running.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7496) [Automation][HyperV] Unable to ssh into the System VMs after Reboot

2014-09-29 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N resolved CLOUDSTACK-7496.
---
Resolution: Fixed

commit 5bddebb8fc6eb85753a030f1d71fe2303969325b
Author: sanjeev 
Date: Mon Sep 22 16:27:44 2014 +0530

In case of Hyper-v ssvm/cpvm reboot takes time so made changes to handle this


> [Automation][HyperV] Unable to ssh into the System VMs after Reboot
> ---
>
> Key: CLOUDSTACK-7496
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7496
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Sowmya Krishnan
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: runinfo.zip
>
>
> I attached the Automation client log information to this bug report. It shows 
> that the System VMs could not be accessed via ssh after reboot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded

2014-09-24 Thread Sanjeev N (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146109#comment-14146109
 ] 

Sanjeev N commented on CLOUDSTACK-7621:
---

Observed this even on the simulator environment.

> Database schema not getting upgraded
> 
>
> Key: CLOUDSTACK-7621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Pavan Kumar Bandarupally
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: management-server.log
>
>
> After installing management server , the process is stuck at database schema 
> update. The update doesn't progress ahead from 4.0.0
> mysql> select * from version;
> ++-+-+--+
> | id | version | updated | step |
> ++-+-+--+
> |  1 | 4.0.0   | 2014-09-24 12:14:11 | Complete |
> ++-+-+--+
> 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7552) [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - TestCreateVolume.test_01_create_volume

2014-09-15 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N resolved CLOUDSTACK-7552.
---
Resolution: Fixed

> [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - 
> TestCreateVolume.test_01_create_volume
> ---
>
> Key: CLOUDSTACK-7552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7552
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Sanjeev N
>Priority: Critical
> Fix For: 4.5.0
>
>
> Test Case at 
> *integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume* 
> failed on HyperV due to querying for wrong disk on the Guest VM. Instead of 
> */dev/sdb*, Query has been made for */dev/sda*



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7552) [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - TestCreateVolume.test_01_create_volume

2014-09-15 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7552:
--
Status: Reviewable  (was: In Progress)

> [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - 
> TestCreateVolume.test_01_create_volume
> ---
>
> Key: CLOUDSTACK-7552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7552
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Sanjeev N
>Priority: Critical
> Fix For: 4.5.0
>
>
> Test Case at 
> *integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume* 
> failed on HyperV due to querying for wrong disk on the Guest VM. Instead of 
> */dev/sdb*, Query has been made for */dev/sda*



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7552) [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - TestCreateVolume.test_01_create_volume

2014-09-15 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7552:
--
Assignee: Sanjeev N  (was: Chandan Purushothama)

> [Automation][HyperV] Fix the script - "/smoke/test_volumes.py" - 
> TestCreateVolume.test_01_create_volume
> ---
>
> Key: CLOUDSTACK-7552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7552
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Sanjeev N
>Priority: Critical
> Fix For: 4.5.0
>
>
> Test Case at 
> *integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume* 
> failed on HyperV due to querying for wrong disk on the Guest VM. Instead of 
> */dev/sdb*, Query has been made for */dev/sda*



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7541) Volume gets created with the size mentioned in the custom disk offering

2014-09-12 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7541:
--
Attachment: cloud.dmp
management-server.rar

Attache MS log file and cloud db dump.

> Volume gets created with the size mentioned in the custom disk offering 
> 
>
> Key: CLOUDSTACK-7541
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7541
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
> Environment: latest build from 4.5 with commit  
> 932ea253eb8c65821503ab9db301073cdb2a413e
>Reporter: Sanjeev N
>Priority: Critical
> Attachments: cloud.dmp, management-server.rar
>
>
> Volume gets created with the size mentioned in the custom disk offering 
> Steps to reproduce:
> ==
> 1.Bring up cs with latest build
> 2.Create custom disk offering with disk size say 2
> 3.Create data disk using this offering and provide disk size as 1 while 
> creating data disk
> Expected Result:
> ==
> Since the disk offering is of type custom , volume should be created with 
> size given during volume creation instead of taking it from the disk offering.
> If the disk offering is custom then the volume creation must ignore the size 
> given in the offering and should create volume with size provide while 
> creating volume.
> Actual Result:
> ===
> Disk got created with size mentioned in disk offering rather than the size 
> given during volume creation time. 
> Observations:
> ===
> http://10.147.38.153:8096/client/api?command=createDiskOffering&isMirrored=false&name=custom&displaytext=custom&storageType=shared&cacheMode=none&provisioningType=thin&customized=true&disksize=2
> { "creatediskofferingresponse" :  { "diskoffering" : 
> {"id":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","name":"custom","displaytext":"custom","disksize":2,"created":"2014-09-12T23:33:24+0530","iscustomized":true,"storagetype":"shared","provisioningtype":"thin","displayoffering":true}
>  }  }
> http://10.147.38.153:8080/client/api?command=createVolume&response=json&sessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3D&name=custom&zoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dd&diskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873b&size=1&_=1410525928417
> { "queryasyncjobresultresponse" : 
> {"accountid":"638d4e82-341f-11e4-a4c9-06097e23","userid":"638d5ddc-341f-11e4-a4c9-06097e23","cmd":"org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"volume":{"id":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","name":"custom","zoneid":"2c67c83e-b8c3-42d0-a37b-b37287ac84dd","zonename":"zone1","type":"DATADISK","provisioningtype":"thin","size":2147483648,"created":"2014-09-12T23:34:32+0530","state":"Allocated","account":"admin","domainid":"2caca782-341f-11e4-a4c9-06097e23","domain":"ROOT","storagetype":"shared","hypervisor":"None","diskofferingid":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","diskofferingname":"custom","diskofferingdisplaytext":"custom","destroyed":false,"isextractable":true,"tags":[],"displayvolume":true,"quiescevm":false,"jobid":"edf1a066-63b0-400b-bf15-4f77bf659206","jobstatus":0}},"jobinstancetype":"Volume","jobinstanceid":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","created":"2014-09-12T23:34:32+0530","jobid":"edf1a066-63b0-400b-bf15-4f77bf659206"}
>  }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7541) Volume gets created with the size mentioned in the custom disk offering

2014-09-12 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-7541:
-

 Summary: Volume gets created with the size mentioned in the custom 
disk offering 
 Key: CLOUDSTACK-7541
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7541
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Volumes
Affects Versions: 4.5.0
 Environment: latest build from 4.5 with commit  
932ea253eb8c65821503ab9db301073cdb2a413e
Reporter: Sanjeev N
Priority: Critical


Volume gets created with the size mentioned in the custom disk offering 

Steps to reproduce:
==
1.Bring up cs with latest build
2.Create custom disk offering with disk size say 2

3.Create data disk using this offering and provide disk size as 1 while 
creating data disk

Expected Result:
==
Since the disk offering is of type custom , volume should be created with size 
given during volume creation instead of taking it from the disk offering.
If the disk offering is custom then the volume creation must ignore the size 
given in the offering and should create volume with size provide while creating 
volume.

Actual Result:
===
Disk got created with size mentioned in disk offering rather than the size 
given during volume creation time. 

Observations:
===
http://10.147.38.153:8096/client/api?command=createDiskOffering&isMirrored=false&name=custom&displaytext=custom&storageType=shared&cacheMode=none&provisioningType=thin&customized=true&disksize=2
{ "creatediskofferingresponse" :  { "diskoffering" : 
{"id":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","name":"custom","displaytext":"custom","disksize":2,"created":"2014-09-12T23:33:24+0530","iscustomized":true,"storagetype":"shared","provisioningtype":"thin","displayoffering":true}
 }  }

http://10.147.38.153:8080/client/api?command=createVolume&response=json&sessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3D&name=custom&zoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dd&diskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873b&size=1&_=1410525928417

{ "queryasyncjobresultresponse" : 
{"accountid":"638d4e82-341f-11e4-a4c9-06097e23","userid":"638d5ddc-341f-11e4-a4c9-06097e23","cmd":"org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"volume":{"id":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","name":"custom","zoneid":"2c67c83e-b8c3-42d0-a37b-b37287ac84dd","zonename":"zone1","type":"DATADISK","provisioningtype":"thin","size":2147483648,"created":"2014-09-12T23:34:32+0530","state":"Allocated","account":"admin","domainid":"2caca782-341f-11e4-a4c9-06097e23","domain":"ROOT","storagetype":"shared","hypervisor":"None","diskofferingid":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","diskofferingname":"custom","diskofferingdisplaytext":"custom","destroyed":false,"isextractable":true,"tags":[],"displayvolume":true,"quiescevm":false,"jobid":"edf1a066-63b0-400b-bf15-4f77bf659206","jobstatus":0}},"jobinstancetype":"Volume","jobinstanceid":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","created":"2014-09-12T23:34:32+0530","jobid":"edf1a066-63b0-400b-bf15-4f77bf659206"}
 }





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7535) [Automation][HyperV] SSH Client tries to connect to the private Guest IP Address instead of Public IP Address

2014-09-11 Thread Sanjeev N (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131155#comment-14131155
 ] 

Sanjeev N commented on CLOUDSTACK-7535:
---

Hi Chandan,

Script is trying to ssh to the public IP address but inside the script while 
printing the error message in case of ssh failure it is using VM's nic ip 
address instead of ssh ip address . 
try:
ssh_client = self.virtual_machine.get_ssh_client()
except Exception as e:
self.fail("SSH failed for virtual machine: %s - %s" %
(self.virtual_machine.ipaddress, e))

In self.fail method vm ipaddress is being used insted of nat ip address.

> [Automation][HyperV] SSH Client tries to connect to the private Guest IP 
> Address instead of Public IP Address
> -
>
> Key: CLOUDSTACK-7535
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7535
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Sanjeev N
>Priority: Critical
> Fix For: 4.5.0
>
>
> Following two BVT Testcases in two different test suites fail with the same 
> root cause:
> 1. test_04_change_offering_small in test_service_offerings.py
> 2. test_10_attachAndDetach_iso
> {noformat}
> 2014-09-09 05:33:30,778 - DEBUG - Sending GET Cmd : 
> listVirtualMachines===
> 2014-09-09 05:33:30,807 - DEBUG - Response : [{domain : u'ROOT', domainid : 
> u'9df0ddd4-37d3-11e4-a979-ba3c937e668f', haenable : False, templatename : 
> u'CentOS 6.4(64-bit) GUI (Hyperv)', securitygroup : [], zoneid : 
> u'd41a93cd-7b6c-432b-9ad4-eb89d8b6e95c', cpunumber : 1, ostypeid : 182, 
> passwordenabled : False, instancename : u'i-23-43-VM', id : 
> u'21ca01e4-e737-4a06-a560-5c558387acb0', networkkbswrite : 1, hostname : 
> u'10.220.163.50', displayvm : True, state : u'Running', guestosid : 
> u'9e0ec9f2-37d3-11e4-a979-ba3c937e668f', cpuused : u'9%', memory : 256, 
> serviceofferingid : u'a178853a-56fb-484a-992c-30af0d3ef72b', zonename : 
> u'XenRT-Zone-0', isdynamicallyscalable : False, displayname : u'testserver', 
> tags : [], nic : [{networkid : u'e46b21a7-e4a3-4a10-ae1b-bce7a9d1d90e', 
> macaddress : u'02:00:34:f7:00:01', isolationuri : u'vlan://3027', type : 
> u'Isolated', broadcasturi : u'vlan://3027', traffictype : u'Guest', netmask : 
> u'255.255.255.0', ipaddress : u'192.168.200.120', id : 
> u'970f3e6a-c36c-485d-a891-c89cc743f969', networkname : 
> u'test-a-TestServiceOfferings-test_01_create_service_offering-MSR9BE-network',
>  gateway : u'192.168.200.1', isdefault : True}], cpuspeed : 100, templateid : 
> u'9df665f6-37d3-11e4-a979-ba3c937e668f', affinitygroup : [], account : 
> u'test-a-TestServiceOfferings-test_01_create_service_offering-MSR9BE', hostid 
> : u'e0e128e6-3efc-4080-8d50-c710d33854b8', name : 
> u'VM-21ca01e4-e737-4a06-a560-5c558387acb0', networkkbsread : 1, created : 
> u'2014-09-09T05:27:17+', hypervisor : u'Hyperv', rootdevicetype : 
> u'ROOT', rootdeviceid : 0, serviceofferingname : u'Small Instance', 
> templatedisplaytext : u'CentOS 6.4 (64-bit) GUI (Hyperv)'}]
> 2014-09-09 05:33:30,807 - DEBUG - VM state: Running
> 2014-09-09 05:44:34,402 - CRITICAL - FAILED: test_04_change_offering_small: 
> ['Traceback (most recent call last):\n', '  File 
> "/usr/lib/python2.7/unittest/case.py", line 332, in run\ntestMethod()\n', 
> '  File "/root/cloudstack/test/integration/smoke/test_service_offerings.py", 
> line 326, in test_04_change_offering_small\n
> (self.medium_virtual_machine.ipaddress, e)\n', '  File 
> "/usr/lib/python2.7/unittest/case.py", line 413, in fail\nraise 
> self.failureException(msg)\n', 'AssertionError: SSH Access failed for 
> *192.168.200.120: SSH connection has Failed.* Waited 600s. Error is SSH 
> Connection Failed\n']
> 2014-09-09 05:44:34,412 - DEBUG - TestCaseName: 
> test_04_change_offering_small; Time Taken: 678 Seconds; StartTime: Tue Sep  9 
> 05:33:15 2014; EndTime: Tue Sep  9 05:44:34 2014; Result: FAILED
> {noformat}
> {noformat}
> 014-09-09 05:37:23,158 - CRITICAL - FAILED: test_10_attachAndDetach_iso: 
> ['Traceback (most recent call last):\n', '  File 
> "/usr/lib/python2.7/unittest/case.py", line 332, in run\ntestMethod()\n', 
> '  File "/root/cloudstack/test/integration/smoke/test_vm_life_cycle.py", line 
> 692, in test_10_attachAndDetach_iso\n(self.virtual_machine.ipaddress, 
> e))\n', '  File "/usr/lib/python2.7/unittest/case.py", line 413, in fail\n
> raise self.failureException(msg)\n', 'AssertionError: SSH failed for virtual 
> machine: 192.168.200.149 - SSH connection h

[jira] [Updated] (CLOUDSTACK-7532) [Templates] Template status is not shown in UI/API response for non-default account users

2014-09-10 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7532:
--
Attachment: template_status.PNG

Attached screenshot to describe the issue.

> [Templates] Template status is not shown in UI/API response for non-default 
> account users
> -
>
> Key: CLOUDSTACK-7532
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7532
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Template
>Affects Versions: 4.5.0
> Environment: Latest build from master with commit:
> c33fea2cd27664db32c1173e98511470bf0a0724
>Reporter: Sanjeev N
>Priority: Critical
>  Labels: api, templates
> Attachments: template_status.PNG
>
>
> [Templates] Template status is not shown in UI/API response for non-default 
> account users
> Steps to Reproduce:
> ===
> 1.Bring up CS with latest build
> 2.Create one account under root domain
> 3.Register template using the account created above
> 4.After the template download is completed verify the template status using 
> the account created at step2
> Expected Result:
> ==
> In UI/API response status field should be there and it should be set to 
> "Download Complete" after the successful template download.
> Actual Behavior:
> 
> Status is shown only for the default admin user. But it is not showed to 
> other account users.
> Impact:
> ==
> Marvin tests which use template register would fail because of the status 
> filed missing.
> Following is the code from base.py where the tests are failing:
>  elif 'Downloaded' in template.status:
> time.sleep(interval)
> becasue template.status is NoneType 
> API:
> 
> http://10.147.40.10:8080/client/api?command=listTemplates&sessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3D&templatefilter=self&id=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa&_=1410351906876
> API Response:
> ===
>  cloud-stack-version="4.5.0-SNAPSHOT">1550ad6ac-38d2-11e4-a56e-d4ae527ccfaaCentOS
>  5.6(64-bit) no GUI (XenServer)CentOS 5.6(64-bit) no GUI 
> (XenServer)true2014-09-10T15:59:38+0530truefalseVHDtruetrue572126ea-38d2-11e4-a56e-d4ae527ccfaaCentOS
>  5.6 
> (64-bit)system680f7c3a-a9ee-4ed3-b594-981d56f8da4bz221474836480BUILTINXenServerROOT54e9d4e4-38d2-11e4-a56e-d4ae527ccfaatrue905cec879afd9c9d22ecc8036131a180falsetrue
> In the above API response status field is missing.
> This bug is easily reproducible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7532) [Templates] Template status is not shown in UI/API response for non-default account users

2014-09-10 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-7532:
-

 Summary: [Templates] Template status is not shown in UI/API 
response for non-default account users
 Key: CLOUDSTACK-7532
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7532
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API, Template
Affects Versions: 4.5.0
 Environment: Latest build from master with commit:
c33fea2cd27664db32c1173e98511470bf0a0724
Reporter: Sanjeev N
Priority: Critical


[Templates] Template status is not shown in UI/API response for non-default 
account users

Steps to Reproduce:
===
1.Bring up CS with latest build
2.Create one account under root domain
3.Register template using the account created above
4.After the template download is completed verify the template status using the 
account created at step2

Expected Result:
==
In UI/API response status field should be there and it should be set to 
"Download Complete" after the successful template download.

Actual Behavior:

Status is shown only for the default admin user. But it is not showed to other 
account users.

Impact:
==
Marvin tests which use template register would fail because of the status filed 
missing.
Following is the code from base.py where the tests are failing:
 elif 'Downloaded' in template.status:
time.sleep(interval)
becasue template.status is NoneType 

API:

http://10.147.40.10:8080/client/api?command=listTemplates&sessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3D&templatefilter=self&id=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa&_=1410351906876
API Response:
===
1550ad6ac-38d2-11e4-a56e-d4ae527ccfaaCentOS
 5.6(64-bit) no GUI (XenServer)CentOS 5.6(64-bit) no GUI 
(XenServer)true2014-09-10T15:59:38+0530truefalseVHDtruetrue572126ea-38d2-11e4-a56e-d4ae527ccfaaCentOS
 5.6 
(64-bit)system680f7c3a-a9ee-4ed3-b594-981d56f8da4bz221474836480BUILTINXenServerROOT54e9d4e4-38d2-11e4-a56e-d4ae527ccfaatrue905cec879afd9c9d22ecc8036131a180falsetrue

In the above API response status field is missing.
This bug is easily reproducible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"

2014-09-08 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N closed CLOUDSTACK-7508.
-

> [Automation] Duplicate entries in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> --
>
> Key: CLOUDSTACK-7508
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7508
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest build from master
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>  Labels: automation
>
> [Automation] Duplicate entried in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> test_data.py in marvin has two dictionaries with name 
> "nw_off_persistent_VPCVR_NoLB" one with ispersistent set to True and another 
> one with ispersistent set to False.
> Tests would fail if the test picks the one with ispersistent set to False. So 
> we should delete the one with ispersistent set to False.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"

2014-09-08 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N resolved CLOUDSTACK-7508.
---
Resolution: Fixed

commit 535e7a667049e37d6a03c7a3e2e5c9645e6ce1f6
Author: sanjeev 
Date:   Mon Sep 8 17:21:11 2014 +0530

CLOUDSTACK-7508: Remove duplicate network offerings from test_data.py


> [Automation] Duplicate entries in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> --
>
> Key: CLOUDSTACK-7508
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7508
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest build from master
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>  Labels: automation
>
> [Automation] Duplicate entried in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> test_data.py in marvin has two dictionaries with name 
> "nw_off_persistent_VPCVR_NoLB" one with ispersistent set to True and another 
> one with ispersistent set to False.
> Tests would fail if the test picks the one with ispersistent set to False. So 
> we should delete the one with ispersistent set to False.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"

2014-09-08 Thread Sanjeev N (JIRA)
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

2014-08-18 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N closed CLOUDSTACK-7188.
-

Resolution: Fixed

This issue has been fixed in CS-7190

> [Automation]Add hyper-v support for test_ssvm.py suite in BVT
> -
>
> Key: CLOUDSTACK-7188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest master build
>Reporter: Sanjeev N
>  Labels: automation
>
> [Automation]Add hyper-v support for test_ssvm.py suite in BVT
> 1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests 
> require ssh access to ssvm/cpvm. Right now the tests have ssh access 
> mechanism supported only for vmware,xen and kvm.
> This bug is to add ssh access support for Hyper-v as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (CLOUDSTACK-7189) [Automation]Add hyper-v support for test_routers.py suite in BVT

2014-08-18 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N closed CLOUDSTACK-7189.
-

Resolution: Fixed

This issue has been fixed in CS-7190

> [Automation]Add hyper-v support for test_routers.py suite in BVT
> 
>
> Key: CLOUDSTACK-7189
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7189
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest build from master
>Reporter: Sanjeev N
>  Labels: automation
>
> [Automation]Add hyper-v support for test_routers.py suite in BVT
> Few tests in test_routers.py suite file require ssh access to VR. Need to add 
> support for hyper-v similar to vmware in accessing VR via ssh.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (CLOUDSTACK-7189) [Automation]Add hyper-v support for test_routers.py suite in BVT

2014-07-28 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-7189:
-

 Summary: [Automation]Add hyper-v support for test_routers.py suite 
in BVT
 Key: CLOUDSTACK-7189
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7189
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
 Environment: Latest build from master
Reporter: Sanjeev N


[Automation]Add hyper-v support for test_routers.py suite in BVT

Few tests in test_routers.py suite file require ssh access to VR. Need to add 
support for hyper-v similar to vmware in accessing VR via ssh.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CLOUDSTACK-7188) [Automation]Add hyper-v support for test_ssvm.py suite in BVT

2014-07-28 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7188:
--

Issue Type: Test  (was: Bug)

> [Automation]Add hyper-v support for test_ssvm.py suite in BVT
> -
>
> Key: CLOUDSTACK-7188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest master build
>Reporter: Sanjeev N
>  Labels: automation
>
> [Automation]Add hyper-v support for test_ssvm.py suite in BVT
> 1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests 
> require ssh access to ssvm/cpvm. Right now the tests have ssh access 
> mechanism supported only for vmware,xen and kvm.
> This bug is to add ssh access support for Hyper-v as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (CLOUDSTACK-7188) [Automation]Add hyper-v support for test_ssvm.py suite in BVT

2014-07-28 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-7188:
-

 Summary: [Automation]Add hyper-v support for test_ssvm.py suite in 
BVT
 Key: CLOUDSTACK-7188
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7188
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
 Environment: Latest master build
Reporter: Sanjeev N


[Automation]Add hyper-v support for test_ssvm.py suite in BVT

1.test_ssvm.py suite file has in BVT has 10 tests and 8 out of these 10 tests 
require ssh access to ssvm/cpvm. Right now the tests have ssh access mechanism 
supported only for vmware,xen and kvm.

This bug is to add ssh access support for Hyper-v as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py

2014-07-16 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N closed CLOUDSTACK-6992.
-


Verified the fix on my local setup before submitting patch. Works fine. 

> [Portable_IP] All tests failed from advanced regression suite 
> test_portable_ip.py
> -
>
> Key: CLOUDSTACK-6992
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>Priority: Critical
>  Labels: automation
> Fix For: 4.4.0
>
>
> [Portable_IP] All tests failed from advanced regression suite 
> test_portable_ip.py
> In this test_portable_ip.py file every test method has the following line:
> portable_ip_range_services = getPortableIpRangeServices(self.config)
> However self.config is not defined. So we are seeing following error from the 
> test run:
> 'NoneType' object has no attribute 'startip'
>  >> begin captured stdout << -
> === TestName: test_associate_ip_address | Status : EXCEPTION ===
> test_associate_ip_address 
> (integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: 
> STARTED : TC: test_associate_ip_address :::
> test_associate_ip_address 
> (integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: 
> EXCEPTION: test_associate_ip_address: ['Traceback (most recent call 
> last):\n', '  File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n  
>   self.setUp()\n', '  File 
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py",
>  line 639, in setUp\nportable_ip_range_services = 
> getPortableIpRangeServices(self.config)\n', '  File 
> "/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py",
>  line 1198, in getPortableIpRangeServices\nif 
> config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no 
> attribute 'startip'\n"]



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Resolved] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py

2014-07-16 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N resolved CLOUDSTACK-6992.
---

Resolution: Fixed

> [Portable_IP] All tests failed from advanced regression suite 
> test_portable_ip.py
> -
>
> Key: CLOUDSTACK-6992
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>Priority: Critical
>  Labels: automation
> Fix For: 4.4.0
>
>
> [Portable_IP] All tests failed from advanced regression suite 
> test_portable_ip.py
> In this test_portable_ip.py file every test method has the following line:
> portable_ip_range_services = getPortableIpRangeServices(self.config)
> However self.config is not defined. So we are seeing following error from the 
> test run:
> 'NoneType' object has no attribute 'startip'
>  >> begin captured stdout << -
> === TestName: test_associate_ip_address | Status : EXCEPTION ===
> test_associate_ip_address 
> (integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: 
> STARTED : TC: test_associate_ip_address :::
> test_associate_ip_address 
> (integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: 
> EXCEPTION: test_associate_ip_address: ['Traceback (most recent call 
> last):\n', '  File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n  
>   self.setUp()\n', '  File 
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py",
>  line 639, in setUp\nportable_ip_range_services = 
> getPortableIpRangeServices(self.config)\n', '  File 
> "/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py",
>  line 1198, in getPortableIpRangeServices\nif 
> config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no 
> attribute 'startip'\n"]



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py

2014-06-26 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6992:
--

Status: Reviewable  (was: In Progress)

> [Portable_IP] All tests failed from advanced regression suite 
> test_portable_ip.py
> -
>
> Key: CLOUDSTACK-6992
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>Priority: Critical
>  Labels: automation
> Fix For: 4.4.0
>
>
> [Portable_IP] All tests failed from advanced regression suite 
> test_portable_ip.py
> In this test_portable_ip.py file every test method has the following line:
> portable_ip_range_services = getPortableIpRangeServices(self.config)
> However self.config is not defined. So we are seeing following error from the 
> test run:
> 'NoneType' object has no attribute 'startip'
>  >> begin captured stdout << -
> === TestName: test_associate_ip_address | Status : EXCEPTION ===
> test_associate_ip_address 
> (integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: 
> STARTED : TC: test_associate_ip_address :::
> test_associate_ip_address 
> (integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: 
> EXCEPTION: test_associate_ip_address: ['Traceback (most recent call 
> last):\n', '  File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n  
>   self.setUp()\n', '  File 
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py",
>  line 639, in setUp\nportable_ip_range_services = 
> getPortableIpRangeServices(self.config)\n', '  File 
> "/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py",
>  line 1198, in getPortableIpRangeServices\nif 
> config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no 
> attribute 'startip'\n"]



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Assigned] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py

2014-06-26 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N reassigned CLOUDSTACK-6992:
-

Assignee: Sanjeev N

> [Portable_IP] All tests failed from advanced regression suite 
> test_portable_ip.py
> -
>
> Key: CLOUDSTACK-6992
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>Priority: Critical
>  Labels: automation
> Fix For: 4.4.0
>
>
> [Portable_IP] All tests failed from advanced regression suite 
> test_portable_ip.py
> In this test_portable_ip.py file every test method has the following line:
> portable_ip_range_services = getPortableIpRangeServices(self.config)
> However self.config is not defined. So we are seeing following error from the 
> test run:
> 'NoneType' object has no attribute 'startip'
>  >> begin captured stdout << -
> === TestName: test_associate_ip_address | Status : EXCEPTION ===
> test_associate_ip_address 
> (integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: 
> STARTED : TC: test_associate_ip_address :::
> test_associate_ip_address 
> (integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: 
> EXCEPTION: test_associate_ip_address: ['Traceback (most recent call 
> last):\n', '  File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n  
>   self.setUp()\n', '  File 
> "/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py",
>  line 639, in setUp\nportable_ip_range_services = 
> getPortableIpRangeServices(self.config)\n', '  File 
> "/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py",
>  line 1198, in getPortableIpRangeServices\nif 
> config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no 
> attribute 'startip'\n"]



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (CLOUDSTACK-6992) [Portable_IP] All tests failed from advanced regression suite test_portable_ip.py

2014-06-25 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6992:
-

 Summary: [Portable_IP] All tests failed from advanced regression 
suite test_portable_ip.py
 Key: CLOUDSTACK-6992
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6992
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.4.0
 Environment: Latest build from 4.4

Reporter: Sanjeev N
Priority: Critical
 Fix For: 4.4.0


[Portable_IP] All tests failed from advanced regression suite 
test_portable_ip.py

In this test_portable_ip.py file every test method has the following line:
portable_ip_range_services = getPortableIpRangeServices(self.config)

However self.config is not defined. So we are seeing following error from the 
test run:

'NoneType' object has no attribute 'startip'
 >> begin captured stdout << -
=== TestName: test_associate_ip_address | Status : EXCEPTION ===

test_associate_ip_address 
(integration.component.test_portable_ip.TestAssociatePublicIp): DEBUG: 
STARTED : TC: test_associate_ip_address :::
test_associate_ip_address 
(integration.component.test_portable_ip.TestAssociatePublicIp): CRITICAL: 
EXCEPTION: test_associate_ip_address: ['Traceback (most recent call last):\n', 
'  File "/usr/lib/python2.7/unittest/case.py", line 323, in run\n
self.setUp()\n', '  File 
"/home/jenkins/workspace/xenrt-reg-adv-xs/cloudstack.git/test/integration/component/test_portable_ip.py",
 line 639, in setUp\nportable_ip_range_services = 
getPortableIpRangeServices(self.config)\n', '  File 
"/local/jenkins/workspace/xenrt-reg-adv-xs/work.57/env/local/lib/python2.7/site-packages/marvin/lib/common.py",
 line 1198, in getPortableIpRangeServices\nif 
config.portableIpRange.startip:\n', "AttributeError: 'NoneType' object has no 
attribute 'startip'\n"]




--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CLOUDSTACK-6841) [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks

2014-06-04 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6841:
--

Attachment: cloud-44.dmp
ovstunnel-host14.log
ovstunnel-host13.log
management-server.rar

> [OVS] Remote_ips for tunnel ports are not configured properly in case of 
> multipel physical networks 
> 
>
> Key: CLOUDSTACK-6841
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6841
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: cloud-44.dmp, management-server.rar, 
> ovstunnel-host13.log, ovstunnel-host14.log
>
>
> [OVS] Remote_ips for tunnel ports are not configured properly in case of 
> multipel physical networks 
> Steps to reproduce:
> ==
> 1.Bring up CS in advanced zone with xen cluster with min of two hosts
> and two nics on both the hosts
> 2.Create two physical networks with GRE isolation during zone creation:
> in physical network1 add guest,public&management traffic types with tag "tag1"
> in physical network2 add only guest traffic with tag "tag2"
> 3.create two network offerings NO1&NO2 with virtual networking and ovs as the 
> connectivity service provider and user taggings tag1 & tag2 in NO1 & NO2 
> respectively
> 4.Create isolated networks nw1 & nw2 using NO1 & NO2
> 5.Deploy vms in both the netwoks and make sure that both the networks are 
> spread across both the hosts in the cluster
> 6.Verify tunnel ports remote_ips on both the hosts 
> On xenservers used NIC0 for physical network1(by using traffic labels) and 
> NIC1 for physical network2
> NIC0&NIC1 both have routable IP addresses.
> Result:
> =
> Remote_ips for all the tunnel ports created in the above networks are set to 
> NIC1 ip addresses. But tunnel ports in network created on physical network1 
> should have NIC0 ip address as remote_ip and NIC1 ip address for the tunnel 
> ports in other network.
> mysql> select * from ovs_tunnel_interface;
> ++--+---+---+-++
> | id | ip   | netmask   | mac   | host_id | label 
>  |
> ++--+---+---+-++
> |  1 | 0| 0 | 0 |   0 | lock  
>  |
> |  2 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab |   1 | 
> management |
> |  3 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d |   2 | 
> management |
> |  4 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab |   1 | gre   
>  |
> |  5 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d |   2 | gre   
>  |
> ++--+---+---+-++
> 5 rows in set (0.00 sec)
> Here management label is on NIC0 and gre is on NIC1 and 
> 10.147.42.13&10.147.42.14 are assigned to NIC1 on the hosts.
> But in the above table we are using same ip address against bot the labels. 
> So tunnel ports for both the networks are created with same remote_ip address.
> Host details are as follows:
> mysql> select 
> id,name,private_ip_address,public_ip_address,data_center_id,cluster_id from 
> host where id in (1,2);
> ++-++---+++
> | id | name| private_ip_address | public_ip_address | 
> data_center_id | cluster_id |
> ++-++---+++
> |  1 | Rack1Pod1Host13 | 10.147.40.13   | 10.147.40.13  | 
>  1 |  1 |
> |  2 | Rack1Pod1Host14 | 10.147.40.14   | 10.147.40.14  | 
>  1 |  1 |
> ++-++---+++
> 2 rows in set (0.00 sec)
> 10.147.40.13& 10.147.40.14 ip addresses are management addresses assigned to 
> NIC0 on both the hosts.
> Tunnel ports details on the hosts are:
> system@xapi16:
> lookups: hit:11752 missed:3227 lost:0
> flows: 4
> port 0: xapi16 (internal)
> port 1: t4018-2-1 (gre: key=4018, remote_ip=10.147.42.13)
> port 2: vif26.0
> system@xapi15:
> lookups: hit:4359 missed:167 lost:0
> flows: 0
> port 0: xapi15 (internal)
> port 1: t992-2-1 (gre: key=992

[jira] [Created] (CLOUDSTACK-6841) [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks

2014-06-04 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6841:
-

 Summary: [OVS] Remote_ips for tunnel ports are not configured 
properly in case of multipel physical networks 
 Key: CLOUDSTACK-6841
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6841
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0


[OVS] Remote_ips for tunnel ports are not configured properly in case of 
multipel physical networks 

Steps to reproduce:
==
1.Bring up CS in advanced zone with xen cluster with min of two hosts
and two nics on both the hosts
2.Create two physical networks with GRE isolation during zone creation:
in physical network1 add guest,public&management traffic types with tag "tag1"
in physical network2 add only guest traffic with tag "tag2"
3.create two network offerings NO1&NO2 with virtual networking and ovs as the 
connectivity service provider and user taggings tag1 & tag2 in NO1 & NO2 
respectively
4.Create isolated networks nw1 & nw2 using NO1 & NO2
5.Deploy vms in both the netwoks and make sure that both the networks are 
spread across both the hosts in the cluster
6.Verify tunnel ports remote_ips on both the hosts 

On xenservers used NIC0 for physical network1(by using traffic labels) and NIC1 
for physical network2
NIC0&NIC1 both have routable IP addresses.

Result:
=
Remote_ips for all the tunnel ports created in the above networks are set to 
NIC1 ip addresses. But tunnel ports in network created on physical network1 
should have NIC0 ip address as remote_ip and NIC1 ip address for the tunnel 
ports in other network.

mysql> select * from ovs_tunnel_interface;
++--+---+---+-++
| id | ip   | netmask   | mac   | host_id | label  |
++--+---+---+-++
|  1 | 0| 0 | 0 |   0 | lock   |
|  2 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab |   1 | management |
|  3 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d |   2 | management |
|  4 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab |   1 | gre|
|  5 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d |   2 | gre|
++--+---+---+-++
5 rows in set (0.00 sec)

Here management label is on NIC0 and gre is on NIC1 and 
10.147.42.13&10.147.42.14 are assigned to NIC1 on the hosts.
But in the above table we are using same ip address against bot the labels. So 
tunnel ports for both the networks are created with same remote_ip address.

Host details are as follows:
mysql> select 
id,name,private_ip_address,public_ip_address,data_center_id,cluster_id from 
host where id in (1,2);
++-++---+++
| id | name| private_ip_address | public_ip_address | 
data_center_id | cluster_id |
++-++---+++
|  1 | Rack1Pod1Host13 | 10.147.40.13   | 10.147.40.13  |  
1 |  1 |
|  2 | Rack1Pod1Host14 | 10.147.40.14   | 10.147.40.14  |  
1 |  1 |
++-++---+++
2 rows in set (0.00 sec)

10.147.40.13& 10.147.40.14 ip addresses are management addresses assigned to 
NIC0 on both the hosts.

Tunnel ports details on the hosts are:
system@xapi16:
lookups: hit:11752 missed:3227 lost:0
flows: 4
port 0: xapi16 (internal)
port 1: t4018-2-1 (gre: key=4018, remote_ip=10.147.42.13)
port 2: vif26.0
system@xapi15:
lookups: hit:4359 missed:167 lost:0
flows: 0
port 0: xapi15 (internal)
port 1: t992-2-1 (gre: key=992, remote_ip=10.147.42.13)
port 2: vif25.0

Attaching MS log file, cloud DB and ovstunnel log files.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CLOUDSTACK-6840) [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if the physical network isolation type is VLAN

2014-06-03 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6840:
--

Attachment: ovs_vlan.PNG

Attached screenshot to describe the issue.

> [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if 
> the physical network isolation type is VLAN
> 
>
> Key: CLOUDSTACK-6840
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6840
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4. with commit 
> 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
>Reporter: Sanjeev N
>Assignee: Gabor Apati-Nagy
>Priority: Critical
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: ovs_vlan.PNG
>
>
> [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if 
> the physical network isolation type is VLAN
> Steps to reproduce:
> ==
> 1.Bring up CS in advanced zone with xen cluster
> 2.While creating physical network during zone creation choose VLAN as the 
> isolation type
> 3.From UI navigate to Home->Infrastructure->Zones->CS-GRE->Physical Network 
> 1->Network Service Providers
> Result:
> ==
> NetworkServiceProviders page shows OVS as one of the providers and by default 
> is in disabled state. Whereas API does not show OVS as one of the providers.
> Following is the API response:
> http://10.147.59.119:8096/client/api?command=listNetworkServiceProviders&physicalnetworkid=e58d6d73-cd77-4917-875a-695f56a4b968
>  cloud-stack-version="4.4.0-SNAPSHOT">4InternalLbVme58d6d73-cd77-4917-875a-695f56a4b968Enabled223a1a51-c6a0-4239-ac82-f96290520669LbtrueVpcVirtualRoutere58d6d73-cd77-4917-875a-695f56a4b968Enabled641ae03f-861b-4e20-8b59-333f0848207eVpnDhcpDnsGatewayLbSourceNatStaticNatPortForwardingUserDatatrueSecurityGroupProvidere58d6d73-cd77-4917-875a-695f56a4b968Disabled2414d618-ec08-4624-b16e-fd22e2326f24SecurityGroupfalseVirtualRoutere58d6d73-cd77-4917-875a-695f56a4b968Enableddae0a4b6-24a7-4d56-91bd-8f0f4919938eVpnDhcpDnsGatewayFirewallLbSourceNatStaticNatPortForwardingUserDatatrue
> DB entries from cloud db are as follows:
> mysql> select * from physical_network_service_providers where 
> physical_network_id=202;
> ++--+-+---+--+-+--+---+--+--+---+-+---+-+--++-+-+-+
> | id | uuid | physical_network_id | 
> provider_name | state| destination_physical_network_id | 
> vpn_service_provided | dhcp_service_provided | dns_service_provided | 
> gateway_service_provided | firewall_service_provided | 
> source_nat_service_provided | load_balance_service_provided | 
> static_nat_service_provided | port_forwarding_service_provided | 
> user_data_service_provided | security_group_service_provided | 
> networkacl_service_provided | removed |
> ++--+-+---+--+-+--+---+--+--+---+-+---+-+--++-+-+-+
> | 11 | dae0a4b6-24a7-4d56-91bd-8f0f4919938e | 202 | 
> VirtualRouter | Enabled  |   0 |  
>   1 | 1 |1 |  
>   1 | 1 |   1 |   
>   1 |   1 |   
>  1 |  1 |   0 |   
> 0 | NULL|
> | 12 | 2414d618-ec08-4624-b16e-fd22e2326f24 | 202 | 
> SecurityGroupProvider | Disabled |   0 |  
>   0 | 0 |0 |  
>   0 | 0 |   0 |   
>   0 | 

[jira] [Created] (CLOUDSTACK-6840) [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if the physical network isolation type is VLAN

2014-06-03 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6840:
-

 Summary: [OVS][UI] Ovs provider should not be displayed in 
NetworkServiceProviders if the physical network isolation type is VLAN
 Key: CLOUDSTACK-6840
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6840
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.4.0
 Environment: Latest build from 4.4. with commit 
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Gabor Apati-Nagy
Priority: Critical
 Fix For: 4.4.0


[OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if 
the physical network isolation type is VLAN

Steps to reproduce:
==
1.Bring up CS in advanced zone with xen cluster
2.While creating physical network during zone creation choose VLAN as the 
isolation type
3.From UI navigate to Home->Infrastructure->Zones->CS-GRE->Physical Network 
1->Network Service Providers

Result:
==
NetworkServiceProviders page shows OVS as one of the providers and by default 
is in disabled state. Whereas API does not show OVS as one of the providers.

Following is the API response:
http://10.147.59.119:8096/client/api?command=listNetworkServiceProviders&physicalnetworkid=e58d6d73-cd77-4917-875a-695f56a4b968
4InternalLbVme58d6d73-cd77-4917-875a-695f56a4b968Enabled223a1a51-c6a0-4239-ac82-f96290520669LbtrueVpcVirtualRoutere58d6d73-cd77-4917-875a-695f56a4b968Enabled641ae03f-861b-4e20-8b59-333f0848207eVpnDhcpDnsGatewayLbSourceNatStaticNatPortForwardingUserDatatrueSecurityGroupProvidere58d6d73-cd77-4917-875a-695f56a4b968Disabled2414d618-ec08-4624-b16e-fd22e2326f24SecurityGroupfalseVirtualRoutere58d6d73-cd77-4917-875a-695f56a4b968Enableddae0a4b6-24a7-4d56-91bd-8f0f4919938eVpnDhcpDnsGatewayFirewallLbSourceNatStaticNatPortForwardingUserDatatrue

DB entries from cloud db are as follows:

mysql> select * from physical_network_service_providers where 
physical_network_id=202;
++--+-+---+--+-+--+---+--+--+---+-+---+-+--++-+-+-+
| id | uuid | physical_network_id | 
provider_name | state| destination_physical_network_id | 
vpn_service_provided | dhcp_service_provided | dns_service_provided | 
gateway_service_provided | firewall_service_provided | 
source_nat_service_provided | load_balance_service_provided | 
static_nat_service_provided | port_forwarding_service_provided | 
user_data_service_provided | security_group_service_provided | 
networkacl_service_provided | removed |
++--+-+---+--+-+--+---+--+--+---+-+---+-+--++-+-+-+
| 11 | dae0a4b6-24a7-4d56-91bd-8f0f4919938e | 202 | 
VirtualRouter | Enabled  |   0 |
1 | 1 |1 |  
  1 | 1 |   1 | 
1 |   1 |1 
|  1 |   0 |
   0 | NULL|
| 12 | 2414d618-ec08-4624-b16e-fd22e2326f24 | 202 | 
SecurityGroupProvider | Disabled |   0 |
0 | 0 |0 |  
  0 | 0 |   0 | 
0 |   0 |0 
|  0 |   1 |
   0 | NULL|
| 13 | 641ae03f-861b-4e20-8b59-333f0848207e | 202 | 
VpcVirtualRouter  | Enabled  |   0 |
1 | 1 |1 |  
  1 | 0 |   1 | 
1 |   1 |   

[jira] [Updated] (CLOUDSTACK-6832) [OVS]vnet is not released even the network is deleted

2014-06-03 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6832:
--

Attachment: management-server.rar

> [OVS]vnet is not released even the network is deleted
> -
>
> Key: CLOUDSTACK-6832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6832
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: management-server.rar
>
>
> [OVS]vnet is not released even the network is deleted
> Steps to reproduce:
> ===
> 1.Bring up CS in advanced zone with xen cluster
> 2.Create physical network with GRE isolation and specify some VNIs as GRE 
> keys for guest traffic
> 3.Create network offering with virtual networking and OVS as the service 
> provider
> 4.Deploy few vms with the above network
> 5.Delete the network after expunging all the vms
> Result:
> =
> Network deletion was successful but the vnet allocated for the network was 
> not released.
> VNI range specified for the guest traffic was 981-1000 and 992 was taken for 
> the implemented network. But the vnet id 992 was not released back to the 
> pool even after deleting the network.
> mysql> select * from op_dc_vnet_alloc;
> +-+--+-++--++-+-+
> | id  | vnet | physical_network_id | data_center_id | reservation_id  
>  | account_id | taken   | account_vnet_map_id |
> +-+--+-++--++-+-+
> | 122 | 989  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 123 | 988  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 124 | 987  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 125 | 982  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 126 | 981  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 127 | 986  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 128 | 985  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 129 | 984  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 130 | 983  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 131 | 996  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 132 | 997  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 133 | 994  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 134 | 995  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 135 | 992  | 203 |  2 | 
> 8edad56a-a59d-4477-8741-9e91a8ef9052 |  2 | 2014-06-03 15:12:55 | 
>NULL |
> | 136 | 993  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 137 | 990  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 138 | 991  | 203 |  2 | NULL
>  |   NULL | NULL|NULL |
> | 139 | 1000 | 203 |  2 | NULL
>  |   NU

[jira] [Created] (CLOUDSTACK-6832) [OVS]vnet is not released even the network is deleted

2014-06-03 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6832:
-

 Summary: [OVS]vnet is not released even the network is deleted
 Key: CLOUDSTACK-6832
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6832
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0


[OVS]vnet is not released even the network is deleted

Steps to reproduce:
===
1.Bring up CS in advanced zone with xen cluster
2.Create physical network with GRE isolation and specify some VNIs as GRE keys 
for guest traffic
3.Create network offering with virtual networking and OVS as the service 
provider
4.Deploy few vms with the above network
5.Delete the network after expunging all the vms

Result:
=
Network deletion was successful but the vnet allocated for the network was not 
released.

VNI range specified for the guest traffic was 981-1000 and 992 was taken for 
the implemented network. But the vnet id 992 was not released back to the pool 
even after deleting the network.

mysql> select * from op_dc_vnet_alloc;
+-+--+-++--++-+-+
| id  | vnet | physical_network_id | data_center_id | reservation_id
   | account_id | taken   | account_vnet_map_id |
+-+--+-++--++-+-+
| 122 | 989  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 123 | 988  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 124 | 987  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 125 | 982  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 126 | 981  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 127 | 986  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 128 | 985  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 129 | 984  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 130 | 983  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 131 | 996  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 132 | 997  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 133 | 994  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 134 | 995  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 135 | 992  | 203 |  2 | 
8edad56a-a59d-4477-8741-9e91a8ef9052 |  2 | 2014-06-03 15:12:55 |   
 NULL |
| 136 | 993  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 137 | 990  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 138 | 991  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 139 | 1000 | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 140 | 998  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 141 | 999  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
+-+--+-++--

[jira] [Updated] (CLOUDSTACK-6828) [OVS] Tunnel ports are not getting deleted even failure in vm deployment

2014-06-03 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6828:
--

Attachment: ovstunnel-host14.log
ovstunnel-host13.log
management-server.rar

> [OVS] Tunnel ports are not getting deleted even failure in vm deployment
> 
>
> Key: CLOUDSTACK-6828
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6828
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: management-server.rar, ovstunnel-host13.log, 
> ovstunnel-host14.log
>
>
> [OVS] Tunnel ports are not getting deleted even failure in vm deployment
> Steps to Reproduce:
> 
> 1.Bringup CS in advanced zone with Xen cluster
> 2.Create physical network with GRE isolation
> 3.Create network offering with virtual networking and ovs as the connectivity 
> service provider.
> 4.Deploy vm with above offering and simulate vm failure
> (In my case I was trying with multiple physical networks scenario and because 
> of some configuration issues network implement failed so failure in vm 
> deployment)
> Result:
> =
> During vm deployment ovs bridge and tunnel ports were created between the two 
> hosts. But after the failure there was no clean up of the ovs-bridge and the 
> tunnel ports.
> Observations:
> ==
> xapi7 and xapi6 were the bridges created for the network.
> Following is the log snippet from ovstunnel log from both the hosts:
> [root@Rack1Pod1Host14 ~]# ovs-vsctl list-ports xapi7
> t10016-4-1
> [root@Rack1Pod1Host14 ~]# grep xapi7 /var/log/cloud/ovstunnel.log
> 2014-06-03 05:38:46DEBUG [root] About to manually create the bridge:xapi7
> 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', 
> '--may-exist', 'add-br', 'xapi7', '--', 'set', 'bridge', 'xapi7', 
> 'other_config:gre_key=OVSTunnel10016']
> 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
> 'Bridge', 'xapi7', 
> 'external_ids:xs-network-uuid=127de5bb-a423-2774-98b6-ce1827d261d7']
> 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
> 'Bridge', 'xapi7', 'stp_enable=true']
> 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
> 'bridge', 'xapi7', 'other_config:gre_key']
> 2014-06-03 05:38:46DEBUG [root] Executing:['/opt/xensource/bin/xe', 
> 'network-list', 'bridge=xapi7', '--minimal']
> 2014-06-03 05:38:46DEBUG [root] Setup_ovs_bridge completed with 
> result:SUCCESS:xapi7
> 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
> '--timeout=30', 'wait-until', 'bridge', 'xapi7', '--', 'get', 'bridge', 
> 'xapi7', 'name']
> 2014-06-03 05:38:50DEBUG [root] bridge xapi7 for creating tunnel - 
> VERIFIED
> 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
> 'add-port', 'xapi7', 't10016-4-1', '--', 'set', 'interface', 't10016-4-1', 
> 'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.13']
> 2014-06-03 05:38:50DEBUG [root] Executing:['/opt/xensource/bin/xe', 
> 'network-list', 'bridge=xapi7', '--minimal']
> 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 
> 'add-flow', 'xapi7', 
> 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,actions=drop']
> 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 
> 'add-flow', 'xapi7', 
> 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,ip,nw_dst=224.0.0.0/24,actions=drop']
> [root@Rack1Pod1Host13 ~]# ovs-vsctl list-ports xapi6
> t10016-1-4
> [root@Rack1Pod1Host13 ~]# grep xapi6 /var/log/cloud/ovstunnel.log
> 2014-06-03 05:38:56DEBUG [root] About to manually create the bridge:xapi6
> 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', 
> '--may-exist', 'add-br', 'xapi6', '--', 'set', 'bridge', 'xapi6', 
> 'other_config:gre_key=OVSTunnel10016']
> 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
> 'Bridge', 'xapi6', 
> 'external_ids:xs-network-uuid=ae6fe450-3399-7dad-b972-aa45755c2803']
> 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
> 'Bridge', 'xapi6', 'stp_enable=true']
> 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
> 'bridge', 'xapi6', 'other_config:gre_key']
> 2014-06-03 05:38:56DEBUG [root] Executing:['/opt/xensource/bin/xe', 
> 'network-list', 'bri

[jira] [Created] (CLOUDSTACK-6828) [OVS] Tunnel ports are not getting deleted even failure in vm deployment

2014-06-02 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6828:
-

 Summary: [OVS] Tunnel ports are not getting deleted even failure 
in vm deployment
 Key: CLOUDSTACK-6828
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6828
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0


[OVS] Tunnel ports are not getting deleted even failure in vm deployment

Steps to Reproduce:

1.Bringup CS in advanced zone with Xen cluster
2.Create physical network with GRE isolation
3.Create network offering with virtual networking and ovs as the connectivity 
service provider.
4.Deploy vm with above offering and simulate vm failure
(In my case I was trying with multiple physical networks scenario and because 
of some configuration issues network implement failed so failure in vm 
deployment)

Result:
=
During vm deployment ovs bridge and tunnel ports were created between the two 
hosts. But after the failure there was no clean up of the ovs-bridge and the 
tunnel ports.

Observations:
==
xapi7 and xapi6 were the bridges created for the network.

Following is the log snippet from ovstunnel log from both the hosts:
[root@Rack1Pod1Host14 ~]# ovs-vsctl list-ports xapi7
t10016-4-1
[root@Rack1Pod1Host14 ~]# grep xapi7 /var/log/cloud/ovstunnel.log
2014-06-03 05:38:46DEBUG [root] About to manually create the bridge:xapi7
2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', 
'--may-exist', 'add-br', 'xapi7', '--', 'set', 'bridge', 'xapi7', 
'other_config:gre_key=OVSTunnel10016']
2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
'Bridge', 'xapi7', 
'external_ids:xs-network-uuid=127de5bb-a423-2774-98b6-ce1827d261d7']
2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
'Bridge', 'xapi7', 'stp_enable=true']
2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
'bridge', 'xapi7', 'other_config:gre_key']
2014-06-03 05:38:46DEBUG [root] Executing:['/opt/xensource/bin/xe', 
'network-list', 'bridge=xapi7', '--minimal']
2014-06-03 05:38:46DEBUG [root] Setup_ovs_bridge completed with 
result:SUCCESS:xapi7
2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'--timeout=30', 'wait-until', 'bridge', 'xapi7', '--', 'get', 'bridge', 
'xapi7', 'name']
2014-06-03 05:38:50DEBUG [root] bridge xapi7 for creating tunnel - VERIFIED
2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'add-port', 'xapi7', 't10016-4-1', '--', 'set', 'interface', 't10016-4-1', 
'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.13']
2014-06-03 05:38:50DEBUG [root] Executing:['/opt/xensource/bin/xe', 
'network-list', 'bridge=xapi7', '--minimal']
2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 
'add-flow', 'xapi7', 
'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,actions=drop']
2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 
'add-flow', 'xapi7', 
'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,ip,nw_dst=224.0.0.0/24,actions=drop']

[root@Rack1Pod1Host13 ~]# ovs-vsctl list-ports xapi6
t10016-1-4
[root@Rack1Pod1Host13 ~]# grep xapi6 /var/log/cloud/ovstunnel.log
2014-06-03 05:38:56DEBUG [root] About to manually create the bridge:xapi6
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', 
'--may-exist', 'add-br', 'xapi6', '--', 'set', 'bridge', 'xapi6', 
'other_config:gre_key=OVSTunnel10016']
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
'Bridge', 'xapi6', 
'external_ids:xs-network-uuid=ae6fe450-3399-7dad-b972-aa45755c2803']
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
'Bridge', 'xapi6', 'stp_enable=true']
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
'bridge', 'xapi6', 'other_config:gre_key']
2014-06-03 05:38:56DEBUG [root] Executing:['/opt/xensource/bin/xe', 
'network-list', 'bridge=xapi6', '--minimal']
2014-06-03 05:38:56DEBUG [root] Setup_ovs_bridge completed with 
result:SUCCESS:xapi6
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'--timeout=30', 'wait-until', 'bridge', 'xapi6', '--', 'get', 'bridge', 
'xapi6', 'name']
2014-06-03 05:38:56DEBUG [root] bridge xapi6 for creating tunnel - VERIFIED
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'add-port', 'xapi6', 't10016-1-4', '--', 'set', 'interface', 't10016-1-4', 
'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.14']
2014-06

[jira] [Updated] (CLOUDSTACK-6827) Can't enable VR service provider in case of multiple physical networks

2014-06-02 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6827:
--

Attachment: management-server.rar

> Can't enable VR service provider in case of multiple physical networks
> --
>
> Key: CLOUDSTACK-6827
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6827
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
>Reporter: Sanjeev N
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.rar
>
>
> Can't enable VR service provider in case of multiple physical networks
> Steps to reproduce:
> ==
> 1.Bring up CS in advanced zone with xen cluster
> 2.Once the system is up disable the zone and add another physical network and 
> add only guest traffic into it.
> 3.Go to network service providers in the physical network 
> 4.All the providers are disabled by default. Try to enable Virtual Router
> http://10.147.59.119:8096/client/api?command=updateNetworkServiceProvider&id=beb30cda-7e3a-44e9-b179-c1c6fd605b47&state=Enabled
> Result:
> =
> Enabling VR service provider failed and observed following exception:
> 2014-06-03 06:13:54,846 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (ApiServer-8:ctx-8602d969 ctx-e30c2238) submit async job-82, details: 
> AsyncJobVO {id:82, userId: 1, accountId: 1, instanceType: 
> PhysicalNetworkServiceProvider, instanceId: null, cmd: 
> org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
>  cmdInfo: 
> {"id":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxDetails":"{\"PhysicalNetworkServiceProvider\":\"beb30cda-7e3a-44e9-b179-c1c6fd605b47\",\"com.cloud.network.PhysicalNetworkServiceProvider\":6}","cmdEventType":"SERVICE.PROVIDER.UPDATE","ctxUserId":"1","state":"Enabled","httpmethod":"GET","uuid":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxAccountId":"1","ctxStartEventId":"218"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-06-03 06:13:54,853 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-45:ctx-4f22f44a job-82) Add job-82 into job monitoring
> 2014-06-03 06:13:54,853 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-45:ctx-4f22f44a job-82) Executing AsyncJobVO {id:82, 
> userId: 1, accountId: 1, instanceType: PhysicalNetworkServiceProvider, 
> instanceId: null, cmd: 
> org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
>  cmdInfo: 
> {"id":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxDetails":"{\"PhysicalNetworkServiceProvider\":\"beb30cda-7e3a-44e9-b179-c1c6fd605b47\",\"com.cloud.network.PhysicalNetworkServiceProvider\":6}","cmdEventType":"SERVICE.PROVIDER.UPDATE","ctxUserId":"1","state":"Enabled","httpmethod":"GET","uuid":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxAccountId":"1","ctxStartEventId":"218"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-06-03 06:13:54,860 WARN  [c.c.a.d.ParamGenericValidationWorker] 
> (API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) Received unknown 
> parameters for command updateNetworkServiceProvider. Unknown parameters : 
> ctxdetails
> 2014-06-03 06:13:54,871 DEBUG [c.c.n.NetworkServiceImpl] 
> (API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) trying to update the 
> state of the service provider id=6 on physical network: 201 to state: Enabled
> 2014-06-03 06:13:54,878 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-2:ctx-e6a2a82e) HostStatsCollector is running...
> 2014-06-03 06:13:54,885 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-45:ctx-4f22f44a job-82) Unexpected exception while 
> executing 
> org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd
> com.cloud.utils.exception.CloudRuntimeException: Provider is not ready, 
> cannot Enable the provider, please configure the provider first
> at 
> com.cloud.network.NetworkServiceImpl.updateNetworkServiceProvider(NetworkServiceImpl.java:3425)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
>

[jira] [Created] (CLOUDSTACK-6827) Can't enable VR service provider in case of multiple physical networks

2014-06-02 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6827:
-

 Summary: Can't enable VR service provider in case of multiple 
physical networks
 Key: CLOUDSTACK-6827
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6827
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Priority: Critical
 Fix For: 4.4.0


Can't enable VR service provider in case of multiple physical networks

Steps to reproduce:
==
1.Bring up CS in advanced zone with xen cluster
2.Once the system is up disable the zone and add another physical network and 
add only guest traffic into it.
3.Go to network service providers in the physical network 
4.All the providers are disabled by default. Try to enable Virtual Router

http://10.147.59.119:8096/client/api?command=updateNetworkServiceProvider&id=beb30cda-7e3a-44e9-b179-c1c6fd605b47&state=Enabled

Result:
=
Enabling VR service provider failed and observed following exception:
2014-06-03 06:13:54,846 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(ApiServer-8:ctx-8602d969 ctx-e30c2238) submit async job-82, details: 
AsyncJobVO {id:82, userId: 1, accountId: 1, instanceType: 
PhysicalNetworkServiceProvider, instanceId: null, cmd: 
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
 cmdInfo: 
{"id":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxDetails":"{\"PhysicalNetworkServiceProvider\":\"beb30cda-7e3a-44e9-b179-c1c6fd605b47\",\"com.cloud.network.PhysicalNetworkServiceProvider\":6}","cmdEventType":"SERVICE.PROVIDER.UPDATE","ctxUserId":"1","state":"Enabled","httpmethod":"GET","uuid":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxAccountId":"1","ctxStartEventId":"218"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-06-03 06:13:54,853 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-45:ctx-4f22f44a job-82) Add job-82 into job monitoring
2014-06-03 06:13:54,853 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-45:ctx-4f22f44a job-82) Executing AsyncJobVO {id:82, userId: 
1, accountId: 1, instanceType: PhysicalNetworkServiceProvider, instanceId: 
null, cmd: 
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
 cmdInfo: 
{"id":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxDetails":"{\"PhysicalNetworkServiceProvider\":\"beb30cda-7e3a-44e9-b179-c1c6fd605b47\",\"com.cloud.network.PhysicalNetworkServiceProvider\":6}","cmdEventType":"SERVICE.PROVIDER.UPDATE","ctxUserId":"1","state":"Enabled","httpmethod":"GET","uuid":"beb30cda-7e3a-44e9-b179-c1c6fd605b47","ctxAccountId":"1","ctxStartEventId":"218"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-06-03 06:13:54,860 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) Received unknown 
parameters for command updateNetworkServiceProvider. Unknown parameters : 
ctxdetails
2014-06-03 06:13:54,871 DEBUG [c.c.n.NetworkServiceImpl] 
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) trying to update the 
state of the service provider id=6 on physical network: 201 to state: Enabled
2014-06-03 06:13:54,878 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-2:ctx-e6a2a82e) HostStatsCollector is running...
2014-06-03 06:13:54,885 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-45:ctx-4f22f44a job-82) Unexpected exception while executing 
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd
com.cloud.utils.exception.CloudRuntimeException: Provider is not ready, cannot 
Enable the provider, please configure the provider first
at 
com.cloud.network.NetworkServiceImpl.updateNetworkServiceProvider(NetworkServiceImpl.java:3425)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.apache.cloudstack.network.contrail.management.EventU

[jira] [Updated] (CLOUDSTACK-6819) [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host

2014-06-01 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6819:
--

Attachment: ovstunnel-host14.log
ovstunnel-host13.log
management-server.rar

> [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host 
> 
>
> Key: CLOUDSTACK-6819
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6819
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: management-server.rar, ovstunnel-host13.log, 
> ovstunnel-host14.log
>
>
> [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host 
> even though the network spanned more than one host
> Steps to reproduce:
> ===
> 1.Bring up CS in advanced zone with multiple clusters(2-3 clusters with 1 
> host in each cluster)
> 2.Create network offering with connectivity service and OVS as the service 
> provider
> 3.Add one guest account and deploy few vms with this new account
> 4.Use host tags to deploy vms in all the clusters to make sure that network 
> is spanned accross all the clusters
> 5.Delete the account
> Result:
> =
> Account deletion was successful and also ovs bridges were deleted from both 
> the hosts but the ovsTunnel porr(vif) for this network was unplugged only 
> from one host's dom0(the host to which OvsDestroyBridgeCommand was sent) but 
> not from the other host's dom0
> Observations:
> ===
> Following is the log snippet from MS log file during account deletion:
> Network was snapped across two hosts Rack1Pod1Host14 and Rack1Pod1Host13 but  
> OvsDestroyBridgeCommand was sent only to Rack1Pod1Host13
> 2014-06-02 07:11:19,838 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Work-Job-Executor-18:ctx-c73e49f0 job-56/job-57 ctx-e2515de4) Asking Ovs to 
> release NicProfile[26-16-2e06143e-28bd-4b43-ae0b-23a71bf0ed35-10.1.1.197-null
> 2014-06-02 07:11:19,839 DEBUG [c.c.n.e.OvsElement] 
> (Work-Job-Executor-18:ctx-c73e49f0 job-56/job-57 ctx-e2515de4) Checking if 
> OvsElement can handle service Connectivity on network acc2-cs-gre
> 2014-06-02 07:11:45,654 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Asking Ovs to 
> release NicProfile[30-18-273ebec1-867a-4081-8607-cb19af4c133d-10.1.1.52-null
> 2014-06-02 07:11:45,655 DEBUG [c.c.n.e.OvsElement] 
> (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Checking if 
> OvsElement can handle service Connectivity on network acc2-cs-gre
> 2014-06-02 07:11:45,665 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
> (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroying 
> bridge for network 207 on host:1
> 2014-06-02 07:11:45,670 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 
> 1-8504203471359062600: Sending  { Cmd , MgmtId: 7332683579487, via: 
> 1(Rack1Pod1Host13), Ver: v1, Flags: 100111, 
> [{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":207,"name":"OVSTunnel992","hostId":1,"wait":0}}]
>  }
> 2014-06-02 07:11:45,670 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 
> 1-8504203471359062600: Executing:  { Cmd , MgmtId: 7332683579487, via: 
> 1(Rack1Pod1Host13), Ver: v1, Flags: 100111, 
> [{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":207,"name":"OVSTunnel992","hostId":1,"wait":0}}]
>  }
> 2014-06-02 07:11:45,761 DEBUG [c.c.h.x.r.CitrixResourceBase] 
> (DirectAgent-148:ctx-0a89d399) Xen Server network for tunnels 
> found:OVSTunnel992
> 2014-06-02 07:11:45,807 DEBUG [c.c.h.x.r.CitrixResourceBase] 
> (DirectAgent-148:ctx-0a89d399) Destroy temp dom0 vifOVSTunnel992 success
> 2014-06-02 07:11:46,127 DEBUG [c.c.h.x.r.CitrixResourceBase] 
> (DirectAgent-148:ctx-0a89d399) OVS Bridge destroyed
> 2014-06-02 07:11:46,232 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
> (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroy bridge 
> fornetwork 207 successful
> 2014-06-02 07:11:46,234 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
> (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroying 
> tunnel to 1 from 4
> 2014-06-02 07:11:46,239 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 
> 4-8413287053881512061: Sending  { Cmd , MgmtId: 7332683579487, via: 
> 4(Rack1Pod1Host14), Ver: v1, Flags: 100111, 
> [{"com.cloud

[jira] [Created] (CLOUDSTACK-6819) [OVs] delete network/account sends OvsDestroyBridgeCommand to only one host

2014-06-01 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6819:
-

 Summary: [OVs] delete network/account sends 
OvsDestroyBridgeCommand to only one host 
 Key: CLOUDSTACK-6819
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6819
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0


[OVs] delete network/account sends OvsDestroyBridgeCommand to only one host 
even though the network spanned more than one host

Steps to reproduce:
===
1.Bring up CS in advanced zone with multiple clusters(2-3 clusters with 1 host 
in each cluster)
2.Create network offering with connectivity service and OVS as the service 
provider
3.Add one guest account and deploy few vms with this new account
4.Use host tags to deploy vms in all the clusters to make sure that network is 
spanned accross all the clusters
5.Delete the account

Result:
=
Account deletion was successful and also ovs bridges were deleted from both the 
hosts but the ovsTunnel porr(vif) for this network was unplugged only from one 
host's dom0(the host to which OvsDestroyBridgeCommand was sent) but not from 
the other host's dom0

Observations:
===
Following is the log snippet from MS log file during account deletion:

Network was snapped across two hosts Rack1Pod1Host14 and Rack1Pod1Host13 but  
OvsDestroyBridgeCommand was sent only to Rack1Pod1Host13

2014-06-02 07:11:19,838 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(Work-Job-Executor-18:ctx-c73e49f0 job-56/job-57 ctx-e2515de4) Asking Ovs to 
release NicProfile[26-16-2e06143e-28bd-4b43-ae0b-23a71bf0ed35-10.1.1.197-null
2014-06-02 07:11:19,839 DEBUG [c.c.n.e.OvsElement] 
(Work-Job-Executor-18:ctx-c73e49f0 job-56/job-57 ctx-e2515de4) Checking if 
OvsElement can handle service Connectivity on network acc2-cs-gre
2014-06-02 07:11:45,654 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Asking Ovs to 
release NicProfile[30-18-273ebec1-867a-4081-8607-cb19af4c133d-10.1.1.52-null
2014-06-02 07:11:45,655 DEBUG [c.c.n.e.OvsElement] 
(Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Checking if 
OvsElement can handle service Connectivity on network acc2-cs-gre
2014-06-02 07:11:45,665 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
(Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroying 
bridge for network 207 on host:1
2014-06-02 07:11:45,670 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 
1-8504203471359062600: Sending  { Cmd , MgmtId: 7332683579487, via: 
1(Rack1Pod1Host13), Ver: v1, Flags: 100111, 
[{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":207,"name":"OVSTunnel992","hostId":1,"wait":0}}]
 }
2014-06-02 07:11:45,670 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 
1-8504203471359062600: Executing:  { Cmd , MgmtId: 7332683579487, via: 
1(Rack1Pod1Host13), Ver: v1, Flags: 100111, 
[{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":207,"name":"OVSTunnel992","hostId":1,"wait":0}}]
 }
2014-06-02 07:11:45,761 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-148:ctx-0a89d399) Xen Server network for tunnels found:OVSTunnel992
2014-06-02 07:11:45,807 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-148:ctx-0a89d399) Destroy temp dom0 vifOVSTunnel992 success
2014-06-02 07:11:46,127 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-148:ctx-0a89d399) OVS Bridge destroyed
2014-06-02 07:11:46,232 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
(Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroy bridge 
fornetwork 207 successful
2014-06-02 07:11:46,234 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
(Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Destroying 
tunnel to 1 from 4
2014-06-02 07:11:46,239 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 
4-8413287053881512061: Sending  { Cmd , MgmtId: 7332683579487, via: 
4(Rack1Pod1Host14), Ver: v1, Flags: 100111, 
[{"com.cloud.agent.api.OvsDestroyTunnelCommand":{"networkId":207,"networkName":"OVSTunnel992","inPortName":"t992-4-1","wait":0}}]
 }
2014-06-02 07:11:46,239 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-19:ctx-39832471 job-56/job-58 ctx-67dba604) Seq 
4-8413287053881512061: Executing:  { Cmd , MgmtId: 7332683579487, via: 
4(Rack1Pod1Host14), Ver: v1, Flags: 100111, 
[{"com.cloud.agent.api.OvsDestroyTunnelCommand":{"networkId":207,"networkName":"OVSTunnel992","inPortName":"t992-4-1","wait":0}}]
 }
2014-06-02 07:11:46,324 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-296:ctx-5132

[jira] [Updated] (CLOUDSTACK-6813) vhd-util is not available on xen servers after adding them to CS

2014-05-30 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6813:
--

Attachment: management-server.rar

> vhd-util is not available on xen servers after adding them to CS
> 
>
> Key: CLOUDSTACK-6813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6813
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, XenServer
>Affects Versions: 4.4.0
> Environment: Any build from 4.4 branch
> Hypervisor: Xenserver
>Reporter: Sanjeev N
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.rar
>
>
> vhd-util is not available on xen servers after adding them to CS.
> 1.Fresh install Xenserver with 6.2
> 2.Fresh install MS with build from 4.4 branch
> 3.Create a zone 
> When host is added to CS , as part of host addition CS pushes scripts to 
> Xenserver. However it is not copying vhd-util.
> So all the volume creations would fail.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (CLOUDSTACK-6813) vhd-util is not available on xen servers after adding them to CS

2014-05-30 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6813:
-

 Summary: vhd-util is not available on xen servers after adding 
them to CS
 Key: CLOUDSTACK-6813
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6813
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, XenServer
Affects Versions: 4.4.0
 Environment: Any build from 4.4 branch
Hypervisor: Xenserver
Reporter: Sanjeev N
Priority: Critical
 Fix For: 4.4.0


vhd-util is not available on xen servers after adding them to CS.

1.Fresh install Xenserver with 6.2
2.Fresh install MS with build from 4.4 branch
3.Create a zone 
When host is added to CS , as part of host addition CS pushes scripts to 
Xenserver. However it is not copying vhd-util.
So all the volume creations would fail.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CLOUDSTACK-6798) [OVS] Network update from OVS to vlan does not implement the network properly

2014-05-28 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6798:
--

Attachment: management-server.rar

Attached MS log file.

> [OVS] Network update from OVS to vlan does not implement the network properly
> -
>
> Key: CLOUDSTACK-6798
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6798
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> d130530bd3e1cd6d8249d5045e00e4e4e2201521
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: management-server.rar
>
>
> [OVS] Network update from OVS to vlan does not implement the network properly
> Steps to Reproduce:
> ==
> 1.Bring up CS in advanced zone with Xen cluster
> 2.Create physical network with GRE isolation
> 3.Create network offering with virtualnetworking and OVS as the connectivity 
> service provider
> 4.Create one guest network with above offering
> 5.Deploy few vms in the above network 
> 6.Stop all the vms and update network  to default isolated network offering 
> "Offering for Isolated networks with Source Nat service" 
> 7.Deploy one vm in the network after network update
> Result:
> ==
> 1.Network update was successful but the network is not implemented propertly. 
> Network did not get any vlan ID. Broadcast uri for the network still remains 
> as vs://985 instead of vlan://985.
> 2.So the guest vms would not get any ip addresses.
> 3.Network is of no use. On Xenserver cluster CS is not creating network with 
> VLAN 985. Deploying new vms or starting the existing vms are plugging vifs to 
> the existing tunnel bridge but tunnel ports not not getting created between 
> the hosts since the offering does not have the OVS provider.
> Following are the network details from db after network update:
> mysql> select * from networks where id=207\G;
> *** 1. row ***
>id: 207
>  name: Admin-ovs
>  uuid: c545e326-218d-49ba-8fb8-4dabd9ab612f
>  display_text: Admin-ovs
>  traffic_type: Guest
> broadcast_domain_type: Vswitch
> broadcast_uri: vs://985
>   gateway: 10.1.1.1
>  cidr: 10.1.1.0/24
>  mode: Dhcp
>   network_offering_id: 8
>   physical_network_id: 200
>data_center_id: 1
> guru_name: OvsGuestNetworkGuru
> state: Implemented
>   related: 207
> domain_id: 1
>account_id: 2
>  dns1: NULL
>  dns2: NULL
> guru_data: NULL
>set_fields: 0
>  acl_type: Account
>network_domain: cs2cloud.internal
>reservation_id: 8b9fa583-35a7-4b43-a023-08efc44b88ee
>guest_type: Isolated
>  restart_required: 0
>   created: 2014-05-27 09:42:15
>   removed: NULL
> specify_ip_ranges: 0
>vpc_id: NULL
>   ip6_gateway: NULL
>  ip6_cidr: NULL
>  network_cidr: NULL
>   display_network: 1
>network_acl_id: NULL
>   streched_l2: 0
> 1 row in set (0.00 sec)
> mysql> select * from network_offerings where id=8\G;
> *** 1. row ***
>id: 8
>  name: DefaultIsolatedNetworkOfferingWithSourceNatService
>  uuid: d82a97f9-366a-491b-9f18-ef96aac732bc
>   unique_name: DefaultIsolatedNetworkOfferingWithSourceNatService
>  display_text: Offering for Isolated networks with Source Nat 
> service enabled
>   nw_rate: NULL
>   mc_rate: NULL
>  traffic_type: Guest
>  tags: NULL
>   system_only: 0
>  specify_vlan: 0
>   service_offering_id: NULL
> conserve_mode: 1
>   created: 2014-05-26 11:21:39
>   removed: NULL
>   default: 1
>  availability: Required
>  dedicated_lb_service: 1
> shared_source_nat_service: 0
>  sort_key: 0
>  redundant_router_service: 0
> state: Enabled
>guest_type: Isolated
>elastic_ip_service: 0
>   eip_associate_public_ip: 1
>elastic_lb_service: 0
> specify_ip_ranges: 0
>inline: 0
> is_persistent: 0
>   internal_lb: 0

[jira] [Created] (CLOUDSTACK-6798) [OVS] Network update from OVS to vlan does not implement the network properly

2014-05-28 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6798:
-

 Summary: [OVS] Network update from OVS to vlan does not implement 
the network properly
 Key: CLOUDSTACK-6798
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6798
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
d130530bd3e1cd6d8249d5045e00e4e4e2201521
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0


[OVS] Network update from OVS to vlan does not implement the network properly

Steps to Reproduce:
==
1.Bring up CS in advanced zone with Xen cluster
2.Create physical network with GRE isolation
3.Create network offering with virtualnetworking and OVS as the connectivity 
service provider
4.Create one guest network with above offering
5.Deploy few vms in the above network 
6.Stop all the vms and update network  to default isolated network offering 
"Offering for Isolated networks with Source Nat service" 
7.Deploy one vm in the network after network update

Result:
==
1.Network update was successful but the network is not implemented propertly. 
Network did not get any vlan ID. Broadcast uri for the network still remains as 
vs://985 instead of vlan://985.
2.So the guest vms would not get any ip addresses.
3.Network is of no use. On Xenserver cluster CS is not creating network with 
VLAN 985. Deploying new vms or starting the existing vms are plugging vifs to 
the existing tunnel bridge but tunnel ports not not getting created between the 
hosts since the offering does not have the OVS provider.

Following are the network details from db after network update:

mysql> select * from networks where id=207\G;
*** 1. row ***
   id: 207
 name: Admin-ovs
 uuid: c545e326-218d-49ba-8fb8-4dabd9ab612f
 display_text: Admin-ovs
 traffic_type: Guest
broadcast_domain_type: Vswitch
broadcast_uri: vs://985
  gateway: 10.1.1.1
 cidr: 10.1.1.0/24
 mode: Dhcp
  network_offering_id: 8
  physical_network_id: 200
   data_center_id: 1
guru_name: OvsGuestNetworkGuru
state: Implemented
  related: 207
domain_id: 1
   account_id: 2
 dns1: NULL
 dns2: NULL
guru_data: NULL
   set_fields: 0
 acl_type: Account
   network_domain: cs2cloud.internal
   reservation_id: 8b9fa583-35a7-4b43-a023-08efc44b88ee
   guest_type: Isolated
 restart_required: 0
  created: 2014-05-27 09:42:15
  removed: NULL
specify_ip_ranges: 0
   vpc_id: NULL
  ip6_gateway: NULL
 ip6_cidr: NULL
 network_cidr: NULL
  display_network: 1
   network_acl_id: NULL
  streched_l2: 0
1 row in set (0.00 sec)
mysql> select * from network_offerings where id=8\G;
*** 1. row ***
   id: 8
 name: DefaultIsolatedNetworkOfferingWithSourceNatService
 uuid: d82a97f9-366a-491b-9f18-ef96aac732bc
  unique_name: DefaultIsolatedNetworkOfferingWithSourceNatService
 display_text: Offering for Isolated networks with Source Nat 
service enabled
  nw_rate: NULL
  mc_rate: NULL
 traffic_type: Guest
 tags: NULL
  system_only: 0
 specify_vlan: 0
  service_offering_id: NULL
conserve_mode: 1
  created: 2014-05-26 11:21:39
  removed: NULL
  default: 1
 availability: Required
 dedicated_lb_service: 1
shared_source_nat_service: 0
 sort_key: 0
 redundant_router_service: 0
state: Enabled
   guest_type: Isolated
   elastic_ip_service: 0
  eip_associate_public_ip: 1
   elastic_lb_service: 0
specify_ip_ranges: 0
   inline: 0
is_persistent: 0
  internal_lb: 0
public_lb: 1
egress_default_policy: 0
   concurrent_connections: NULL
   keep_alive_enabled: 0
 supports_streched_l2: 0
1 row in set (0.00 sec)


Please look for job-133 in the attached MS log file for the sequence of events 
happened during update network.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (CLOUDSTACK-6796) [OVS]Failure in network update does not change network offering to original offering

2014-05-28 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6796:
--

Attachment: management-server.rar

Attached MS log file

> [OVS]Failure in network update does not change network offering to original 
> offering
> 
>
> Key: CLOUDSTACK-6796
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6796
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> d130530bd3e1cd6d8249d5045e00e4e4e2201521
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: management-server.rar
>
>
> [OVS]Failure in network update does not change network offering to original 
> offering hence starting vms would fail in the network
> Steps to Reproduce:
> ===
> 1.Bring up CS in advanced zone with xen cluster
> 2.Create physical network with GRE isolation
> 3.Create network with default offering 
> "DefaultIsolatedNetworkOfferingWithSourceNatService"
> 4.Deploy few vms in the above netwrok
> 5.Create another network offering with virtual networking service and OVS as 
> the connectivity service provider
> 6.Stop all the vms in the network
> 7.Update network with new offering created at step5
> Results:
> ==
> Network update will fail from vlan isolation to connectivity service due to 
> bug CS-6795. However the network offering id for the network is changing to 
> new network offering. It is not setting back to default isolated network 
> offering.
> mysql> select * from ntwk_offering_service_map where network_offering_id=15;
> ++-++---+-+
> | id | network_offering_id | service| provider  | created 
> |
> ++-++---+-+
> | 60 |  15 | Connectivity   | Ovs   | 2014-05-26 
> 12:51:34 |
> | 55 |  15 | Dhcp   | VirtualRouter | 2014-05-26 
> 12:51:34 |
> | 54 |  15 | Dns| VirtualRouter | 2014-05-26 
> 12:51:34 |
> | 61 |  15 | Firewall   | VirtualRouter | 2014-05-26 
> 12:51:34 |
> | 58 |  15 | Lb | VirtualRouter | 2014-05-26 
> 12:51:34 |
> | 57 |  15 | PortForwarding | VirtualRouter | 2014-05-26 
> 12:51:34 |
> | 56 |  15 | SourceNat  | VirtualRouter | 2014-05-26 
> 12:51:34 |
> | 59 |  15 | StaticNat  | VirtualRouter | 2014-05-26 
> 12:51:34 |
> | 53 |  15 | UserData   | VirtualRouter | 2014-05-26 
> 12:51:34 |
> ++-++---+-+
> 9 rows in set (0.00 sec)
> Following is the network created with default isolated network offering but 
> after network update failure the offering still shows the new offering:
> mysql> select * from networks where id=211\G;
> *** 1. row ***
>id: 211
>  name: vlan1
>  uuid: f803e17f-b59b-4229-9e70-5bb4fcfc2570
>  display_text: vlan1
>  traffic_type: Guest
> broadcast_domain_type: Vlan
> broadcast_uri: vlan://986
>   gateway: 10.1.1.1
>  cidr: 10.1.1.0/24
>  mode: Dhcp
>   network_offering_id: 15
>   physical_network_id: 200
>data_center_id: 1
> guru_name: ExternalGuestNetworkGuru
> state: Shutdown
>   related: 211
> domain_id: 1
>account_id: 2
>  dns1: NULL
>  dns2: NULL
> guru_data: NULL
>set_fields: 0
>  acl_type: Account
>network_domain: cs2cloud.internal
>reservation_id: c2b3cb64-adfd-4722-9aed-8d2d7710e32f
>guest_type: Isolated
>  restart_required: 0
>   created: 2014-05-28 11:09:16
>   removed: NULL
> specify_ip_ranges: 0
>vpc_id: NULL
>   ip6_gateway: NULL
>  ip6_cidr: NULL
>  network_cidr: NULL
>   display_network: 1
>network_acl_id: NULL
>   streched_l2: 0
> 1 row in set (0.00 sec)
> ERROR:
> No query specified
> Impact of this:
> ===
> Since the network offering is with connectivity service , CS is failed to 
> implement the network and vm start is failing.
> 2014-05-28 07:52:28,188 DEBUG [c.c.n.e.OvsElement] 
>

[jira] [Created] (CLOUDSTACK-6796) [OVS]Failure in network update does not change network offering to original offering

2014-05-28 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6796:
-

 Summary: [OVS]Failure in network update does not change network 
offering to original offering
 Key: CLOUDSTACK-6796
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6796
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
d130530bd3e1cd6d8249d5045e00e4e4e2201521
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0
 Attachments: management-server.rar

[OVS]Failure in network update does not change network offering to original 
offering hence starting vms would fail in the network

Steps to Reproduce:
===
1.Bring up CS in advanced zone with xen cluster
2.Create physical network with GRE isolation
3.Create network with default offering 
"DefaultIsolatedNetworkOfferingWithSourceNatService"
4.Deploy few vms in the above netwrok
5.Create another network offering with virtual networking service and OVS as 
the connectivity service provider
6.Stop all the vms in the network
7.Update network with new offering created at step5

Results:
==
Network update will fail from vlan isolation to connectivity service due to bug 
CS-6795. However the network offering id for the network is changing to new 
network offering. It is not setting back to default isolated network offering.

mysql> select * from ntwk_offering_service_map where network_offering_id=15;
++-++---+-+
| id | network_offering_id | service| provider  | created   
  |
++-++---+-+
| 60 |  15 | Connectivity   | Ovs   | 2014-05-26 
12:51:34 |
| 55 |  15 | Dhcp   | VirtualRouter | 2014-05-26 
12:51:34 |
| 54 |  15 | Dns| VirtualRouter | 2014-05-26 
12:51:34 |
| 61 |  15 | Firewall   | VirtualRouter | 2014-05-26 
12:51:34 |
| 58 |  15 | Lb | VirtualRouter | 2014-05-26 
12:51:34 |
| 57 |  15 | PortForwarding | VirtualRouter | 2014-05-26 
12:51:34 |
| 56 |  15 | SourceNat  | VirtualRouter | 2014-05-26 
12:51:34 |
| 59 |  15 | StaticNat  | VirtualRouter | 2014-05-26 
12:51:34 |
| 53 |  15 | UserData   | VirtualRouter | 2014-05-26 
12:51:34 |
++-++---+-+
9 rows in set (0.00 sec)

Following is the network created with default isolated network offering but 
after network update failure the offering still shows the new offering:

mysql> select * from networks where id=211\G;
*** 1. row ***
   id: 211
 name: vlan1
 uuid: f803e17f-b59b-4229-9e70-5bb4fcfc2570
 display_text: vlan1
 traffic_type: Guest
broadcast_domain_type: Vlan
broadcast_uri: vlan://986
  gateway: 10.1.1.1
 cidr: 10.1.1.0/24
 mode: Dhcp
  network_offering_id: 15
  physical_network_id: 200
   data_center_id: 1
guru_name: ExternalGuestNetworkGuru
state: Shutdown
  related: 211
domain_id: 1
   account_id: 2
 dns1: NULL
 dns2: NULL
guru_data: NULL
   set_fields: 0
 acl_type: Account
   network_domain: cs2cloud.internal
   reservation_id: c2b3cb64-adfd-4722-9aed-8d2d7710e32f
   guest_type: Isolated
 restart_required: 0
  created: 2014-05-28 11:09:16
  removed: NULL
specify_ip_ranges: 0
   vpc_id: NULL
  ip6_gateway: NULL
 ip6_cidr: NULL
 network_cidr: NULL
  display_network: 1
   network_acl_id: NULL
  streched_l2: 0
1 row in set (0.00 sec)

ERROR:
No query specified


Impact of this:
===
Since the network offering is with connectivity service , CS is failed to 
implement the network and vm start is failing.

2014-05-28 07:52:28,188 DEBUG [c.c.n.e.OvsElement] 
(Work-Job-Executor-47:ctx-3e2b5a9e job-122/job-123 ctx-ccbcca96) Checking if 
OvsElement can handle service SourceNat on network vlan1
2014-05-28 07:52:28,189 DEBUG [c.c.n.e.OvsElement] 
(Work-Job-Executor-47:ctx-3e2b5a9e job-122/job-123 ctx-ccbcca96) Virtual router 
element doesn't need to associate ip addresses on the backend; virtual router 
doesn't exist in the network 211
2014-05-28 07:52:28,193 DEBUG [c.c.n.e.VirtualRouterElement] 
(Work-Job-Executor-47:ctx-3e2b5a9e job-122/job-12

[jira] [Created] (CLOUDSTACK-6795) [OVS]Faile to upgrade network from vlan isolation to network with ovs provider

2014-05-27 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6795:
-

 Summary: [OVS]Faile to upgrade network from vlan isolation to 
network with ovs provider
 Key: CLOUDSTACK-6795
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6795
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
d130530bd3e1cd6d8249d5045e00e4e4e2201521
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0
 Attachments: management-server.rar

[OVS]Faile to upgrade network from vlan isolation to network with ovs provider

Steps to reproduce:
==
1.Bring up CS in advanced zone with xen cluster
2.Create physical network with GRE isolation
3.Create an isolated network offering with default offering 
"DefaultIsolatedNetworkOfferingWithSourceNatService" 
4.Deploy one vm using above network offering
5.Create another guest network with Virtual networking and OVS as the 
connectivity service provider
6.Stop the vm and upgrade network with above network offering

Result:
=
Failed to upgrade network with the offering which has connectivity service and 
ovs as the provider

Observations:
==
Following is the log snippet from MS log:
2014-05-28 07:27:28,419 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Seq 
4-1333065489701674831: Received:  { Ans: , MgmtId: 7332683579487, via: 4, Ver: 
v1, Flags: 10, { Answer } }
2014-05-28 07:27:28,429 INFO  [o.a.c.s.v.VolumeServiceImpl] 
(API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Volume 26 is not 
referred anywhere, remove it from volumes table
2014-05-28 07:27:28,435 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Expunged 
VM[DomainRouter|r-26-VM]
2014-05-28 07:27:28,458 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
(consoleproxy-1:ctx-b2ec9be1) Zone 1 is ready to launch console proxy
2014-05-28 07:27:28,480 DEBUG [c.c.n.NetworkServiceImpl] 
(API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Implementing the 
network Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] elements and 
resources as a part of network update
2014-05-28 07:27:28,486 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Asking Ovs to 
implemenet Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15]
2014-05-28 07:27:28,486 DEBUG [c.c.n.e.OvsElement] 
(API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) entering OvsElement 
implement function for network vlan1 (state Implemented)
2014-05-28 07:27:28,486 DEBUG [c.c.n.e.OvsElement] 
(API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Checking if OvsElement 
can handle service Connectivity on network vlan1
2014-05-28 07:27:28,487 WARN  [c.c.n.NetworkServiceImpl] 
(API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Failed to implement 
network Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] elements and 
resources as a part of network update due to
com.cloud.utils.exception.CloudRuntimeException: Failed to implement provider 
Ovs for network with specified id
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1081)
at 
com.cloud.network.NetworkServiceImpl.updateGuestNetwork(NetworkServiceImpl.java:2303)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy

[jira] [Updated] (CLOUDSTACK-6795) [OVS]Faile to upgrade network from vlan isolation to network with ovs provider

2014-05-27 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6795:
--

Attachment: management-server.rar

Attached MS log file

> [OVS]Faile to upgrade network from vlan isolation to network with ovs provider
> --
>
> Key: CLOUDSTACK-6795
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6795
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> d130530bd3e1cd6d8249d5045e00e4e4e2201521
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: management-server.rar
>
>
> [OVS]Faile to upgrade network from vlan isolation to network with ovs provider
> Steps to reproduce:
> ==
> 1.Bring up CS in advanced zone with xen cluster
> 2.Create physical network with GRE isolation
> 3.Create an isolated network offering with default offering 
> "DefaultIsolatedNetworkOfferingWithSourceNatService" 
> 4.Deploy one vm using above network offering
> 5.Create another guest network with Virtual networking and OVS as the 
> connectivity service provider
> 6.Stop the vm and upgrade network with above network offering
> Result:
> =
> Failed to upgrade network with the offering which has connectivity service 
> and ovs as the provider
> Observations:
> ==
> Following is the log snippet from MS log:
> 2014-05-28 07:27:28,419 DEBUG [c.c.a.t.Request] 
> (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Seq 
> 4-1333065489701674831: Received:  { Ans: , MgmtId: 7332683579487, via: 4, 
> Ver: v1, Flags: 10, { Answer } }
> 2014-05-28 07:27:28,429 INFO  [o.a.c.s.v.VolumeServiceImpl] 
> (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Volume 26 is not 
> referred anywhere, remove it from volumes table
> 2014-05-28 07:27:28,435 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Expunged 
> VM[DomainRouter|r-26-VM]
> 2014-05-28 07:27:28,458 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-b2ec9be1) Zone 1 is ready to launch console proxy
> 2014-05-28 07:27:28,480 DEBUG [c.c.n.NetworkServiceImpl] 
> (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Implementing the 
> network Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] elements and 
> resources as a part of network update
> 2014-05-28 07:27:28,486 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Asking Ovs to 
> implemenet Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15]
> 2014-05-28 07:27:28,486 DEBUG [c.c.n.e.OvsElement] 
> (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) entering OvsElement 
> implement function for network vlan1 (state Implemented)
> 2014-05-28 07:27:28,486 DEBUG [c.c.n.e.OvsElement] 
> (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Checking if 
> OvsElement can handle service Connectivity on network vlan1
> 2014-05-28 07:27:28,487 WARN  [c.c.n.NetworkServiceImpl] 
> (API-Job-Executor-62:ctx-3460d0b7 job-119 ctx-672875b5) Failed to implement 
> network Ntwk[f803e17f-b59b-4229-9e70-5bb4fcfc2570|Guest|15] elements and 
> resources as a part of network update due to
> com.cloud.utils.exception.CloudRuntimeException: Failed to implement provider 
> Ovs for network with specified id
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1081)
> at 
> com.cloud.network.NetworkServiceImpl.updateGuestNetwork(NetworkServiceImpl.java:2303)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEven

[jira] [Updated] (CLOUDSTACK-6779) [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table

2014-05-27 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6779:
--

Attachment: ovstunnel.log_host14
ovstunnel.log_host13
management-server.rar

Attached log files from MS, ovstunnel files from both the hosts inside the 
cluster.

> [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
> table
> --
>
> Key: CLOUDSTACK-6779
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6779
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> d130530bd3e1cd6d8249d5045e00e4e4e2201521
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Blocker
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: management-server.rar, ovstunnel.log_host13, 
> ovstunnel.log_host14
>
>
> [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
> table
> Steps to reproduce:
> 
> 1.Bring up CS in advanced zone with min of 2 xen hosts in a cluster
> 2.Add physical network with GRE isolation
> 3.Create network offering with connectivity service and OVS as the provider
> 4.Create an isolated network with above offering and deploy few vms (4-5) in 
> that network and make sure that vms are spanned across both the hosts
> 5.After this verify flow table rules on the ovs bridge
> 6.Expunge one of the vms created at step4
> 7.Again verify flow table rules on the host from where vm was deleted
> Result:
> =
> All the flow table rules were deleted from the OVS bridge. Only default flow 
> rule is present.
> Attaching management server log file and ovstunnel log files from both the 
> hosts. 
> Please look for xapi5 and xapi7 in ovstunnel log files.
> Flow table rules before destroy the vm:
> [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=374.111s, table=0, n_packets=4, n_bytes=768, 
> priority=1100,dl_dst=ff:ff:ff:ff:ff:ff 
> actions=output:1,output:2,output:3,output:4,output:5
>  cookie=0x0, duration=300.162s, table=0, n_packets=0, n_bytes=0, 
> priority=1000,ip,in_port=6,nw_dst=224.0.0.0/24 actions=drop
>  cookie=0x0, duration=374.122s, table=0, n_packets=0, n_bytes=0, 
> priority=1200,ip,in_port=5,nw_dst=224.0.0.0/24 actions=NORMAL
>  cookie=0x0, duration=5350.811s, table=0, n_packets=0, n_bytes=0, 
> priority=1200,ip,in_port=4,nw_dst=224.0.0.0/24 actions=NORMAL
>  cookie=0x0, duration=6016.913s, table=0, n_packets=0, n_bytes=0, 
> priority=1200,ip,in_port=3,nw_dst=224.0.0.0/24 actions=NORMAL
>  cookie=0x0, duration=6753.464s, table=0, n_packets=0, n_bytes=0, 
> priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
>  cookie=0x0, duration=6890.423s, table=0, n_packets=7594, n_bytes=6858309, 
> priority=0 actions=NORMAL
>  cookie=0x0, duration=374.1s, table=0, n_packets=0, n_bytes=0, 
> priority=1100,ip,nw_dst=224.0.0.0/24 
> actions=output:1,output:2,output:3,output:4,output:5
>  cookie=0x0, duration=374.132s, table=0, n_packets=5, n_bytes=810, 
> priority=1200,in_port=5,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
>  cookie=0x0, duration=5350.823s, table=0, n_packets=8, n_bytes=1236, 
> priority=1200,in_port=4,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
>  cookie=0x0, duration=300.173s, table=0, n_packets=0, n_bytes=0, 
> priority=1000,in_port=6,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
>  cookie=0x0, duration=6016.924s, table=0, n_packets=8, n_bytes=1236, 
> priority=1200,in_port=3,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
>  cookie=0x0, duration=6753.474s, table=0, n_packets=6, n_bytes=852, 
> priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
> After destroying the vm:
> [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=877.901s, table=0, n_packets=46, n_bytes=9748, 
> priority=0 actions=NORMAL
> [root@Rack1Pod1Host13 ~]#



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (CLOUDSTACK-6779) [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table

2014-05-27 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6779:
-

 Summary: [OVS] Expunging VM (deleting vif) deletes all the rules 
from ovs bridge flow table
 Key: CLOUDSTACK-6779
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6779
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
d130530bd3e1cd6d8249d5045e00e4e4e2201521
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Blocker
 Fix For: 4.4.0


[OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
table

Steps to reproduce:

1.Bring up CS in advanced zone with min of 2 xen hosts in a cluster
2.Add physical network with GRE isolation
3.Create network offering with connectivity service and OVS as the provider
4.Create an isolated network with above offering and deploy few vms (4-5) in 
that network and make sure that vms are spanned across both the hosts
5.After this verify flow table rules on the ovs bridge
6.Expunge one of the vms created at step4
7.Again verify flow table rules on the host from where vm was deleted

Result:
=
All the flow table rules were deleted from the OVS bridge. Only default flow 
rule is present.

Attaching management server log file and ovstunnel log files from both the 
hosts. 
Please look for xapi5 and xapi7 in ovstunnel log files.

Flow table rules before destroy the vm:
[root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=374.111s, table=0, n_packets=4, n_bytes=768, 
priority=1100,dl_dst=ff:ff:ff:ff:ff:ff 
actions=output:1,output:2,output:3,output:4,output:5
 cookie=0x0, duration=300.162s, table=0, n_packets=0, n_bytes=0, 
priority=1000,ip,in_port=6,nw_dst=224.0.0.0/24 actions=drop
 cookie=0x0, duration=374.122s, table=0, n_packets=0, n_bytes=0, 
priority=1200,ip,in_port=5,nw_dst=224.0.0.0/24 actions=NORMAL
 cookie=0x0, duration=5350.811s, table=0, n_packets=0, n_bytes=0, 
priority=1200,ip,in_port=4,nw_dst=224.0.0.0/24 actions=NORMAL
 cookie=0x0, duration=6016.913s, table=0, n_packets=0, n_bytes=0, 
priority=1200,ip,in_port=3,nw_dst=224.0.0.0/24 actions=NORMAL
 cookie=0x0, duration=6753.464s, table=0, n_packets=0, n_bytes=0, 
priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
 cookie=0x0, duration=6890.423s, table=0, n_packets=7594, n_bytes=6858309, 
priority=0 actions=NORMAL
 cookie=0x0, duration=374.1s, table=0, n_packets=0, n_bytes=0, 
priority=1100,ip,nw_dst=224.0.0.0/24 
actions=output:1,output:2,output:3,output:4,output:5
 cookie=0x0, duration=374.132s, table=0, n_packets=5, n_bytes=810, 
priority=1200,in_port=5,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 cookie=0x0, duration=5350.823s, table=0, n_packets=8, n_bytes=1236, 
priority=1200,in_port=4,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 cookie=0x0, duration=300.173s, table=0, n_packets=0, n_bytes=0, 
priority=1000,in_port=6,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
 cookie=0x0, duration=6016.924s, table=0, n_packets=8, n_bytes=1236, 
priority=1200,in_port=3,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 cookie=0x0, duration=6753.474s, table=0, n_packets=6, n_bytes=852, 
priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL

After destroying the vm:
[root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=877.901s, table=0, n_packets=46, n_bytes=9748, priority=0 
actions=NORMAL
[root@Rack1Pod1Host13 ~]#




--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (CLOUDSTACK-6763) [OVS] Deleting one ovs bridge deletes flow table entries for other bridge as well

2014-05-26 Thread Sanjeev N (JIRA)
Sanjeev N created CLOUDSTACK-6763:
-

 Summary: [OVS] Deleting one ovs bridge deletes flow table entries 
for other bridge as well
 Key: CLOUDSTACK-6763
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6763
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller, XenServer
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
d130530bd3e1cd6d8249d5045e00e4e4e2201521
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0


[OVS] Deleting one ovs bridge deletes flow table entries for other bridge as 
well

Steps to Reproduce:
=
1.Bring up CS in advanced zone with two hosts in a xen cluster
2.Create physical network with GRE isolation
3.Create network offering with connectivity service and OVS as the provider
4.Create a user account and deploy few vms with above network offering (make 
sure vms are spanned across the hosts)
5.Create another user account and repeat step4
6.Destroy all vms in account2
7.Verify flow table rules for the ovs bridge created for account1 network

Result:
===
After deleting account2 vms ovs bridge for this network was destroyed from both 
the hosts and also the flow table rules for account1 network were also deleted 
from both the hosts

Observations:
===
xapi3 is the bridge created for account2 network and xapi2 is for account1 
network.

xapi3 is for network: OVSTunnel983
xapi2 is for network: OVSTunnel984

Following is the log snippet from MS log file for deleting OVS Bridge:

2014-05-26 12:08:59,334 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Asking Ovs to 
release NicProfile[15-8-038ca005-deeb-4146-addf-5f8f96436e68-10.1.1.11-null
2014-05-26 12:08:59,335 DEBUG [c.c.n.e.OvsElement] 
(Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Checking if 
OvsElement can handle service Connectivity on network test2-ovs
2014-05-26 12:08:59,344 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
(Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Destroying 
bridge for network 206 on host:1
2014-05-26 12:08:59,350 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Seq 
1-8670555182595048072: Sending  { Cmd , MgmtId: 7332683579487, via: 
1(Rack1Pod1Host13), Ver: v1, Flags: 100111, 
[{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":206,"name":"OVSTunnel983","hostId":1,"wait":0}}]
 }
2014-05-26 12:08:59,350 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Seq 
1-8670555182595048072: Executing:  { Cmd , MgmtId: 7332683579487, via: 
1(Rack1Pod1Host13), Ver: v1, Flags: 100111, 
[{"com.cloud.agent.api.OvsDestroyBridgeCommand":{"networkId":206,"name":"OVSTunnel983","hostId":1,"wait":0}}]
 }
2014-05-26 12:08:59,350 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-183:ctx-51a7921b) Seq 1-8670555182595048072: Executing request
2014-05-26 12:08:59,395 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-183:ctx-51a7921b) A VIF for dom0 has already been found - No need 
to create one
2014-05-26 12:08:59,414 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-183:ctx-51a7921b) Xen Server network for tunnels found:OVSTunnel983
2014-05-26 12:08:59,451 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-183:ctx-51a7921b) A VIF in dom0 for the network is found - so 
destroy the vif
2014-05-26 12:08:59,455 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-183:ctx-51a7921b) Destroy temp dom0 vifOVSTunnel983 success
2014-05-26 12:08:59,816 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-183:ctx-51a7921b) OVS Bridge destroyed
2014-05-26 12:08:59,828 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
(Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Destroy bridge 
fornetwork 206 successful
2014-05-26 12:08:59,830 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
(Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Destroying 
tunnel to 1 from 4
2014-05-26 12:08:59,835 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Seq 
4-1333065489701667402: Sending  { Cmd , MgmtId: 7332683579487, via: 
4(Rack1Pod1Host14), Ver: v1, Flags: 100111, 
[{"com.cloud.agent.api.OvsDestroyTunnelCommand":{"networkId":206,"networkName":"OVSTunnel983","inPortName":"t983-4-1","wait":0}}]
 }
2014-05-26 12:08:59,835 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-11:ctx-4073a866 job-41/job-42 ctx-e591f82f) Seq 
4-1333065489701667402: Executing:  { Cmd , MgmtId: 7332683579487, via: 
4(Rack1Pod1Host14), Ver: v1, Flags: 100111, 
[{"com.cloud.agent.api.OvsDestroyTunnelCommand":{"networkId":206,"networkName":"OVSTunnel983","inPortName":"t983-4-1","wait":0}}]
 }
2014-05-26 12:08:59,836 DEBUG [c.c.a.m.DirectAgentA

[jira] [Updated] (CLOUDSTACK-6762) [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not added in bridge flow table

2014-05-26 Thread Sanjeev N (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-6762:
--

Attachment: management-server.rar

> [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not 
> added in bridge flow table 
> ---
>
> Key: CLOUDSTACK-6762
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6762
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.4.0
> Environment: Latest build from 4.4 with commit 
> d130530bd3e1cd6d8249d5045e00e4e4e2201521
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: ovs
> Fix For: 4.4.0
>
> Attachments: management-server.rar
>
>
> [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not 
> added in bridge flow table 
> Steps to reproduce:
> 
> 1.Bring up CS in advanced zone with two hosts in xen cluster
> 2.Add physical network with isolation type GRE
> 3.Create an isolated network offering with connectivity service and OVS asc 
> the provider
> 4.Create a user account and deploy one vm with above network offering and 
> make sure that vm comes on host1 and VR comes on host2
> 5.Verify the flow table on the ovs bridge created for this network
> Result:
> ==
> flow table rules to drop multicast and broacast traffic on tunnel ports are 
> not added on the host where VR is running but the same rules are added on the 
> host where vm is running
> VR is running on the following host:
> [root@Rack1Pod1Host14 ~]# ovs-ofctl dump-flows xapi3
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=988.459s, table=0, n_packets=5, n_bytes=810, 
> priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2
>  cookie=0x0, duration=988.469s, table=0, n_packets=0, n_bytes=0, 
> priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
>  cookie=0x0, duration=1011.44s, table=0, n_packets=20, n_bytes=2354, 
> priority=0 actions=NORMAL
>  cookie=0x0, duration=988.45s, table=0, n_packets=0, n_bytes=0, 
> priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2
>  cookie=0x0, duration=988.479s, table=0, n_packets=0, n_bytes=0, 
> priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
> [root@Rack1Pod1Host14 ~]#
> VM is running on the following host:
> 
> [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi3
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=456.937s, table=0, n_packets=0, n_bytes=0, 
> priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2
>  cookie=0x0, duration=456.951s, table=0, n_packets=0, n_bytes=0, 
> priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
>  cookie=0x0, duration=551.614s, table=0, n_packets=0, n_bytes=0, 
> priority=1000,ip,in_port=1,nw_dst=224.0.0.0/24 actions=drop
>  cookie=0x0, duration=551.932s, table=0, n_packets=15, n_bytes=1836, 
> priority=0 actions=NORMAL
>  cookie=0x0, duration=456.926s, table=0, n_packets=0, n_bytes=0, 
> priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2
>  cookie=0x0, duration=551.624s, table=0, n_packets=0, n_bytes=0, 
> priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
>  cookie=0x0, duration=456.962s, table=0, n_packets=9, n_bytes=2178, 
> priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
> On both the hosts port 1 is tunnel port and port 2 is vif.
> Following is the log snippet for xapi3 from host where VR is running:
> 2014-05-26 08:06:14DEBUG [root] About to manually create the bridge:xapi3
> 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', 
> '--may-exist', 'add-br', 'xapi3', '--', 'set', 'bridge', 'xapi3', 
> 'other_config:gre_key=OVSTunnel983']
> 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
> 'Bridge', 'xapi3', 
> 'external_ids:xs-network-uuid=9d7ff1a3-342a-b206-ca09-7fbe8bcabfd0']
> 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
> 'Bridge', 'xapi3', 'stp_enable=true']
> 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
> 'bridge', 'xapi3', 'other_config:gre_key']
> 2014-05-26 08:06:14DEBUG [root] Executing:['/opt/xensource/bin/xe', 
> 'network-list', 'bridge=xapi3', '--minimal']
> 2014-05-26 08:06:14DEBUG [root] Setup_ovs_bridge completed with 
> result:SUCCESS:xapi3
> 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
> '--timeout=30', 'wait-until', 'bridge', 'xapi3', '--', 'get', 'bridge', 
> 'xapi3', 'name']
> 2014-05-26 08:06:14DEBUG [root] bridge xapi3 for creating tunnel - 
> VERIFIED
> 2014-05-26 08:06:14DEBU

  1   2   3   4   5   6   7   >