[jira] [Commented] (CLOUDSTACK-7284) Holder for KVM regression test script issues

2014-08-13 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-7284: Fixed test script related to expunge VM in 
test_add_remove_network.py


 Holder for KVM regression test script issues
 

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


 This bug is holder for all test script issues identified in KVM regression 
 run.



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


[jira] [Commented] (CLOUDSTACK-7294) [Automation] ListUser API call returns null, with admin user

2014-08-13 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-7294: Passing listall=True for listUser api admin call


 [Automation] ListUser API call returns null, with admin user
 

 Key: CLOUDSTACK-7294
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7294
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Blocker
 Fix For: 4.5.0


 This is issue observed in automation run, listUser API call from admin 
 account its not returning anything 
 {noformat}
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?username=test-a-TestScaleVmDynamicServiceOffering-test_check_vm_stats_1_ADMIN_ACCOUNT-CSLTD9apiKey=6zw5hCTgehiuRygidlX9Lg089xLncrgdPOB1kUI32G6CG19hYJiT8hEKlIyJL5hOaSW9nJ2s0hc3a605fi0wVQcommand=listUsersresponse=jsonsignature=spQJXI%2Bz76Enm%2B1mthEXDtdFc64%3D
  HTTP/1.1 200 29
 test_check_vm_stats_1_ADMIN_ACCOUNT 
 (integration.component.test_dynamic_compute_offering.TestDynamicServiceOffering):
  DEBUG: Response : None
 test_check_vm_stats_1_ADMIN_ACCOUNT 
 (integration.component.test_dynamic_compute_offering.TestDynamicServiceOffering):
  ERROR: Exception Occurred Under getUserApiClient : ['Traceback (most recent 
 call last):\n', '  File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py, line 
 349, in __createUserApiClient\nuserId = listuserRes[0].id\n', TypeError: 
 'NoneType' object is not subscriptable\n]
 Traceback (most recent call last):
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py, line 
 349, in __createUserApiClient
 userId = listuserRes[0].id
 TypeError: 'NoneType' object is not subscriptable
 {noformat}



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


[jira] [Resolved] (CLOUDSTACK-7294) [Automation] ListUser API call returns null, with admin user

2014-08-13 Thread Gaurav Aradhye (JIRA)

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

Gaurav Aradhye resolved CLOUDSTACK-7294.


Resolution: Fixed

 [Automation] ListUser API call returns null, with admin user
 

 Key: CLOUDSTACK-7294
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7294
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Blocker
 Fix For: 4.5.0


 This is issue observed in automation run, listUser API call from admin 
 account its not returning anything 
 {noformat}
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?username=test-a-TestScaleVmDynamicServiceOffering-test_check_vm_stats_1_ADMIN_ACCOUNT-CSLTD9apiKey=6zw5hCTgehiuRygidlX9Lg089xLncrgdPOB1kUI32G6CG19hYJiT8hEKlIyJL5hOaSW9nJ2s0hc3a605fi0wVQcommand=listUsersresponse=jsonsignature=spQJXI%2Bz76Enm%2B1mthEXDtdFc64%3D
  HTTP/1.1 200 29
 test_check_vm_stats_1_ADMIN_ACCOUNT 
 (integration.component.test_dynamic_compute_offering.TestDynamicServiceOffering):
  DEBUG: Response : None
 test_check_vm_stats_1_ADMIN_ACCOUNT 
 (integration.component.test_dynamic_compute_offering.TestDynamicServiceOffering):
  ERROR: Exception Occurred Under getUserApiClient : ['Traceback (most recent 
 call last):\n', '  File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py, line 
 349, in __createUserApiClient\nuserId = listuserRes[0].id\n', TypeError: 
 'NoneType' object is not subscriptable\n]
 Traceback (most recent call last):
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py, line 
 349, in __createUserApiClient
 userId = listuserRes[0].id
 TypeError: 'NoneType' object is not subscriptable
 {noformat}



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


[jira] [Assigned] (CLOUDSTACK-7331) [Automation] test_vpc_network_life_cycle_1_delete failed while deleting VPC network

2014-08-13 Thread Gaurav Aradhye (JIRA)

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

Gaurav Aradhye reassigned CLOUDSTACK-7331:
--

Assignee: Gaurav Aradhye

 [Automation] test_vpc_network_life_cycle_1_delete failed while deleting VPC 
 network 
 

 Key: CLOUDSTACK-7331
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7331
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 integration.component.test_persistent_networks.TestVPCNetworkOperations.test_vpc_network_life_cycle_1_delete
 This failure need more analysis,  from the log look, like test case trying to 
 delete VPC , which   used by 2 networks
 Error Message
 Job failed: {jobprocstatus : 0, created : u'2014-08-11T18:10:39-0700', cmd : 
 u'org.apache.cloudstack.api.command.user.vpc.DeleteVPCCmd', userid : 
 u'c0533784-2197-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid : 
 u'55fb327b-ca86-4ae8-9489-4f50cc3e0b6b', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : uCan't delete VPC [VPC 
 [30-vpc_vpn-ONQVTO] as its used by 2 networks}, accountid : 
 u'c0532ca8-2197-11e4-9ac6-1a6f7bb0d0a8'}
   begin captured stdout  -
 === TestName: test_vpc_network_life_cycle_1_delete | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_vpc_network_life_cycle_1_delete 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: STARTED : TC: test_vpc_network_life_cycle_1_delete 
 :::
 test_vpc_network_life_cycle_1_delete 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Payload: {'username': 
 'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
  'domainid': u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', 'firstname': 'test', 
 'lastname': 'test', 'response': 'json', 'apiKey': 
 u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
  'command': 'createAccount', 'accounttype': 0, 'signature': 
 'r41I7ga909Z8suAixwuNvXMPZXg=', 'password': 'password', 'email': 
 'test-acco...@test.com'}
 test_vpc_network_life_cycle_1_delete 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Sending GET Cmd : createAccount===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?username=test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Qdomainid=6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8firstname=testlastname=testemail=test-account%40test.comapiKey=78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQcommand=createAccountaccounttype=0signature=r41I7ga909Z8suAixwuNvXMPZXg%3Dpassword=passwordresponse=json
  HTTP/1.1 200 1737
 test_vpc_network_life_cycle_1_delete 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT', 
 domainid : u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', vpclimit : u'Unlimited', 
 iplimit : u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0, 
 secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal 
 : 0, id : u'a6046056-0ef6-41d3-a49d-24a3296f856a', cpuavailable : 
 u'Unlimited', snapshotlimit : u'Unlimited', networklimit : u'Unlimited', 
 iptotal : 0, volumetotal : 0, projectlimit : u'Unlimited', state : 
 u'enabled', networktotal : 0, accounttype : 0, networkavailable : 
 u'Unlimited', primarystoragetotal : 0, templatelimit : u'Unlimited', 
 snapshottotal : 0, templateavailable : u'Unlimited', vmlimit : u'Unlimited', 
 vpcavailable : u'Unlimited', memoryavailable : u'Unlimited', 
 secondarystoragetotal : 0, templatetotal : 0, projecttotal : 0, user : 
 [{username : 
 u'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
  account : 
 u'test-a-TestVPCNetworkOperations-test_vpc_network_life_cycle_1_delete-D8X26Q',
  domainid : u'6c15608e-2197-11e4-9ac6-1a6f7bb0d0a8', firstname : u'test', 
 created : u'2014-08-11T18:09:30-0700', lastname : u'test', domain : u'ROOT', 
 id : u'7c010648-ba13-4b79-b20c-383670fdc77c', iscallerchilddomain : False, 
 state : u'enabled', accounttype : 0, email : u'test-acco...@test.com', 
 isdefault : False, accountid : u'a6046056-0ef6-41d3-a49d-24a3296f856a'}], 
 

[jira] [Created] (CLOUDSTACK-7333) [vGPU] Windows VM with GPU cards and PV drivers is going to repair state when deployed with dynamic scaling enabled option.

2014-08-13 Thread Abhinav Roy (JIRA)
Abhinav Roy created CLOUDSTACK-7333:
---

 Summary: [vGPU] Windows VM with GPU cards and PV drivers is going 
to repair state when deployed with dynamic scaling enabled option.
 Key: CLOUDSTACK-7333
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7333
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.5.0
 Environment: Xenserver 6.2.5  + PV drivers (up to date)

Reporter: Abhinav Roy
Priority: Blocker
 Fix For: 4.5.0


There are 4 scenarios which i tried :

Setup :
=
CS 4.5 advanced zone with Xen 6.2.5 + PV drivers ( XS Tools)
Dynamic scaling is enabled on zone level.

Scenario 1 :

1. Register a windows 8 or windows 2012 template ( without dynamic scaling 
enabled) and deploy a VM with vGPU service offering from it.
 
  -- Template is registered and VM is deployed. 

2. Install the PV drivers on the VM.

  -- PV drivers are installed successfully (make sure they are latest)

3. Now stop the VM, enable dynamic scaling and start the VM.

  -- VM fails to start and goes into the repair state.

Scenario 2 :

1. Register a windows 8 or windows 2012 template ( with dynamic scaling 
enabled) and deploy a VM with vGPU service offering from it.
 
  -- Template is registered and VM is deployed. 

2. Install the PV drivers on the VM.

  -- PV drivers fail to install and VM goes to repair state.


Scenario 3 :

1. Register a windows 8 or windows 2012 template ( with dynamic scaling enabled 
and PV drivers installed) and deploy a VM with vGPU service offering from it.
 
  -- Template is registered and VM fails to deploy, it goes into repair state. 


Scenario 4 :

1. Register a windows 8 or windows 2012 template ( without dynamic scaling 
enabled but PV drivers are installed) and deploy a VM with vGPU service 
offering from it.
 
  -- Template is registered and VM is deployed. 

2. Now stop the VM, enable dynamic scaling and start the VM.

  -- VM fails to start and goes into the repair state


Scenario 5 :

1. Register a windows 8 or windows 2012 ISO and deploy a VM with vGPU service 
offering from it.
 
  -- ISO is registered and VM is deployed. 

2. Install the PV drivers on the VM.

  -- PV drivers are installed successfully (make sure they are latest)

3. Now stop the VM, enable dynamic scaling and start the VM.

  -- VM fails to start and goes into the repair state





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


[jira] [Commented] (CLOUDSTACK-7275) [Automation] NPE thrown in MS log while starting ConsoleProxy

2014-08-13 Thread Rajani Karuturi (JIRA)

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

Rajani Karuturi commented on CLOUDSTACK-7275:
-

[~rayeesn], Can you specify the test case which failed?



 [Automation] NPE thrown in MS log while starting ConsoleProxy
 -

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

 Attachments: Aug_06_KVM.rar


 Below NPE  thrown in MS while starting Console Proxy
 {noformat}
 2014-08-06 08:00:48,370 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Deplo
 ymentPlanningManagerImpl
 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Clust
 eredVirtualMachineManagerImpl
 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Netwo
 rkOrchestrator
 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: Downl
 oadListener
 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
 DirectNetworkStatsListener
 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
 UploadListener
 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
 BehindOnPingListener
 2014-08-06 08:00:48,371 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
 ConsoleProxyListener
 2014-08-06 08:00:48,442 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-7:null) Ping from 3
 2014-08-06 08:00:48,496 INFO  [c.c.c.ConsoleProxyManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Proxy 4 is no longer in DB, skip 
 sending startup command
 2014-08-06 08:00:48,497 ERROR [c.c.c.AgentHookBase] 
 (AgentConnectTaskPool-66:ctx-277af113) Unexpected exception when sending http 
 handling startup command(time out) to the console proxy resource for proxy:4
 java.lang.NullPointerException
 at 
 com.cloud.consoleproxy.AgentHookBase.startAgentHttpHandlerInVM(AgentHookBase.java:212)
 at 
 com.cloud.consoleproxy.ConsoleProxyListener.processConnect(ConsoleProxyListener.java:71)
 at 
 com.cloud.agent.manager.AgentManagerImpl.notifyMonitorsOfConnection(AgentManagerImpl.java:537)
 at 
 com.cloud.agent.manager.AgentManagerImpl.handleConnectedAgent(AgentManagerImpl.java:1030)
 at 
 com.cloud.agent.manager.AgentManagerImpl.access$000(AgentManagerImpl.java:119)
 at 
 com.cloud.agent.manager.AgentManagerImpl$HandleAgentConnectTask.runInContext(AgentManagerImpl.java:1114)
 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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-08-06 08:00:48,497 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentConnectTaskPool-66:ctx-277af113) Sending Connect to listener: 
 SshKeysDistriMonitor
 {noformat}



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


[jira] [Updated] (CLOUDSTACK-7333) [vGPU] Windows VM with GPU cards and PV drivers is going to repair state when deployed with dynamic scaling enabled option.

2014-08-13 Thread Abhinav Roy (JIRA)

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

Abhinav Roy updated CLOUDSTACK-7333:


Attachment: CS-7333.zip

Attaching MS logs, DB dumps and xe-param-list output for vgpu and non-vgpu VMs

 [vGPU] Windows VM with GPU cards and PV drivers is going to repair state when 
 deployed with dynamic scaling enabled option.
 -

 Key: CLOUDSTACK-7333
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7333
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.5.0
 Environment: Xenserver 6.2.5  + PV drivers (up to date)
Reporter: Abhinav Roy
Priority: Blocker
 Fix For: 4.5.0

 Attachments: CS-7333.zip


 There are 4 scenarios which i tried :
 Setup :
 =
 CS 4.5 advanced zone with Xen 6.2.5 + PV drivers ( XS Tools)
 Dynamic scaling is enabled on zone level.
 Scenario 1 :
 
 1. Register a windows 8 or windows 2012 template ( without dynamic scaling 
 enabled) and deploy a VM with vGPU service offering from it.
  
   -- Template is registered and VM is deployed. 
 2. Install the PV drivers on the VM.
   -- PV drivers are installed successfully (make sure they are latest)
 3. Now stop the VM, enable dynamic scaling and start the VM.
   -- VM fails to start and goes into the repair state.
 Scenario 2 :
 
 1. Register a windows 8 or windows 2012 template ( with dynamic scaling 
 enabled) and deploy a VM with vGPU service offering from it.
  
   -- Template is registered and VM is deployed. 
 2. Install the PV drivers on the VM.
   -- PV drivers fail to install and VM goes to repair state.
 Scenario 3 :
 
 1. Register a windows 8 or windows 2012 template ( with dynamic scaling 
 enabled and PV drivers installed) and deploy a VM with vGPU service offering 
 from it.
  
   -- Template is registered and VM fails to deploy, it goes into repair 
 state. 
 Scenario 4 :
 
 1. Register a windows 8 or windows 2012 template ( without dynamic scaling 
 enabled but PV drivers are installed) and deploy a VM with vGPU service 
 offering from it.
  
   -- Template is registered and VM is deployed. 
 2. Now stop the VM, enable dynamic scaling and start the VM.
   -- VM fails to start and goes into the repair state
 Scenario 5 :
 
 1. Register a windows 8 or windows 2012 ISO and deploy a VM with vGPU service 
 offering from it.
  
   -- ISO is registered and VM is deployed. 
 2. Install the PV drivers on the VM.
   -- PV drivers are installed successfully (make sure they are latest)
 3. Now stop the VM, enable dynamic scaling and start the VM.
   -- VM fails to start and goes into the repair state



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


[jira] [Assigned] (CLOUDSTACK-7330) [Automation] test_persistent_networks.TestVPCNetworkOperations test failed to ListNetwrok API call

2014-08-13 Thread Gaurav Aradhye (JIRA)

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

Gaurav Aradhye reassigned CLOUDSTACK-7330:
--

Assignee: Gaurav Aradhye

 [Automation] test_persistent_networks.TestVPCNetworkOperations test failed to 
 ListNetwrok API call 
 ---

 Key: CLOUDSTACK-7330
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7330
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 Test integration/component/test_persistent_networks.py, line 1928, in 
 test_vpc_force_delete_domain failing while list network 
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Response : {domain : u'domain-4M0XO1', specifyipranges : False, 
 related : u'6286d150-0603-45e1-8ae7-7c017ea08f00', zoneid : 
 u'169dbf29-8372-43f9-891d-8002e7d27f3f', domainid : 
 u'427de23b-229f-48f1-8a4d-ce700e66fbc6', displaytext : u'Isolated Network', 
 gateway : u'10.1.1.1', canusefordeploy : True, physicalnetworkid : 
 u'8cf2dd88-61b7-45b5-9be9-79acc15981de', networkdomain : 
 u'csbcauto.advanced', service : [{name : u'StaticNat'}, {capability : [{value 
 : u'true', name : u'DhcpAccrossMultipleSubnets', canchooseservicecapability : 
 False}], name : u'Dhcp'}, {capability : [{value : u's2svpn', name : 
 u'VpnTypes', canchooseservicecapability : False}, {value : 
 u'pptp,l2tp,ipsec', name : u'SupportedVpnTypes', canchooseservicecapability : 
 False}], name : u'Vpn'}, {capability : [{value : u'peraccount', name : 
 u'SupportedSourceNatTypes', canchooseservicecapability : False}, {value : 
 u'false', name : u'RedundantRouter', canchooseservicecapability : False}], 
 name : u'SourceNat'}, {name : u'PortForwarding'}, {capability : [{value : 
 u'tcp,udp,icmp', name : u'SupportedProtocols', canchooseservicecapability : 
 False}], name : u'NetworkACL'}, {capability : [{value : u'true', name : 
 u'AllowDnsSuffixModification', canchooseservicecapability : False}], name : 
 u'Dns'}, {name : u'UserData'}], strechedl2subnet : False, id : 
 u'6286d150-0603-45e1-8ae7-7c017ea08f00', state : u'Implemented', type : 
 u'Isolated', broadcasturi : u'vlan://2347', zonename : u'Adv-KVM-Zone1', 
 networkofferingavailability : u'Optional', networkofferingid : 
 u'1079d837-1006-4ed4-8275-3874dc03f352', tags : [], displaynetwork : True, 
 vlan : u'2347', networkofferingdisplaytext : u'VPC Network off-CZSZH7', 
 traffictype : u'Guest', netmask : u'255.255.255.0', vpcid : 
 u'f1c80510-9971-49de-a25a-3b421a6927ce', cidr : u'10.1.1.0/24', 
 restartrequired : False, broadcastdomaintype : u'Vlan', account : 
 u'test-a-TestVPCNetworkOperations-test_vpc_force_delete_domain-3K82RQ', 
 ispersistent : True, name : u'Isolated Network', dns1 : u'8.8.8.8', 
 networkofferingconservemode : False, acltype : u'Account', 
 networkofferingname : u'VPC Network offering-B2EPH9', issystem : False}
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Payload: {'apiKey': 
 u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
  'id': u'6286d150-0603-45e1-8ae7-7c017ea08f00', 'response': 'json', 
 'command': 'listNetworks', 'signature': 'd4+7JeVeAlODVIDRzOkZtn5wxh0='}
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Sending GET Cmd : listNetworks===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=d4%2B7JeVeAlODVIDRzOkZtn5wxh0%3DapiKey=78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQcommand=listNetworksid=6286d150-0603-45e1-8ae7-7c017ea08f00response=json
  HTTP/1.1 200 32
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Response : None
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 CRITICAL: FAILED: test_vpc_force_delete_domain: ['Traceback (most recent call 
 last):\n', '  File /usr/local/lib/python2.7/unittest/case.py, line 318, in 
 run\ntestMethod()\n', '  File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_persistent_networks.py,
  line 1928, in test_vpc_force_delete_domain\nself.fail(e)\n', '  File 
 /usr/local/lib/python2.7/unittest/case.py, line 393, in fail\nraise 
 self.failureException(msg)\n', 'AssertionError: 

[jira] [Assigned] (CLOUDSTACK-7332) CloudMonkey setup.py undefined variable 'requires'

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav reassigned CLOUDSTACK-7332:
---

Assignee: Rohit Yadav

 CloudMonkey setup.py undefined variable 'requires'
 --

 Key: CLOUDSTACK-7332
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7332
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Cloudmonkey
 Environment: Windows 8.1, cmd.exe, python 2.7.8, pip 1.5.6
Reporter: Scott Trotter
Assignee: Rohit Yadav
Priority: Minor
   Original Estimate: 1h
  Remaining Estimate: 1h

 I'm setting up a Windows system to see how effective (or not) it is for FOSS 
 development. I installed the following components, in order, one right after 
 another, using cmd.exe CLI, not PowerShell or Git Bash:
 Github for Windows 2.2.0.0
 Python (x64) 2.7.8
 ez_setup.py
 get-pip.py
 pip install cloudmonkey
 The latter resulted in the following error, which I copied from pip.log:
 File e:\temp\pip_build_Scott\cloudmonkey\setup.py, line 32, in module
 requires.append('readline')
 NameError: name 'requires' is not defined
 I downloaded apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2 and unpacked it 
 manually. Here is the problem area, starting with line 29:
 try:
 import readline
 except ImportError:
 requires.append('readline')
 This test FAILED on my system, but I'm guessing that it typically doesn't 
 fail on others because readline is typically already installed by the time 
 someone tries to install CloudMonkey.
 I also poked around in the repo, and it's easy to see how this bug got 
 introduced. In the last commit on Mar. 19, 2013, the maintainer changed the 
 way that required modules are handled, in part by removing the 'requires' 
 variable, but missed the try/except clause shown above. It probably remained 
 undiscovered this long due to my unusual installation sequence.
 This should be very simple to fix. I have pip.log if you need it, but I don't 
 see any way to attach files in this report form. I can email it to you if you 
 want.
 Questions? sc...@trotternet.com



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


[jira] [Resolved] (CLOUDSTACK-7332) CloudMonkey setup.py undefined variable 'requires'

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav resolved CLOUDSTACK-7332.
-

Resolution: Fixed

 CloudMonkey setup.py undefined variable 'requires'
 --

 Key: CLOUDSTACK-7332
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7332
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Cloudmonkey
 Environment: Windows 8.1, cmd.exe, python 2.7.8, pip 1.5.6
Reporter: Scott Trotter
Assignee: Rohit Yadav
Priority: Minor
   Original Estimate: 1h
  Remaining Estimate: 1h

 I'm setting up a Windows system to see how effective (or not) it is for FOSS 
 development. I installed the following components, in order, one right after 
 another, using cmd.exe CLI, not PowerShell or Git Bash:
 Github for Windows 2.2.0.0
 Python (x64) 2.7.8
 ez_setup.py
 get-pip.py
 pip install cloudmonkey
 The latter resulted in the following error, which I copied from pip.log:
 File e:\temp\pip_build_Scott\cloudmonkey\setup.py, line 32, in module
 requires.append('readline')
 NameError: name 'requires' is not defined
 I downloaded apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2 and unpacked it 
 manually. Here is the problem area, starting with line 29:
 try:
 import readline
 except ImportError:
 requires.append('readline')
 This test FAILED on my system, but I'm guessing that it typically doesn't 
 fail on others because readline is typically already installed by the time 
 someone tries to install CloudMonkey.
 I also poked around in the repo, and it's easy to see how this bug got 
 introduced. In the last commit on Mar. 19, 2013, the maintainer changed the 
 way that required modules are handled, in part by removing the 'requires' 
 variable, but missed the try/except clause shown above. It probably remained 
 undiscovered this long due to my unusual installation sequence.
 This should be very simple to fix. I have pip.log if you need it, but I don't 
 see any way to attach files in this report form. I can email it to you if you 
 want.
 Questions? sc...@trotternet.com



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


[jira] [Created] (CLOUDSTACK-7334) [VMware] AddHost command fails if there is a space in the VMware DC/Cluster name

2014-08-13 Thread Likitha Shetty (JIRA)
Likitha Shetty created CLOUDSTACK-7334:
--

 Summary: [VMware] AddHost command fails if there is a space in the 
VMware DC/Cluster name
 Key: CLOUDSTACK-7334
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7334
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup, VMware
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
 Fix For: 4.5.0


If VMware DC contains a space character then adding a host to the corresponding 
Zone in CCP fails with the below error - 
{noformat}
2014-08-13 10:39:47,468 DEBUG [c.c.a.ApiServlet] 
(24967510@qtp-6691912-0:ctx-165190ee) ===START===  10.252.241.50 -- GET  
command=addClusterzoneId=8fda1cb2-4673-4d65-8b18-d9fae061decbhypervisor=VMwareclustertype=ExternalManagedpodId=3aa2f52b-5cca-459b-9c30-8af3adb0fbc6username=administratorurl=http%3A%2F%2F10.102.192.248%2FTest%20Cloud%2FInteractive_Cloudclustername=10.102.192.248%2FCitrix%20Test%20Cloud%2FInteractive_Cloudresponse=jsonsessionkey=Zu6EOaK1gAqbBjrM%2Bls%2Fydj7IJU%3D_=1407907218055
2014-08-13 10:39:47,545 INFO  [c.c.h.v.VmwareServerDiscoverer] 
(24967510@qtp-6691912-0:ctx-165190ee ctx-bc3e621b) Discover host. dc: 1, pod: 
1, cluster: 1, uri host: 10.102.192.248
2014-08-13 10:39:47,552 ERROR [c.c.h.v.VmwareServerDiscoverer] 
(24967510@qtp-6691912-0:ctx-165190ee ctx-bc3e621b) This cluster 
Interactive_Cloud belongs to VMware DC Test+Cloud .But this zone is associated 
with VMware DC Test Cloud. Make sure the cluster being added belongs to VMware 
DC Test Cloud in vCenter 10.102.192.248
2014-08-13 10:39:47,553 INFO  [c.c.u.e.CSExceptionErrorCode] 
(24967510@qtp-6691912-0:ctx-165190ee ctx-bc3e621b) Could not find exception: 
com.cloud.exception.DiscoveryException in error code list for exceptions
2014-08-13 10:39:47,752 WARN  [o.a.c.a.c.a.c.AddClusterCmd] 
(24967510@qtp-6691912-0:ctx-165190ee ctx-bc3e621b) Exception:
com.cloud.exception.DiscoveryException: This cluster Interactive_Cloud belongs 
to VMware DC Test+Cloud .But this zone is associated with VMware DC Citrix Test 
Cloud. Make sure the cluster being added belongs to VMware DC Test Cloud in 
vCenter 10.102.192.248
at 
com.cloud.hypervisor.vmware.VmwareServerDiscoverer.validateCluster(VmwareServerDiscoverer.java:489)
at 
com.cloud.hypervisor.vmware.VmwareServerDiscoverer.find(VmwareServerDiscoverer.java:152)
at 
com.cloud.resource.ResourceManagerImpl.discoverCluster(ResourceManagerImpl.java:511)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.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.$Proxy163.discoverCluster(Unknown Source)
at 
org.apache.cloudstack.api.command.admin.cluster.AddClusterCmd.execute(AddClusterCmd.java:196)
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.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 

[jira] [Commented] (CLOUDSTACK-7332) CloudMonkey setup.py undefined variable 'requires'

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav commented on CLOUDSTACK-7332:
-

Hi Fixed on master, thanks for reporting and the work around. From now onwards 
it should installed pyreadline on windows. We'll release next version of 
cloudmonkey on pypi soon.

 CloudMonkey setup.py undefined variable 'requires'
 --

 Key: CLOUDSTACK-7332
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7332
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Cloudmonkey
 Environment: Windows 8.1, cmd.exe, python 2.7.8, pip 1.5.6
Reporter: Scott Trotter
Assignee: Rohit Yadav
Priority: Minor
   Original Estimate: 1h
  Remaining Estimate: 1h

 I'm setting up a Windows system to see how effective (or not) it is for FOSS 
 development. I installed the following components, in order, one right after 
 another, using cmd.exe CLI, not PowerShell or Git Bash:
 Github for Windows 2.2.0.0
 Python (x64) 2.7.8
 ez_setup.py
 get-pip.py
 pip install cloudmonkey
 The latter resulted in the following error, which I copied from pip.log:
 File e:\temp\pip_build_Scott\cloudmonkey\setup.py, line 32, in module
 requires.append('readline')
 NameError: name 'requires' is not defined
 I downloaded apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2 and unpacked it 
 manually. Here is the problem area, starting with line 29:
 try:
 import readline
 except ImportError:
 requires.append('readline')
 This test FAILED on my system, but I'm guessing that it typically doesn't 
 fail on others because readline is typically already installed by the time 
 someone tries to install CloudMonkey.
 I also poked around in the repo, and it's easy to see how this bug got 
 introduced. In the last commit on Mar. 19, 2013, the maintainer changed the 
 way that required modules are handled, in part by removing the 'requires' 
 variable, but missed the try/except clause shown above. It probably remained 
 undiscovered this long due to my unusual installation sequence.
 This should be very simple to fix. I have pip.log if you need it, but I don't 
 see any way to attach files in this report form. I can email it to you if you 
 want.
 Questions? sc...@trotternet.com



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


[jira] [Closed] (CLOUDSTACK-7332) CloudMonkey setup.py undefined variable 'requires'

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav closed CLOUDSTACK-7332.
---


commit 9b97077d3bb22d53d116981ea11675f1aaafcfc1
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date:   Wed Aug 13 11:42:02 2014 +0200

CLOUDSTACK-7332: handle cloudmonkey installation for windows

Checks and appends pyreadline or readline to dependencies based on platform

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

 CloudMonkey setup.py undefined variable 'requires'
 --

 Key: CLOUDSTACK-7332
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7332
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Cloudmonkey
 Environment: Windows 8.1, cmd.exe, python 2.7.8, pip 1.5.6
Reporter: Scott Trotter
Assignee: Rohit Yadav
Priority: Minor
   Original Estimate: 1h
  Remaining Estimate: 1h

 I'm setting up a Windows system to see how effective (or not) it is for FOSS 
 development. I installed the following components, in order, one right after 
 another, using cmd.exe CLI, not PowerShell or Git Bash:
 Github for Windows 2.2.0.0
 Python (x64) 2.7.8
 ez_setup.py
 get-pip.py
 pip install cloudmonkey
 The latter resulted in the following error, which I copied from pip.log:
 File e:\temp\pip_build_Scott\cloudmonkey\setup.py, line 32, in module
 requires.append('readline')
 NameError: name 'requires' is not defined
 I downloaded apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2 and unpacked it 
 manually. Here is the problem area, starting with line 29:
 try:
 import readline
 except ImportError:
 requires.append('readline')
 This test FAILED on my system, but I'm guessing that it typically doesn't 
 fail on others because readline is typically already installed by the time 
 someone tries to install CloudMonkey.
 I also poked around in the repo, and it's easy to see how this bug got 
 introduced. In the last commit on Mar. 19, 2013, the maintainer changed the 
 way that required modules are handled, in part by removing the 'requires' 
 variable, but missed the try/except clause shown above. It probably remained 
 undiscovered this long due to my unusual installation sequence.
 This should be very simple to fix. I have pip.log if you need it, but I don't 
 see any way to attach files in this report form. I can email it to you if you 
 want.
 Questions? sc...@trotternet.com



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


[jira] [Updated] (CLOUDSTACK-7280) Add support for xenserver 6.5

2014-08-13 Thread Abhinandan Prateek (JIRA)

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

Abhinandan Prateek updated CLOUDSTACK-7280:
---

Assignee: Anthony Xu  (was: Damodar Reddy T)

 Add support for xenserver 6.5
 -

 Key: CLOUDSTACK-7280
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7280
 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.5.0
 Environment: Xenserver : 6.5  with vGPU drivers
 CS : 4.5.0
Reporter: Abhinav Roy
Assignee: Anthony Xu
Priority: Blocker
 Fix For: 4.5.0


 I am not able to add XEN 6.5 in my CS 4.5.0 setup. It says that the xenserver 
 version is not supported. 
 014-08-07 15:22:36,082 DEBUG [c.c.h.x.d.XcpServerDiscoverer] 
 (catalina-exec-1:ctx-0286b366 ctx-24e71e8e) other exceptions: 
 java.lang.RuntimeException: Only support XCP 1.0.0, 1.1.0, 1.4.x, 1.5 beta, 
 1.6.x; XenServer 5.6,  XenServer 5.6 FP1, XenServer 5.6 SP2, Xenserver 6.0, 
 6.0.2, 6.1.0, 6.2.0 but this one is XenServer 6.4.93
 java.lang.RuntimeException: Only support XCP 1.0.0, 1.1.0, 1.4.x, 1.5 beta, 
 1.6.x; XenServer 5.6,  XenServer 5.6 FP1, XenServer 5.6 SP2, Xenserver 6.0, 
 6.0.2, 6.1.0, 6.2.0 .
 Please add support for this version as it is blocking my vGPU testing.



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


[jira] [Updated] (CLOUDSTACK-7172) not getting Console view of vms in KVM

2014-08-13 Thread shweta agarwal (JIRA)

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

shweta agarwal updated CLOUDSTACK-7172:
---

Priority: Blocker  (was: Critical)

 not getting Console view of vms in KVM 
 ---

 Key: CLOUDSTACK-7172
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7172
 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: KVM  advance zone on build 
 CloudPlatform-4.5.0-78-rhel6.3.tar.gz
Reporter: shweta agarwal
Assignee: Murali Reddy
Priority: Blocker
 Fix For: 4.5.0

 Attachments: MSlog.tar.gz, kvmhostlog.tar.gz


 Repro steps:
 1. Create an  advacne zone with KVM  host .
 2. Once system vms are up and running try accessing console view of vm
 Bug : 
 Console view not coming up getting message The connection was reset
 Ms log shows :
 014-07-23 04:38:06,662 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-5:null) Ping from 3
 2014-07-23 04:38:09,002 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-4:null) SeqA 2-9868: Processing Seq 2-9868:  { Cmd , 
 MgmtId: -1, via: 2, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:1,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2014-07-23 04:38:09,049 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-4:null) SeqA 2-9868: Sending Seq 2-9868:  { Ans: , 
 MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 2014-07-23 04:38:18,964 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-13:null) SeqA 2-9869: Processing Seq 2-9869:  { Cmd , 
 MgmtId: -1, via: 2, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:1,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2014-07-23 04:38:19,034 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-13:null) SeqA 2-9869: Sending Seq 2-9869:  { Ans: , 
 MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 2014-07-23 04:38:21,992 DEBUG [c.c.s.StatsCollector] 
 (StatsCollector-4:ctx-a44d6b26) AutoScaling Monitor is running...
 2014-07-23 04:38:27,328 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
 (consoleproxy-1:ctx-2fbab117) Zone 1 is ready to launch console proxy
 2014-07-23 04:38:27,451 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
 (secstorage-1:ctx-99b6542a) Zone 1 is ready to launch secondary storage VM
 2014-07-23 04:38:28,964 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-20:null) SeqA 2-9870: Processing Seq 2-9870:  { Cmd , 
 MgmtId: -1, via: 2, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:1,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2014-07-23 04:38:29,029 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-20:null) SeqA 2-9870: Sending Seq 2-9870:  { Ans: , 
 MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 attaching agent and MS logs



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


[jira] [Updated] (CLOUDSTACK-7171) not getting console of user vm via virsh on kvm

2014-08-13 Thread shweta agarwal (JIRA)

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

shweta agarwal updated CLOUDSTACK-7171:
---

Priority: Blocker  (was: Critical)

 not getting console of user vm via virsh on kvm
 ---

 Key: CLOUDSTACK-7171
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7171
 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: KMV host on centos6.2 
 advance zone
Reporter: shweta agarwal
Assignee: Murali Reddy
Priority: Blocker
 Fix For: 4.5.0

 Attachments: MSlog.tar.gz, kvmhostlog.tar.gz


 Repro steps:
 Create a KVM(centos6.2) advance zone setup . Once everything is uop created a 
 user vm with default centos 5.5 template
 On KVM host try to access console of this user vm via vrish
 Bug :
 Nothing happens
 I even tried registering ubuntu template and created a ubuntu VM  still not 
 able to access console via virsh for ubuntu VM  as well
 But able to access console via virsh for system vms , CPVM, SSVM, router vm
 Attaching MS logs and kvm logs for the same



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


[jira] [Assigned] (CLOUDSTACK-7329) [Automation] Test suite test_region_vpc fails with error in service offering

2014-08-13 Thread Gaurav Aradhye (JIRA)

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

Gaurav Aradhye reassigned CLOUDSTACK-7329:
--

Assignee: Gaurav Aradhye

 [Automation] Test suite test_region_vpc fails with error in service 
 offering 
 ---

 Key: CLOUDSTACK-7329
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7329
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 Test cases from test_region_vpc failing due to wrong service offering 
 1) 
 integration.component.test_region_vpc.TestRegionVpcOffering.test_01_create_vpc_offering_with_regionlevelvpc_service_capability
 Error Message
 VPC offering is not set up for region level VPC
   begin captured stdout  -
 === TestName: 
 test_01_create_vpc_offering_with_regionlevelvpc_service_capability | Status : 
 FAILED ===
 -  end captured stdout  --
   begin captured logging  
 CSLog: DEBUG: Payload: {'apiKey': 
 u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
  'command': 'listDomains', 'signature': 'LT9kazKdEbvGfsD7KsWGo0Z9Zgw=', 
 'response': 'json'}
 CSLog: DEBUG: Sending GET Cmd : listDomains===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 2) 
 integration.component.test_region_vpc.TestRegionVpcOffering.test_02_create_vpc_from_offering_with_regionlevelvpc_service_capability
 Error Message
 VPC created should have 'distributedvpcrouter' set to True
   begin captured stdout  -
 === TestName: 
 test_02_create_vpc_from_offering_with_regionlevelvpc_service_capability | 
 Status : FAILED ===
 3) 
 integration.component.test_region_vpc.TestRegionVpcOffering.test_03_deploy_vms_in_vpc_with_regionlevelvp
 VPC offering is not set up for region level VPC



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


[jira] [Resolved] (CLOUDSTACK-7334) [VMware] AddHost command fails if there is a space in the VMware DC/Cluster name

2014-08-13 Thread Likitha Shetty (JIRA)

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

Likitha Shetty resolved CLOUDSTACK-7334.


Resolution: Fixed

 [VMware] AddHost command fails if there is a space in the VMware DC/Cluster 
 name
 

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


 If VMware DC contains a space character then adding a host to the 
 corresponding Zone in CCP fails with the below error - 
 {noformat}
 2014-08-13 10:39:47,468 DEBUG [c.c.a.ApiServlet] 
 (24967510@qtp-6691912-0:ctx-165190ee) ===START===  10.252.241.50 -- GET  
 command=addClusterzoneId=8fda1cb2-4673-4d65-8b18-d9fae061decbhypervisor=VMwareclustertype=ExternalManagedpodId=3aa2f52b-5cca-459b-9c30-8af3adb0fbc6username=administratorurl=http%3A%2F%2F10.102.192.248%2FTest%20Cloud%2FInteractive_Cloudclustername=10.102.192.248%2FCitrix%20Test%20Cloud%2FInteractive_Cloudresponse=jsonsessionkey=Zu6EOaK1gAqbBjrM%2Bls%2Fydj7IJU%3D_=1407907218055
 2014-08-13 10:39:47,545 INFO  [c.c.h.v.VmwareServerDiscoverer] 
 (24967510@qtp-6691912-0:ctx-165190ee ctx-bc3e621b) Discover host. dc: 1, pod: 
 1, cluster: 1, uri host: 10.102.192.248
 2014-08-13 10:39:47,552 ERROR [c.c.h.v.VmwareServerDiscoverer] 
 (24967510@qtp-6691912-0:ctx-165190ee ctx-bc3e621b) This cluster 
 Interactive_Cloud belongs to VMware DC Test+Cloud .But this zone is 
 associated with VMware DC Test Cloud. Make sure the cluster being added 
 belongs to VMware DC Test Cloud in vCenter 10.102.192.248
 2014-08-13 10:39:47,553 INFO  [c.c.u.e.CSExceptionErrorCode] 
 (24967510@qtp-6691912-0:ctx-165190ee ctx-bc3e621b) Could not find exception: 
 com.cloud.exception.DiscoveryException in error code list for exceptions
 2014-08-13 10:39:47,752 WARN  [o.a.c.a.c.a.c.AddClusterCmd] 
 (24967510@qtp-6691912-0:ctx-165190ee ctx-bc3e621b) Exception:
 com.cloud.exception.DiscoveryException: This cluster Interactive_Cloud 
 belongs to VMware DC Test+Cloud .But this zone is associated with VMware DC 
 Citrix Test Cloud. Make sure the cluster being added belongs to VMware DC 
 Test Cloud in vCenter 10.102.192.248
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.validateCluster(VmwareServerDiscoverer.java:489)
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.find(VmwareServerDiscoverer.java:152)
 at 
 com.cloud.resource.ResourceManagerImpl.discoverCluster(ResourceManagerImpl.java:511)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.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.$Proxy163.discoverCluster(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.cluster.AddClusterCmd.execute(AddClusterCmd.java:196)
 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 

[jira] [Resolved] (CLOUDSTACK-7306) [Automation] test_01_primary_storage_iscsi shouldn't run on KVM or HyperV

2014-08-13 Thread Alex Brett (JIRA)

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

Alex Brett resolved CLOUDSTACK-7306.


   Resolution: Fixed
Fix Version/s: 4.5.0

Fixed in commit 4c4d89f4d93c25e551dc094ebce1bc4c5ee5b16d

 [Automation] test_01_primary_storage_iscsi shouldn't run on KVM or HyperV
 -

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


 test_01_primary_storage_iscsi in 
 test/integration/smoke/test_primary_storage.py currently attempts to set up 
 an iSCSI primary storage pool, regardless of the type of host.
 For KVM, we only support iSCSI via shared mount point, and for Hyper-V we 
 don't support it at all, so the test should skip in these cases.



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


[jira] [Commented] (CLOUDSTACK-7333) [vGPU] Windows VM with GPU cards and PV drivers is going to repair state when deployed with dynamic scaling enabled option.

2014-08-13 Thread Abhinav Roy (JIRA)

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

Abhinav Roy commented on CLOUDSTACK-7333:
-

The same behavior has been seen with windows 7 VMs also.

 [vGPU] Windows VM with GPU cards and PV drivers is going to repair state when 
 deployed with dynamic scaling enabled option.
 -

 Key: CLOUDSTACK-7333
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7333
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.5.0
 Environment: Xenserver 6.2.5  + PV drivers (up to date)
Reporter: Abhinav Roy
Priority: Blocker
 Fix For: 4.5.0

 Attachments: CS-7333.zip


 There are 4 scenarios which i tried :
 Setup :
 =
 CS 4.5 advanced zone with Xen 6.2.5 + PV drivers ( XS Tools)
 Dynamic scaling is enabled on zone level.
 Scenario 1 :
 
 1. Register a windows 8 or windows 2012 template ( without dynamic scaling 
 enabled) and deploy a VM with vGPU service offering from it.
  
   -- Template is registered and VM is deployed. 
 2. Install the PV drivers on the VM.
   -- PV drivers are installed successfully (make sure they are latest)
 3. Now stop the VM, enable dynamic scaling and start the VM.
   -- VM fails to start and goes into the repair state.
 Scenario 2 :
 
 1. Register a windows 8 or windows 2012 template ( with dynamic scaling 
 enabled) and deploy a VM with vGPU service offering from it.
  
   -- Template is registered and VM is deployed. 
 2. Install the PV drivers on the VM.
   -- PV drivers fail to install and VM goes to repair state.
 Scenario 3 :
 
 1. Register a windows 8 or windows 2012 template ( with dynamic scaling 
 enabled and PV drivers installed) and deploy a VM with vGPU service offering 
 from it.
  
   -- Template is registered and VM fails to deploy, it goes into repair 
 state. 
 Scenario 4 :
 
 1. Register a windows 8 or windows 2012 template ( without dynamic scaling 
 enabled but PV drivers are installed) and deploy a VM with vGPU service 
 offering from it.
  
   -- Template is registered and VM is deployed. 
 2. Now stop the VM, enable dynamic scaling and start the VM.
   -- VM fails to start and goes into the repair state
 Scenario 5 :
 
 1. Register a windows 8 or windows 2012 ISO and deploy a VM with vGPU service 
 offering from it.
  
   -- ISO is registered and VM is deployed. 
 2. Install the PV drivers on the VM.
   -- PV drivers are installed successfully (make sure they are latest)
 3. Now stop the VM, enable dynamic scaling and start the VM.
   -- VM fails to start and goes into the repair state



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


[jira] [Created] (CLOUDSTACK-7335) Automation:integration.smoke.test_templates.TestTemplates.test_06_copy_template Failed

2014-08-13 Thread Bharat Kumar (JIRA)
Bharat Kumar created CLOUDSTACK-7335:


 Summary: 
Automation:integration.smoke.test_templates.TestTemplates.test_06_copy_template 
Failed
 Key: CLOUDSTACK-7335
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7335
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
Reporter: Bharat Kumar
Assignee: Bharat Kumar
 Fix For: 4.5.0


 Below TC Failed in CI Run
Automation:integration.smoke.test_templates.TestTemplates.test_06_copy_template 
Failed
Log File Path Below :  
http://nfs1.lab.vmops.com/automation//ccp-4.5/kvm/kvm__Log_15774.zip
Failure Message:
Job failed: {jobprocstatus : 0, created : u'2014-08-10T18:16:33-0700', 
jobresult :
{errorcode : 530, errortext : u'Failed to copy template'}
, cmd : 
u'org.apache.cloudstack.api.command.admin.template.CopyTemplateCmdByAdmin', 
userid : u'a7abf822-20ef-11e4-b052-00163e5d4a0e', jobstatus : 2, jobid : 
u'fde11b0d-af9a-45e0-962f-5af9d2bacf6d', jobresultcode : 530, jobinstanceid : 
u'a89d6284-2c2d-4ff4-a356-925f992bf43c', jobresulttype : u'object', 
jobinstancetype : u'Template', accountid : 
u'a7abc352-20ef-11e4-b052-00163e5d4a0e'}
  begin captured stdout  -
=== TestName: test_06_copy_template | Status : EXCEPTION ===
-  end captured stdout  --
  begin captured logging  
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
STARTED : TC: test_06_copy_template :::
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
Copy template from Zone: a54cb8bf-9060-445a-bb45-98f3e0a07bfd to 
ba915df8-d4ef-4901-848b-e8d8257ba830
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
Payload:
{'sourcezoneid': u'a54cb8bf-9060-445a-bb45-98f3e0a07bfd', 'apiKey': 
u'mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtw',
 'id': u'a89d6284-2c2d-4ff4-a356-925f992bf43c', 'command': 'copyTemplate', 
'signature': 'kFETVPXF0CRW1R+SRw60s/WjG3U=', 'destzoneid': 
u'ba915df8-d4ef-4901-848b-e8d8257ba830', 'response': 'json'}
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
Sending GET Cmd : copyTemplate===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 172.16.88.28
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?sourcezoneid=a54cb8bf-9060-445a-bb45-98f3e0a07bfdapiKey=mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtwdestzoneid=ba915df8-d4ef-4901-848b-e8d8257ba830command=copyTemplatesignature=kFETVPXF0CRW1R%2BSRw60s%2FWjG3U%3Dresponse=jsonid=a89d6284-2c2d-4ff4-a356-925f992bf43c
 HTTP/1.1 200 77
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
=== Jobid: fde11b0d-af9a-45e0-962f-5af9d2bacf6d Started ===
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
Payload:
{'signature': 'qlhp3LhXoNOXP3MeHVgc+aLpoKg=', 'apiKey': 
u'mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtw',
 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
u'fde11b0d-af9a-45e0-962f-5af9d2bacf6d'}
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 172.16.88.28
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?jobid=fde11b0d-af9a-45e0-962f-5af9d2bacf6dapiKey=mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtwcommand=queryAsyncJobResultresponse=jsonsignature=qlhp3LhXoNOXP3MeHVgc%2BaLpoKg%3D
 HTTP/1.1 200 434
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
Response :
{jobprocstatus : 0, created : u'2014-08-10T18:16:33-0700', cmd : 
u'org.apache.cloudstack.api.command.admin.template.CopyTemplateCmdByAdmin', 
userid : u'a7abf822-20ef-11e4-b052-00163e5d4a0e', jobstatus : 0, jobid : 
u'fde11b0d-af9a-45e0-962f-5af9d2bacf6d', jobresultcode : 0, jobinstanceid : 
u'a89d6284-2c2d-4ff4-a356-925f992bf43c', jobinstancetype : u'Template', 
accountid : u'a7abc352-20ef-11e4-b052-00163e5d4a0e'}
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
=== JobId:fde11b0d-af9a-45e0-962f-5af9d2bacf6d is Still Processing, Will 
TimeOut in:3595 
test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: 
Payload:
{'signature': 'qlhp3LhXoNOXP3MeHVgc+aLpoKg=', 'apiKey': 
u'mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtw',
 'command': 

[jira] [Commented] (CLOUDSTACK-7329) [Automation] Test suite test_region_vpc fails with error in service offering

2014-08-13 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-7329: Fixed issues in test_region_vpc.py

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


 [Automation] Test suite test_region_vpc fails with error in service 
 offering 
 ---

 Key: CLOUDSTACK-7329
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7329
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 Test cases from test_region_vpc failing due to wrong service offering 
 1) 
 integration.component.test_region_vpc.TestRegionVpcOffering.test_01_create_vpc_offering_with_regionlevelvpc_service_capability
 Error Message
 VPC offering is not set up for region level VPC
   begin captured stdout  -
 === TestName: 
 test_01_create_vpc_offering_with_regionlevelvpc_service_capability | Status : 
 FAILED ===
 -  end captured stdout  --
   begin captured logging  
 CSLog: DEBUG: Payload: {'apiKey': 
 u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
  'command': 'listDomains', 'signature': 'LT9kazKdEbvGfsD7KsWGo0Z9Zgw=', 
 'response': 'json'}
 CSLog: DEBUG: Sending GET Cmd : listDomains===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 2) 
 integration.component.test_region_vpc.TestRegionVpcOffering.test_02_create_vpc_from_offering_with_regionlevelvpc_service_capability
 Error Message
 VPC created should have 'distributedvpcrouter' set to True
   begin captured stdout  -
 === TestName: 
 test_02_create_vpc_from_offering_with_regionlevelvpc_service_capability | 
 Status : FAILED ===
 3) 
 integration.component.test_region_vpc.TestRegionVpcOffering.test_03_deploy_vms_in_vpc_with_regionlevelvp
 VPC offering is not set up for region level VPC



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


[jira] [Commented] (CLOUDSTACK-7330) [Automation] test_persistent_networks.TestVPCNetworkOperations test failed to ListNetwrok API call

2014-08-13 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-7330: Fixing ListNetworks issue in test_portable_ip.py

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


 [Automation] test_persistent_networks.TestVPCNetworkOperations test failed to 
 ListNetwrok API call 
 ---

 Key: CLOUDSTACK-7330
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7330
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 Test integration/component/test_persistent_networks.py, line 1928, in 
 test_vpc_force_delete_domain failing while list network 
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Response : {domain : u'domain-4M0XO1', specifyipranges : False, 
 related : u'6286d150-0603-45e1-8ae7-7c017ea08f00', zoneid : 
 u'169dbf29-8372-43f9-891d-8002e7d27f3f', domainid : 
 u'427de23b-229f-48f1-8a4d-ce700e66fbc6', displaytext : u'Isolated Network', 
 gateway : u'10.1.1.1', canusefordeploy : True, physicalnetworkid : 
 u'8cf2dd88-61b7-45b5-9be9-79acc15981de', networkdomain : 
 u'csbcauto.advanced', service : [{name : u'StaticNat'}, {capability : [{value 
 : u'true', name : u'DhcpAccrossMultipleSubnets', canchooseservicecapability : 
 False}], name : u'Dhcp'}, {capability : [{value : u's2svpn', name : 
 u'VpnTypes', canchooseservicecapability : False}, {value : 
 u'pptp,l2tp,ipsec', name : u'SupportedVpnTypes', canchooseservicecapability : 
 False}], name : u'Vpn'}, {capability : [{value : u'peraccount', name : 
 u'SupportedSourceNatTypes', canchooseservicecapability : False}, {value : 
 u'false', name : u'RedundantRouter', canchooseservicecapability : False}], 
 name : u'SourceNat'}, {name : u'PortForwarding'}, {capability : [{value : 
 u'tcp,udp,icmp', name : u'SupportedProtocols', canchooseservicecapability : 
 False}], name : u'NetworkACL'}, {capability : [{value : u'true', name : 
 u'AllowDnsSuffixModification', canchooseservicecapability : False}], name : 
 u'Dns'}, {name : u'UserData'}], strechedl2subnet : False, id : 
 u'6286d150-0603-45e1-8ae7-7c017ea08f00', state : u'Implemented', type : 
 u'Isolated', broadcasturi : u'vlan://2347', zonename : u'Adv-KVM-Zone1', 
 networkofferingavailability : u'Optional', networkofferingid : 
 u'1079d837-1006-4ed4-8275-3874dc03f352', tags : [], displaynetwork : True, 
 vlan : u'2347', networkofferingdisplaytext : u'VPC Network off-CZSZH7', 
 traffictype : u'Guest', netmask : u'255.255.255.0', vpcid : 
 u'f1c80510-9971-49de-a25a-3b421a6927ce', cidr : u'10.1.1.0/24', 
 restartrequired : False, broadcastdomaintype : u'Vlan', account : 
 u'test-a-TestVPCNetworkOperations-test_vpc_force_delete_domain-3K82RQ', 
 ispersistent : True, name : u'Isolated Network', dns1 : u'8.8.8.8', 
 networkofferingconservemode : False, acltype : u'Account', 
 networkofferingname : u'VPC Network offering-B2EPH9', issystem : False}
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Payload: {'apiKey': 
 u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
  'id': u'6286d150-0603-45e1-8ae7-7c017ea08f00', 'response': 'json', 
 'command': 'listNetworks', 'signature': 'd4+7JeVeAlODVIDRzOkZtn5wxh0='}
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Sending GET Cmd : listNetworks===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=d4%2B7JeVeAlODVIDRzOkZtn5wxh0%3DapiKey=78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQcommand=listNetworksid=6286d150-0603-45e1-8ae7-7c017ea08f00response=json
  HTTP/1.1 200 32
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Response : None
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 CRITICAL: FAILED: test_vpc_force_delete_domain: ['Traceback (most recent call 
 last):\n', '  File 

[jira] [Resolved] (CLOUDSTACK-7329) [Automation] Test suite test_region_vpc fails with error in service offering

2014-08-13 Thread Gaurav Aradhye (JIRA)

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

Gaurav Aradhye resolved CLOUDSTACK-7329.


Resolution: Fixed

 [Automation] Test suite test_region_vpc fails with error in service 
 offering 
 ---

 Key: CLOUDSTACK-7329
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7329
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 Test cases from test_region_vpc failing due to wrong service offering 
 1) 
 integration.component.test_region_vpc.TestRegionVpcOffering.test_01_create_vpc_offering_with_regionlevelvpc_service_capability
 Error Message
 VPC offering is not set up for region level VPC
   begin captured stdout  -
 === TestName: 
 test_01_create_vpc_offering_with_regionlevelvpc_service_capability | Status : 
 FAILED ===
 -  end captured stdout  --
   begin captured logging  
 CSLog: DEBUG: Payload: {'apiKey': 
 u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
  'command': 'listDomains', 'signature': 'LT9kazKdEbvGfsD7KsWGo0Z9Zgw=', 
 'response': 'json'}
 CSLog: DEBUG: Sending GET Cmd : listDomains===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 2) 
 integration.component.test_region_vpc.TestRegionVpcOffering.test_02_create_vpc_from_offering_with_regionlevelvpc_service_capability
 Error Message
 VPC created should have 'distributedvpcrouter' set to True
   begin captured stdout  -
 === TestName: 
 test_02_create_vpc_from_offering_with_regionlevelvpc_service_capability | 
 Status : FAILED ===
 3) 
 integration.component.test_region_vpc.TestRegionVpcOffering.test_03_deploy_vms_in_vpc_with_regionlevelvp
 VPC offering is not set up for region level VPC



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


[jira] [Resolved] (CLOUDSTACK-7330) [Automation] test_persistent_networks.TestVPCNetworkOperations test failed to ListNetwrok API call

2014-08-13 Thread Gaurav Aradhye (JIRA)

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

Gaurav Aradhye resolved CLOUDSTACK-7330.


Resolution: Fixed

 [Automation] test_persistent_networks.TestVPCNetworkOperations test failed to 
 ListNetwrok API call 
 ---

 Key: CLOUDSTACK-7330
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7330
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 Test integration/component/test_persistent_networks.py, line 1928, in 
 test_vpc_force_delete_domain failing while list network 
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Response : {domain : u'domain-4M0XO1', specifyipranges : False, 
 related : u'6286d150-0603-45e1-8ae7-7c017ea08f00', zoneid : 
 u'169dbf29-8372-43f9-891d-8002e7d27f3f', domainid : 
 u'427de23b-229f-48f1-8a4d-ce700e66fbc6', displaytext : u'Isolated Network', 
 gateway : u'10.1.1.1', canusefordeploy : True, physicalnetworkid : 
 u'8cf2dd88-61b7-45b5-9be9-79acc15981de', networkdomain : 
 u'csbcauto.advanced', service : [{name : u'StaticNat'}, {capability : [{value 
 : u'true', name : u'DhcpAccrossMultipleSubnets', canchooseservicecapability : 
 False}], name : u'Dhcp'}, {capability : [{value : u's2svpn', name : 
 u'VpnTypes', canchooseservicecapability : False}, {value : 
 u'pptp,l2tp,ipsec', name : u'SupportedVpnTypes', canchooseservicecapability : 
 False}], name : u'Vpn'}, {capability : [{value : u'peraccount', name : 
 u'SupportedSourceNatTypes', canchooseservicecapability : False}, {value : 
 u'false', name : u'RedundantRouter', canchooseservicecapability : False}], 
 name : u'SourceNat'}, {name : u'PortForwarding'}, {capability : [{value : 
 u'tcp,udp,icmp', name : u'SupportedProtocols', canchooseservicecapability : 
 False}], name : u'NetworkACL'}, {capability : [{value : u'true', name : 
 u'AllowDnsSuffixModification', canchooseservicecapability : False}], name : 
 u'Dns'}, {name : u'UserData'}], strechedl2subnet : False, id : 
 u'6286d150-0603-45e1-8ae7-7c017ea08f00', state : u'Implemented', type : 
 u'Isolated', broadcasturi : u'vlan://2347', zonename : u'Adv-KVM-Zone1', 
 networkofferingavailability : u'Optional', networkofferingid : 
 u'1079d837-1006-4ed4-8275-3874dc03f352', tags : [], displaynetwork : True, 
 vlan : u'2347', networkofferingdisplaytext : u'VPC Network off-CZSZH7', 
 traffictype : u'Guest', netmask : u'255.255.255.0', vpcid : 
 u'f1c80510-9971-49de-a25a-3b421a6927ce', cidr : u'10.1.1.0/24', 
 restartrequired : False, broadcastdomaintype : u'Vlan', account : 
 u'test-a-TestVPCNetworkOperations-test_vpc_force_delete_domain-3K82RQ', 
 ispersistent : True, name : u'Isolated Network', dns1 : u'8.8.8.8', 
 networkofferingconservemode : False, acltype : u'Account', 
 networkofferingname : u'VPC Network offering-B2EPH9', issystem : False}
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Payload: {'apiKey': 
 u'78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQ',
  'id': u'6286d150-0603-45e1-8ae7-7c017ea08f00', 'response': 'json', 
 'command': 'listNetworks', 'signature': 'd4+7JeVeAlODVIDRzOkZtn5wxh0='}
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Sending GET Cmd : listNetworks===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=d4%2B7JeVeAlODVIDRzOkZtn5wxh0%3DapiKey=78MI-CP2cM9Oc6lGqvgXYmL_Cw3i-tLSPo4K4Vivv04g8OXByYZBG9zQe_MqXMqFKP-1IDmilhtG8Zgqx1exnQcommand=listNetworksid=6286d150-0603-45e1-8ae7-7c017ea08f00response=json
  HTTP/1.1 200 32
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 DEBUG: Response : None
 test_vpc_force_delete_domain 
 (integration.component.test_persistent_networks.TestVPCNetworkOperations): 
 CRITICAL: FAILED: test_vpc_force_delete_domain: ['Traceback (most recent call 
 last):\n', '  File /usr/local/lib/python2.7/unittest/case.py, line 318, in 
 run\ntestMethod()\n', '  File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_persistent_networks.py,
  line 1928, in test_vpc_force_delete_domain\nself.fail(e)\n', '  File 
 /usr/local/lib/python2.7/unittest/case.py, line 393, in fail\nraise 
 self.failureException(msg)\n', 'AssertionError: Networks list 

[jira] [Commented] (CLOUDSTACK-7284) Holder for KVM regression test script issues

2014-08-13 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-7284: Fixed string issue in test_snapshots.py


 Holder for KVM regression test script issues
 

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


 This bug is holder for all test script issues identified in KVM regression 
 run.



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


[jira] [Created] (CLOUDSTACK-7337) Volume creation failure keeps the volume in allocated state

2014-08-13 Thread Harikrishna Patnala (JIRA)
Harikrishna Patnala created CLOUDSTACK-7337:
---

 Summary: Volume creation failure keeps the volume in allocated 
state
 Key: CLOUDSTACK-7337
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7337
 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: Harikrishna Patnala
Assignee: Harikrishna Patnala
 Fix For: 4.5.0


when we try to create volume from a snapshot and upon any failure CS throws 
exception but the volume is still in Allocated state.
This may lead to problems with the further operations when this volume (in 
allocated) is used to attach to a VM.

We need to mark the volume to Destroy state so that no one can use that volume 
and Storage GC will clean it up later.



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


[jira] [Commented] (CLOUDSTACK-7337) Volume creation failure keeps the volume in allocated state

2014-08-13 Thread Harikrishna Patnala (JIRA)

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

Harikrishna Patnala commented on CLOUDSTACK-7337:
-

Ready to review @ https://reviews.apache.org/r/24646/

 Volume creation failure keeps the volume in allocated state
 ---

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


 when we try to create volume from a snapshot and upon any failure CS throws 
 exception but the volume is still in Allocated state.
 This may lead to problems with the further operations when this volume (in 
 allocated) is used to attach to a VM.
 We need to mark the volume to Destroy state so that no one can use that 
 volume and Storage GC will clean it up later.



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


[jira] [Updated] (CLOUDSTACK-7337) Volume creation failure keeps the volume in allocated state

2014-08-13 Thread Harikrishna Patnala (JIRA)

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

Harikrishna Patnala updated CLOUDSTACK-7337:


Status: Reviewable  (was: In Progress)

 Volume creation failure keeps the volume in allocated state
 ---

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


 when we try to create volume from a snapshot and upon any failure CS throws 
 exception but the volume is still in Allocated state.
 This may lead to problems with the further operations when this volume (in 
 allocated) is used to attach to a VM.
 We need to mark the volume to Destroy state so that no one can use that 
 volume and Storage GC will clean it up later.



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


[jira] [Commented] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav commented on CLOUDSTACK-4770:
-

In my case, I used a host which was previous used for some ACS testing and had 
cloud0 interface which had the mac ID 0x00.
So, to fix this as a workaround one can delete the cloud0 bridge or any bridge 
that gets created by cloudstack and if safe to delete.
For ubuntu:
ifconfig -a | head -1 # get the name of the first interface, see if it has mac 
address == 0x00
brctl delbr cloud0

After this, macaddress should succeed with finding a non zero address; (from 
4.4.1)
java -classpath 
/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.4.1-SNAPSHOT.jar
 com.cloud.utils.net.MacAddress

We can perhaps document this. In the bugfix, I'll add a case to skip both 0xff 
and 0x00 address and let it try next interfaces.

 Management server fails to start with Unable to get the management server 
 node due to downed interface with no MAC address 
 -

 Key: CLOUDSTACK-4770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.1, 4.2.0, 4.4.0
 Environment: CentOS 6.4, Ubuntu 14.04
Reporter: Richard Chatterton
Priority: Minor

 Installing CloudStack 4.1.1 today, the management server failed to start with 
 the following errors:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I 
 attempted to reinstall with CloudStack 4.2.0. This produced the following 
 error messages:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 com.cloud.utils.exception.CloudRuntimeException: Unable to get the management 
 server node id
 at 
 com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46)
 at 
 com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90)
 at 
 com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)
 I found a mailing list post which mentioned that this might be due to missing 
 MAC address, and recommended testing by running the class directly. This 
 produced the following output for me:
 $ java -classpath 
 /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar
  com.cloud.utils.net.MacAddress
 addr in integer is 0
 addr in bytes is  0 0 0 0 0 0
 addr in char is 00:00:00:00:00:00
 This was odd to me, as the output of ifconfig didn't have any MAC addresses 
 that were 00:00:00:00:00:00. Looking into the code for that module, I found 
 that what it appears to be doing is parsing ifconfig -a and returning the 
 first string that looks like a MAC address. Reviewing the ifconfig -a output 
 on the server, there was a downed bond interface with a MAC address of 
 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC 
 address from one of its slave physical interfaces.
 After assigning a dummy IP address to that interface and upping it, it 
 received a MAC address and I was able to start the management server normally.
 I expect that there may be a better way to determine what the node id for the 
 management server should be, or logic could be implemented to look for 
 another MAC address if the first once it receives is invalid. Alternatively, 
 if this behavior is expected, logging/debugging resources should be provided 
 to help the user correct the problem.



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


[jira] [Updated] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav updated CLOUDSTACK-4770:


Fix Version/s: 4.4.1
   4.5.0

 Management server fails to start with Unable to get the management server 
 node due to downed interface with no MAC address 
 -

 Key: CLOUDSTACK-4770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.1, 4.2.0, 4.4.0
 Environment: CentOS 6.4, Ubuntu 14.04
Reporter: Richard Chatterton
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.0, 4.4.1


 Installing CloudStack 4.1.1 today, the management server failed to start with 
 the following errors:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I 
 attempted to reinstall with CloudStack 4.2.0. This produced the following 
 error messages:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 com.cloud.utils.exception.CloudRuntimeException: Unable to get the management 
 server node id
 at 
 com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46)
 at 
 com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90)
 at 
 com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)
 I found a mailing list post which mentioned that this might be due to missing 
 MAC address, and recommended testing by running the class directly. This 
 produced the following output for me:
 $ java -classpath 
 /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar
  com.cloud.utils.net.MacAddress
 addr in integer is 0
 addr in bytes is  0 0 0 0 0 0
 addr in char is 00:00:00:00:00:00
 This was odd to me, as the output of ifconfig didn't have any MAC addresses 
 that were 00:00:00:00:00:00. Looking into the code for that module, I found 
 that what it appears to be doing is parsing ifconfig -a and returning the 
 first string that looks like a MAC address. Reviewing the ifconfig -a output 
 on the server, there was a downed bond interface with a MAC address of 
 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC 
 address from one of its slave physical interfaces.
 After assigning a dummy IP address to that interface and upping it, it 
 received a MAC address and I was able to start the management server normally.
 I expect that there may be a better way to determine what the node id for the 
 management server should be, or logic could be implemented to look for 
 another MAC address if the first once it receives is invalid. Alternatively, 
 if this behavior is expected, logging/debugging resources should be provided 
 to help the user correct the problem.



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


[jira] [Assigned] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav reassigned CLOUDSTACK-4770:
---

Assignee: Rohit Yadav

 Management server fails to start with Unable to get the management server 
 node due to downed interface with no MAC address 
 -

 Key: CLOUDSTACK-4770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.1, 4.2.0, 4.4.0
 Environment: CentOS 6.4, Ubuntu 14.04
Reporter: Richard Chatterton
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.0, 4.4.1


 Installing CloudStack 4.1.1 today, the management server failed to start with 
 the following errors:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I 
 attempted to reinstall with CloudStack 4.2.0. This produced the following 
 error messages:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 com.cloud.utils.exception.CloudRuntimeException: Unable to get the management 
 server node id
 at 
 com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46)
 at 
 com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90)
 at 
 com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)
 I found a mailing list post which mentioned that this might be due to missing 
 MAC address, and recommended testing by running the class directly. This 
 produced the following output for me:
 $ java -classpath 
 /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar
  com.cloud.utils.net.MacAddress
 addr in integer is 0
 addr in bytes is  0 0 0 0 0 0
 addr in char is 00:00:00:00:00:00
 This was odd to me, as the output of ifconfig didn't have any MAC addresses 
 that were 00:00:00:00:00:00. Looking into the code for that module, I found 
 that what it appears to be doing is parsing ifconfig -a and returning the 
 first string that looks like a MAC address. Reviewing the ifconfig -a output 
 on the server, there was a downed bond interface with a MAC address of 
 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC 
 address from one of its slave physical interfaces.
 After assigning a dummy IP address to that interface and upping it, it 
 received a MAC address and I was able to start the management server normally.
 I expect that there may be a better way to determine what the node id for the 
 management server should be, or logic could be implemented to look for 
 another MAC address if the first once it receives is invalid. Alternatively, 
 if this behavior is expected, logging/debugging resources should be provided 
 to help the user correct the problem.



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


[jira] [Commented] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address

2014-08-13 Thread ASF subversion and git services (JIRA)

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

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

Commit 3b5aa42c6d87fb7e2573146efb8c7d2d0a4692b3 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3b5aa42 ]

CLOUDSTACK-4770: In MacAddress skip macAddress when parsed value is 0x00

In MacAddress class, we start by settig macAddress String as null and go through
the output of ifconfig -a and pick the one string that is a valid mac address
but is not 0x00 and 0xff. With each loop we set the macAddress to null so that
it does not pick the last one if everything fails.

Tested on Ubuntu where I had an interface called cloud0 whose mac id was 0x00
and it was skipped to get the next one:

$ java -classpath path-to-cloud-utils.jar com.cloud.utils.net.MacAddress
addr in integer is 5071953436
addr in bytes is  0 1 2e 4f de 1c
addr in char is 00:01:2e:4f:de:1c

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 Management server fails to start with Unable to get the management server 
 node due to downed interface with no MAC address 
 -

 Key: CLOUDSTACK-4770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.1, 4.2.0, 4.4.0
 Environment: CentOS 6.4, Ubuntu 14.04
Reporter: Richard Chatterton
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.0, 4.4.1


 Installing CloudStack 4.1.1 today, the management server failed to start with 
 the following errors:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I 
 attempted to reinstall with CloudStack 4.2.0. This produced the following 
 error messages:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 com.cloud.utils.exception.CloudRuntimeException: Unable to get the management 
 server node id
 at 
 com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46)
 at 
 com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90)
 at 
 com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)
 I found a mailing list post which mentioned that this might be due to missing 
 MAC address, and recommended testing by running the class directly. This 
 produced the following output for me:
 $ java -classpath 
 /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar
  com.cloud.utils.net.MacAddress
 addr in integer is 0
 addr in bytes is  0 0 0 0 0 0
 addr in char is 00:00:00:00:00:00
 This was odd to me, as the output of ifconfig didn't have any MAC addresses 
 that were 00:00:00:00:00:00. Looking into the code for that module, I found 
 that what it appears to be doing is parsing ifconfig -a and returning the 
 first string that looks like a MAC address. Reviewing the ifconfig -a output 
 on the server, there was a downed bond interface with a MAC address of 
 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC 
 address from one of its slave physical interfaces.
 After assigning a dummy IP address to that interface and upping it, it 
 received a MAC address and I was able to start the management server normally.
 I expect that there may be a better way to determine what the node id for the 
 management server should be, or logic could be implemented to look for 
 another MAC address if the first once it receives is invalid. Alternatively, 
 if this behavior is expected, logging/debugging resources should be provided 
 to help the user correct the problem.



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


[jira] [Resolved] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav resolved CLOUDSTACK-4770.
-

Resolution: Fixed

Fixed for master/4.5.0 to skip macAddress if 0x00 is found

 Management server fails to start with Unable to get the management server 
 node due to downed interface with no MAC address 
 -

 Key: CLOUDSTACK-4770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.1, 4.2.0, 4.4.0
 Environment: CentOS 6.4, Ubuntu 14.04
Reporter: Richard Chatterton
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.0, 4.4.1


 Installing CloudStack 4.1.1 today, the management server failed to start with 
 the following errors:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I 
 attempted to reinstall with CloudStack 4.2.0. This produced the following 
 error messages:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 com.cloud.utils.exception.CloudRuntimeException: Unable to get the management 
 server node id
 at 
 com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46)
 at 
 com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90)
 at 
 com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)
 I found a mailing list post which mentioned that this might be due to missing 
 MAC address, and recommended testing by running the class directly. This 
 produced the following output for me:
 $ java -classpath 
 /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar
  com.cloud.utils.net.MacAddress
 addr in integer is 0
 addr in bytes is  0 0 0 0 0 0
 addr in char is 00:00:00:00:00:00
 This was odd to me, as the output of ifconfig didn't have any MAC addresses 
 that were 00:00:00:00:00:00. Looking into the code for that module, I found 
 that what it appears to be doing is parsing ifconfig -a and returning the 
 first string that looks like a MAC address. Reviewing the ifconfig -a output 
 on the server, there was a downed bond interface with a MAC address of 
 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC 
 address from one of its slave physical interfaces.
 After assigning a dummy IP address to that interface and upping it, it 
 received a MAC address and I was able to start the management server normally.
 I expect that there may be a better way to determine what the node id for the 
 management server should be, or logic could be implemented to look for 
 another MAC address if the first once it receives is invalid. Alternatively, 
 if this behavior is expected, logging/debugging resources should be provided 
 to help the user correct the problem.



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


[jira] [Commented] (CLOUDSTACK-7284) Holder for KVM regression test script issues

2014-08-13 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-7284: Fixed regression issue in test_escalations_instances.py


 Holder for KVM regression test script issues
 

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


 This bug is holder for all test script issues identified in KVM regression 
 run.



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


[jira] [Commented] (CLOUDSTACK-7310) [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer

2014-08-13 Thread John Dilley (JIRA)

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

John Dilley commented on CLOUDSTACK-7310:
-

I can't see any patch for this? I've put one up for review at 
https://reviews.apache.org/r/24648/ because I can't see any time when shrinking 
would be valid - QCOW2 doesn't support it, and nor does XenServer.

 [Automation] XenServer does not support shrink data disk. CloudStack should 
 prevent such an operation on XenServer
 --

 Key: CLOUDSTACK-7310
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Volumes, XenServer
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Animesh Chaturvedi
Priority: Critical
 Fix For: 4.5.0


 XenServer does not allowing shrinking of disks currently. Please add code on 
 Cloudstack to prevent such an operation (similar to VMWare case). Failing to 
 prevent such an operation on XenServer leads to 
 https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . 



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


[jira] [Created] (CLOUDSTACK-7338) [vGPU] Live migration of GPU enabled VM fails with Live Migration of GPU enabled VM is not supported

2014-08-13 Thread Abhinav Roy (JIRA)
Abhinav Roy created CLOUDSTACK-7338:
---

 Summary: [vGPU] Live migration of GPU enabled VM fails with Live 
Migration of GPU enabled VM is not supported
 Key: CLOUDSTACK-7338
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7338
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.5.0
 Environment: Xenserver 6.2.5 + GPU cards
Reporter: Abhinav Roy
Priority: Blocker
 Fix For: 4.5.0


Steps :

1. Deploy an advanced zone CS 4.5.0 setup with 2 GPU enabled hosts in a cluster.
2. Register a windows 8 template with PV drivers.
3. create a VM vm1 with the template registered above on host1.
4. Live migrate vm1 to host2


Expected behavior :

Live migration should be successful.

Observed behavior :
===
Live migration fails with the following exception

2014-08-13 20:04:10,104 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-89:ctx-73c2d9da job-404) Executing AsyncJobVO {id:404, 
userId: 1, accountId: 1, instanceType: None, instanceId: null, cmd: 
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo: 
{ctxDetails:{\com.cloud.vm.VirtualMachine\:26,\com.cloud.host.Host\:5,\com.cloud.uservm.UserVm\:26,\com.cloud.network.router.VirtualRouter\:26},virtualmachineid:26,cmdEventType:VM.MIGRATE,hostid:5,ctxUserId:1,httpmethod:GET,ctxAccountId:1,ctxStartEventId:602,apiKey:,signature:hhjnohmcAc63BXTHmXQu58w3plY\u003d},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-08-13 20:04:10,187 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-89:ctx-73c2d9da job-404) Unexpected exception while executing 
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
com.cloud.exception.InvalidParameterValueException: Live Migration of GPU 
enabled VM is not supported
at 
com.cloud.vm.UserVmManagerImpl.migrateVirtualMachine(UserVmManagerImpl.java:3860)
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.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy211.migrateVirtualMachine(Unknown Source)
at 
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:161)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at 
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
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 

[jira] [Updated] (CLOUDSTACK-7338) [vGPU] Live migration of GPU enabled VM fails with Live Migration of GPU enabled VM is not supported

2014-08-13 Thread Abhinav Roy (JIRA)

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

Abhinav Roy updated CLOUDSTACK-7338:


Attachment: CS-7338.zip

Attaching MS logs and DB dump

 [vGPU] Live migration of GPU enabled VM fails with Live Migration of GPU 
 enabled VM is not supported
 --

 Key: CLOUDSTACK-7338
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7338
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
 Environment: Xenserver 6.2.5 + GPU cards
Reporter: Abhinav Roy
Priority: Blocker
 Fix For: 4.5.0

 Attachments: CS-7338.zip


 Steps :
 
 1. Deploy an advanced zone CS 4.5.0 setup with 2 GPU enabled hosts in a 
 cluster.
 2. Register a windows 8 template with PV drivers.
 3. create a VM vm1 with the template registered above on host1.
 4. Live migrate vm1 to host2
 Expected behavior :
 
 Live migration should be successful.
 Observed behavior :
 ===
 Live migration fails with the following exception
 2014-08-13 20:04:10,104 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-89:ctx-73c2d9da job-404) Executing AsyncJobVO {id:404, 
 userId: 1, accountId: 1, instanceType: None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo: 
 {ctxDetails:{\com.cloud.vm.VirtualMachine\:26,\com.cloud.host.Host\:5,\com.cloud.uservm.UserVm\:26,\com.cloud.network.router.VirtualRouter\:26},virtualmachineid:26,cmdEventType:VM.MIGRATE,hostid:5,ctxUserId:1,httpmethod:GET,ctxAccountId:1,ctxStartEventId:602,apiKey:,signature:hhjnohmcAc63BXTHmXQu58w3plY\u003d},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-08-13 20:04:10,187 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-89:ctx-73c2d9da job-404) Unexpected exception while 
 executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
 com.cloud.exception.InvalidParameterValueException: Live Migration of GPU 
 enabled VM is not supported
 at 
 com.cloud.vm.UserVmManagerImpl.migrateVirtualMachine(UserVmManagerImpl.java:3860)
 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.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at $Proxy211.migrateVirtualMachine(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:161)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 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 
 

[jira] [Closed] (CLOUDSTACK-7338) [vGPU] Live migration of GPU enabled VM fails with Live Migration of GPU enabled VM is not supported

2014-08-13 Thread Abhinav Roy (JIRA)

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

Abhinav Roy closed CLOUDSTACK-7338.
---

Resolution: Invalid
  Assignee: Abhinav Roy

Resolving and closing the issue as this is the expected behavior.

 [vGPU] Live migration of GPU enabled VM fails with Live Migration of GPU 
 enabled VM is not supported
 --

 Key: CLOUDSTACK-7338
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7338
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
 Environment: Xenserver 6.2.5 + GPU cards
Reporter: Abhinav Roy
Assignee: Abhinav Roy
Priority: Blocker
 Fix For: 4.5.0

 Attachments: CS-7338.zip


 Steps :
 
 1. Deploy an advanced zone CS 4.5.0 setup with 2 GPU enabled hosts in a 
 cluster.
 2. Register a windows 8 template with PV drivers.
 3. create a VM vm1 with the template registered above on host1.
 4. Live migrate vm1 to host2
 Expected behavior :
 
 Live migration should be successful.
 Observed behavior :
 ===
 Live migration fails with the following exception
 2014-08-13 20:04:10,104 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-89:ctx-73c2d9da job-404) Executing AsyncJobVO {id:404, 
 userId: 1, accountId: 1, instanceType: None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo: 
 {ctxDetails:{\com.cloud.vm.VirtualMachine\:26,\com.cloud.host.Host\:5,\com.cloud.uservm.UserVm\:26,\com.cloud.network.router.VirtualRouter\:26},virtualmachineid:26,cmdEventType:VM.MIGRATE,hostid:5,ctxUserId:1,httpmethod:GET,ctxAccountId:1,ctxStartEventId:602,apiKey:,signature:hhjnohmcAc63BXTHmXQu58w3plY\u003d},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-08-13 20:04:10,187 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-89:ctx-73c2d9da job-404) Unexpected exception while 
 executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
 com.cloud.exception.InvalidParameterValueException: Live Migration of GPU 
 enabled VM is not supported
 at 
 com.cloud.vm.UserVmManagerImpl.migrateVirtualMachine(UserVmManagerImpl.java:3860)
 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.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at $Proxy211.migrateVirtualMachine(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:161)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 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 
 

[jira] [Updated] (CLOUDSTACK-7339) [UI] Delete Host button is missing in the UI

2014-08-13 Thread Abhinav Roy (JIRA)

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

Abhinav Roy updated CLOUDSTACK-7339:


Attachment: delete_host_missing.jpg

 [UI] Delete Host button is missing in the UI
 

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

 Attachments: delete_host_missing.jpg


 Steps :
 ===
 1. Login to CS from UI
 2. Goto Infrastructure -  Hosts -  Hostname and put the host to 
 maintenance mode.
 3. Try to delete the Host from UI
 Expected behavior :
 ==
 UI button to delete host should be present.
 Observed behavior :
 ==
 UI button to delete host is missing.
 Attaching a screenshot for the same.



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


[jira] [Created] (CLOUDSTACK-7339) [UI] Delete Host button is missing in the UI

2014-08-13 Thread Abhinav Roy (JIRA)
Abhinav Roy created CLOUDSTACK-7339:
---

 Summary: [UI] Delete Host button is missing in the UI
 Key: CLOUDSTACK-7339
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7339
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.5.0
Reporter: Abhinav Roy
Priority: Critical
 Fix For: 4.5.0
 Attachments: delete_host_missing.jpg

Steps :
===
1. Login to CS from UI
2. Goto Infrastructure -  Hosts -  Hostname and put the host to maintenance 
mode.
3. Try to delete the Host from UI

Expected behavior :
==
UI button to delete host should be present.

Observed behavior :
==
UI button to delete host is missing.

Attaching a screenshot for the same.




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


[jira] [Commented] (CLOUDSTACK-7130) [Automation] Attach volume to VM failing in KVM with Unexpected exception

2014-08-13 Thread Rayees Namathponnan (JIRA)

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

Rayees Namathponnan commented on CLOUDSTACK-7130:
-

Logs available at https://citrix.sharefile.com/d/s99df84c78344cf5b

 [Automation] Attach volume to VM failing in KVM with Unexpected exception
 ---

 Key: CLOUDSTACK-7130
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7130
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.5.0
 Environment: KVM
Reporter: Gaurav Aradhye
Assignee: edison su
  Labels: automation
 Fix For: 4.5.0

 Attachments: KVMAttachVolumeFailureLog.txt, agent.zip


 Steps to reproduce:
 1. Deploy a VM
 2. Create a data volume
 3. Attach volume to VM
 The operation fails with Unexpected exception
 Log:
 2014-07-18 05:27:37,182 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654 ctx-4c56de83) create 
 volume failed: java.lang.NullPo
 interException
 2014-07-18 05:27:37,182 ERROR [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654 ctx-4c56de83) 
 Invocation exception, caused by: com.cl
 oud.utils.exception.CloudRuntimeException: create volume 
 failed:java.lang.NullPointerException
 2014-07-18 05:27:37,183 INFO  [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654 ctx-4c56de83) Rethrow 
 exception com.cloud.utils.excep
 tion.CloudRuntimeException: create volume 
 failed:java.lang.NullPointerException
 2014-07-18 05:27:37,183 DEBUG [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654) Done with run of VM 
 work job: com.cloud.storage.VmWork
 AttachVolume for VM 864, job origin: 5653
 2014-07-18 05:27:37,183 ERROR [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654) Unable to complete 
 AsyncJobVO {id:5654, userId: 2, acc
 ountId: 2, instanceType: null, instanceId: null, cmd: 
 com.cloud.storage.VmWorkAttachVolume, cmdInfo: 
 rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtBdHRhY2hWb2x1bWUHra_5YY
 fiHAIAAkwACGRldmljZUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOY
 W1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACA2B0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbHBzcgAOamF2YS5sYW5nLkxvbmc7i-SQzI8j3wIAAUoABXZhbHVleHIAEGphdmEubGFuZy5O
 dW1iZXKGrJUdC5TgiwIAAHhwA5g, cmdVersion: 0, status: IN_PROGRESS, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 29066118877352, 
 completeMsid: null, l
 astUpdated: null, lastPolled: null, created: Fri Jul 18 05:27:35 PDT 2014}, 
 job origin:5653
 com.cloud.utils.exception.CloudRuntimeException: create volume 
 failed:java.lang.NullPointerException
 at 
 org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:482)
 at 
 org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:763)
 at 
 com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1306)
 at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1173)
 at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2601)
 at sun.reflect.GeneratedMethodAccessor790.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:2640)
 at sun.reflect.GeneratedMethodAccessor668.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 
 

[jira] [Resolved] (CLOUDSTACK-7328) [Automation] Register ISO failing with invalid iso format error

2014-08-13 Thread Min Chen (JIRA)

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

Min Chen resolved CLOUDSTACK-7328.
--

Resolution: Fixed

 [Automation] Register ISO failing with  invalid iso format error 
 -

 Key: CLOUDSTACK-7328
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: ISO
Affects Versions: 4.5.0
 Environment: KVM and Xen
Reporter: Rayees Namathponnan
Assignee: Min Chen
Priority: Blocker
 Fix For: 4.5.0

 Attachments: vmops.log


 Steps to reproduce 
 1) Run the BVT test TestISO
 2) Test case registering ISO with valid URL, 
 Result 
 Register ISO fails with below error 
 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] 
 (494953500@qtp-420407682-10:ctx-28a25fd8) ===START===  172.16.88.7 -- GET  
 account=test-a-TestCreateIso-W648O8domainid=af30b8e6-2219-11e4-9b06-00163e189e44name=ISO+1isfeatured=Trueispublic=Trueisextractable=Truezoneid=144183bf-f5a5-4b7e-810e-a5136db32441url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.isoapiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQwdisplaytext=Test+ISO+1ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3Dcommand=registerIsoresponse=json
 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006.  The uuid is 
 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e
 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-157:ctx-44b5242a) Created a vif 
 fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0
 2014-08-12 05:36:07,796 INFO  [c.c.a.ApiServer] 
 (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please 
 specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for 
 the format iso



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


[jira] [Created] (CLOUDSTACK-7340) Instances unable to reach internet using SG provider and KVM

2014-08-13 Thread Rohit Yadav (JIRA)
Rohit Yadav created CLOUDSTACK-7340:
---

 Summary: Instances unable to reach internet using SG provider and 
KVM
 Key: CLOUDSTACK-7340
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7340
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0, 4.5.0, 4.4.1
Reporter: Rohit Yadav
Priority: Blocker
 Fix For: 4.4.1


Deployed a basic zone with Security Group, used KVM and setup agent.

Host: Ubuntu 14.04, Core i7, 

The test hardware had two nics but used only eth0 and created two bridges 
cloud0 and cloud1:

auto eth0
iface eth0 inet manual

auto wlan0
iface wlan0 inet manual

# Public network
auto cloudbr0
iface cloudbr0 inet static
address 192.168.1.150
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1 8.8.8.8
#post-up route add default gw 192.168.1.1 
bridge_ports eth0
bridge_fd 5
bridge_stp off
bridge_maxwait 1

# Private network
auto cloudbr1
iface cloudbr1 inet manual
bridge_ports none
bridge_fd 5
bridge_stp off
bridge_maxwait 1

The cloudstack-agent (4.4.1) was configured to use cloudbr0 for public, private 
and guest network in its properties file. The default gateway was setup to 
192.168.1.1 on cloudbr0 interface.

- SSVM was able to reach internet.
- CPVM was not

Bridge output:
$ brctl show
bridge name bridge id   STP enabled interfaces
cloud0  8000.fe00a9fe0190   no  vnet0
vnet4
vnet8
cloudbr08000.00012e4fde1c   no  eth0
vnet1
vnet2
vnet3
vnet5
vnet6
vnet7
vnet9
cloudbr18000.   no
lxcbr0  8000.   no
virbr0  8000.   yes

I'm suspecting something with traffic not going to right nic, not good at 
debugging network/bridge/kvm stuff so I'll need someone to setup and try with 
4.4 branch.



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


[jira] [Closed] (CLOUDSTACK-7328) [Automation] Register ISO failing with invalid iso format error

2014-08-13 Thread Rayees Namathponnan (JIRA)

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

Rayees Namathponnan closed CLOUDSTACK-7328.
---


Verified 

 [Automation] Register ISO failing with  invalid iso format error 
 -

 Key: CLOUDSTACK-7328
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: ISO
Affects Versions: 4.5.0
 Environment: KVM and Xen
Reporter: Rayees Namathponnan
Assignee: Min Chen
Priority: Blocker
 Fix For: 4.5.0

 Attachments: vmops.log


 Steps to reproduce 
 1) Run the BVT test TestISO
 2) Test case registering ISO with valid URL, 
 Result 
 Register ISO fails with below error 
 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] 
 (494953500@qtp-420407682-10:ctx-28a25fd8) ===START===  172.16.88.7 -- GET  
 account=test-a-TestCreateIso-W648O8domainid=af30b8e6-2219-11e4-9b06-00163e189e44name=ISO+1isfeatured=Trueispublic=Trueisextractable=Truezoneid=144183bf-f5a5-4b7e-810e-a5136db32441url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.isoapiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQwdisplaytext=Test+ISO+1ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3Dcommand=registerIsoresponse=json
 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006.  The uuid is 
 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e
 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-157:ctx-44b5242a) Created a vif 
 fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0
 2014-08-12 05:36:07,796 INFO  [c.c.a.ApiServer] 
 (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please 
 specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for 
 the format iso



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


[jira] [Commented] (CLOUDSTACK-7340) Instances unable to reach internet using SG provider and KVM

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav commented on CLOUDSTACK-7340:
-

In iptables -L -n I see:

Chain BF-cloudbr0-IN (1 references)
target prot opt source   destination 
r-10-VMall  --  0.0.0.0/00.0.0.0/0PHYSDEV match 
--physdev-in vnet7 --physdev-is-bridged

Chain BF-cloudbr0-OUT (1 references)
target prot opt source   destination 
r-10-VMall  --  0.0.0.0/00.0.0.0/0PHYSDEV match 
--physdev-out vnet7 --physdev-is-bridged

Chain r-10-VM (2 references)
target prot opt source   destination 
RETURN all  --  0.0.0.0/00.0.0.0/0PHYSDEV match 
--physdev-in vnet7 --physdev-is-bridged
ACCEPT all  --  0.0.0.0/00.0.0.0/0   


But in ebtables (bridges) -t nat -L I see vnet9 instead of vnet7
Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
-i vnet9 -j i-2-9-VM-in

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT


We need some KVM hacker to check this.

 Instances unable to reach internet using SG provider and KVM
 

 Key: CLOUDSTACK-7340
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7340
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0, 4.5.0, 4.4.1
Reporter: Rohit Yadav
Priority: Blocker
 Fix For: 4.4.1


 Deployed a basic zone with Security Group, used KVM and setup agent.
 Host: Ubuntu 14.04, Core i7, 
 The test hardware had two nics but used only eth0 and created two bridges 
 cloud0 and cloud1:
 auto eth0
 iface eth0 inet manual
 auto wlan0
 iface wlan0 inet manual
 # Public network
 auto cloudbr0
 iface cloudbr0 inet static
 address 192.168.1.150
 netmask 255.255.255.0
 gateway 192.168.1.1
 dns-nameservers 192.168.1.1 8.8.8.8
 #post-up route add default gw 192.168.1.1 
 bridge_ports eth0
 bridge_fd 5
 bridge_stp off
 bridge_maxwait 1
 # Private network
 auto cloudbr1
 iface cloudbr1 inet manual
 bridge_ports none
 bridge_fd 5
 bridge_stp off
 bridge_maxwait 1
 The cloudstack-agent (4.4.1) was configured to use cloudbr0 for public, 
 private and guest network in its properties file. The default gateway was 
 setup to 192.168.1.1 on cloudbr0 interface.
 - SSVM was able to reach internet.
 - CPVM was not
 Bridge output:
 $ brctl show
 bridge name bridge id   STP enabled interfaces
 cloud0  8000.fe00a9fe0190   no  vnet0
 vnet4
 vnet8
 cloudbr08000.00012e4fde1c   no  eth0
 vnet1
 vnet2
 vnet3
 vnet5
 vnet6
 vnet7
 vnet9
 cloudbr18000.   no
 lxcbr0  8000.   no
 virbr0  8000.   yes
 I'm suspecting something with traffic not going to right nic, not good at 
 debugging network/bridge/kvm stuff so I'll need someone to setup and try with 
 4.4 branch.



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


[jira] [Commented] (CLOUDSTACK-7171) not getting console of user vm via virsh on kvm

2014-08-13 Thread Rohit Yadav (JIRA)

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

Rohit Yadav commented on CLOUDSTACK-7171:
-

If applicable please do backport the fix to 4.4 branch as well.

 not getting console of user vm via virsh on kvm
 ---

 Key: CLOUDSTACK-7171
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7171
 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: KMV host on centos6.2 
 advance zone
Reporter: shweta agarwal
Assignee: Murali Reddy
Priority: Blocker
 Fix For: 4.5.0

 Attachments: MSlog.tar.gz, kvmhostlog.tar.gz


 Repro steps:
 Create a KVM(centos6.2) advance zone setup . Once everything is uop created a 
 user vm with default centos 5.5 template
 On KVM host try to access console of this user vm via vrish
 Bug :
 Nothing happens
 I even tried registering ubuntu template and created a ubuntu VM  still not 
 able to access console via virsh for ubuntu VM  as well
 But able to access console via virsh for system vms , CPVM, SSVM, router vm
 Attaching MS logs and kvm logs for the same



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


[jira] [Reopened] (CLOUDSTACK-7130) [Automation] Attach volume to VM failing in KVM with Unexpected exception

2014-08-13 Thread edison su (JIRA)

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

edison su reopened CLOUDSTACK-7130:
---


Looking at the logs now.

 [Automation] Attach volume to VM failing in KVM with Unexpected exception
 ---

 Key: CLOUDSTACK-7130
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7130
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.5.0
 Environment: KVM
Reporter: Gaurav Aradhye
Assignee: edison su
  Labels: automation
 Fix For: 4.5.0

 Attachments: KVMAttachVolumeFailureLog.txt, agent.zip


 Steps to reproduce:
 1. Deploy a VM
 2. Create a data volume
 3. Attach volume to VM
 The operation fails with Unexpected exception
 Log:
 2014-07-18 05:27:37,182 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654 ctx-4c56de83) create 
 volume failed: java.lang.NullPo
 interException
 2014-07-18 05:27:37,182 ERROR [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654 ctx-4c56de83) 
 Invocation exception, caused by: com.cl
 oud.utils.exception.CloudRuntimeException: create volume 
 failed:java.lang.NullPointerException
 2014-07-18 05:27:37,183 INFO  [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654 ctx-4c56de83) Rethrow 
 exception com.cloud.utils.excep
 tion.CloudRuntimeException: create volume 
 failed:java.lang.NullPointerException
 2014-07-18 05:27:37,183 DEBUG [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654) Done with run of VM 
 work job: com.cloud.storage.VmWork
 AttachVolume for VM 864, job origin: 5653
 2014-07-18 05:27:37,183 ERROR [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654) Unable to complete 
 AsyncJobVO {id:5654, userId: 2, acc
 ountId: 2, instanceType: null, instanceId: null, cmd: 
 com.cloud.storage.VmWorkAttachVolume, cmdInfo: 
 rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtBdHRhY2hWb2x1bWUHra_5YY
 fiHAIAAkwACGRldmljZUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOY
 W1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACA2B0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbHBzcgAOamF2YS5sYW5nLkxvbmc7i-SQzI8j3wIAAUoABXZhbHVleHIAEGphdmEubGFuZy5O
 dW1iZXKGrJUdC5TgiwIAAHhwA5g, cmdVersion: 0, status: IN_PROGRESS, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 29066118877352, 
 completeMsid: null, l
 astUpdated: null, lastPolled: null, created: Fri Jul 18 05:27:35 PDT 2014}, 
 job origin:5653
 com.cloud.utils.exception.CloudRuntimeException: create volume 
 failed:java.lang.NullPointerException
 at 
 org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:482)
 at 
 org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:763)
 at 
 com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1306)
 at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1173)
 at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2601)
 at sun.reflect.GeneratedMethodAccessor790.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:2640)
 at sun.reflect.GeneratedMethodAccessor668.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)

[jira] [Resolved] (CLOUDSTACK-7130) [Automation] Attach volume to VM failing in KVM with Unexpected exception

2014-08-13 Thread edison su (JIRA)

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

edison su resolved CLOUDSTACK-7130.
---

Resolution: Won't Fix

It's a KVM issue: https://bugzilla.redhat.com/show_bug.cgi?id=807023
Seems it's only been fixed in RHEV with 
qemu-kvm-rhev-0.12.1.2-2.428.el6.x86_64, not in RHEL yet...

 [Automation] Attach volume to VM failing in KVM with Unexpected exception
 ---

 Key: CLOUDSTACK-7130
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7130
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.5.0
 Environment: KVM
Reporter: Gaurav Aradhye
Assignee: edison su
  Labels: automation
 Fix For: 4.5.0

 Attachments: KVMAttachVolumeFailureLog.txt, agent.zip


 Steps to reproduce:
 1. Deploy a VM
 2. Create a data volume
 3. Attach volume to VM
 The operation fails with Unexpected exception
 Log:
 2014-07-18 05:27:37,182 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654 ctx-4c56de83) create 
 volume failed: java.lang.NullPo
 interException
 2014-07-18 05:27:37,182 ERROR [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654 ctx-4c56de83) 
 Invocation exception, caused by: com.cl
 oud.utils.exception.CloudRuntimeException: create volume 
 failed:java.lang.NullPointerException
 2014-07-18 05:27:37,183 INFO  [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654 ctx-4c56de83) Rethrow 
 exception com.cloud.utils.excep
 tion.CloudRuntimeException: create volume 
 failed:java.lang.NullPointerException
 2014-07-18 05:27:37,183 DEBUG [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654) Done with run of VM 
 work job: com.cloud.storage.VmWork
 AttachVolume for VM 864, job origin: 5653
 2014-07-18 05:27:37,183 ERROR [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-108:ctx-4fd8d076 job-5653/job-5654) Unable to complete 
 AsyncJobVO {id:5654, userId: 2, acc
 ountId: 2, instanceType: null, instanceId: null, cmd: 
 com.cloud.storage.VmWorkAttachVolume, cmdInfo: 
 rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtBdHRhY2hWb2x1bWUHra_5YY
 fiHAIAAkwACGRldmljZUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOY
 W1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACA2B0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbHBzcgAOamF2YS5sYW5nLkxvbmc7i-SQzI8j3wIAAUoABXZhbHVleHIAEGphdmEubGFuZy5O
 dW1iZXKGrJUdC5TgiwIAAHhwA5g, cmdVersion: 0, status: IN_PROGRESS, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 29066118877352, 
 completeMsid: null, l
 astUpdated: null, lastPolled: null, created: Fri Jul 18 05:27:35 PDT 2014}, 
 job origin:5653
 com.cloud.utils.exception.CloudRuntimeException: create volume 
 failed:java.lang.NullPointerException
 at 
 org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:482)
 at 
 org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:763)
 at 
 com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1306)
 at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1173)
 at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2601)
 at sun.reflect.GeneratedMethodAccessor790.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:2640)
 at sun.reflect.GeneratedMethodAccessor668.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 
 

[jira] [Created] (CLOUDSTACK-7341) Snapshot not allowed for hypervisor KVM

2014-08-13 Thread Rohit Yadav (JIRA)
Rohit Yadav created CLOUDSTACK-7341:
---

 Summary: Snapshot not allowed for hypervisor KVM
 Key: CLOUDSTACK-7341
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7341
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0, 4.4.1
Reporter: Rohit Yadav
Priority: Blocker
 Fix For: 4.4.1


Deployed Basic zone (default networking) on KVM/Ubuntu, created an instance. 
Tried to create snapshot of running and stopped instance, both failed with: 431 
VM snapshot is not enabled for hypervisor type: KVM (from api response).

Is this alright, or something wrong with KVM, we don't have snapshots with KVM?



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


[jira] [Commented] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address

2014-08-13 Thread ASF subversion and git services (JIRA)

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

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

Commit 47fee57312db62d9ea723c1db367042c27e5034c in cloudstack's branch 
refs/heads/4.4 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=47fee57 ]

CLOUDSTACK-4770: In MacAddress skip macAddress when parsed value is 0x00

In MacAddress class, we start by settig macAddress String as null and go through
the output of ifconfig -a and pick the one string that is a valid mac address
but is not 0x00 and 0xff. With each loop we set the macAddress to null so that
it does not pick the last one if everything fails.

Tested on Ubuntu where I had an interface called cloud0 whose mac id was 0x00
and it was skipped to get the next one:

$ java -classpath path-to-cloud-utils.jar com.cloud.utils.net.MacAddress
addr in integer is 5071953436
addr in bytes is  0 1 2e 4f de 1c
addr in char is 00:01:2e:4f:de:1c

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
(cherry picked from commit 3b5aa42c6d87fb7e2573146efb8c7d2d0a4692b3)


 Management server fails to start with Unable to get the management server 
 node due to downed interface with no MAC address 
 -

 Key: CLOUDSTACK-4770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.1, 4.2.0, 4.4.0
 Environment: CentOS 6.4, Ubuntu 14.04
Reporter: Richard Chatterton
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.0, 4.4.1


 Installing CloudStack 4.1.1 today, the management server failed to start with 
 the following errors:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I 
 attempted to reinstall with CloudStack 4.2.0. This produced the following 
 error messages:
 2013-09-30 14:43:43,436 INFO  [utils.component.ComponentContext] 
 (Timer-2:null) Running SystemIntegrityChecker managementServerNode
 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] 
 (Timer-2:null) System integrity check failed. Refuse to startup
 com.cloud.utils.exception.CloudRuntimeException: Unable to get the management 
 server node id
 at 
 com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46)
 at 
 com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90)
 at 
 com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)
 I found a mailing list post which mentioned that this might be due to missing 
 MAC address, and recommended testing by running the class directly. This 
 produced the following output for me:
 $ java -classpath 
 /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar
  com.cloud.utils.net.MacAddress
 addr in integer is 0
 addr in bytes is  0 0 0 0 0 0
 addr in char is 00:00:00:00:00:00
 This was odd to me, as the output of ifconfig didn't have any MAC addresses 
 that were 00:00:00:00:00:00. Looking into the code for that module, I found 
 that what it appears to be doing is parsing ifconfig -a and returning the 
 first string that looks like a MAC address. Reviewing the ifconfig -a output 
 on the server, there was a downed bond interface with a MAC address of 
 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC 
 address from one of its slave physical interfaces.
 After assigning a dummy IP address to that interface and upping it, it 
 received a MAC address and I was able to start the management server normally.
 I expect that there may be a better way to determine what the node id for the 
 management server should be, or logic could be implemented to look for 
 another MAC address if the first once it receives is invalid. Alternatively, 
 if this behavior is expected, logging/debugging resources should be provided 
 to help the user correct the problem.



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


[jira] [Created] (CLOUDSTACK-7342) Fail to delete template while using Swift as Secondary Storage

2014-08-13 Thread Pierre-Luc Dion (JIRA)
Pierre-Luc Dion created CLOUDSTACK-7342:
---

 Summary: Fail to delete template while using Swift as Secondary 
Storage
 Key: CLOUDSTACK-7342
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7342
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.4.0, 4.4.1
Reporter: Pierre-Luc Dion
Priority: Minor


When trying to delete Templates using Swift as secondary storage. Delete fail 
with following error message:

{code}
Unable to execute API command deletetemplate due to invalid value. Invalid 
parameter zoneid value=undefined due to incorrect long value format, or entity 
does not exist or due to incorrect parameter annotation for the field in api 
cmd class.
{code}




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


[jira] [Created] (CLOUDSTACK-7343) cannot create Instance from template using Swift as secondary storage

2014-08-13 Thread Pierre-Luc Dion (JIRA)
Pierre-Luc Dion created CLOUDSTACK-7343:
---

 Summary: cannot create Instance from template using Swift as 
secondary storage
 Key: CLOUDSTACK-7343
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7343
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.4.0, 4.4.1
 Environment: acs4.4.1-snapshot 
Reporter: Pierre-Luc Dion
Priority: Minor


Fail to create Instance from Template or ISOS when using Swift as secondary 
storage. 

The templates is show as ready in Cloudstack UI, when creating the new instance 
the template is created on the staging NFS share at the SSVM, but the vm will 
still fail to create.



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


[jira] [Updated] (CLOUDSTACK-7343) cannot create Instance from template using Swift as secondary storage

2014-08-13 Thread Pierre-Luc Dion (JIRA)

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

Pierre-Luc Dion updated CLOUDSTACK-7343:


Attachment: cloud.log_fromtemplate

ssvm log.

 cannot create Instance from template using Swift as secondary storage
 -

 Key: CLOUDSTACK-7343
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7343
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0, 4.4.1
 Environment: acs4.4.1-snapshot 
Reporter: Pierre-Luc Dion
Priority: Minor
  Labels: swift
 Attachments: cloud.log_fromtemplate


 Fail to create Instance from Template or ISOS when using Swift as secondary 
 storage. 
 The templates is show as ready in Cloudstack UI, when creating the new 
 instance the template is created on the staging NFS share at the SSVM, but 
 the vm will still fail to create.



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


[jira] [Commented] (CLOUDSTACK-7343) cannot create Instance from template using Swift as secondary storage

2014-08-13 Thread Francois Gaudreault (JIRA)

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

Francois Gaudreault commented on CLOUDSTACK-7343:
-

Same bug as S3:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=services/secondary-storage/server/src/org/apache/cloudstack/storage/resource/NfsSecondaryStorageResource.java;h=78f4bf19a9192f1df581c1c0ddb90f2491a93cc9;hp=6927f028cf23db81c86c8e5d0059e3a3c3f37a81;hb=6b8b7b82f41c415f1e0d1ed715e14f3664e39e22;hpb=f7dd1720cb6217d4425e9a92268f6b716e88a18c

Easy fix :)

 cannot create Instance from template using Swift as secondary storage
 -

 Key: CLOUDSTACK-7343
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7343
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0, 4.4.1
 Environment: acs4.4.1-snapshot 
Reporter: Pierre-Luc Dion
Priority: Minor
  Labels: swift
 Attachments: cloud.log_fromtemplate


 Fail to create Instance from Template or ISOS when using Swift as secondary 
 storage. 
 The templates is show as ready in Cloudstack UI, when creating the new 
 instance the template is created on the staging NFS share at the SSVM, but 
 the vm will still fail to create.



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


[jira] [Commented] (CLOUDSTACK-7342) Fail to delete template while using Swift as Secondary Storage

2014-08-13 Thread Francois Gaudreault (JIRA)

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

Francois Gaudreault commented on CLOUDSTACK-7342:
-

Tested using the API, and it works fine. 

This looks like a UI bug :S

 Fail to delete template while using Swift as Secondary Storage
 --

 Key: CLOUDSTACK-7342
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7342
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0, 4.4.1
Reporter: Pierre-Luc Dion
Priority: Minor
  Labels: swift

 When trying to delete Templates using Swift as secondary storage. Delete fail 
 with following error message:
 {code}
 Unable to execute API command deletetemplate due to invalid value. Invalid 
 parameter zoneid value=undefined due to incorrect long value format, or 
 entity does not exist or due to incorrect parameter annotation for the field 
 in api cmd class.
 {code}



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


[jira] [Commented] (CLOUDSTACK-7290) VO classes shouldn¹t have any class variables declared as native type

2014-08-13 Thread Nitin Mehta (JIRA)

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

Nitin Mehta commented on CLOUDSTACK-7290:
-

We could but why create a confusion. Why not make all of them object types with 
no exception ? This makes it easier for someone to write new VO class without 
wondering when to make them native type and when to make them object type. Its 
a clean implementation. I doubt some of the VO classes might have followed that 
convention but later on this got muddled resulting in bugs such as these.

 VO classes shouldn¹t have any class variables declared as native type
 -

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


 VO classes which are the mapping of schema to Java objects shouldn¹t
 have any class variables declared as native type. Because native types
 have default values whereas schema columns can be null and declaring as
 native types masks that.



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


[jira] [Created] (CLOUDSTACK-7344) VOLUME.DELETE usage event missing for VM's in ERROR state

2014-08-13 Thread Min Chen (JIRA)
Min Chen created CLOUDSTACK-7344:


 Summary: VOLUME.DELETE usage event missing for VM's in ERROR state
 Key: CLOUDSTACK-7344
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7344
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Storage Controller
Affects Versions: 4.2.0
Reporter: Min Chen
Priority: Critical
 Fix For: 4.5.0


CloudStack is not generating the VOLUME.DELETE event for VM's which are failed 
to be deployed. That is if the VM deployment is failed for some reason. The VM 
state is updated as ERROR and cleanup is performed to release the resources 
allocated to the VM. As a part of cleanup volume state is updated as 'DESTROY' 
but no VOLUME.DELETE event is generated causing the usage issue customer is 
seeing now.



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


[jira] [Assigned] (CLOUDSTACK-7344) VOLUME.DELETE usage event missing for VM's in ERROR state

2014-08-13 Thread Min Chen (JIRA)

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

Min Chen reassigned CLOUDSTACK-7344:


Assignee: Min Chen

 VOLUME.DELETE usage event missing for VM's in ERROR state
 -

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


 CloudStack is not generating the VOLUME.DELETE event for VM's which are 
 failed to be deployed. That is if the VM deployment is failed for some 
 reason. The VM state is updated as ERROR and cleanup is performed to release 
 the resources allocated to the VM. As a part of cleanup volume state is 
 updated as 'DESTROY' but no VOLUME.DELETE event is generated causing the 
 usage issue customer is seeing now.



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


[jira] [Commented] (CLOUDSTACK-7344) VOLUME.DELETE usage event missing for VM's in ERROR state

2014-08-13 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-7344:VOLUME.DELETE usage event missing for VM's in ERROR
state.

 VOLUME.DELETE usage event missing for VM's in ERROR state
 -

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


 CloudStack is not generating the VOLUME.DELETE event for VM's which are 
 failed to be deployed. That is if the VM deployment is failed for some 
 reason. The VM state is updated as ERROR and cleanup is performed to release 
 the resources allocated to the VM. As a part of cleanup volume state is 
 updated as 'DESTROY' but no VOLUME.DELETE event is generated causing the 
 usage issue customer is seeing now.



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