[jira] [Resolved] (CLOUDSTACK-6913) VM could not perform live migrate afte the template deleted.

2014-07-11 Thread Sanjay Tripathi (JIRA)

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

Sanjay Tripathi resolved CLOUDSTACK-6913.
-

Resolution: Cannot Reproduce

 VM could not perform live migrate afte the template deleted.
 

 Key: CLOUDSTACK-6913
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6913
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
 Environment: Cloudstack4.3+Xenserver6.2sp1
Reporter: Guangsheng Xu
Assignee: Sanjay Tripathi
   Original Estimate: 672h
  Remaining Estimate: 672h

 I use a template to launch a Instance, after the Instance up and running, I 
 can migrate the VM to a nother host inside the Cluster via Cloudstack Web by 
 clicking 'Migrate'on this VM. But after I delete the template which I used to 
 create this VM. Then a few minutes latter, there is no response when I click 
 'Migrate' on this VM.
 Catalina log shows:  GET command=findHostsForMigrationVirtualMachineId 530 
 null



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


[jira] [Commented] (CLOUDSTACK-6913) VM could not perform live migrate afte the template deleted.

2014-07-11 Thread Sanjay Tripathi (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058443#comment-14058443
 ] 

Sanjay Tripathi commented on CLOUDSTACK-6913:
-

Hi, i tried the steps mentioned in the bugs and not able to reproduce the 
issue. Also the code flow looks fine and user should not get null output as a 
part of API call response.

[~guangsheng...@ericsson.com]: Can you please share the management server logs 
where you are getting this problem. That will help us to in narrowing down this 
issue.

 VM could not perform live migrate afte the template deleted.
 

 Key: CLOUDSTACK-6913
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6913
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
 Environment: Cloudstack4.3+Xenserver6.2sp1
Reporter: Guangsheng Xu
Assignee: Sanjay Tripathi
   Original Estimate: 672h
  Remaining Estimate: 672h

 I use a template to launch a Instance, after the Instance up and running, I 
 can migrate the VM to a nother host inside the Cluster via Cloudstack Web by 
 clicking 'Migrate'on this VM. But after I delete the template which I used to 
 create this VM. Then a few minutes latter, there is no response when I click 
 'Migrate' on this VM.
 Catalina log shows:  GET command=findHostsForMigrationVirtualMachineId 530 
 null



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


[jira] [Updated] (CLOUDSTACK-6933) registering an iso fails in KVM deployment.

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-6933:
---

Assignee: Bharat Kumar

 registering an iso fails in KVM deployment.
 ---

 Key: CLOUDSTACK-6933
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6933
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
 Environment: KVM advanced network
Reporter: Bharat Kumar
Assignee: Bharat Kumar
 Fix For: 4.4.0


 registing an iso fails with the connection refused error in KVM deployment.
 below are the iptable rules on the relevant SSVM in the env.
 Chain INPUT (policy DROP 28 packets, 1340 bytes)
  pkts bytes target prot opt in out source   
 destination 
 0 0 ACCEPT tcp  --  eth2   *   0.0.0.0/00.0.0.0/0 
state NEW tcp dpt:443
 0 0 ACCEPT tcp  --  eth2   *   0.0.0.0/00.0.0.0/0 
state NEW tcp dpt:80
 0 0 ACCEPT tcp  --  eth1   *   0.0.0.0/00.0.0.0/0 
state NEW tcp dpt:3922
   172 13277 ACCEPT all  --  eth0   *   0.0.0.0/00.0.0.0/0 
state RELATED,ESTABLISHED
  4122  469K ACCEPT all  --  eth1   *   0.0.0.0/00.0.0.0/0 
state RELATED,ESTABLISHED
   196 10976 ACCEPT all  --  eth2   *   0.0.0.0/00.0.0.0/0 
state RELATED,ESTABLISHED
 0 0 ACCEPT all  --  eth3   *   0.0.0.0/00.0.0.0/0 
state RELATED,ESTABLISHED
 0 0 ACCEPT all  --  lo *   0.0.0.0/00.0.0.0/0 
   
 0 0 DROP   icmp --  *  *   0.0.0.0/00.0.0.0/0 
icmptype 13
 0 0 ACCEPT icmp --  *  *   0.0.0.0/00.0.0.0/0 
   
 3   180 ACCEPT tcp  --  eth0   *   0.0.0.0/00.0.0.0/0 
state NEW tcp dpt:3922
 Chain FORWARD (policy DROP 0 packets, 0 bytes)
  pkts bytes target prot opt in out source   
 destination 
 Chain OUTPUT (policy ACCEPT 511 packets, 81586 bytes)
  pkts bytes target prot opt in out source   
 destination 
 0 0 ACCEPT tcp  --  *  eth10.0.0.0/0
 172.16.88.0/24   state NEW tcp
  2576  155K ACCEPT tcp  --  *  eth10.0.0.0/0
 172.16.88.0/24   state NEW tcp
 0 0 REJECT tcp  --  *  eth10.0.0.0/00.0.0.0/0 
state NEW tcp dpt:80 reject-with icmp-port-unreachable
 0 0 REJECT tcp  --  *  eth10.0.0.0/00.0.0.0/0 
state NEW tcp dpt:443 reject-with icmp-port-unreachable
 Chain HTTP (0 references)
  pkts bytes target prot opt in out source   
 destination 
 root@s-54-QA:~# route -n 
 Kernel IP routing table
 Destination Gateway Genmask Flags Metric RefUse Iface
 0.0.0.0 172.16.171.10.0.0.0 UG0  00 eth2
 169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
 172.16.88.0 0.0.0.0 255.255.255.0   U 0  00 eth1
 172.16.88.0 0.0.0.0 255.255.255.0   U 0  00 eth3
 172.16.171.00.0.0.0 255.255.255.0   U 0  00 eth2
 As per the above config when a packet is sent to 172.16.88.x/24 subnet  we 
 are routing it via interface eth1. but we also have a reject rule in the 
 OUTPUT chain for the packets leaving from eth1. as a result the packets get 
 dropped. 
 if we interchange the routes i.e. if the route related to eth3 is hit before 
 hitting the eth1 route the register iso is successful. 



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


[jira] [Updated] (CLOUDSTACK-6969) Data Volume Shrink operation failing with Unexpected Exception

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-6969:
---

Assignee: Kelven Yang

 Data Volume Shrink operation failing with Unexpected Exception
 

 Key: CLOUDSTACK-6969
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6969
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
 Environment: KVM, Vmware
Reporter: Girish Shilamkar
Assignee: Kelven Yang
  Labels: automation, volumes
 Fix For: 4.4.0


 1. Attach a volume to VM
 2. Grow volume by resize
 3. Try to shrink back the volume by resize with shrinkok option set to True
 Operation fails with Unexpected exception and the management server log 
 indicates null pointer exception.
 log:
 2014-06-20 04:41:36,626 ERROR [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-166:ctx-82122433 job-7959/job-7960) Unable to complete 
 AsyncJobVO {id:7960, userId: 2, ac
 countId: 2, instanceType: null, instanceId: null, cmd: 
 com.cloud.storage.VmWorkResizeVolume, cmdInfo: 
 rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtSZXNpemVWb2x1bWVU03zH
 0Fe-ggIABUoAC2N1cnJlbnRTaXplSgAHbmV3U2l6ZVoACHNocmlua09rSgAIdm9sdW1lSWRMABRuZXdTZXJ2aWNlT2ZmZXJpbmdJZHQAEExqYXZhL2xhbmcvTG9uZzt4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJW
 drAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACBLd0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbAUA
 AoABBRFzcgAOamF2YS5sYW5nLkxvbmc7i-SQzI8j3wIAAUoABXZhbHVleHIAEGphdmEubGFuZy5OdW1iZXKGrJUdC5TgiwIAAHhwAXo,
  cmdVersion: 0, status: IN_PROGRESS, p
 rocessStatus: 0, resultCode: 0, result: null, initMsid: 29066118877352, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: Fri Jun 20 
 04:41:34 PDT 2014
 }, job origin:7959
 java.lang.NullPointerException
 at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2495)
 at sun.reflect.GeneratedMethodAccessor1071.invoke(Unknown Source)
 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:2515)
 at sun.reflect.GeneratedMethodAccessor476.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.$Proxy182.handleVmWorkJob(Unknown Source)
 at 
 com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
 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 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

[jira] [Updated] (CLOUDSTACK-7031) [Automation] deployDataCenter.py issues

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-7031:
---

Assignee: Santhosh Kumar Edukulla

 [Automation] deployDataCenter.py issues
 ---

 Key: CLOUDSTACK-7031
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7031
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Alex Brett
Assignee: Santhosh Kumar Edukulla
 Fix For: 4.4.0


 In Marvin's deployDataCenter.py on master and 4.4-forward, some functions 
 within the DeployDataCenters class call sys.exit(1) directly. Good practise 
 is for sys.exit to only ever be called from inside a __main__ environment, 
 and not from within a class.
 In particular, if using the deployDataCenter.py code as a library rather than 
 invoking it directly, this can result in unexpected application exits if a 
 problem occurs.
 In addition, when run directly deployDataCenter.py will always exit with 
 error code 1, even after a successful deploy, which is not helpful to anybody 
 wanting to script the code.
 I've prepared a patch against 4.4-forward that resolves these issues (and 
 also tidies up logging by removing calls to print from inside the 
 DeployDataCenters class), which I'll submit for review. I can't assign this 
 ticket to myself however...



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


[jira] [Updated] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-7004:
---

Assignee: Kishan Kavala

 [Automation] [KVM] Deploying a VM with rootdisksize less than the size of 
 template does not fail
 

 Key: CLOUDSTACK-7004
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Automation, KVM
Affects Versions: 4.4.0
 Environment: KVM
Reporter: Gaurav Aradhye
Assignee: Kishan Kavala
  Labels: api, automation, kvm
 Fix For: 4.4.0


 Deploy a VM with parameter rootdisksize less than the template size.
 API should throw error for this but it succeeds.
 Although the root disk size of deployed VM is equal to template size in this 
 case, but this operation should throw error and VM should not be deployed.



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


[jira] [Updated] (CLOUDSTACK-6991) VM does not get expunged even after waiting for 10 times the expunge interval time

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-6991:
---

Assignee: Alena Prokharchyk

 VM does not get expunged even after waiting for 10 times the expunge interval 
 time
 --

 Key: CLOUDSTACK-6991
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6991
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, KVM
Affects Versions: 4.4.0
 Environment: Observed on KVM
Reporter: Gaurav Aradhye
Assignee: Alena Prokharchyk
  Labels: automation
 Fix For: 4.4.0


 Create a VM and destroy it.
 VM should get expunged after expunge interval, but it stays in Destroyed 
 state.
 test_09_expunge_vm failing due to this.



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


[jira] [Updated] (CLOUDSTACK-7031) [Automation] deployDataCenter.py issues

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-7031:
---

Assignee: (was: Santhosh Kumar Edukulla)

 [Automation] deployDataCenter.py issues
 ---

 Key: CLOUDSTACK-7031
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7031
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Alex Brett
 Fix For: 4.4.0


 In Marvin's deployDataCenter.py on master and 4.4-forward, some functions 
 within the DeployDataCenters class call sys.exit(1) directly. Good practise 
 is for sys.exit to only ever be called from inside a __main__ environment, 
 and not from within a class.
 In particular, if using the deployDataCenter.py code as a library rather than 
 invoking it directly, this can result in unexpected application exits if a 
 problem occurs.
 In addition, when run directly deployDataCenter.py will always exit with 
 error code 1, even after a successful deploy, which is not helpful to anybody 
 wanting to script the code.
 I've prepared a patch against 4.4-forward that resolves these issues (and 
 also tidies up logging by removing calls to print from inside the 
 DeployDataCenters class), which I'll submit for review. I can't assign this 
 ticket to myself however...



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


[jira] [Updated] (CLOUDSTACK-7062) Creating storage pool failing with xenserver with NullPointerException

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-7062:
---

Assignee: Koushik Das

 Creating storage pool failing with xenserver with NullPointerException
 --

 Key: CLOUDSTACK-7062
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7062
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Storage Controller
Affects Versions: 4.4.0
 Environment: XenServer
Reporter: Gaurav Aradhye
Assignee: Koushik Das
 Fix For: 4.4.0


 test case related to iscsi failing with Failed to add data store and log 
 shows nullPointerException
 Management Server Log:
 2014-07-02 11:32:49,504 DEBUG 
 [o.a.c.s.d.l.CloudStackPrimaryDataStoreLifeCycleImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) 
 createPool Par
 ams @ scheme - iscsi storageHost - 172.16.88.27 hostPath - 
 /iqn.2006-01.com.openfiler:tsn.b7c10b2d6ab6 port - -1
 2014-07-02 11:32:49,505 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-40:ctx-d91132bb) Seq 2-177610710304424049: Executing request
 2014-07-02 11:32:49,509 DEBUG [c.c.s.StorageManagerImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) Failed 
 to add data store: null
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl.initialize(CloudStackPrimaryDataStoreLifeCycleImpl.java:263)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:666)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:178)
 at 
 org.apache.cloudstack.api.command.admin.storage.CreateStoragePoolCmd.execute(CreateStoragePoolCmd.java:163)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:682)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:511)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
 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:115)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
 at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
 at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
 at 
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
 at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
 at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:326)
 at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
 at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
 at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
 at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 2014-07-02 11:32:49,510 INFO  [c.c.a.ApiServer] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) Failed 
 to add data store: null



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


[jira] [Updated] (CLOUDSTACK-4899) Providing Configuration support for Marvin

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-4899:
---

Assignee: Santhosh Kumar Edukulla

 Providing Configuration support for Marvin
 --

 Key: CLOUDSTACK-4899
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4899
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Reporter: Santhosh Kumar Edukulla
Assignee: Santhosh Kumar Edukulla

 Providing Configuration support to Marvin. Currently, there is no way to 
 provide and drive a uniform configuraiton support to Marvin. The framework 
 currently does not have the support to retrieve and provide a uniform object 
 as dictionary to test features under marvin. All features should be removed 
 of hard coded strings. Move all hard coded and configuration settings to one 
 config directory.  This way, we can have a confiugration module and use 
 uniform object provided as part of TestClient, so that user can segregate 
 code from config and maintain config at single place. This is good and 
 maintain readability



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


[jira] [Updated] (CLOUDSTACK-4901) Move all code currently under tools/marvin/marvin directory to a common lib

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-4901:
---

Assignee: Santhosh Kumar Edukulla

 Move all code currently under tools/marvin/marvin directory to a common lib
 ---

 Key: CLOUDSTACK-4901
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4901
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Reporter: Santhosh Kumar Edukulla
Assignee: Santhosh Kumar Edukulla

 Currently, there are few modules viz., 
 cloudstackConnection.py,dbConnection.py,deployDataCenter.py etc under 
 marvin/marvin directory. These should be moved to lib directory 
 appropriately. It will maintain proper directory structure for marvin.



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


[jira] [Resolved] (CLOUDSTACK-4899) Providing Configuration support for Marvin

2014-07-11 Thread Santhosh Kumar Edukulla (JIRA)

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

Santhosh Kumar Edukulla resolved CLOUDSTACK-4899.
-

Resolution: Fixed

We added a ConfigManager interface and moved relevant data to config.

 Providing Configuration support for Marvin
 --

 Key: CLOUDSTACK-4899
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4899
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Reporter: Santhosh Kumar Edukulla
Assignee: Santhosh Kumar Edukulla

 Providing Configuration support to Marvin. Currently, there is no way to 
 provide and drive a uniform configuraiton support to Marvin. The framework 
 currently does not have the support to retrieve and provide a uniform object 
 as dictionary to test features under marvin. All features should be removed 
 of hard coded strings. Move all hard coded and configuration settings to one 
 config directory.  This way, we can have a confiugration module and use 
 uniform object provided as part of TestClient, so that user can segregate 
 code from config and maintain config at single place. This is good and 
 maintain readability



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


[jira] [Updated] (CLOUDSTACK-7082) [Automation] System vm are not getting created in Xen

2014-07-11 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-7082:
---

Assignee: Koushik Das  (was: Animesh Chaturvedi)

 [Automation] System vm are not getting created in Xen 
 --

 Key: CLOUDSTACK-7082
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7082
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Xen
Affects Versions: 4.5.0
 Environment: Xen
 Build 4.4 / master 
Reporter: Rayees Namathponnan
Assignee: Koushik Das
Priority: Blocker
 Fix For: 4.5.0

 Attachments: management-server_CLOUDSTACK-7082.rar


 Create advanced zone in Xen with 4.5 build. SSVM and CPVM failed to create, 
 observed below error in MS log, also attached full log
 2014-07-08 10:13:32,271 DEBUG [c.c.s.ConfigurationServerImpl] (main:null) 
 Caught SQLException when inserting system user: Duplicate entry '1' for key 
 'PRIMARY'
 2014-07-08 10:13:32,271 DEBUG [c.c.s.ConfigurationServerImpl] (main:null) 
 Caught SQLException when creating admin account: Duplicate entry '2' for key 
 'PRIMARY'
 2014-07-08 10:13:32,272 DEBUG [c.c.s.ConfigurationServerImpl] (main:null) 
 Caught SQLException when inserting admin user: Duplicate entry '2' for key 
 'PRIMARY'
 2014-07-08 10:13:32,273 DEBUG [c.c.s.ConfigurationServerImpl] (main:null) 
 Caught (SQL?)Exception: no network_group  Table 'cloud.network_group' doesn't 
 exist
 java.io.IOException: Fail to generate certificate!: sudo: no tty present and 
 no askpass program specified
 2014-07-08 10:13:51,450 WARN  [c.c.c.d.ManagementServerHostDaoImpl] 
 (Cluster-Heartbeat-1:ctx-b1344ab9) update:Exception:Invalid cluster session 
 detected
 com.cloud.utils.exception.CloudRuntimeException: Invalid cluster session 
 detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 java.lang.RuntimeException: update:Exception:Invalid cluster session detected
 Caused by: com.cloud.utils.exception.CloudRuntimeException: Invalid cluster 
 session detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 2014-07-08 10:13:52,854 WARN  [c.c.c.d.ManagementServerHostDaoImpl] 
 (Cluster-Heartbeat-1:ctx-32db3a37) update:Exception:Invalid cluster session 
 detected
 com.cloud.utils.exception.CloudRuntimeException: Invalid cluster session 
 detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 java.lang.RuntimeException: update:Exception:Invalid cluster session detected
 Caused by: com.cloud.utils.exception.CloudRuntimeException: Invalid cluster 
 session detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 2014-07-08 10:13:54,354 WARN  [c.c.c.d.ManagementServerHostDaoImpl] 
 (Cluster-Heartbeat-1:ctx-bc4d14ae) update:Exception:Invalid cluster session 
 detected
 com.cloud.utils.exception.CloudRuntimeException: Invalid cluster session 
 detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 java.lang.RuntimeException: update:Exception:Invalid cluster session detected
 Caused by: com.cloud.utils.exception.CloudRuntimeException: Invalid cluster 
 session detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid



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


[jira] [Created] (CLOUDSTACK-7096) [Automation] SSH to VM with LB rule to its secondary IP fails with error SSHException: Error reading SSH protocol banner

2014-07-11 Thread Ashutosk Kelkar (JIRA)
Ashutosk Kelkar created CLOUDSTACK-7096:
---

 Summary: [Automation] SSH to VM with LB rule to its secondary IP 
fails with error SSHException: Error reading SSH protocol banner
 Key: CLOUDSTACK-7096
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7096
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Network Controller
Affects Versions: 4.4.0
 Environment: KVM
Reporter: Ashutosk Kelkar
 Fix For: 4.4.0


Steps:
1. Create an account
2. Deploy a VM
3. Acquire secondary IP for default VM NIC
4. Acquire public IP in the network
5. Create firewall rule for public IP
6. Create load balancer rule for this IP to the secondary IP of VM
7. Try to SSH to VM using public IP

It fails with error SSHException: Error reading SSH protocol banner

If you create load balancer rule for the primary IP, then SSH succeeds



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


[jira] [Updated] (CLOUDSTACK-7096) [Automation] SSH to VM with LB rule to its secondary IP fails with error SSHException: Error reading SSH protocol banner

2014-07-11 Thread Ashutosk Kelkar (JIRA)

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

Ashutosk Kelkar updated CLOUDSTACK-7096:


Attachment: iptablesOnHost.txt

Attaching iptables on host

 [Automation] SSH to VM with LB rule to its secondary IP fails with error 
 SSHException: Error reading SSH protocol banner
 --

 Key: CLOUDSTACK-7096
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7096
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Network Controller
Affects Versions: 4.4.0
 Environment: KVM
Reporter: Ashutosk Kelkar
  Labels: automation
 Fix For: 4.4.0

 Attachments: iptablesOnHost.txt


 Steps:
 1. Create an account
 2. Deploy a VM
 3. Acquire secondary IP for default VM NIC
 4. Acquire public IP in the network
 5. Create firewall rule for public IP
 6. Create load balancer rule for this IP to the secondary IP of VM
 7. Try to SSH to VM using public IP
 It fails with error SSHException: Error reading SSH protocol banner
 If you create load balancer rule for the primary IP, then SSH succeeds



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


[jira] [Created] (CLOUDSTACK-7097) failing to add kvm host to MS

2014-07-11 Thread shweta agarwal (JIRA)
shweta agarwal created CLOUDSTACK-7097:
--

 Summary: failing to add  kvm host to MS
 Key: CLOUDSTACK-7097
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7097
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM, Management Server
Affects Versions: 4.5.0
Reporter: shweta agarwal
Priority: Blocker
 Fix For: 4.5.0


Repro steps:
Create a agent on rhel 6.3
create a MS on rhel 6.3

Try creating a zone

Bug : zone creation fails at adding host step


MS log shows :
014-07-11 03:33:46,284 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Received unknown parameters for 
command addHost. Unknown parameters : clustertype
2014-07-11 03:33:46,294 INFO  [c.c.r.ResourceManagerImpl] 
(catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Trying to add a new host at 
http://10.147.40.24 in data center 1
2014-07-11 03:33:46,487 DEBUG [c.c.u.s.SSHCmdHelper] 
(catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
2014-07-11 03:33:47,505 DEBUG [c.c.u.s.SSHCmdHelper] 
(catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
2014-07-11 03:33:48,556 DEBUG [c.c.u.s.SSHCmdHelper] 
(catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
2014-07-11 03:33:49,607 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] 
(catalina-exec-12:ctx-007b5513 ctx-c586ed3c) It's not a KVM enabled machine
2014-07-11 03:33:49,608 WARN  [c.c.r.ResourceManagerImpl] 
(catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Unable to find the server 
resources at http://10.147.40.24
2014-07-11 03:33:49,611 INFO  [c.c.u.e.CSExceptionErrorCode] 
(catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Could not find exception: 
com.cloud.exception.DiscoveryException in error code list for exceptions
2014-07-11 03:33:49,611 WARN  [o.a.c.a.c.a.h.AddHostCmd] 
(catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Exception:
com.cloud.exception.DiscoveryException: Unable to add the host
at 
com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791)
at 
com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586)
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:601)
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 $Proxy148.discoverHosts(Unknown Source)
at 
org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
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:115)
at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

[jira] [Updated] (CLOUDSTACK-7097) failing to add kvm host to MS

2014-07-11 Thread shweta agarwal (JIRA)

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

shweta agarwal updated CLOUDSTACK-7097:
---

Attachment: management-server.log.tar.gz

 failing to add  kvm host to MS
 --

 Key: CLOUDSTACK-7097
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7097
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM, Management Server
Affects Versions: 4.5.0
Reporter: shweta agarwal
Priority: Blocker
 Fix For: 4.5.0

 Attachments: management-server.log.tar.gz


 Repro steps:
 Create a agent on rhel 6.3
 create a MS on rhel 6.3
 Try creating a zone
 Bug : zone creation fails at adding host step
 MS log shows :
 014-07-11 03:33:46,284 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Received unknown parameters for 
 command addHost. Unknown parameters : clustertype
 2014-07-11 03:33:46,294 INFO  [c.c.r.ResourceManagerImpl] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Trying to add a new host at 
 http://10.147.40.24 in data center 1
 2014-07-11 03:33:46,487 DEBUG [c.c.u.s.SSHCmdHelper] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
 2014-07-11 03:33:47,505 DEBUG [c.c.u.s.SSHCmdHelper] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
 2014-07-11 03:33:48,556 DEBUG [c.c.u.s.SSHCmdHelper] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
 2014-07-11 03:33:49,607 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) It's not a KVM enabled machine
 2014-07-11 03:33:49,608 WARN  [c.c.r.ResourceManagerImpl] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Unable to find the server 
 resources at http://10.147.40.24
 2014-07-11 03:33:49,611 INFO  [c.c.u.e.CSExceptionErrorCode] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Could not find exception: 
 com.cloud.exception.DiscoveryException in error code list for exceptions
 2014-07-11 03:33:49,611 WARN  [o.a.c.a.c.a.h.AddHostCmd] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Exception:
 com.cloud.exception.DiscoveryException: Unable to add the host
 at 
 com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791)
 at 
 com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586)
 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:601)
 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 $Proxy148.discoverHosts(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
 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:115)
 at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at 
 

[jira] [Commented] (CLOUDSTACK-7097) failing to add kvm host to MS

2014-07-11 Thread Wei Zhou (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058583#comment-14058583
 ] 

Wei Zhou commented on CLOUDSTACK-7097:
--

it looks kvm is not supported on the host. it should like this:

root@cs-001:~# lsmod |grep kvm
kvm_intel 137721  18
kvm   415550  1 kvm_intel


If not, please check the BIOS configuration

 failing to add  kvm host to MS
 --

 Key: CLOUDSTACK-7097
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7097
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM, Management Server
Affects Versions: 4.5.0
Reporter: shweta agarwal
Priority: Blocker
 Fix For: 4.5.0

 Attachments: management-server.log.tar.gz


 Repro steps:
 Create a agent on rhel 6.3
 create a MS on rhel 6.3
 Try creating a zone
 Bug : zone creation fails at adding host step
 MS log shows :
 014-07-11 03:33:46,284 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Received unknown parameters for 
 command addHost. Unknown parameters : clustertype
 2014-07-11 03:33:46,294 INFO  [c.c.r.ResourceManagerImpl] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Trying to add a new host at 
 http://10.147.40.24 in data center 1
 2014-07-11 03:33:46,487 DEBUG [c.c.u.s.SSHCmdHelper] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
 2014-07-11 03:33:47,505 DEBUG [c.c.u.s.SSHCmdHelper] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
 2014-07-11 03:33:48,556 DEBUG [c.c.u.s.SSHCmdHelper] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
 2014-07-11 03:33:49,607 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) It's not a KVM enabled machine
 2014-07-11 03:33:49,608 WARN  [c.c.r.ResourceManagerImpl] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Unable to find the server 
 resources at http://10.147.40.24
 2014-07-11 03:33:49,611 INFO  [c.c.u.e.CSExceptionErrorCode] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Could not find exception: 
 com.cloud.exception.DiscoveryException in error code list for exceptions
 2014-07-11 03:33:49,611 WARN  [o.a.c.a.c.a.h.AddHostCmd] 
 (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Exception:
 com.cloud.exception.DiscoveryException: Unable to add the host
 at 
 com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791)
 at 
 com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586)
 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:601)
 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 $Proxy148.discoverHosts(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
 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:115)
 at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at 

[jira] [Updated] (CLOUDSTACK-7096) [Automation] SSH to VM with LB rule to its secondary IP fails with error SSHException: Error reading SSH protocol banner

2014-07-11 Thread Ashutosk Kelkar (JIRA)

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

Ashutosk Kelkar updated CLOUDSTACK-7096:


Attachment: management-server.log

Attaching management server log

 [Automation] SSH to VM with LB rule to its secondary IP fails with error 
 SSHException: Error reading SSH protocol banner
 --

 Key: CLOUDSTACK-7096
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7096
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Network Controller
Affects Versions: 4.4.0
 Environment: KVM
Reporter: Ashutosk Kelkar
  Labels: automation
 Fix For: 4.4.0

 Attachments: iptablesOnHost.txt, management-server.log


 Steps:
 1. Create an account
 2. Deploy a VM
 3. Acquire secondary IP for default VM NIC
 4. Acquire public IP in the network
 5. Create firewall rule for public IP
 6. Create load balancer rule for this IP to the secondary IP of VM
 7. Try to SSH to VM using public IP
 It fails with error SSHException: Error reading SSH protocol banner
 If you create load balancer rule for the primary IP, then SSH succeeds



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


[jira] [Assigned] (CLOUDSTACK-4440) CloudStack should handle native VMware HA for virtual routers

2014-07-11 Thread Sateesh Chodapuneedi (JIRA)

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

Sateesh Chodapuneedi reassigned CLOUDSTACK-4440:


Assignee: Sateesh Chodapuneedi

 CloudStack should handle native VMware HA for virtual routers
 -

 Key: CLOUDSTACK-4440
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4440
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc, Management Server
Affects Versions: 4.5.0
Reporter: Kirk Kosinski
Assignee: Sateesh Chodapuneedi
Priority: Minor
  Labels: ha, networking, virtualrouter, vmware, vsphere

 Currently when a virtual router is rebooted by native VMware HA in vSphere, 
 it will lose its network and iptables configuration and cause connectivity 
 problems for VMs. Resolving this requires manual intervention by the 
 CloudStack administrator; the router must be rebooted, or the network 
 restarted.
 This behavior is not ideal and will prolong downtime caused by an HA event, 
 and there is no point for the non-functional virtual router to even be 
 running. CloudStack should handle this situation gracefully by reconfiguring 
 a virtual router that is successfully rebooted by VMware HA. 
 In the meantime this limitation should be documented.



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


[jira] [Updated] (CLOUDSTACK-4440) CloudStack should handle native VMware HA for virtual routers

2014-07-11 Thread Sateesh Chodapuneedi (JIRA)

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

Sateesh Chodapuneedi updated CLOUDSTACK-4440:
-

Affects Version/s: (was: 4.2.0)
   4.5.0

 CloudStack should handle native VMware HA for virtual routers
 -

 Key: CLOUDSTACK-4440
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4440
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc, Management Server
Affects Versions: 4.5.0
Reporter: Kirk Kosinski
Assignee: Sateesh Chodapuneedi
Priority: Minor
  Labels: ha, networking, virtualrouter, vmware, vsphere

 Currently when a virtual router is rebooted by native VMware HA in vSphere, 
 it will lose its network and iptables configuration and cause connectivity 
 problems for VMs. Resolving this requires manual intervention by the 
 CloudStack administrator; the router must be rebooted, or the network 
 restarted.
 This behavior is not ideal and will prolong downtime caused by an HA event, 
 and there is no point for the non-functional virtual router to even be 
 running. CloudStack should handle this situation gracefully by reconfiguring 
 a virtual router that is successfully rebooted by VMware HA. 
 In the meantime this limitation should be documented.



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


[jira] [Updated] (CLOUDSTACK-7096) [Automation] SSH to VM with LB rule to its secondary IP fails with error SSHException: Error reading SSH protocol banner

2014-07-11 Thread Jayapal Reddy (JIRA)

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

Jayapal Reddy updated CLOUDSTACK-7096:
--

Assignee: Ashutosk Kelkar

 [Automation] SSH to VM with LB rule to its secondary IP fails with error 
 SSHException: Error reading SSH protocol banner
 --

 Key: CLOUDSTACK-7096
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7096
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Network Controller
Affects Versions: 4.4.0
 Environment: KVM
Reporter: Ashutosk Kelkar
Assignee: Ashutosk Kelkar
  Labels: automation
 Fix For: 4.4.0

 Attachments: iptablesOnHost.txt, management-server.log


 Steps:
 1. Create an account
 2. Deploy a VM
 3. Acquire secondary IP for default VM NIC
 4. Acquire public IP in the network
 5. Create firewall rule for public IP
 6. Create load balancer rule for this IP to the secondary IP of VM
 7. Try to SSH to VM using public IP
 It fails with error SSHException: Error reading SSH protocol banner
 If you create load balancer rule for the primary IP, then SSH succeeds



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


[jira] [Updated] (CLOUDSTACK-7096) [Automation] SSH to VM with LB rule to its secondary IP fails with error SSHException: Error reading SSH protocol banner

2014-07-11 Thread Ashutosk Kelkar (JIRA)

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

Ashutosk Kelkar updated CLOUDSTACK-7096:


Attachment: agent.log

Attaching agent log

 [Automation] SSH to VM with LB rule to its secondary IP fails with error 
 SSHException: Error reading SSH protocol banner
 --

 Key: CLOUDSTACK-7096
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7096
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Network Controller
Affects Versions: 4.4.0
 Environment: KVM
Reporter: Ashutosk Kelkar
Assignee: Ashutosk Kelkar
  Labels: automation
 Fix For: 4.4.0

 Attachments: agent.log, iptablesOnHost.txt, management-server.log


 Steps:
 1. Create an account
 2. Deploy a VM
 3. Acquire secondary IP for default VM NIC
 4. Acquire public IP in the network
 5. Create firewall rule for public IP
 6. Create load balancer rule for this IP to the secondary IP of VM
 7. Try to SSH to VM using public IP
 It fails with error SSHException: Error reading SSH protocol banner
 If you create load balancer rule for the primary IP, then SSH succeeds



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


[jira] [Commented] (CLOUDSTACK-7012) [Atomation] Vcenter Hang during 4.4 automation runs

2014-07-11 Thread Sateesh Chodapuneedi (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058615#comment-14058615
 ] 

Sateesh Chodapuneedi commented on CLOUDSTACK-7012:
--

ERROR [c.c.h.v.r.VmwareResource] (DirectAgentCronJob-500:ctx-756811b8) Unable 
to connect to vSphere server: 10.223.52.12
com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP 
status code 503: Service Unavailable
at 
com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.checkStatusCode(HttpTransportPipe.java:296)
at 
com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:245)
at 
com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:203)
at 
com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:122)
at 
com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:123)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:626)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:585)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:570)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:467)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:308)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:163)
at 
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98)
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:135)
at com.sun.proxy.$Proxy399.retrieveServiceContent(Unknown Source)
at 
com.cloud.hypervisor.vmware.util.VmwareClient.connect(VmwareClient.java:144)
at 
com.cloud.hypervisor.vmware.resource.VmwareContextFactory.create(VmwareContextFactory.java:70)
at 
com.cloud.hypervisor.vmware.resource.VmwareContextFactory.getContext(VmwareContextFactory.java:88)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.getServiceContext(VmwareResource.java:4951)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.getServiceContext(VmwareResource.java:4927)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.gcAndKillHungWorkerVMs(VmwareResource.java:3888)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.getCurrentStatus(VmwareResource.java:3865)
at 
com.cloud.agent.manager.DirectAgentAttache$PingTask.runInContext(DirectAgentAttache.java:164)
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.runAndReset(FutureTask.java:304)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)


 [Atomation] Vcenter Hang during 4.4 automation runs
 ---

 Key: CLOUDSTACK-7012
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7012
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.4.0
 Environment: VCenter 5.0
 Exi 5.0
Reporter: Rayees Namathponnan
Assignee: Sateesh Chodapuneedi
Priority: Critical
 Fix For: 4.4.0

 Attachments: catalina.rar


 This issue observed with 4.4 automation run with Vcenter 5.0,  during BVT run 
 VM deployment fail,  if you try to connect VCenter from console gets below 
 error 
 Call ServiceInstance.RetrieveContent for object ServiceInstance on Server 
 10.223.52.12 failed.
 I was using same VCenter more 1.5 year, i never faced this issue earlier, 
 then i tried to run automation with 4.2 and 4.3 build last week i didnt 
 observe this issue,  i think some of the changes in CS 4.4 causing VCenter to 
 hang 
 Observed below error in MS Log
 INFO  [c.c.h.v.u.VmwareContext] (DirectAgentCronJob-455:ctx-71dce779) New 
 VmwareContext object, current outstanding count: 451
 INFO  [c.c.h.v.r.VmwareResource] 

[jira] [Commented] (CLOUDSTACK-7096) [Automation] SSH to VM with LB rule to its secondary IP fails with error SSHException: Error reading SSH protocol banner

2014-07-11 Thread Jayapal Reddy (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058640#comment-14058640
 ] 

Jayapal Reddy commented on CLOUDSTACK-7096:
---

Hi Ashutosk,

After acquiring secondary ip did you configure the same in the guest vm 
manually ?
Then only the LB rule works.
This step is important here. Can you please confirm that there ?

Thanks,
Jayapal

 [Automation] SSH to VM with LB rule to its secondary IP fails with error 
 SSHException: Error reading SSH protocol banner
 --

 Key: CLOUDSTACK-7096
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7096
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Network Controller
Affects Versions: 4.4.0
 Environment: KVM
Reporter: Ashutosk Kelkar
Assignee: Ashutosk Kelkar
  Labels: automation
 Fix For: 4.4.0

 Attachments: agent.log, iptablesOnHost.txt, management-server.log


 Steps:
 1. Create an account
 2. Deploy a VM
 3. Acquire secondary IP for default VM NIC
 4. Acquire public IP in the network
 5. Create firewall rule for public IP
 6. Create load balancer rule for this IP to the secondary IP of VM
 7. Try to SSH to VM using public IP
 It fails with error SSHException: Error reading SSH protocol banner
 If you create load balancer rule for the primary IP, then SSH succeeds



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


[jira] [Created] (CLOUDSTACK-7098) Improvised CloudByte Storage Plugin for 4.5 and above.

2014-07-11 Thread punith (JIRA)
punith created CLOUDSTACK-7098:
--

 Summary: Improvised CloudByte Storage Plugin for 4.5 and above.
 Key: CLOUDSTACK-7098
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7098
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.5.0
Reporter: punith


The new improvised cloudbyte plugin for cloudstack supports the following 
features

* support for managed storage, where each vm disk has the guaranteed 
  QoS.

* account integration in cloudbyte with respect to domains in cloudstack.

* supports resize of the volume.

* supports both iscsi and nfs protocols in XEN server, and iscsi protocol for 
KVM and vmware ESX.

* supports storage level snapshot capabilites as well as hypervisor level 
snapshot feature.

* also exposing the custom api's for ui integration.

* support for unlimited storage nodes across the sites.




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


[jira] [Created] (CLOUDSTACK-7099) Volume snapshot is not getting backed up

2014-07-11 Thread Likitha Shetty (JIRA)
Likitha Shetty created CLOUDSTACK-7099:
--

 Summary: Volume snapshot is not getting backed up
 Key: CLOUDSTACK-7099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7099
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Snapshot
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
 Fix For: 4.5.0


While trying to snapshot a volume, the volume snapshot is not backed up and it 
remains in 'Allocated' state.

As a result of the fix made to resolve 
[https://issues.apache.org/jira/browse/CLOUDSTACK-3272], ConfigDao is not being 
injected into SnapshotStateListener which results in an NPE. And this causes 
the snapshot process to fail .



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


[jira] [Commented] (CLOUDSTACK-7062) Creating storage pool failing with xenserver with NullPointerException

2014-07-11 Thread Koushik Das (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058664#comment-14058664
 ] 

Koushik Das commented on CLOUDSTACK-7062:
-

Not able to repro this issue on latest master/4.4-forward. Mostly this was 
fixed as part of commit d3ffb7a5659bf988d00f607ee14cc07741b76c4a on master. The 
fix is also present on 4.4.

On master I am still seeing that the test is marked as 
required_hardware=false. Why is that?

@attr(tags = [advanced, advancedns, smoke, basic, sg], 
required_hardware=false, BugId=7062)
def test_01_primary_storage_iscsi(self):


 Creating storage pool failing with xenserver with NullPointerException
 --

 Key: CLOUDSTACK-7062
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7062
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Storage Controller
Affects Versions: 4.4.0
 Environment: XenServer
Reporter: Gaurav Aradhye
Assignee: Koushik Das
 Fix For: 4.4.0


 test case related to iscsi failing with Failed to add data store and log 
 shows nullPointerException
 Management Server Log:
 2014-07-02 11:32:49,504 DEBUG 
 [o.a.c.s.d.l.CloudStackPrimaryDataStoreLifeCycleImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) 
 createPool Par
 ams @ scheme - iscsi storageHost - 172.16.88.27 hostPath - 
 /iqn.2006-01.com.openfiler:tsn.b7c10b2d6ab6 port - -1
 2014-07-02 11:32:49,505 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-40:ctx-d91132bb) Seq 2-177610710304424049: Executing request
 2014-07-02 11:32:49,509 DEBUG [c.c.s.StorageManagerImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) Failed 
 to add data store: null
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl.initialize(CloudStackPrimaryDataStoreLifeCycleImpl.java:263)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:666)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:178)
 at 
 org.apache.cloudstack.api.command.admin.storage.CreateStoragePoolCmd.execute(CreateStoragePoolCmd.java:163)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:682)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:511)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
 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:115)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
 at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
 at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
 at 
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
 at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
 at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:326)
 at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
 at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
 at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
 at 
 

[jira] [Commented] (CLOUDSTACK-7062) Creating storage pool failing with xenserver with NullPointerException

2014-07-11 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058670#comment-14058670
 ] 

ASF subversion and git services commented on CLOUDSTACK-7062:
-

Commit ba389819338a9be23f1cb604b9d586afb5598795 in cloudstack's branch 
refs/heads/master from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ba38981 ]

CLOUDSTACK-7062: Enabled back the test as not able to repro


 Creating storage pool failing with xenserver with NullPointerException
 --

 Key: CLOUDSTACK-7062
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7062
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Storage Controller
Affects Versions: 4.4.0
 Environment: XenServer
Reporter: Gaurav Aradhye
Assignee: Koushik Das
 Fix For: 4.4.0


 test case related to iscsi failing with Failed to add data store and log 
 shows nullPointerException
 Management Server Log:
 2014-07-02 11:32:49,504 DEBUG 
 [o.a.c.s.d.l.CloudStackPrimaryDataStoreLifeCycleImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) 
 createPool Par
 ams @ scheme - iscsi storageHost - 172.16.88.27 hostPath - 
 /iqn.2006-01.com.openfiler:tsn.b7c10b2d6ab6 port - -1
 2014-07-02 11:32:49,505 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-40:ctx-d91132bb) Seq 2-177610710304424049: Executing request
 2014-07-02 11:32:49,509 DEBUG [c.c.s.StorageManagerImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) Failed 
 to add data store: null
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl.initialize(CloudStackPrimaryDataStoreLifeCycleImpl.java:263)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:666)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:178)
 at 
 org.apache.cloudstack.api.command.admin.storage.CreateStoragePoolCmd.execute(CreateStoragePoolCmd.java:163)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:682)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:511)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
 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:115)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
 at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
 at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
 at 
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
 at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
 at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:326)
 at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
 at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
 at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
 at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 2014-07-02 11:32:49,510 INFO  [c.c.a.ApiServer] 
 

[jira] [Commented] (CLOUDSTACK-7062) Creating storage pool failing with xenserver with NullPointerException

2014-07-11 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058671#comment-14058671
 ] 

ASF subversion and git services commented on CLOUDSTACK-7062:
-

Commit 5e181acbdb0865c0d26307c4e5359ec9c615f615 in cloudstack's branch 
refs/heads/4.4-forward from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5e181ac ]

CLOUDSTACK-7062: Enabled back the test as not able to repro


 Creating storage pool failing with xenserver with NullPointerException
 --

 Key: CLOUDSTACK-7062
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7062
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Storage Controller
Affects Versions: 4.4.0
 Environment: XenServer
Reporter: Gaurav Aradhye
Assignee: Koushik Das
 Fix For: 4.4.0


 test case related to iscsi failing with Failed to add data store and log 
 shows nullPointerException
 Management Server Log:
 2014-07-02 11:32:49,504 DEBUG 
 [o.a.c.s.d.l.CloudStackPrimaryDataStoreLifeCycleImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) 
 createPool Par
 ams @ scheme - iscsi storageHost - 172.16.88.27 hostPath - 
 /iqn.2006-01.com.openfiler:tsn.b7c10b2d6ab6 port - -1
 2014-07-02 11:32:49,505 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-40:ctx-d91132bb) Seq 2-177610710304424049: Executing request
 2014-07-02 11:32:49,509 DEBUG [c.c.s.StorageManagerImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) Failed 
 to add data store: null
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl.initialize(CloudStackPrimaryDataStoreLifeCycleImpl.java:263)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:666)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:178)
 at 
 org.apache.cloudstack.api.command.admin.storage.CreateStoragePoolCmd.execute(CreateStoragePoolCmd.java:163)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:682)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:511)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
 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:115)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
 at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
 at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
 at 
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
 at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
 at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:326)
 at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
 at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
 at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
 at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 2014-07-02 11:32:49,510 INFO  [c.c.a.ApiServer] 
 

[jira] [Resolved] (CLOUDSTACK-7062) Creating storage pool failing with xenserver with NullPointerException

2014-07-11 Thread Koushik Das (JIRA)

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

Koushik Das resolved CLOUDSTACK-7062.
-

   Resolution: Cannot Reproduce
Fix Version/s: 4.5.0

 Creating storage pool failing with xenserver with NullPointerException
 --

 Key: CLOUDSTACK-7062
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7062
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Storage Controller
Affects Versions: 4.4.0
 Environment: XenServer
Reporter: Gaurav Aradhye
Assignee: Koushik Das
 Fix For: 4.4.0, 4.5.0


 test case related to iscsi failing with Failed to add data store and log 
 shows nullPointerException
 Management Server Log:
 2014-07-02 11:32:49,504 DEBUG 
 [o.a.c.s.d.l.CloudStackPrimaryDataStoreLifeCycleImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) 
 createPool Par
 ams @ scheme - iscsi storageHost - 172.16.88.27 hostPath - 
 /iqn.2006-01.com.openfiler:tsn.b7c10b2d6ab6 port - -1
 2014-07-02 11:32:49,505 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-40:ctx-d91132bb) Seq 2-177610710304424049: Executing request
 2014-07-02 11:32:49,509 DEBUG [c.c.s.StorageManagerImpl] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) Failed 
 to add data store: null
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl.initialize(CloudStackPrimaryDataStoreLifeCycleImpl.java:263)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:666)
 at 
 com.cloud.storage.StorageManagerImpl.createPool(StorageManagerImpl.java:178)
 at 
 org.apache.cloudstack.api.command.admin.storage.CreateStoragePoolCmd.execute(CreateStoragePoolCmd.java:163)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:682)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:511)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
 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:115)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
 at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
 at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
 at 
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
 at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
 at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:326)
 at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
 at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
 at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
 at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 2014-07-02 11:32:49,510 INFO  [c.c.a.ApiServer] 
 (1501785494@qtp-1004950349-6:ctx-966a5b97 ctx-7e89c3e9 ctx-fcfd86a0) Failed 
 to add data store: null



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


[jira] [Commented] (CLOUDSTACK-7099) Volume snapshot is not getting backed up

2014-07-11 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058679#comment-14058679
 ] 

ASF subversion and git services commented on CLOUDSTACK-7099:
-

Commit 00778de96eb9f47a34bac79dc5175d16d71df194 in cloudstack's branch 
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=00778de ]

CLOUDSTACK-7099. Volume snapshot is not getting backed up.
Correctly inject ConfigDao into SnapshotStateListener.


 Volume snapshot is not getting backed up
 

 Key: CLOUDSTACK-7099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7099
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Snapshot
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
 Fix For: 4.5.0


 While trying to snapshot a volume, the volume snapshot is not backed up and 
 it remains in 'Allocated' state.
 As a result of the fix made to resolve 
 [https://issues.apache.org/jira/browse/CLOUDSTACK-3272], ConfigDao is not 
 being injected into SnapshotStateListener which results in an NPE. And this 
 causes the snapshot process to fail .



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


[jira] [Resolved] (CLOUDSTACK-7099) Volume snapshot is not getting backed up

2014-07-11 Thread Likitha Shetty (JIRA)

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

Likitha Shetty resolved CLOUDSTACK-7099.


Resolution: Fixed

 Volume snapshot is not getting backed up
 

 Key: CLOUDSTACK-7099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7099
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Snapshot
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
 Fix For: 4.5.0


 While trying to snapshot a volume, the volume snapshot is not backed up and 
 it remains in 'Allocated' state.
 As a result of the fix made to resolve 
 [https://issues.apache.org/jira/browse/CLOUDSTACK-3272], ConfigDao is not 
 being injected into SnapshotStateListener which results in an NPE. And this 
 causes the snapshot process to fail .



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


[jira] [Resolved] (CLOUDSTACK-7082) [Automation] System vm are not getting created in Xen

2014-07-11 Thread Koushik Das (JIRA)

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

Koushik Das resolved CLOUDSTACK-7082.
-

Resolution: Duplicate

 [Automation] System vm are not getting created in Xen 
 --

 Key: CLOUDSTACK-7082
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7082
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Xen
Affects Versions: 4.5.0
 Environment: Xen
 Build 4.4 / master 
Reporter: Rayees Namathponnan
Assignee: Koushik Das
Priority: Blocker
 Fix For: 4.5.0

 Attachments: management-server_CLOUDSTACK-7082.rar


 Create advanced zone in Xen with 4.5 build. SSVM and CPVM failed to create, 
 observed below error in MS log, also attached full log
 2014-07-08 10:13:32,271 DEBUG [c.c.s.ConfigurationServerImpl] (main:null) 
 Caught SQLException when inserting system user: Duplicate entry '1' for key 
 'PRIMARY'
 2014-07-08 10:13:32,271 DEBUG [c.c.s.ConfigurationServerImpl] (main:null) 
 Caught SQLException when creating admin account: Duplicate entry '2' for key 
 'PRIMARY'
 2014-07-08 10:13:32,272 DEBUG [c.c.s.ConfigurationServerImpl] (main:null) 
 Caught SQLException when inserting admin user: Duplicate entry '2' for key 
 'PRIMARY'
 2014-07-08 10:13:32,273 DEBUG [c.c.s.ConfigurationServerImpl] (main:null) 
 Caught (SQL?)Exception: no network_group  Table 'cloud.network_group' doesn't 
 exist
 java.io.IOException: Fail to generate certificate!: sudo: no tty present and 
 no askpass program specified
 2014-07-08 10:13:51,450 WARN  [c.c.c.d.ManagementServerHostDaoImpl] 
 (Cluster-Heartbeat-1:ctx-b1344ab9) update:Exception:Invalid cluster session 
 detected
 com.cloud.utils.exception.CloudRuntimeException: Invalid cluster session 
 detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 java.lang.RuntimeException: update:Exception:Invalid cluster session detected
 Caused by: com.cloud.utils.exception.CloudRuntimeException: Invalid cluster 
 session detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 2014-07-08 10:13:52,854 WARN  [c.c.c.d.ManagementServerHostDaoImpl] 
 (Cluster-Heartbeat-1:ctx-32db3a37) update:Exception:Invalid cluster session 
 detected
 com.cloud.utils.exception.CloudRuntimeException: Invalid cluster session 
 detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 java.lang.RuntimeException: update:Exception:Invalid cluster session detected
 Caused by: com.cloud.utils.exception.CloudRuntimeException: Invalid cluster 
 session detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 2014-07-08 10:13:54,354 WARN  [c.c.c.d.ManagementServerHostDaoImpl] 
 (Cluster-Heartbeat-1:ctx-bc4d14ae) update:Exception:Invalid cluster session 
 detected
 com.cloud.utils.exception.CloudRuntimeException: Invalid cluster session 
 detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid
 java.lang.RuntimeException: update:Exception:Invalid cluster session detected
 Caused by: com.cloud.utils.exception.CloudRuntimeException: Invalid cluster 
 session detected
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404814404734 is no longer valid



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


[jira] [Commented] (CLOUDSTACK-5800) While creating a VM from template (which is created based on existing newly created vm) getting error as Unable to deploy vm base on template due to of insufficie

2014-07-11 Thread Mandar Barve (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058692#comment-14058692
 ] 

Mandar Barve commented on CLOUDSTACK-5800:
--

Here is what I tried:

1. Started a VM from an existing ISO
2. Created a template from the VM
3. Started a new instance based on the created template
4. VM was created fine.

Tried this twice and couldn't reproduce the problem. I tried this with master 
code 4.5

 While creating a VM from template (which is created based on existing newly 
 created  vm) getting error as Unable to deploy vm base on template due to of 
 insufficient server capicity
 -

 Key: CLOUDSTACK-5800
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5800
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Template
Affects Versions: 4.3.0
 Environment: CENTOS 6.4,WIN2012,ACS 4.3.0,
Reporter: rashid
 Fix For: 4.4.0


 While creating a vm from template 
 INFO  [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-5:ctx-c259052d) Add job-46 
 into job monitoring
 INFO  [o.a.c.s.v.VolumeServiceImpl] (Job-Executor-5:ctx-c259052d 
 ctx-506ea49e) lock is acquired for VMTemplateStoragePool 7
 WARN  [o.a.c.alerts] (CapacityChecker:ctx-374c70b5)  alertType:: 24 // 
 dataCenterId:: 1 // podId:: null // clusterId:: null // message:: System 
 Alert: Number of unallocated shared network IPs is low in availability zone 
 NEWZONE
 WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-45) has 
 been pending for 104 seconds
 WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-46) has 
 been pending for 103 seconds
 WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-45) has 
 been pending for 164 seconds
 WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-46) has 
 been pending for 163 seconds
 WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) 
 destoryVDIbyNameLabel failed due to there are 0 VDIs with name 
 cloud-377c12f4-a8e9-491a-8cba-34b9532455f8
 WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) 
 failed to set hidden to 0  
 /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
 WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) 
 Catch Exception com.cloud.utils.exception.CloudRuntimeException for template 
 +  due to com.cloud.utils.exception.CloudRuntimeException: failed to set 
 hidden to 0  
 /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
 com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0  
 /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
 at 
 com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:858)
 at 
 com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:928)
 at 
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75)
 at 
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:609)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 

[jira] [Commented] (CLOUDSTACK-7051) [Automation] Failed to create SSVM and CPVM in KVM,

2014-07-11 Thread Sudha Ponnaganti (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058710#comment-14058710
 ] 

Sudha Ponnaganti commented on CLOUDSTACK-7051:
--

Any update n this ticket. 

 [Automation] Failed to create SSVM and CPVM in KVM, 
 

 Key: CLOUDSTACK-7051
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7051
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
 Environment: RHEL : 6.3
 build : 4.5
Reporter: Rayees Namathponnan
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.5.0

 Attachments: agent.rar, management-server.rar


 SSVM and CPVM not creating with latest 4.5 build,  copy command failing form 
 agent  observed below error in agent log, 
 2014-07-02 16:14:58,170 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Execution is successful.
 2014-07-02 16:14:58,171 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Formatting '/mnt/4f3ad80a-b7
 96-3db3-b126-9c12b5b5eafc/48ef9a74-0244-11e4-b040-1a6f7bb0d0a8', fmt=qcow2 
 size=262144 encryption=off clus
 ter_size=65536 preallocation='off'
 2014-07-02 16:14:58,171 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Executing: qemu-img info --o
 utput json 
 /mnt/4f3ad80a-b796-3db3-b126-9c12b5b5eafc/48ef9a74-0244-11e4-b040-1a6f7bb0d0a8
 2014-07-02 16:14:58,173 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Exit value is 1
 2014-07-02 16:14:58,173 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) info: invalid option -- '-'q
 emu-img version 0.12.1, Copyright (c) 2004-2008 Fabrice Bellardusage: 
 qemu-img command [command options]QEMU d
 isk image utilityCommand syntax:  check [-f fmt] filename  create [-f fmt] 
 [-o options] filename [size]  commi
 t [-f fmt] [-t cache] filename  convert [-c] [-p] [-f fmt] [-t cache] [-O 
 output_fmt] [-o options] [-S sparse_
 size] filename [filename2 [...]] output_filename  info [-f fmt] filename  
 snapshot [-l | -a snapshot | -c snap
 shot | -d snapshot] filename  rebase [-f fmt] [-t cache] [-p] [-u] -b 
 backing_file [-F backing_fmt] filename
 resize filename [+ | -]sizeCommand parameters:  'filename' is a disk image 
 filename  'fmt' is the disk image f
 ormat. It is guessed automatically in most cases  'cache' is the cache mode 
 used to write the output disk imag
 e, the validoptions are: 'none', 'writeback' (default), 'writethrough' 
 and 'unsafe'  'size' is the disk im
 age size in bytes. Optional suffixes'k' or 'K' (kilobyte, 1024), 'M' 
 (megabyte, 1024k), 'G' (gigabyte, 102
 4M)and T (terabyte, 1024G) are supported. 'b' is ignored.  
 'output_filename' is the destination disk image
  filename  'output_fmt' is the destination format  'options' is a comma 
 separated list of format specific opti
 ons in aname=value format. Use -o ? for an overview of the options 
 supported by theused format  '-c' i
 ndicates that target image must be compressed (qcow format only)  '-u' 
 enables unsafe rebasing. It is assumed
 that old and new backing file   match exactly. The image doesn't need a 
 working backing file before
 rebasing in this case (useful for renaming the backing file)  '-h' with or 
 without a command shows this help a
 nd lists the supported formats  '-p' show progress of command (only certain 
 commands)  '-S' indicates the cons
 ecutive number of bytes that must contain only zeros   for qemu-img to 
 create a sparse image during conver
 sionParameters to snapshot subcommand:  'snapshot' is the name of the 
 snapshot to create, apply or delete  '-a
 ' applies a snapshot (revert disk to saved state)  '-c' creates a snapshot  
 '-d' deletes a snapshot  '-l' lists all snapshots in the given imageSupported 
 formats: raw cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 qed parallels 
 nbd blkdebug host_cdrom host_floppy host_device file



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


[jira] [Comment Edited] (CLOUDSTACK-6036) CloudStack stops the machine for no reason

2014-07-11 Thread Daan Hoogland (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058733#comment-14058733
 ] 

Daan Hoogland edited comment on CLOUDSTACK-6036 at 7/11/14 1:00 PM:


Damodar, can you comment on the status of this issue? It gets a minus one to 
the 4.4.0 release


was (Author: dahn):
Damodar, can you comment on the status of this issue?

  CloudStack stops the machine for no reason
 ---

 Key: CLOUDSTACK-6036
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.1
 Environment: ACS 4.2.1 after upgrade from 3.0.2
 ACS 4.2.1 clean install
 XCP 1.1
Reporter: Tomasz Zieba
Assignee: Damodar Reddy T
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.log.2014-02-19.gz, 
 management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt


 After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error 
 associated with self-stopping machine after changing the offering. 
 Steps to reproduce: 
 1. Running instance of the machine 
 2. Stop with the operating system 
 3. Change offering of machine
 4. Start the machine 
 5. Waiting for 10 minutes 
 6. CloudStack stops the machine for no reason
 7. Restart the machine 
 In the logs you can find information:
 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request] 
 (DirectAgent-316:null) Seq 50-1756626952: Processing:  { Ans: , MgmtId: 
 160544475005497, via: 50, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:2,_newStates:{i-41-824-VM:{t:f32a4fee-b64e-4868-9c52-2a27e32d4c0e,u:Running,v:viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4}},_isExecuted:false,result:true,wait:0}}]
  }
 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState = 
 Running
 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState = 
 Running
 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] 
 (HA-Worker-1:work-1511) Seq 51-1374970375: Sending  { Cmd , MgmtId: 
 160544475005497, via: 51, Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:i-41-824-VM,wait:0}}]
  }
 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] 
 (HA-Worker-1:work-1511) Seq 51-1374970375: Executing:  { Cmd , MgmtId: 
 160544475005497, via: 51, Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:i-41-824-VM,wait:0}}]
  }
 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
 You will notice that the stop of the machine corresponds to the component 
 HA-Worker. 
 Such operation after the upgrade is complicating work of users.



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


[jira] [Commented] (CLOUDSTACK-6036) CloudStack stops the machine for no reason

2014-07-11 Thread Daan Hoogland (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058733#comment-14058733
 ] 

Daan Hoogland commented on CLOUDSTACK-6036:
---

Damodar, can you comment on the status of this issue?

  CloudStack stops the machine for no reason
 ---

 Key: CLOUDSTACK-6036
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.1
 Environment: ACS 4.2.1 after upgrade from 3.0.2
 ACS 4.2.1 clean install
 XCP 1.1
Reporter: Tomasz Zieba
Assignee: Damodar Reddy T
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.log.2014-02-19.gz, 
 management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt


 After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error 
 associated with self-stopping machine after changing the offering. 
 Steps to reproduce: 
 1. Running instance of the machine 
 2. Stop with the operating system 
 3. Change offering of machine
 4. Start the machine 
 5. Waiting for 10 minutes 
 6. CloudStack stops the machine for no reason
 7. Restart the machine 
 In the logs you can find information:
 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request] 
 (DirectAgent-316:null) Seq 50-1756626952: Processing:  { Ans: , MgmtId: 
 160544475005497, via: 50, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:2,_newStates:{i-41-824-VM:{t:f32a4fee-b64e-4868-9c52-2a27e32d4c0e,u:Running,v:viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4}},_isExecuted:false,result:true,wait:0}}]
  }
 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState = 
 Running
 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState = 
 Running
 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] 
 (HA-Worker-1:work-1511) Seq 51-1374970375: Sending  { Cmd , MgmtId: 
 160544475005497, via: 51, Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:i-41-824-VM,wait:0}}]
  }
 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] 
 (HA-Worker-1:work-1511) Seq 51-1374970375: Executing:  { Cmd , MgmtId: 
 160544475005497, via: 51, Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:i-41-824-VM,wait:0}}]
  }
 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
 You will notice that the stop of the machine corresponds to the component 
 HA-Worker. 
 Such operation after the upgrade is complicating work of users.



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


[jira] [Commented] (CLOUDSTACK-6036) CloudStack stops the machine for no reason

2014-07-11 Thread Damodar Reddy T (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058744#comment-14058744
 ] 

Damodar Reddy T commented on CLOUDSTACK-6036:
-

I tried to look into the logs long back but I could not come to a conclusion, 
what is causing the issue for this. I will try to re look into the logs once 
again..

  CloudStack stops the machine for no reason
 ---

 Key: CLOUDSTACK-6036
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.1
 Environment: ACS 4.2.1 after upgrade from 3.0.2
 ACS 4.2.1 clean install
 XCP 1.1
Reporter: Tomasz Zieba
Assignee: Damodar Reddy T
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.log.2014-02-19.gz, 
 management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt


 After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error 
 associated with self-stopping machine after changing the offering. 
 Steps to reproduce: 
 1. Running instance of the machine 
 2. Stop with the operating system 
 3. Change offering of machine
 4. Start the machine 
 5. Waiting for 10 minutes 
 6. CloudStack stops the machine for no reason
 7. Restart the machine 
 In the logs you can find information:
 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request] 
 (DirectAgent-316:null) Seq 50-1756626952: Processing:  { Ans: , MgmtId: 
 160544475005497, via: 50, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:2,_newStates:{i-41-824-VM:{t:f32a4fee-b64e-4868-9c52-2a27e32d4c0e,u:Running,v:viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4}},_isExecuted:false,result:true,wait:0}}]
  }
 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState = 
 Running
 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState = 
 Running
 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] 
 (HA-Worker-1:work-1511) Seq 51-1374970375: Sending  { Cmd , MgmtId: 
 160544475005497, via: 51, Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:i-41-824-VM,wait:0}}]
  }
 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] 
 (HA-Worker-1:work-1511) Seq 51-1374970375: Executing:  { Cmd , MgmtId: 
 160544475005497, via: 51, Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:i-41-824-VM,wait:0}}]
  }
 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
 You will notice that the stop of the machine corresponds to the component 
 HA-Worker. 
 Such operation after the upgrade is complicating work of users.



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


[jira] [Commented] (CLOUDSTACK-6708) [Automation]: Few suites were failing on simulator run

2014-07-11 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058891#comment-14058891
 ] 

ASF subversion and git services commented on CLOUDSTACK-6708:
-

Commit aab6e1222fc75a37f8015ba1d2c7bc923c1cf614 in cloudstack's branch 
refs/heads/master from santhosh
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aab6e12 ]

Fixed Regression issues mentioned under CLOUDSTACK-6708

Signed-off-by: santhosh santhosh.eduku...@gmail.com

Conflicts:

test/integration/smoke/test_deploy_vm.py
test/integration/smoke/test_network.py
test/integration/smoke/test_routers.py
test/integration/smoke/test_vm_life_cycle.py


 [Automation]: Few suites were failing on simulator run
 --

 Key: CLOUDSTACK-6708
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6708
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Reporter: Santhosh Kumar Edukulla
Assignee: Santhosh Kumar Edukulla

 integration.smoke.test_deploy_vm.TestDeployVMStartFailure.test_deploy_vm_start_failure
 integration.smoke.test_hosts.TestHosts.test_01_clusters
 integration.smoke.test_network.TestDeleteAccount.test_delete_account
 integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account
 integration.smoke.test_network.TestReleaseIP.test_releaseIP
 integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_08_migrate_vm
 integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_09_expunge_vm



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


[jira] [Updated] (CLOUDSTACK-6191) Volume provisioning type option

2014-07-11 Thread Kishan Kavala (JIRA)

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

Kishan Kavala updated CLOUDSTACK-6191:
--

Priority: Blocker  (was: Minor)

 Volume provisioning type option
 ---

 Key: CLOUDSTACK-6191
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6191
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM, Management Server
Reporter: Yoshikazu Nojima
Assignee: Yoshikazu Nojima
Priority: Blocker
 Fix For: 4.5.0


 Thin provisioning of a volume saves consumption of a storage, and fat 
 provisioning minimizes IOPS performance overhead.
 This feature implements a global setting to provide users an option to select 
 how to provision volumes.
 Design doc:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Volume+provisioning+type+option



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


[jira] [Commented] (CLOUDSTACK-7051) [Automation] Failed to create SSVM and CPVM in KVM,

2014-07-11 Thread Kishan Kavala (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058899#comment-14058899
 ] 

Kishan Kavala commented on CLOUDSTACK-7051:
---

Issue is blocked by CLOUDSTACK-6191. Marked CLOUDSTACK-6191 as blocker

 [Automation] Failed to create SSVM and CPVM in KVM, 
 

 Key: CLOUDSTACK-7051
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7051
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
 Environment: RHEL : 6.3
 build : 4.5
Reporter: Rayees Namathponnan
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.5.0

 Attachments: agent.rar, management-server.rar


 SSVM and CPVM not creating with latest 4.5 build,  copy command failing form 
 agent  observed below error in agent log, 
 2014-07-02 16:14:58,170 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Execution is successful.
 2014-07-02 16:14:58,171 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Formatting '/mnt/4f3ad80a-b7
 96-3db3-b126-9c12b5b5eafc/48ef9a74-0244-11e4-b040-1a6f7bb0d0a8', fmt=qcow2 
 size=262144 encryption=off clus
 ter_size=65536 preallocation='off'
 2014-07-02 16:14:58,171 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Executing: qemu-img info --o
 utput json 
 /mnt/4f3ad80a-b796-3db3-b126-9c12b5b5eafc/48ef9a74-0244-11e4-b040-1a6f7bb0d0a8
 2014-07-02 16:14:58,173 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Exit value is 1
 2014-07-02 16:14:58,173 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) info: invalid option -- '-'q
 emu-img version 0.12.1, Copyright (c) 2004-2008 Fabrice Bellardusage: 
 qemu-img command [command options]QEMU d
 isk image utilityCommand syntax:  check [-f fmt] filename  create [-f fmt] 
 [-o options] filename [size]  commi
 t [-f fmt] [-t cache] filename  convert [-c] [-p] [-f fmt] [-t cache] [-O 
 output_fmt] [-o options] [-S sparse_
 size] filename [filename2 [...]] output_filename  info [-f fmt] filename  
 snapshot [-l | -a snapshot | -c snap
 shot | -d snapshot] filename  rebase [-f fmt] [-t cache] [-p] [-u] -b 
 backing_file [-F backing_fmt] filename
 resize filename [+ | -]sizeCommand parameters:  'filename' is a disk image 
 filename  'fmt' is the disk image f
 ormat. It is guessed automatically in most cases  'cache' is the cache mode 
 used to write the output disk imag
 e, the validoptions are: 'none', 'writeback' (default), 'writethrough' 
 and 'unsafe'  'size' is the disk im
 age size in bytes. Optional suffixes'k' or 'K' (kilobyte, 1024), 'M' 
 (megabyte, 1024k), 'G' (gigabyte, 102
 4M)and T (terabyte, 1024G) are supported. 'b' is ignored.  
 'output_filename' is the destination disk image
  filename  'output_fmt' is the destination format  'options' is a comma 
 separated list of format specific opti
 ons in aname=value format. Use -o ? for an overview of the options 
 supported by theused format  '-c' i
 ndicates that target image must be compressed (qcow format only)  '-u' 
 enables unsafe rebasing. It is assumed
 that old and new backing file   match exactly. The image doesn't need a 
 working backing file before
 rebasing in this case (useful for renaming the backing file)  '-h' with or 
 without a command shows this help a
 nd lists the supported formats  '-p' show progress of command (only certain 
 commands)  '-S' indicates the cons
 ecutive number of bytes that must contain only zeros   for qemu-img to 
 create a sparse image during conver
 sionParameters to snapshot subcommand:  'snapshot' is the name of the 
 snapshot to create, apply or delete  '-a
 ' applies a snapshot (revert disk to saved state)  '-c' creates a snapshot  
 '-d' deletes a snapshot  '-l' lists all snapshots in the given imageSupported 
 formats: raw cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 qed parallels 
 nbd blkdebug host_cdrom host_floppy host_device file



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


[jira] [Updated] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere

2014-07-11 Thread Stephen Turner (JIRA)

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

Stephen Turner updated CLOUDSTACK-4787:
---

Priority: Critical  (was: Blocker)

 Allow selection of scsi controller type in vSphere
 --

 Key: CLOUDSTACK-4787
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, UI, VMware
Affects Versions: 4.2.0, 4.3.0
 Environment: vSphere 5.1
Reporter: Chris Sciarrino
Assignee: Sateesh Chodapuneedi
Priority: Critical
 Fix For: Future


 When adding an OVA template for a vSphere environment allow the selection of 
 the scsi controller type. 
 Currently the instances are deployed with the the LSI Parallel controller 
 type. This results in a blue screen on boot when attempting to deploy 
 templates that use the LSI SAS controller.



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


[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere

2014-07-11 Thread Stephen Turner (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058937#comment-14058937
 ] 

Stephen Turner commented on CLOUDSTACK-4787:


This seems to have turned into a New Feature, so I have updated the ticket 
metadata.

 Allow selection of scsi controller type in vSphere
 --

 Key: CLOUDSTACK-4787
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, UI, VMware
Affects Versions: 4.2.0, 4.3.0
 Environment: vSphere 5.1
Reporter: Chris Sciarrino
Assignee: Sateesh Chodapuneedi
Priority: Critical
 Fix For: Future


 When adding an OVA template for a vSphere environment allow the selection of 
 the scsi controller type. 
 Currently the instances are deployed with the the LSI Parallel controller 
 type. This results in a blue screen on boot when attempting to deploy 
 templates that use the LSI SAS controller.



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


[jira] [Comment Edited] (CLOUDSTACK-7070) Continuous Error messages Invalid cluster session detected in MS logs after starting the management server

2014-07-11 Thread Santhosh Kumar Edukulla (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058409#comment-14058409
 ] 

Santhosh Kumar Edukulla edited comment on CLOUDSTACK-7070 at 7/11/14 5:26 PM:
--

There was an issue where TransactionLegacy interface when closed,  has got some 
issues. We reverted the changes done to one such file 
ManagementHostDaoImpl.java and tested, now issue is no longer reproducible. 
Please check the mail on devlist.

Commitid for revert: 1f3d02b38acbd269a65e2a9b0a1d0233b69a7598


was (Author: santhoshe):
There was an issue where TransactionLegacy interface used has got some issues 
because of recent fixes. We reverted the changes done to one such class 
ManagementHostDaoImpl.java and tested, issue is no longer reproducible. Please 
check the mail on devlist.

 Continuous Error messages Invalid cluster session detected in MS logs after 
 starting the management server
 

 Key: CLOUDSTACK-7070
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7070
 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: manasaveloori
Assignee: Santhosh Kumar Edukulla
Priority: Blocker
 Attachments: management-server.rar


 Observed DB exception in logs which is mentioned in bug CLOUDSTACK-7041 
 After this DB exception observing the follwoing continuous ERROR  messages in 
 logs:
 2014-07-07 15:14:40,043 WARN  [c.c.c.d.ManagementServerHostDaoImpl] 
 (Cluster-Heartbeat-1:ctx-49fa7a77) update:Exception:Invalid cluster session 
 detected
 com.cloud.utils.exception.CloudRuntimeException: Invalid cluster session 
 detected
 at 
 com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:147)
 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 
 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.$Proxy150.update(Unknown Source)
 at 
 com.cloud.cluster.ClusterManagerImpl$4.runInContext(ClusterManagerImpl.java:545)
 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.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 Caused by: com.cloud.cluster.ClusterInvalidSessionException: runid 
 1404760440284 is no longer valid
 at 
 

[jira] [Updated] (CLOUDSTACK-7023) [Automation] DeleteTagsCmd failed due to Unable to find tags by parameters specified

2014-07-11 Thread Animesh Chaturvedi (JIRA)

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

Animesh Chaturvedi updated CLOUDSTACK-7023:
---

Assignee: Alena Prokharchyk  (was: Prachi Damle)

 [Automation] DeleteTagsCmd failed due to Unable to find tags by parameters 
 specified
 --

 Key: CLOUDSTACK-7023
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7023
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Assignee: Alena Prokharchyk
 Fix For: 4.4.0, 4.5.0


 ==
 Test Script Code:
 ==
 def test_07_iso_tag(self):
  Test creation, listing and deletion tags on ISO
 
 # Validate the following
 # 1. Create  a tag on ISO using createTags API
 # 2. Delete above created tag using deleteTags API
 iso = Iso.create(
  self.apiclient,
  self.services[iso],
  account=self.account.name,
  domainid=self.account.domainid
  )
 self.debug(ISO created with ID: %s % iso.id)
 list_iso_response = Iso.list(self.apiclient,
  id=iso.id)
 self.assertEqual(
  isinstance(list_iso_response, list),
  True,
  Check list response returns a valid list
  )
 self.debug(Creating a tag for the ISO)
 tag = Tag.create(
  self.apiclient,
  resourceIds=iso.id,
  resourceType='ISO',
  tags={'OS': 'CentOS'}
  )
 self.debug(Tag created: %s % tag.__dict__)
 tags = Tag.list(
 self.apiclient,
 listall=True,
 resourceType='ISO',
 account=self.account.name,
 domainid=self.account.domainid,
 key='OS',
 value='CentOS'
 )
 self.assertEqual(
  isinstance(tags, list),
  True,
  List tags should not return empty response
  )
 self.assertEqual(
  tags[0].value,
  'CentOS',
  'The tag should have original value'
  )
 isos = Iso.list(
 self.apiclient,
 key='OS',
 value='CentOS',
 account=self.account.name,
 domainid=self.account.domainid,
 isofilter='all'
 )
 self.assertEqual(
  isinstance(isos, list),
  True,
  List isos should not return an empty response
  )
 self.debug(Deleting the created tag..)
 try:
 tag.delete(
self.apiclient,
resourceIds=iso.id,
resourceType='ISO',
tags={'OS': 'CentOS'}
)
 except Exception as e:
 self.fail(Failed to delete the tag - %s % e)
 self.debug(Verifying if tag is actually deleted!)
 tags = Tag.list(
 self.apiclient,
 listall=True,
 resourceType='ISO',
 account=self.account.name,
 domainid=self.account.domainid,
 key='OS',
 value='CentOS'
 )
 self.assertEqual(
  tags,
  None,
  List tags should return empty response
  )
 return
 ===
 Unable to find tags by parameters specified:
 ===
 test_07_iso_tag (integration.component.test_tags.TestResourceTags): DEBUG: 
 Payload: {'account': u'test-TestResourceTags-BQG75M', 'domainid': 
 u'36c9d3ba-fc58-11e3-919f-4eba41a459a4', 'name': 'Dummy ISO', 'ispublic': 
 False, 'isextractable': True, 'zoneid': 
 u'89d23f5c-c768-4fb0-80aa-f970a6f2d70b', 'isfeatured': True, 'apiKey': 
 u'Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q',
  

[jira] [Updated] (CLOUDSTACK-7023) [Automation] DeleteTagsCmd failed due to Unable to find tags by parameters specified

2014-07-11 Thread Animesh Chaturvedi (JIRA)

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

Animesh Chaturvedi updated CLOUDSTACK-7023:
---

Fix Version/s: 4.5.0

 [Automation] DeleteTagsCmd failed due to Unable to find tags by parameters 
 specified
 --

 Key: CLOUDSTACK-7023
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7023
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Assignee: Alena Prokharchyk
 Fix For: 4.4.0, 4.5.0


 ==
 Test Script Code:
 ==
 def test_07_iso_tag(self):
  Test creation, listing and deletion tags on ISO
 
 # Validate the following
 # 1. Create  a tag on ISO using createTags API
 # 2. Delete above created tag using deleteTags API
 iso = Iso.create(
  self.apiclient,
  self.services[iso],
  account=self.account.name,
  domainid=self.account.domainid
  )
 self.debug(ISO created with ID: %s % iso.id)
 list_iso_response = Iso.list(self.apiclient,
  id=iso.id)
 self.assertEqual(
  isinstance(list_iso_response, list),
  True,
  Check list response returns a valid list
  )
 self.debug(Creating a tag for the ISO)
 tag = Tag.create(
  self.apiclient,
  resourceIds=iso.id,
  resourceType='ISO',
  tags={'OS': 'CentOS'}
  )
 self.debug(Tag created: %s % tag.__dict__)
 tags = Tag.list(
 self.apiclient,
 listall=True,
 resourceType='ISO',
 account=self.account.name,
 domainid=self.account.domainid,
 key='OS',
 value='CentOS'
 )
 self.assertEqual(
  isinstance(tags, list),
  True,
  List tags should not return empty response
  )
 self.assertEqual(
  tags[0].value,
  'CentOS',
  'The tag should have original value'
  )
 isos = Iso.list(
 self.apiclient,
 key='OS',
 value='CentOS',
 account=self.account.name,
 domainid=self.account.domainid,
 isofilter='all'
 )
 self.assertEqual(
  isinstance(isos, list),
  True,
  List isos should not return an empty response
  )
 self.debug(Deleting the created tag..)
 try:
 tag.delete(
self.apiclient,
resourceIds=iso.id,
resourceType='ISO',
tags={'OS': 'CentOS'}
)
 except Exception as e:
 self.fail(Failed to delete the tag - %s % e)
 self.debug(Verifying if tag is actually deleted!)
 tags = Tag.list(
 self.apiclient,
 listall=True,
 resourceType='ISO',
 account=self.account.name,
 domainid=self.account.domainid,
 key='OS',
 value='CentOS'
 )
 self.assertEqual(
  tags,
  None,
  List tags should return empty response
  )
 return
 ===
 Unable to find tags by parameters specified:
 ===
 test_07_iso_tag (integration.component.test_tags.TestResourceTags): DEBUG: 
 Payload: {'account': u'test-TestResourceTags-BQG75M', 'domainid': 
 u'36c9d3ba-fc58-11e3-919f-4eba41a459a4', 'name': 'Dummy ISO', 'ispublic': 
 False, 'isextractable': True, 'zoneid': 
 u'89d23f5c-c768-4fb0-80aa-f970a6f2d70b', 'isfeatured': True, 'apiKey': 
 u'Sng6IriYYMri4AHzMZOEdseGWMJBZ-mfmhG30ZJIjV__AynsK03iV0GbvMzhglLVIff8W5ujp6gnTEdNS7LJ5Q',
  'displaytext': 'Dummy ISO', 

[jira] [Resolved] (CLOUDSTACK-7023) [Automation] DeleteTagsCmd failed due to Unable to find tags by parameters specified

2014-07-11 Thread Alena Prokharchyk (JIRA)

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

Alena Prokharchyk resolved CLOUDSTACK-7023.
---

Resolution: Cannot Reproduce

Chandan, I can't reproduce the problem. Please check the sequence of commands 
that your script calls. I can see that the listResourceTags calls the command 
on the ISO with the id different from what you specify in 
createResourceTag/deleteResourceTag.  Also check if there can be any command 
that runs in parallel removing the tag.

Here are the steps I've taken to reproduce the problem:

1) Created the tag with the same name/value as in your scenario:

resourcetype=ISOresourceIds=200command=createTagstags%5B0%5D.key=OSresponse=jsontags%5B0%5D.value=CentOS

mysql select * from resource_tags;
++--+--++-+--+---+--+---++
| id | uuid | key  | value  | resource_id | 
resource_uuid| resource_type | customer | domain_id | 
account_id |
++--+--++-+--+---+--+---++
|  1 | 047c1818-b30e-491c-8f70-a9b9b5fca4ea | OS   | CentOS | 200 | 
f635ea63-913b-4597-80e2-fea64e6a5ce6 | ISO   | NULL | 1 |   
   1 |
++--+--++-+--+---+--+---++
1 row in set (0.01 sec)

2) Deleted the resource tag using the command you've specified in your script: 

resourcetype=ISOresourceIds=200command=deleteTagstags%5B0%5D.key=OSresponse=jsontags%5B0%5D.value=CentOS


queryasyncjobresultresponse cloud-stack-version=4.4.0-SNAPSHOT
accountid2b9eb92a-092c-11e4-aa4b-21b62cb8174b/accountid
userid2b9ed6b2-092c-11e4-aa4b-21b62cb8174b/userid
cmd
org.apache.cloudstack.api.command.user.tag.DeleteTagsCmd
/cmd
jobstatus1/jobstatus
jobprocstatus0/jobprocstatus
jobresultcode0/jobresultcode
jobresulttypeobject/jobresulttype
jobresult
successtrue/success
/jobresult
created2014-07-11T11:56:21-0700/created
jobid86978438-d306-4d3f-a0f0-52ba0bcb4f5a/jobid
/queryasyncjobresultresponse

Tag is removed from the DB:

mysql select * from resource_tags;
Empty set (0.00 sec)

 [Automation] DeleteTagsCmd failed due to Unable to find tags by parameters 
 specified
 --

 Key: CLOUDSTACK-7023
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7023
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Assignee: Alena Prokharchyk
 Fix For: 4.4.0, 4.5.0


 ==
 Test Script Code:
 ==
 def test_07_iso_tag(self):
  Test creation, listing and deletion tags on ISO
 
 # Validate the following
 # 1. Create  a tag on ISO using createTags API
 # 2. Delete above created tag using deleteTags API
 iso = Iso.create(
  self.apiclient,
  self.services[iso],
  account=self.account.name,
  domainid=self.account.domainid
  )
 self.debug(ISO created with ID: %s % iso.id)
 list_iso_response = Iso.list(self.apiclient,
  id=iso.id)
 self.assertEqual(
  isinstance(list_iso_response, list),
  True,
  Check list response returns a valid list
  )
 self.debug(Creating a tag for the ISO)
 tag = Tag.create(
  self.apiclient,
  resourceIds=iso.id,
  resourceType='ISO',
  tags={'OS': 'CentOS'}
  )
 self.debug(Tag created: %s % tag.__dict__)
 tags = Tag.list(
 self.apiclient,
 listall=True,
 resourceType='ISO',
 account=self.account.name,
 domainid=self.account.domainid,
 key='OS',
 value='CentOS'
 )
 self.assertEqual(
  isinstance(tags, list),
  True,
  List tags should not return empty response
  )
 self.assertEqual(
  

[jira] [Resolved] (CLOUDSTACK-7074) [Automation] [BVT] test_01_primary_storage_nfs failing during PreparePrimaryStorageForMaintenanceCmd

2014-07-11 Thread edison su (JIRA)

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

edison su resolved CLOUDSTACK-7074.
---

Resolution: Not a Problem

It's bug in test case:
One test case adds a primary storage, while another test case tries to create a 
vm right after the primary storage added, unfortunately, management server 
chooses this newly added primary storage to create the vm, then the test case 
tries to delete primary storage fails, due to other vm is using the primary 
storage.

The proper fix for the primary storage test case is that, add a primary storage 
with a tag, so mgt server won't choose the newly added primary storage to 
create vms.

 [Automation] [BVT] test_01_primary_storage_nfs failing during 
 PreparePrimaryStorageForMaintenanceCmd
 

 Key: CLOUDSTACK-7074
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7074
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Simulator
Affects Versions: 4.5.0
 Environment: Master - 4.5 build
 BVT run from simulator 
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Blocker
 Fix For: 4.5.0

 Attachments: vmops.rar


 Steps to reproduce 
 Run BVT from simulator, test case 
 integration.smoke.test_primary_storage.TestPrimaryStorageServices.test_01_primary_storage_nfs
  fails with below error 
 2014-07-06 23:17:10,745 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-124:ctx-fedceda0 job-223) Executing AsyncJobVO {id:223, use
 rId: 2, accountId: 2, instanceType: StoragePool, instanceId: 4, cmd: 
 org.apache.cloudstack.api.command.admin.storage.PreparePrimaryStorageFor
 MaintenanceCmd, cmdInfo: 
 {response:json,id:54e824e0-8431-3e45-b35d-a4f9b547df56,ctxDetails:{\com.cloud.storage.StoragePool\:\54
 e824e0-8431-3e45-b35d-a4f9b547df56\},cmdEventType:MAINT.PREPARE.PS,ctxUserId:2,httpmethod:GET,uuid:54e824e0-8431-3e45-b35d-a
 4f9b547df56,ctxAccountId:2,ctxStartEventId:720,apiKey:XhIrLnYTF-2c2uBt22f_kAbgMMuKDbHrjPyLKSOca9k5o08kGxZiiFVG-m637OyA71QLs9MRgbK
 2twbtvYcQNg,signature:6Ppi5k2c5/wYcs3i4XmPDq1SWGc\u003d}, cmdVersion: 0, 
 status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: n
 ull, initMsid: 95530185772, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-07-06 23:17:10,746 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
 (Work-Job-Executor-72:ctx-01201e17 job-221/job-222 ctx-68ee52cf) Deployme
 ntPlanner allocation algorithm: com.cloud.deploy.FirstFitPlanner@2553e6
 2014-07-06 23:17:10,746 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
 (Work-Job-Executor-72:ctx-01201e17 job-221/job-222 ctx-68ee52cf) Trying t
 o allocate a host and storage pools from dc:1, pod:null,cluster:null, 
 requested cpu: 500, requested ram: 134217728
 2014-07-06 23:17:10,746 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
 (Work-Job-Executor-72:ctx-01201e17 job-221/job-222 ctx-68ee52cf) Is ROOT
 volume READY (pool already allocated)?: No
 2014-07-06 23:17:10,746 DEBUG [c.c.d.FirstFitPlanner] 
 (Work-Job-Executor-72:ctx-01201e17 job-221/job-222 ctx-68ee52cf) Searching 
 all possible
  resources under this Zone: 1
 2014-07-06 23:17:10,747 DEBUG [c.c.d.FirstFitPlanner] 
 (Work-Job-Executor-72:ctx-01201e17 job-221/job-222 ctx-68ee52cf) Listing 
 clusters in or
 der of aggregate capacity, that have (atleast one host with) enough CPU and 
 RAM capacity under this Zone: 1
 2014-07-06 23:17:10,749 DEBUG [c.c.a.ApiServlet] 
 (1061680681@qtp-1957555412-3:ctx-d0db1f98) ===START===  172.16.88.7 -- GET  
 jobid=6c848209-6
 f65-41cb-b80a-c62c32bce55dapiKey=XhIrLnYTF-2c2uBt22f_kAbgMMuKDbHrjPyLKSOca9k5o08kGxZiiFVG-m637OyA71QLs9MRgbK2twbtvYcQNgcommand=queryAsyncJo
 bResultresponse=jsonsignature=sxMFd6BpPKZJpsDRjRAZHif1w30%3D
 2014-07-06 23:17:10,762 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-124:ctx-fedceda0 job-223) Unexpected exception while 
 executing
 org.apache.cloudstack.api.command.admin.storage.PreparePrimaryStorageForMaintenanceCmd
 com.cloud.exception.InvalidParameterValueException: Primary storage with id 4 
 is not ready for migration, as the status is:Maintenance
 at 
 com.cloud.storage.StorageManagerImpl.preparePrimaryStorageForMaintenance(StorageManagerImpl.java:1221)
 at 
 com.cloud.storage.StorageManagerImpl.preparePrimaryStorageForMaintenance(StorageManagerImpl.java:179)
 at 
 org.apache.cloudstack.api.command.admin.storage.PreparePrimaryStorageForMaintenanceCmd.execute(PreparePrimaryStorageForMaintenance
 Cmd.java:103)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 

[jira] [Commented] (CLOUDSTACK-6191) Volume provisioning type option

2014-07-11 Thread edison su (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059388#comment-14059388
 ] 

edison su commented on CLOUDSTACK-6191:
---

I didn't realize it's a huge patch, to just add an option, specific to KVM 
volume creation. From a user point of view, I doubt anybody care about how the 
disk is created, we'd better not expose implementation detail to end users.
I would suggest, add a new option(like: qcow2.provision=flat/sparse/thin etc) 
in kvm agent.properties, to give admin an opportunity to optimize the volume 
creation. Is it OK for everybody?

 Volume provisioning type option
 ---

 Key: CLOUDSTACK-6191
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6191
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM, Management Server
Reporter: Yoshikazu Nojima
Assignee: Yoshikazu Nojima
Priority: Blocker
 Fix For: 4.5.0


 Thin provisioning of a volume saves consumption of a storage, and fat 
 provisioning minimizes IOPS performance overhead.
 This feature implements a global setting to provide users an option to select 
 how to provision volumes.
 Design doc:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Volume+provisioning+type+option



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


[jira] [Commented] (CLOUDSTACK-6191) Volume provisioning type option

2014-07-11 Thread Yoshikazu Nojima (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059425#comment-14059425
 ] 

Yoshikazu Nojima commented on CLOUDSTACK-6191:
--

The details are not exposed to end users. What end users can do is just select 
predefined compute offering or disk offering.
If we implement the option in agent.properties, CloudStack operator cannot use 
thin provisioned volume and fat provisioned volume at the same time.

 Volume provisioning type option
 ---

 Key: CLOUDSTACK-6191
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6191
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM, Management Server
Reporter: Yoshikazu Nojima
Assignee: Yoshikazu Nojima
Priority: Blocker
 Fix For: 4.5.0


 Thin provisioning of a volume saves consumption of a storage, and fat 
 provisioning minimizes IOPS performance overhead.
 This feature implements a global setting to provide users an option to select 
 how to provision volumes.
 Design doc:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Volume+provisioning+type+option



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


[jira] [Created] (CLOUDSTACK-7100) https://issues.citrite.net/browse/CS-15789

2014-07-11 Thread Alena Prokharchyk (JIRA)
Alena Prokharchyk created CLOUDSTACK-7100:
-

 Summary: https://issues.citrite.net/browse/CS-15789
 Key: CLOUDSTACK-7100
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7100
 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: Alena Prokharchyk
Assignee: Alena Prokharchyk
 Fix For: 4.5.0


Steps to reproduce:
1. configure the global setting project.invite.timeout to 300space 
2. restart management server
Expected result:
1. Management server should restart correctly (it may ignore the invalid value 
configured and throw a warning and set the value to default)
Actual result:
2012-08-01 09:53:26,982 INFO [cloud.consoleproxy.ConsoleProxyManagerImpl] 
(main:null) Console Proxy Manager is configured.
2012-08-01 09:53:26,982 INFO [utils.component.ComponentLocator] (main:null) 
Configuring singleton Manager: ProjectManager
2012-08-01 09:53:26,982 ERROR [utils.component.ComponentLocator] (main:null) 
Unable to load configuration for management-server from components.xml
java.lang.NumberFormatException: For input string: 300 
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:438)
at java.lang.Long.valueOf(Long.java:535)
at com.cloud.projects.ProjectManagerImpl.configure(ProjectManagerImpl.java:130)
at 
com.cloud.utils.component.ComponentLocator.configureManagers(ComponentLocator.java:422)
at com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:213)
at 
com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:790)
at 
com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:828)
at com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4496)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
(Thread-5:null) Skippng ClusterService because it has already stopped
2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
(Thread-5:null) Skippng BasicAgentAuthorizer because it has already stopped
2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
(Thread-5:null) Skippng XenServerGuru because it has already stopped
2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
(Thread-5:null) Skippng KVMGuru because it has already stopped



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


[jira] [Updated] (CLOUDSTACK-7100) Invalid Global setting is preventing management servert to restart

2014-07-11 Thread Alena Prokharchyk (JIRA)

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

Alena Prokharchyk updated CLOUDSTACK-7100:
--

Summary: Invalid Global setting is preventing management servert to restart 
 (was: https://issues.citrite.net/browse/CS-15789)

 Invalid Global setting is preventing management servert to restart
 --

 Key: CLOUDSTACK-7100
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7100
 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: Alena Prokharchyk
Assignee: Alena Prokharchyk
 Fix For: 4.5.0


 Steps to reproduce:
 1. configure the global setting project.invite.timeout to 300space 
 2. restart management server
 Expected result:
 1. Management server should restart correctly (it may ignore the invalid 
 value configured and throw a warning and set the value to default)
 Actual result:
 2012-08-01 09:53:26,982 INFO [cloud.consoleproxy.ConsoleProxyManagerImpl] 
 (main:null) Console Proxy Manager is configured.
 2012-08-01 09:53:26,982 INFO [utils.component.ComponentLocator] (main:null) 
 Configuring singleton Manager: ProjectManager
 2012-08-01 09:53:26,982 ERROR [utils.component.ComponentLocator] (main:null) 
 Unable to load configuration for management-server from components.xml
 java.lang.NumberFormatException: For input string: 300 
 at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
 at java.lang.Long.parseLong(Long.java:438)
 at java.lang.Long.valueOf(Long.java:535)
 at 
 com.cloud.projects.ProjectManagerImpl.configure(ProjectManagerImpl.java:130)
 at 
 com.cloud.utils.component.ComponentLocator.configureManagers(ComponentLocator.java:422)
 at com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:213)
 at 
 com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:790)
 at 
 com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:828)
 at com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44)
 at javax.servlet.GenericServlet.init(GenericServlet.java:212)
 at 
 org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
 at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
 at 
 org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187)
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4496)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
 at 
 org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
 at 
 org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
 at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
 at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
 at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
 at org.apache.catalina.core.StandardService.start(StandardService.java:516)
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
 2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
 (Thread-5:null) Skippng ClusterService because it has already stopped
 2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
 (Thread-5:null) Skippng BasicAgentAuthorizer because it has already stopped
 2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
 (Thread-5:null) Skippng XenServerGuru because it has already stopped
 2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
 (Thread-5:null) Skippng KVMGuru because it has already stopped



--
This message was sent by 

[jira] [Commented] (CLOUDSTACK-7100) Invalid Global setting is preventing management servert to restart

2014-07-11 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059474#comment-14059474
 ] 

ASF subversion and git services commented on CLOUDSTACK-7100:
-

Commit 63b81995f6f85238866fc388d04b16955354099d in cloudstack's branch 
refs/heads/master from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=63b8199 ]

CLOUDSTACK-7100: update global config - trim leading and trailing whitespaces 
before global config value update


 Invalid Global setting is preventing management servert to restart
 --

 Key: CLOUDSTACK-7100
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7100
 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: Alena Prokharchyk
Assignee: Alena Prokharchyk
 Fix For: 4.5.0


 Steps to reproduce:
 1. configure the global setting project.invite.timeout to 300space 
 2. restart management server
 Expected result:
 1. Management server should restart correctly (it may ignore the invalid 
 value configured and throw a warning and set the value to default)
 Actual result:
 2012-08-01 09:53:26,982 INFO [cloud.consoleproxy.ConsoleProxyManagerImpl] 
 (main:null) Console Proxy Manager is configured.
 2012-08-01 09:53:26,982 INFO [utils.component.ComponentLocator] (main:null) 
 Configuring singleton Manager: ProjectManager
 2012-08-01 09:53:26,982 ERROR [utils.component.ComponentLocator] (main:null) 
 Unable to load configuration for management-server from components.xml
 java.lang.NumberFormatException: For input string: 300 
 at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
 at java.lang.Long.parseLong(Long.java:438)
 at java.lang.Long.valueOf(Long.java:535)
 at 
 com.cloud.projects.ProjectManagerImpl.configure(ProjectManagerImpl.java:130)
 at 
 com.cloud.utils.component.ComponentLocator.configureManagers(ComponentLocator.java:422)
 at com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:213)
 at 
 com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:790)
 at 
 com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:828)
 at com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44)
 at javax.servlet.GenericServlet.init(GenericServlet.java:212)
 at 
 org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
 at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
 at 
 org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187)
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4496)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
 at 
 org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
 at 
 org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
 at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
 at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
 at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
 at org.apache.catalina.core.StandardService.start(StandardService.java:516)
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
 2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
 (Thread-5:null) Skippng ClusterService because it has already stopped
 2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
 (Thread-5:null) Skippng BasicAgentAuthorizer because it has already stopped
 2012-08-01 09:53:26,985 DEBUG 

[jira] [Resolved] (CLOUDSTACK-7100) Invalid Global setting is preventing management servert to restart

2014-07-11 Thread Alena Prokharchyk (JIRA)

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

Alena Prokharchyk resolved CLOUDSTACK-7100.
---

Resolution: Fixed

Fixed with commit 63b81995f6f85238866fc388d04b16955354099d
Author: Alena Prokharchyk alena.prokharc...@citrix.com
Date:   Fri Jul 11 16:01:34 2014 -0700

CLOUDSTACK-7100: update global config - trim leading and trailing 
whitespaces before global config value update

 Invalid Global setting is preventing management servert to restart
 --

 Key: CLOUDSTACK-7100
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7100
 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: Alena Prokharchyk
Assignee: Alena Prokharchyk
 Fix For: 4.5.0


 Steps to reproduce:
 1. configure the global setting project.invite.timeout to 300space 
 2. restart management server
 Expected result:
 1. Management server should restart correctly (it may ignore the invalid 
 value configured and throw a warning and set the value to default)
 Actual result:
 2012-08-01 09:53:26,982 INFO [cloud.consoleproxy.ConsoleProxyManagerImpl] 
 (main:null) Console Proxy Manager is configured.
 2012-08-01 09:53:26,982 INFO [utils.component.ComponentLocator] (main:null) 
 Configuring singleton Manager: ProjectManager
 2012-08-01 09:53:26,982 ERROR [utils.component.ComponentLocator] (main:null) 
 Unable to load configuration for management-server from components.xml
 java.lang.NumberFormatException: For input string: 300 
 at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
 at java.lang.Long.parseLong(Long.java:438)
 at java.lang.Long.valueOf(Long.java:535)
 at 
 com.cloud.projects.ProjectManagerImpl.configure(ProjectManagerImpl.java:130)
 at 
 com.cloud.utils.component.ComponentLocator.configureManagers(ComponentLocator.java:422)
 at com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:213)
 at 
 com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:790)
 at 
 com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:828)
 at com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44)
 at javax.servlet.GenericServlet.init(GenericServlet.java:212)
 at 
 org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
 at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
 at 
 org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187)
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4496)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
 at 
 org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
 at 
 org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
 at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
 at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
 at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
 at org.apache.catalina.core.StandardService.start(StandardService.java:516)
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
 2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
 (Thread-5:null) Skippng ClusterService because it has already stopped
 2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
 (Thread-5:null) Skippng BasicAgentAuthorizer because it has already stopped
 2012-08-01 09:53:26,985 DEBUG [utils.component.ComponentLocator] 
 (Thread-5:null) Skippng XenServerGuru because it has already 

[jira] [Commented] (CLOUDSTACK-7051) [Automation] Failed to create SSVM and CPVM in KVM,

2014-07-11 Thread Yoshikazu Nojima (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059505#comment-14059505
 ] 

Yoshikazu Nojima commented on CLOUDSTACK-7051:
--

I couldn't reproduce the bug you experienced in my environment (CentOS 6.5, 
build: 4.5 (as of aab6e1222fc75a37f8015ba1d2c7bc923c1cf614)).
But I face another issue during plugging a nic to CPVM (off-topic).

2014-07-11 19:30:04,768 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null) 
Request:Seq 1-3713780842720395322:  { Cmd , MgmtId: 161330501388, via: 1, Ver: 
v1, Flags: 100011, 
[{com.cloud.agent.api.StartCommand:{vm:{id:2,name:v-2-VM,type:ConsoleProxy,cpus:1,minSpeed:500,maxSpeed:500,minRam:1073741824,maxRam:1073741824,arch:x86_64,os:Debian
 GNU/Linux 5.0 (64-bit),bootArgs: template=domP type=consoleproxy 
host=198.172.18.40 port=8250 name=v-2-VM zone=1 pod=1 guid=Proxy.2 proxy_vm=2 
disable_rp_filter=true eth2ip=198.172.17.178 eth2mask=255.255.255.0 
gateway=198.172.17.1 eth0ip=169.254.0.133 eth0mask=255.255.0.0 
eth1ip=10.1.36.106 eth1mask=255.255.0.0 mgmtcidr=198.172.18.0/24 
localgw=10.1.2.17 internaldns1=8.8.8.8 
dns1=8.8.8.8,rebootOnCrash:false,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:d398dba089ca9227,params:{},uuid:155d8eb0-180f-430f-8c21-b9721ddf262b,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7653829b-52b1-4d0b-9087-e526d1de30ac,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:ef9d8d36-ef60-321f-a2c3-7a74371293d7,id:3,poolType:NetworkFilesystem,host:10.1.3.46,path:/exports/stack8-primary1,port:2049,url:NetworkFilesystem://10.1.3.46/exports/stack8-primary1/?ROLE=PrimarySTOREUUID=ef9d8d36-ef60-321f-a2c3-7a74371293d7}},name:ROOT-2,size:0,path:7653829b-52b1-4d0b-9087-e526d1de30ac,volumeId:2,vmName:v-2-VM,accountId:1,format:QCOW2,provisioningType:THIN,id:2,deviceId:0,hypervisorType:KVM}},diskSeq:0,path:7653829b-52b1-4d0b-9087-e526d1de30ac,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:10.1.3.46,volumeSize:0}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,pxeDisable:true,uuid:606da644-6f88-4257-8b50-2875c7cdb9d3,ip:198.172.17.178,netmask:255.255.255.0,gateway:198.172.17.1,mac:06:fe:a4:00:00:0c,dns1:8.8.8.8,broadcastType:Vlan,type:Public,broadcastUri:vlan://untagged,isolationUri:vlan://untagged,isSecurityGroupEnabled:false,name:cloudbr1},{deviceId:0,networkRateMbps:-1,defaultNic:false,pxeDisable:true,uuid:66998599-dd25-426a-a080-b152ab732183,ip:169.254.0.133,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:00:85,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,pxeDisable:true,uuid:01b5e274-fb46-406b-a253-f1292d420ccd,ip:10.1.36.106,netmask:255.255.0.0,gateway:10.1.2.17,mac:06:f2:88:00:00:06,broadcastType:Native,type:Management,isSecurityGroupEnabled:false,name:cloudbr0}]},hostIp:10.1.2.41,executeInSequence:false,wait:0}},{com.cloud.agent.api.check.CheckSshCommand:{ip:169.254.0.133,port:3922,interval:6,retries:100,name:v-2-VM,wait:0}}]
 }
2014-07-11 19:30:04,769 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null) 
Processing command: com.cloud.agent.api.StartCommand
2014-07-11 19:30:04,770 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-3:null) Trying to fetch storage pool 
ef9d8d36-ef60-321f-a2c3-7a74371293d7 from libvirt
2014-07-11 19:30:04,807 DEBUG [kvm.resource.KVMGuestOsMapper] 
(agentRequest-Handler-3:null) Can't find the mapping of guest os: Debian 
GNU/Linux 5.0 (64-bit)
2014-07-11 19:30:04,807 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-3:null) Trying to fetch storage pool 
ef9d8d36-ef60-321f-a2c3-7a74371293d7 from libvirt
2014-07-11 19:30:04,829 DEBUG [kvm.resource.BridgeVifDriver] 
(agentRequest-Handler-3:null) nic=[Nic:Control-169.254.0.133-null]
2014-07-11 19:30:04,829 WARN  [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-3:null) InternalErrorException
com.cloud.exception.InternalErrorException: plug: protocol or vNetId value is 
null
at 
com.cloud.hypervisor.kvm.resource.BridgeVifDriver.plug(BridgeVifDriver.java:106)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVif(LibvirtComputingResource.java:4046)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVifs(LibvirtComputingResource.java:3777)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3814)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1337)
at com.cloud.agent.Agent.processRequest(Agent.java:501)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
at com.cloud.utils.nio.Task.run(Task.java:84)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 

[jira] [Commented] (CLOUDSTACK-7051) [Automation] Failed to create SSVM and CPVM in KVM,

2014-07-11 Thread Rayees Namathponnan (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059510#comment-14059510
 ] 

Rayees Namathponnan commented on CLOUDSTACK-7051:
-

I am using RHEL 6.3

 [Automation] Failed to create SSVM and CPVM in KVM, 
 

 Key: CLOUDSTACK-7051
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7051
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
 Environment: RHEL : 6.3
 build : 4.5
Reporter: Rayees Namathponnan
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.5.0

 Attachments: agent.rar, management-server.rar


 SSVM and CPVM not creating with latest 4.5 build,  copy command failing form 
 agent  observed below error in agent log, 
 2014-07-02 16:14:58,170 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Execution is successful.
 2014-07-02 16:14:58,171 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Formatting '/mnt/4f3ad80a-b7
 96-3db3-b126-9c12b5b5eafc/48ef9a74-0244-11e4-b040-1a6f7bb0d0a8', fmt=qcow2 
 size=262144 encryption=off clus
 ter_size=65536 preallocation='off'
 2014-07-02 16:14:58,171 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Executing: qemu-img info --o
 utput json 
 /mnt/4f3ad80a-b796-3db3-b126-9c12b5b5eafc/48ef9a74-0244-11e4-b040-1a6f7bb0d0a8
 2014-07-02 16:14:58,173 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Exit value is 1
 2014-07-02 16:14:58,173 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) info: invalid option -- '-'q
 emu-img version 0.12.1, Copyright (c) 2004-2008 Fabrice Bellardusage: 
 qemu-img command [command options]QEMU d
 isk image utilityCommand syntax:  check [-f fmt] filename  create [-f fmt] 
 [-o options] filename [size]  commi
 t [-f fmt] [-t cache] filename  convert [-c] [-p] [-f fmt] [-t cache] [-O 
 output_fmt] [-o options] [-S sparse_
 size] filename [filename2 [...]] output_filename  info [-f fmt] filename  
 snapshot [-l | -a snapshot | -c snap
 shot | -d snapshot] filename  rebase [-f fmt] [-t cache] [-p] [-u] -b 
 backing_file [-F backing_fmt] filename
 resize filename [+ | -]sizeCommand parameters:  'filename' is a disk image 
 filename  'fmt' is the disk image f
 ormat. It is guessed automatically in most cases  'cache' is the cache mode 
 used to write the output disk imag
 e, the validoptions are: 'none', 'writeback' (default), 'writethrough' 
 and 'unsafe'  'size' is the disk im
 age size in bytes. Optional suffixes'k' or 'K' (kilobyte, 1024), 'M' 
 (megabyte, 1024k), 'G' (gigabyte, 102
 4M)and T (terabyte, 1024G) are supported. 'b' is ignored.  
 'output_filename' is the destination disk image
  filename  'output_fmt' is the destination format  'options' is a comma 
 separated list of format specific opti
 ons in aname=value format. Use -o ? for an overview of the options 
 supported by theused format  '-c' i
 ndicates that target image must be compressed (qcow format only)  '-u' 
 enables unsafe rebasing. It is assumed
 that old and new backing file   match exactly. The image doesn't need a 
 working backing file before
 rebasing in this case (useful for renaming the backing file)  '-h' with or 
 without a command shows this help a
 nd lists the supported formats  '-p' show progress of command (only certain 
 commands)  '-S' indicates the cons
 ecutive number of bytes that must contain only zeros   for qemu-img to 
 create a sparse image during conver
 sionParameters to snapshot subcommand:  'snapshot' is the name of the 
 snapshot to create, apply or delete  '-a
 ' applies a snapshot (revert disk to saved state)  '-c' creates a snapshot  
 '-d' deletes a snapshot  '-l' lists all snapshots in the given imageSupported 
 formats: raw cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 qed parallels 
 nbd blkdebug host_cdrom host_floppy host_device file



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


[jira] [Commented] (CLOUDSTACK-7051) [Automation] Failed to create SSVM and CPVM in KVM,

2014-07-11 Thread Yoshikazu Nojima (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059513#comment-14059513
 ] 

Yoshikazu Nojima commented on CLOUDSTACK-7051:
--

Here is a log CopyCommand works for my environment.

2014-07-11 19:44:12,774 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) 
Request:Seq 1-6160642815266127881:  { Cmd , MgmtId: 161330501388, via: 1, Ver: 
v1, Flags: 100011, 
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:8764e810-094f-11e4-905f-0025900c170c,origUrl:http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-kvm.qcow2.bz2,uuid:8764e810-094f-11e4-905f-0025900c170c,id:3,format:QCOW2,accountId:1,checksum:85a1bed07bf43cbf022451cb2ecae4ff,hvm:false,displayText:SystemVM
 Template 
(KVM),imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:ef9d8d36-ef60-321f-a2c3-7a74371293d7,id:3,poolType:NetworkFilesystem,host:10.1.3.46,path:/exports/stack8-primary1,port:2049,url:NetworkFilesystem://10.1.3.46/exports/stack8-primary1/?ROLE=PrimarySTOREUUID=ef9d8d36-ef60-321f-a2c3-7a74371293d7}},name:routing-3,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7f71939b-77bd-4917-9e3b-0fa3378cdfce,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:ef9d8d36-ef60-321f-a2c3-7a74371293d7,id:3,poolType:NetworkFilesystem,host:10.1.3.46,path:/exports/stack8-primary1,port:2049,url:NetworkFilesystem://10.1.3.46/exports/stack8-primary1/?ROLE=PrimarySTOREUUID=ef9d8d36-ef60-321f-a2c3-7a74371293d7}},name:ROOT-19,size:0,volumeId:19,vmName:s-19-VM,accountId:1,format:QCOW2,provisioningType:THIN,id:19,deviceId:0,hypervisorType:KVM}},executeInSequence:false,options:{},wait:0}}]
 }
2014-07-11 19:44:12,774 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) 
Processing command: org.apache.cloudstack.storage.command.CopyCommand
2014-07-11 19:44:12,775 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Trying to fetch storage pool 
ef9d8d36-ef60-321f-a2c3-7a74371293d7 from libvirt
2014-07-11 19:44:12,804 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Trying to fetch storage pool 
ef9d8d36-ef60-321f-a2c3-7a74371293d7 from libvirt
2014-07-11 19:44:12,845 INFO  [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Creating volume 
7f71939b-77bd-4917-9e3b-0fa3378cdfce from template 
8764e810-094f-11e4-905f-0025900c170c in pool 
ef9d8d36-ef60-321f-a2c3-7a74371293d7 (NetworkFilesystem) with size 0
2014-07-11 19:44:12,845 INFO  [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Attempting to create volume 
7f71939b-77bd-4917-9e3b-0fa3378cdfce (NetworkFilesystem) in pool 
ef9d8d36-ef60-321f-a2c3-7a74371293d7 with size 262144
2014-07-11 19:44:12,845 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Executing: qemu-img create -o preallocation=off, 
-f qcow2 
/mnt/ef9d8d36-ef60-321f-a2c3-7a74371293d7/7f71939b-77bd-4917-9e3b-0fa3378cdfce 
262144
2014-07-11 19:44:12,868 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Execution is successful.
2014-07-11 19:44:12,869 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Formatting 
'/mnt/ef9d8d36-ef60-321f-a2c3-7a74371293d7/7f71939b-77bd-4917-9e3b-0fa3378cdfce',
 fmt=qcow2 size=262144 encryption=off cluster_size=65536 preallocation='off'

2014-07-11 19:44:17,225 INFO  [cloud.agent.Agent] (UgentTask-4:null) Connected 
to the server
2014-07-11 19:44:17,225 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Executing: qemu-img info --output json 
/mnt/ef9d8d36-ef60-321f-a2c3-7a74371293d7/7f71939b-77bd-4917-9e3b-0fa3378cdfce
2014-07-11 19:44:17,233 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Execution is successful.
2014-07-11 19:44:17,234 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Executing: qemu-img create -o preallocation=off, 
-f qcow2 -b 
/mnt/ef9d8d36-ef60-321f-a2c3-7a74371293d7/8764e810-094f-11e4-905f-0025900c170c 
/mnt/ef9d8d36-ef60-321f-a2c3-7a74371293d7/7f71939b-77bd-4917-9e3b-0fa3378cdfce 
262144
2014-07-11 19:44:17,266 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Execution is successful.
2014-07-11 19:44:17,266 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Formatting 
'/mnt/ef9d8d36-ef60-321f-a2c3-7a74371293d7/7f71939b-77bd-4917-9e3b-0fa3378cdfce',
 fmt=qcow2 size=262144 
backing_file='/mnt/ef9d8d36-ef60-321f-a2c3-7a74371293d7/8764e810-094f-11e4-905f-0025900c170c'
 encryption=off cluster_size=65536 preallocation='off'

2014-07-11 19:44:17,267 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) 
Seq 1-6160642815266127881:  { Ans: , MgmtId: 161330501388, via: 1, Ver: v1, 
Flags: 10, 

[jira] [Commented] (CLOUDSTACK-7051) [Automation] Failed to create SSVM and CPVM in KVM,

2014-07-11 Thread Yoshikazu Nojima (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059634#comment-14059634
 ] 

Yoshikazu Nojima commented on CLOUDSTACK-7051:
--

I reproduced the bug with CentOS 6.3. Since qemu-img provided by CentOS 6.3 
doesn't support --ourput option, this error raised.
I'll try to remove the --output option.

 [Automation] Failed to create SSVM and CPVM in KVM, 
 

 Key: CLOUDSTACK-7051
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7051
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
 Environment: RHEL : 6.3
 build : 4.5
Reporter: Rayees Namathponnan
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.5.0

 Attachments: agent.rar, management-server.rar


 SSVM and CPVM not creating with latest 4.5 build,  copy command failing form 
 agent  observed below error in agent log, 
 2014-07-02 16:14:58,170 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Execution is successful.
 2014-07-02 16:14:58,171 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Formatting '/mnt/4f3ad80a-b7
 96-3db3-b126-9c12b5b5eafc/48ef9a74-0244-11e4-b040-1a6f7bb0d0a8', fmt=qcow2 
 size=262144 encryption=off clus
 ter_size=65536 preallocation='off'
 2014-07-02 16:14:58,171 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Executing: qemu-img info --o
 utput json 
 /mnt/4f3ad80a-b796-3db3-b126-9c12b5b5eafc/48ef9a74-0244-11e4-b040-1a6f7bb0d0a8
 2014-07-02 16:14:58,173 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Exit value is 1
 2014-07-02 16:14:58,173 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) info: invalid option -- '-'q
 emu-img version 0.12.1, Copyright (c) 2004-2008 Fabrice Bellardusage: 
 qemu-img command [command options]QEMU d
 isk image utilityCommand syntax:  check [-f fmt] filename  create [-f fmt] 
 [-o options] filename [size]  commi
 t [-f fmt] [-t cache] filename  convert [-c] [-p] [-f fmt] [-t cache] [-O 
 output_fmt] [-o options] [-S sparse_
 size] filename [filename2 [...]] output_filename  info [-f fmt] filename  
 snapshot [-l | -a snapshot | -c snap
 shot | -d snapshot] filename  rebase [-f fmt] [-t cache] [-p] [-u] -b 
 backing_file [-F backing_fmt] filename
 resize filename [+ | -]sizeCommand parameters:  'filename' is a disk image 
 filename  'fmt' is the disk image f
 ormat. It is guessed automatically in most cases  'cache' is the cache mode 
 used to write the output disk imag
 e, the validoptions are: 'none', 'writeback' (default), 'writethrough' 
 and 'unsafe'  'size' is the disk im
 age size in bytes. Optional suffixes'k' or 'K' (kilobyte, 1024), 'M' 
 (megabyte, 1024k), 'G' (gigabyte, 102
 4M)and T (terabyte, 1024G) are supported. 'b' is ignored.  
 'output_filename' is the destination disk image
  filename  'output_fmt' is the destination format  'options' is a comma 
 separated list of format specific opti
 ons in aname=value format. Use -o ? for an overview of the options 
 supported by theused format  '-c' i
 ndicates that target image must be compressed (qcow format only)  '-u' 
 enables unsafe rebasing. It is assumed
 that old and new backing file   match exactly. The image doesn't need a 
 working backing file before
 rebasing in this case (useful for renaming the backing file)  '-h' with or 
 without a command shows this help a
 nd lists the supported formats  '-p' show progress of command (only certain 
 commands)  '-S' indicates the cons
 ecutive number of bytes that must contain only zeros   for qemu-img to 
 create a sparse image during conver
 sionParameters to snapshot subcommand:  'snapshot' is the name of the 
 snapshot to create, apply or delete  '-a
 ' applies a snapshot (revert disk to saved state)  '-c' creates a snapshot  
 '-d' deletes a snapshot  '-l' lists all snapshots in the given imageSupported 
 formats: raw cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 qed parallels 
 nbd blkdebug host_cdrom host_floppy host_device file



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