[jira] [Assigned] (CLOUDSTACK-7146) [Automation] Fix the scripts test_assign_vm.py, test_project_limits.py,test_project_resources.py,test_ps_domain_limits.py - Cleanup of domain should be done after

2014-08-19 Thread Gaurav Aradhye (JIRA)

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

Gaurav Aradhye reassigned CLOUDSTACK-7146:
--

Assignee: Gaurav Aradhye  (was: Girish Shilamkar)

 [Automation] Fix the scripts test_assign_vm.py, 
 test_project_limits.py,test_project_resources.py,test_ps_domain_limits.py - 
 Cleanup of domain should be done after cleaning up account in it
 --

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


 
 *Error Messages:*
 
 ---
 *One:*
 ---
 {code}
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Payload: 
 {'signature': 'ctoosHX10fXC2XJv8iFdUiNqV5Q=', 'apiKey': 
 u'K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'ebbf78c7-5a1d-4051-8404-26314a59151a'}
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): DEBUG: 
 Sending GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.41
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=ctoosHX10fXC2XJv8iFdUiNqV5Q%3DapiKey=K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOAcommand=queryAsyncJobResultresponse=jsonjobid=ebbf78c7-5a1d-4051-8404-26314a59151a
  HTTP/1.1 200 477
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-07-11T16:11:24+', cmd : 
 u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
 u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
 u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : uCan't delete the 
 domain yet because it has 1 accounts to cleanup}, accountid : 
 u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): ERROR:  __poll: 
 Exception Occurred :Job failed: {jobprocstatus : 0, created : 
 u'2014-07-11T16:11:24+', cmd : 
 u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
 u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
 u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : uCan't delete the 
 domain yet because it has 1 accounts to cleanup}, accountid : 
 u'ce30160a-0901-11e4-a9bc-5a9383355ca2'} 
 Traceback (most recent call last):
   File 
 /local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 105, in __poll
 % async_response)
 Exception: Job failed: {jobprocstatus : 0, created : 
 u'2014-07-11T16:11:24+', cmd : 
 u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
 u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
 u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : uCan't delete the 
 domain yet because it has 1 accounts to cleanup}, accountid : 
 u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : 
 FAILED
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): ERROR: marvinRequest 
 : CmdName: marvin.cloudstackAPI.deleteDomain.deleteDomainCmd object at 
 0x3844810 Exception: ['Traceback (most recent call last):\n', '  File 
 /local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 375, in marvinRequest\nraise self.__lastError\n', 'Exception: Job 
 failed: {jobprocstatus : 0, created : u\'2014-07-11T16:11:24+\', cmd : 
 u\'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd\', userid : 
 u\'ce302410-0901-11e4-a9bc-5a9383355ca2\', jobstatus : 2, jobid : 
 

[jira] [Commented] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy

2014-08-19 Thread Harikrishna Patnala (JIRA)

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

Harikrishna Patnala commented on CLOUDSTACK-7351:
-

I wonder how the test was passed before my fix.
Without the hypervisor type how can a vm is deployed using ISO !

 [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
 

 Key: CLOUDSTACK-7351
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
 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
 Environment: KVM (RHEL 6.3)
Reporter: Rayees Namathponnan
Assignee: Girish Shilamkar
Priority: Critical
 Fix For: 4.5.0

 Attachments: CLOUDSTACK-7351.rar


 This issue observed while running the test case 
 integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
 This test case deploying VM with below command 
 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
 account=test-TestVMAcc
 ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Ydomainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8displayname=testserversignature=4xBMTxK5iiaze
 Fgwm2GisNo1SvM%3Dzoneid=a99226f1-d924-4156-8157-90bec0fa6579apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
 TzASxzSN0OSUnfoQstartvm=Truetemplateid=5cc1e055-5f49-4f12-91da-d01bf7ee509ccommand=deployVirtualMachineresponse=jsondiskofferingid=543
 e345e-645a-4bf9-bd4e-af1db46470e7serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
 This deployment failed with below error 
 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
 Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
 parameter is needed to deploy VM or the hypervisor parameter value passed is 
 invalid
 Is it required to pass hypervisor type ? 



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


[jira] [Resolved] (CLOUDSTACK-7363) [Automation] test_vmware_drs should skip on non-VMWare Hypervisors

2014-08-19 Thread Alex Brett (JIRA)

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

Alex Brett resolved CLOUDSTACK-7363.


Resolution: Fixed

 [Automation] test_vmware_drs should skip on non-VMWare Hypervisors
 --

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


 test/integration/component/test_vmware_drs.py is testing pure VMWare 
 features, so is only valid if run on VMWare hosts, however it currently 
 doesn't check this.
 It should test the hypervisor type and skip if a non-VMWare hypervisor is in 
 use.



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


[jira] [Updated] (CLOUDSTACK-7193) Rebooting a VM doesn't update iptables rules

2014-08-19 Thread sebastien goasguen (JIRA)

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

sebastien goasguen updated CLOUDSTACK-7193:
---

Fix Version/s: 4.4.1
   4.3.1

 Rebooting a VM doesn't update iptables rules
 

 Key: CLOUDSTACK-7193
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7193
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.3.0
 Environment: Ubuntu Lucid 12.04 and more recent
Reporter: Vincent Bernat
Assignee: sebastien goasguen
 Fix For: 4.3.1, 4.4.1


 Hi!
 Rebooting a VM doesn't update the iptables rules despite the change on the 
 interface name. To reproduce:
  1. Starts two VM
  2. Stop the first one.
  3. Reboot the second one. It will use the vnet device of the first one.
  4. Checks that the iptables rules for the second one are still referencing 
 the old interface.
 The defect seems to be in security_group.py. The periodic 
 get_rule_logs_for_vm which also handles rebooted VM fails because of the 
 following traceback:
 {code}
 2014-07-28 15:15:19,035 - 'int' object has no attribute 'isdigit'
 Traceback (most recent call last):
   File /usr/share/cloudstack-common/scripts/vm/network/security_group.py, 
 line 705, in get_rule_logs_for_vms
 network_rules_for_rebooted_vm(name)
   File /usr/share/cloudstack-common/scripts/vm/network/security_group.py, 
 line 637, in network_rules_for_rebooted_vm
 [curr_domid, old_domid] = check_domid_changed(vm_name)
   File /usr/share/cloudstack-common/scripts/vm/network/security_group.py, 
 line 619, in check_domid_changed
 if (curr_domid is None) or (not curr_domid.isdigit()):
 AttributeError: 'int' object has no attribute 'isdigit'
 {code}
 This exception is catched by some try...except.
 On Ubuntu Lucid 12.04, a domain ID is an integer. This is with libvirt 0.9.8. 
 I also checked that this is still the case with libvirt 1.2.4.



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


[jira] [Assigned] (CLOUDSTACK-7193) Rebooting a VM doesn't update iptables rules

2014-08-19 Thread sebastien goasguen (JIRA)

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

sebastien goasguen reassigned CLOUDSTACK-7193:
--

Assignee: sebastien goasguen

 Rebooting a VM doesn't update iptables rules
 

 Key: CLOUDSTACK-7193
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7193
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.3.0
 Environment: Ubuntu Lucid 12.04 and more recent
Reporter: Vincent Bernat
Assignee: sebastien goasguen
 Fix For: 4.3.1, 4.4.1


 Hi!
 Rebooting a VM doesn't update the iptables rules despite the change on the 
 interface name. To reproduce:
  1. Starts two VM
  2. Stop the first one.
  3. Reboot the second one. It will use the vnet device of the first one.
  4. Checks that the iptables rules for the second one are still referencing 
 the old interface.
 The defect seems to be in security_group.py. The periodic 
 get_rule_logs_for_vm which also handles rebooted VM fails because of the 
 following traceback:
 {code}
 2014-07-28 15:15:19,035 - 'int' object has no attribute 'isdigit'
 Traceback (most recent call last):
   File /usr/share/cloudstack-common/scripts/vm/network/security_group.py, 
 line 705, in get_rule_logs_for_vms
 network_rules_for_rebooted_vm(name)
   File /usr/share/cloudstack-common/scripts/vm/network/security_group.py, 
 line 637, in network_rules_for_rebooted_vm
 [curr_domid, old_domid] = check_domid_changed(vm_name)
   File /usr/share/cloudstack-common/scripts/vm/network/security_group.py, 
 line 619, in check_domid_changed
 if (curr_domid is None) or (not curr_domid.isdigit()):
 AttributeError: 'int' object has no attribute 'isdigit'
 {code}
 This exception is catched by some try...except.
 On Ubuntu Lucid 12.04, a domain ID is an integer. This is with libvirt 0.9.8. 
 I also checked that this is still the case with libvirt 1.2.4.



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


[jira] [Updated] (CLOUDSTACK-7006) Template ID is missing in ROOT volume usages

2014-08-19 Thread sebastien goasguen (JIRA)

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

sebastien goasguen updated CLOUDSTACK-7006:
---

Fix Version/s: 4.4.1

 Template ID is missing in ROOT volume usages
 

 Key: CLOUDSTACK-7006
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7006
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Reporter: Olivier Lemasle
Assignee: Olivier Lemasle
Priority: Minor
 Fix For: 4.3.1, 4.4.1


 In previous versions of CloudStack, the template ID was recorded for ROOT 
 volume usages, when the VM is created from a template.
 Since CloudStack 4.2, the template ID isn't recorded anymore, due to a 
 regression in the EVENT_VOLUME_CREATE event publishing:
 In commit 
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=730d04508507409065a432e2aac931225947f268,
  the last EVENT_VOLUME_CREATE misses the template id, that was previously 
 set. It seems a simple copy-paste error.



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


[jira] [Resolved] (CLOUDSTACK-7193) Rebooting a VM doesn't update iptables rules

2014-08-19 Thread sebastien goasguen (JIRA)

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

sebastien goasguen resolved CLOUDSTACK-7193.


Resolution: Fixed

 Rebooting a VM doesn't update iptables rules
 

 Key: CLOUDSTACK-7193
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7193
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.3.0
 Environment: Ubuntu Lucid 12.04 and more recent
Reporter: Vincent Bernat
Assignee: sebastien goasguen
 Fix For: 4.3.1, 4.4.1


 Hi!
 Rebooting a VM doesn't update the iptables rules despite the change on the 
 interface name. To reproduce:
  1. Starts two VM
  2. Stop the first one.
  3. Reboot the second one. It will use the vnet device of the first one.
  4. Checks that the iptables rules for the second one are still referencing 
 the old interface.
 The defect seems to be in security_group.py. The periodic 
 get_rule_logs_for_vm which also handles rebooted VM fails because of the 
 following traceback:
 {code}
 2014-07-28 15:15:19,035 - 'int' object has no attribute 'isdigit'
 Traceback (most recent call last):
   File /usr/share/cloudstack-common/scripts/vm/network/security_group.py, 
 line 705, in get_rule_logs_for_vms
 network_rules_for_rebooted_vm(name)
   File /usr/share/cloudstack-common/scripts/vm/network/security_group.py, 
 line 637, in network_rules_for_rebooted_vm
 [curr_domid, old_domid] = check_domid_changed(vm_name)
   File /usr/share/cloudstack-common/scripts/vm/network/security_group.py, 
 line 619, in check_domid_changed
 if (curr_domid is None) or (not curr_domid.isdigit()):
 AttributeError: 'int' object has no attribute 'isdigit'
 {code}
 This exception is catched by some try...except.
 On Ubuntu Lucid 12.04, a domain ID is an integer. This is with libvirt 0.9.8. 
 I also checked that this is still the case with libvirt 1.2.4.



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


[jira] [Assigned] (CLOUDSTACK-7323) [vGPU] Creation of VM snapshot with memory is failing

2014-08-19 Thread Sanjay Tripathi (JIRA)

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

Sanjay Tripathi reassigned CLOUDSTACK-7323:
---

Assignee: Sanjay Tripathi

 [vGPU] Creation of VM snapshot with memory is failing 
 

 Key: CLOUDSTACK-7323
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7323
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Snapshot
Affects Versions: 4.5.0
 Environment: Xenserver 6.2 SP1 + vGPU
Reporter: Abhinav Roy
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.5.0

 Attachments: CS-7323.zip


 Steps :
 
 1. Deploy CloudStack setup with Xenserver 6.2 sp1 host which has GPU cards.
 2. Create a VM with windows template.
 3. Install PV drivers in the VM created above.
 4. Take VM snapshot with memory
 Expected behavior :
 
 VM snapshot should be successful.
 Observed behavior :
 ===
 VM snapshot fails with the following error :
 2014-08-12 19:39:34,089 DEBUG [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-28:ctx-52530808 job-605/job-606) Run VM work job: 
 com.cloud.vm.snapshot.VmWorkCreateVMSnapshot for VM 38, job origin: 605
 2014-08-12 19:39:34,093 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-28:ctx-52530808 job-605/job-606 ctx-05ea1ea9) Execute VM 
 work job: 
 com.cloud.vm.snapshot.VmWorkCreateVMSnapshot{vmSnapshotId:2,quiesceVm:false,userId:61,accountId:61,vmId:38,handlerName:VMSnapshotManagerImpl}
 2014-08-12 19:39:34,120 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-28:ctx-52530808 job-605/job-606 ctx-05ea1ea9) Seq 
 1-2048293405523443998: Sending  { Cmd , MgmtId: 55355881446856, via: 
 1(cldstk-R720-66), Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.CreateVMSnapshotCommand:{vmState:Running,volumeTOs:[{uuid:3af646dd-6f53-490a-a897-978428b5d608,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:96438f80-3b68-34fe-8492-f6ac9e3db3dc,id:1,poolType:NetworkFilesystem,host:10.102.192.101,path:/Sailaja/goletaps1,port:2049,url:NetworkFilesystem://10.102.192.101/Sailaja/goletaps1/?ROLE=PrimarySTOREUUID=96438f80-3b68-34fe-8492-f6ac9e3db3dc}},name:ROOT-38,size:21474836480,path:e8645c41-4904-4a7c-adb0-87ce0d414da7,volumeId:39,vmName:i-61-38-VM,accountId:61,format:VHD,provisioningType:THIN,id:39,deviceId:0,hypervisorType:XenServer}],target:{id:2,snapshotName:i-61-38-VM_VS_20140812140932,type:DiskAndMemory,current:false,quiescevm:false},vmName:i-61-38-VM,guestOSType:Windows
  8 (64-bit),platformEmulator:Windows 8 (64-bit),wait:1800}}] }
 2014-08-12 19:39:34,121 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-28:ctx-52530808 job-605/job-606 ctx-05ea1ea9) Seq 
 1-2048293405523443998: Executing:  { Cmd , MgmtId: 55355881446856, via: 
 1(cldstk-R720-66), Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.CreateVMSnapshotCommand:{vmState:Running,volumeTOs:[{uuid:3af646dd-6f53-490a-a897-978428b5d608,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:96438f80-3b68-34fe-8492-f6ac9e3db3dc,id:1,poolType:NetworkFilesystem,host:10.102.192.101,path:/Sailaja/goletaps1,port:2049,url:NetworkFilesystem://10.102.192.101/Sailaja/goletaps1/?ROLE=PrimarySTOREUUID=96438f80-3b68-34fe-8492-f6ac9e3db3dc}},name:ROOT-38,size:21474836480,path:e8645c41-4904-4a7c-adb0-87ce0d414da7,volumeId:39,vmName:i-61-38-VM,accountId:61,format:VHD,provisioningType:THIN,id:39,deviceId:0,hypervisorType:XenServer}],target:{id:2,snapshotName:i-61-38-VM_VS_20140812140932,type:DiskAndMemory,current:false,quiescevm:false},vmName:i-61-38-VM,guestOSType:Windows
  8 (64-bit),platformEmulator:Windows 8 (64-bit),wait:1800}}] }
 2014-08-12 19:39:34,121 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-36:ctx-9bff71f3) Seq 1-2048293405523443998: Executing request
 2014-08-12 19:39:34,224 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-36:ctx-9bff71f3) Task failed! Task record: uuid: 
 ba41eab1-b90c-a468-d1b3-55b1024b81b8
nameLabel: Async.VM.checkpoint
  nameDescription:
allowedOperations: []
currentOperations: {}
  created: Tue Aug 12 18:27:26 IST 2014
 finished: Tue Aug 12 18:27:26 IST 2014
   status: failure
   residentOn: com.xensource.xenapi.Host@fb990ea3
 progress: 1.0
 type: none/
   result:
errorInfo: [VM_HAS_VGPU, 
 OpaqueRef:f197581b-ad88-d3eb-3229-ab9732fa6aaf]
  otherConfig: {CS_VM_SNAPSHOT_KEY=i-61-38-VM_VS_20140812140932}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
 subtasks: []
 2014-08-12 19:39:34,237 ERROR [c.c.h.x.r.CitrixResourceBase] 
 

[jira] [Assigned] (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-19 Thread Sanjay Tripathi (JIRA)

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

Sanjay Tripathi reassigned CLOUDSTACK-7333:
---

Assignee: Sanjay Tripathi

 [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
Assignee: Sanjay Tripathi
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-7371) [VMware] Enabling primary storage maintenance fails when storages are across cluster

2014-08-19 Thread Likitha Shetty (JIRA)
Likitha Shetty created CLOUDSTACK-7371:
--

 Summary: [VMware] Enabling primary storage maintenance fails when 
storages are across cluster
 Key: CLOUDSTACK-7371
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7371
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Storage Controller, VMware
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
 Fix For: 4.5.0


Have two primary storage across 2 clusters. Put the storage that has at least 
one system vm into maintenance. The system vm will fail to start in the second 
storage with the following error - 
{noformat}
2014-08-18 17:07:50,337 WARN  [c.c.h.v.r.VmwareResource] 
(DirectAgent-134:ctx-440166e2 10.102.192.7, job-129/job-134, cmd: StartCommand) 
StartCommand failed due to Exception: java.lang.RuntimeException
Message: The name 's-2-VM' already exists.

java.lang.RuntimeException: The name 's-2-VM' already exists.
at 
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:335)
at com.cloud.hypervisor.vmware.mo.HostMO.createVm(HostMO.java:559)
at 
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.createBlankVm(HypervisorHostHelper.java:1165)
at com.cloud.hypervisor.vmware.mo.HostMO.createBlankVm(HostMO.java:744)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1391)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:448)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:294)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
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)
{noformat}



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


[jira] [Commented] (CLOUDSTACK-7146) [Automation] Fix the scripts test_assign_vm.py, test_project_limits.py,test_project_resources.py,test_ps_domain_limits.py - Cleanup of domain should be done afte

2014-08-19 Thread Gaurav Aradhye (JIRA)

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

Gaurav Aradhye commented on CLOUDSTACK-7146:


On KVM and VMware, the tests are passing, there is no defect in test cases.
I think these are Xen Specific issues.

 [Automation] Fix the scripts test_assign_vm.py, 
 test_project_limits.py,test_project_resources.py,test_ps_domain_limits.py - 
 Cleanup of domain should be done after cleaning up account in it
 --

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


 
 *Error Messages:*
 
 ---
 *One:*
 ---
 {code}
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Payload: 
 {'signature': 'ctoosHX10fXC2XJv8iFdUiNqV5Q=', 'apiKey': 
 u'K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'ebbf78c7-5a1d-4051-8404-26314a59151a'}
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): DEBUG: 
 Sending GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.41
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=ctoosHX10fXC2XJv8iFdUiNqV5Q%3DapiKey=K1eKecmH_8ipIelDho9Wm-HZm0WhiIw-2cGFZveZJdKOwB_Cchln9O4QBNxkyy8U8UHCRt_leTpa-yvEb04EOAcommand=queryAsyncJobResultresponse=jsonjobid=ebbf78c7-5a1d-4051-8404-26314a59151a
  HTTP/1.1 200 477
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-07-11T16:11:24+', cmd : 
 u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
 u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
 u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : uCan't delete the 
 domain yet because it has 1 accounts to cleanup}, accountid : 
 u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): ERROR:  __poll: 
 Exception Occurred :Job failed: {jobprocstatus : 0, created : 
 u'2014-07-11T16:11:24+', cmd : 
 u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
 u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
 u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : uCan't delete the 
 domain yet because it has 1 accounts to cleanup}, accountid : 
 u'ce30160a-0901-11e4-a9bc-5a9383355ca2'} 
 Traceback (most recent call last):
   File 
 /local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 105, in __poll
 % async_response)
 Exception: Job failed: {jobprocstatus : 0, created : 
 u'2014-07-11T16:11:24+', cmd : 
 u'org.apache.cloudstack.api.command.admin.domain.DeleteDomainCmd', userid : 
 u'ce302410-0901-11e4-a9bc-5a9383355ca2', jobstatus : 2, jobid : 
 u'ebbf78c7-5a1d-4051-8404-26314a59151a', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : uCan't delete the 
 domain yet because it has 1 accounts to cleanup}, accountid : 
 u'ce30160a-0901-11e4-a9bc-5a9383355ca2'}
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Response : 
 FAILED
 test_16_move_across_subdomain_volume_and_account_limit 
 (integration.component.test_assign_vm.TestVMOwnership): ERROR: marvinRequest 
 : CmdName: marvin.cloudstackAPI.deleteDomain.deleteDomainCmd object at 
 0x3844810 Exception: ['Traceback (most recent call last):\n', '  File 
 /local/jenkins/workspace/xenrt-reg-adv-xs/work.63/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 375, in marvinRequest\nraise self.__lastError\n', 'Exception: Job 
 failed: {jobprocstatus : 0, created : u\'2014-07-11T16:11:24+\', cmd : 
 

[jira] [Resolved] (CLOUDSTACK-6448) VPC router won't be created when a private gateway is defined.

2014-08-19 Thread Saksham Srivastava (JIRA)

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

Saksham Srivastava resolved CLOUDSTACK-6448.


Resolution: Cannot Reproduce

Closing the issue as it is not reproducible on latest master.

 VPC router won't be created when a private gateway is defined. 
 ---

 Key: CLOUDSTACK-6448
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6448
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices, Virtual Router
Affects Versions: 4.3.0, 4.4.0, 4.3.1
Reporter: Anton Opgenoort
Assignee: Saksham Srivastava

 Reproduce by creating a VPC, adding a gateway, and destroy the associated 
 virtual router. Then try to start a VM in one of the VPC network tiers; this 
 results in message below, and routerVM is not started for VPC network. 
 Then remove the private gateway, and start a VM again. Now the routerVM is 
 started normally, and the VM is being provisioned. 
 2014-04-18 10:35:04,895 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) VM is being created in podId: 1
 2014-04-18 10:35:04,907 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Network id=1143 is already 
 implemented
 2014-04-18 10:35:04,943 DEBUG [c.c.n.NetworkModelImpl] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Service SecurityGroup is not 
 supported in the network id=1143
 2014-04-18 10:35:04,958 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Changing active number of nics 
 for network id=1143 on 1
 2014-04-18 10:35:04,973 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Asking VpcVirtualRouter to 
 prepare for Nic[98879-15684-e51a9969-e1f1-4c45-ad65-761e51435b90-10.1.1.98]
 2014-04-18 10:35:04,979 DEBUG [c.c.n.r.VpcVirtualNetworkApplianceManagerImpl] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Deploying Virtual Router in VPC 
 [VPC [313-mccoat1]
 2014-04-18 10:35:05,006 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Adding nic for Virtual Router in 
 Control network 
 2014-04-18 10:35:05,014 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Found existing network 
 configuration for offering [Network Offering 
 [5-Control-System-Control-Network]: Ntwk[202|Control|5]
 2014-04-18 10:35:05,014 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Releasing lock for 
 Acct[5083d876-e429-4aa4-bb9a-1958ad753f18-system]
 2014-04-18 10:35:05,016 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Adding nic for Virtual Router in 
 Public network 
 2014-04-18 10:35:05,026 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Found existing network 
 configuration for offering [Network Offering 
 [1-Public-System-Public-Network]: Ntwk[200|Public|1]
 2014-04-18 10:35:05,026 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Releasing lock for 
 Acct[5083d876-e429-4aa4-bb9a-1958ad753f18-system]
 2014-04-18 10:35:05,055 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Failed to start instance 
 VM[User|antontest-cloud-1600]
 java.lang.NullPointerException
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.createPrivateNicProfileForGateway(VpcVirtualNetworkApplianceManagerImpl.java:1290)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.createVpcRouterNetworks(VpcVirtualNetworkApplianceManagerImpl.java:1231)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.deployVpcRouter(VpcVirtualNetworkApplianceManagerImpl.java:344)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInVpc(VpcVirtualNetworkApplianceManagerImpl.java:234)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.deployVirtualRouterInVpc(VpcVirtualNetworkApplianceManagerImpl.java:183)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 

[jira] [Updated] (CLOUDSTACK-6634) DOC: update the ldap section of the admin guide

2014-08-19 Thread Rajani Karuturi (JIRA)

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

Rajani Karuturi updated CLOUDSTACK-6634:


Status: Reviewable  (was: In Progress)

 DOC: update the ldap section of the admin guide
 ---

 Key: CLOUDSTACK-6634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6634
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
  Labels: ldap
 Fix For: 4.4.0


 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.3/accounts.html#using-an-ldap-server-for-user-authentication
 there are changes/enhancements in the way ldap server is configured since 4.3 
 documentation needs to be updated with the latest info.
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+provisioning



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


[jira] [Commented] (CLOUDSTACK-6634) DOC: update the ldap section of the admin guide

2014-08-19 Thread Rajani Karuturi (JIRA)

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

Rajani Karuturi commented on CLOUDSTACK-6634:
-

created a pull request https://github.com/apache/cloudstack-docs-admin/pull/15

 DOC: update the ldap section of the admin guide
 ---

 Key: CLOUDSTACK-6634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6634
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
  Labels: ldap
 Fix For: 4.4.0


 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.3/accounts.html#using-an-ldap-server-for-user-authentication
 there are changes/enhancements in the way ldap server is configured since 4.3 
 documentation needs to be updated with the latest info.
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+provisioning



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


[jira] [Commented] (CLOUDSTACK-6634) DOC: update the ldap section of the admin guide

2014-08-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-6634:


GitHub user karuturi opened a pull request:

https://github.com/apache/cloudstack-docs-admin/pull/15

CLOUDSTACK-6634

updated the ldap section in admin guide

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/karuturi/cloudstack-docs-admin 4.3-ldap-doc

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack-docs-admin/pull/15.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #15


commit 145a0bbf2a73aeac4a61012eb358c20034a9bf63
Author: Rajani Karuturi rajanikarut...@gmail.com
Date:   2014-08-19T10:57:43Z

CLOUDSTACK-6634

updated the ldap section in admin guide




 DOC: update the ldap section of the admin guide
 ---

 Key: CLOUDSTACK-6634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6634
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
  Labels: ldap
 Fix For: 4.4.0


 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.3/accounts.html#using-an-ldap-server-for-user-authentication
 there are changes/enhancements in the way ldap server is configured since 4.3 
 documentation needs to be updated with the latest info.
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+provisioning



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


[jira] [Comment Edited] (CLOUDSTACK-6634) DOC: update the ldap section of the admin guide

2014-08-19 Thread Rajani Karuturi (JIRA)

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

Rajani Karuturi edited comment on CLOUDSTACK-6634 at 8/19/14 11:22 AM:
---

created a pull request https://github.com/apache/cloudstack-docs-admin/pull/15

This one is for the 4.3 docs. It needs to be merged to 4.4 and latest as it is 
the same there.


was (Author: rajanik):
created a pull request https://github.com/apache/cloudstack-docs-admin/pull/15

 DOC: update the ldap section of the admin guide
 ---

 Key: CLOUDSTACK-6634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6634
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
  Labels: ldap
 Fix For: 4.4.0


 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.3/accounts.html#using-an-ldap-server-for-user-authentication
 there are changes/enhancements in the way ldap server is configured since 4.3 
 documentation needs to be updated with the latest info.
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+provisioning



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


[jira] [Closed] (CLOUDSTACK-231) Tag creation using special characters

2014-08-19 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-231.
---


agree with saksham's assessment

 Tag creation using special characters 
 --

 Key: CLOUDSTACK-231
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-231
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: pre-4.0.0
 Environment: MS(rhel6.3)
 Git Revision: 046e916fcf6d847e2cdf281233d2e68a8e6500f8
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
Reporter: prashant kumar mishra
Assignee: Saksham Srivastava
Priority: Minor
 Fix For: 4.4.0


 Tag creation 
 -
 -
 steps to reproduce
 
 
 1-create tag on any resource(vm/template/PF/FW)
 2-provide detail key=value=some special character
 EXPECTED
 --
 --
 Tag creation shouldn't be happening with message special character's are not 
 allowed
 ACTUAL
 ---
 --
 Tag creation is happening properly using special characters



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


[jira] [Commented] (CLOUDSTACK-5879) Document on how to use RabbitMq event bus with spring modularisation done in 4.3, also document how to use encrypted password in the config file

2014-08-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-5879:


GitHub user terbolous opened a pull request:

https://github.com/apache/cloudstack-docs-admin/pull/16

CLOUDSTACK-5879: Updated rabbitmq eventbus path



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/terbolous/cloudstack-docs-admin patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack-docs-admin/pull/16.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #16


commit c2a61ada781ee734f5f31ce2858c04adeb6624e4
Author: Erik Weber terbol...@gmail.com
Date:   2014-08-19T17:57:13Z

CLOUDSTACK-5879: Updated rabbitmq eventbus path




 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file
 

 Key: CLOUDSTACK-5879
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5879
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Murali Reddy
Assignee: Radhika Nair
 Fix For: 4.5.0


 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file.
 From 4.3 RabbitMq event bus plug-in configuration need to be specified 
 differently (in 4.2 and 4.1 it was specified in componenetConext file) in 
 separate file. This doc bug is to get the necessary details required for 4.3



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


[jira] [Commented] (CLOUDSTACK-6043) VMware detaching volume fails if volume has snapshots

2014-08-19 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti commented on CLOUDSTACK-6043:
--

Chris,

Do you agree with this assessment

thanks
/sudha

 VMware detaching volume fails if volume has snapshots
 -

 Key: CLOUDSTACK-6043
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6043
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware, Volumes
Affects Versions: 4.3.0
Reporter: Chris Suich
Assignee: Likitha Shetty
  Labels: vmware, volumes
 Fix For: 4.4.0


 When detaching VMware volumes, a call is first made to the hypervisor to 
 remove all snapshots for that volume. After this happens, the path for the 
 volume potentially changes, but isn't updated in the ACS DB, which causes 
 problems when the call is made to actually detach the volume.
 For example, if the volume has a single snapshot, then the current path would 
 be something like VOLUME-1.vmdk which is a delta disk for VOLUME.vmdk. 
 Once the snapshot is deleted, VOLUME-1.vmdk is coalesced into 
 VOLUME.vmdk, which becomes the active path. However, ACS still believes the 
 correct path is VOLUME-1.vmdk which causes the detach to fail.



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


[jira] [Commented] (CLOUDSTACK-4627) HA not working, User VM wasn't Migrated

2014-08-19 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti commented on CLOUDSTACK-4627:
--

can you cofirm that this is actually working

 HA not working, User VM wasn't Migrated
 ---

 Key: CLOUDSTACK-4627
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4627
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, KVM, Management Server
Affects Versions: 4.2.0
 Environment: CentOS 6.3 64bit
Reporter: Naoki Sakamoto
Assignee: edison su
 Fix For: 4.2.1

 Attachments: 20130906_HA_SystemVM_Migration_OK_But_UserVM_NG.zip, 
 20130909_HA_UserVM_Migration_NG.zip


 1. We made one of KVM Host Power OFF by push power button of hardware for 
 High Availability Test.
 2. Vritual Router / Secodary Storage VM / Console Proxy VM is Migrated.
But User VM wasn't Migrated.



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


[jira] [Commented] (CLOUDSTACK-5879) Document on how to use RabbitMq event bus with spring modularisation done in 4.3, also document how to use encrypted password in the config file

2014-08-19 Thread Erik Weber (JIRA)

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

Erik Weber commented on CLOUDSTACK-5879:


In this bean:
bean id=environmentVariablesConfiguration 
class=org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig
property name=algorithm value=PBEWithMD5AndDES /
property name=passwordEnvName value=APP_ENCRYPTION_PASSWORD /
/bean

Is APP_ENCRYPTION_PASSWORD a placeholder for something? in that case, what 
should it be replaced with?

 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file
 

 Key: CLOUDSTACK-5879
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5879
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Murali Reddy
Assignee: Radhika Nair
 Fix For: 4.5.0


 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file.
 From 4.3 RabbitMq event bus plug-in configuration need to be specified 
 differently (in 4.2 and 4.1 it was specified in componenetConext file) in 
 separate file. This doc bug is to get the necessary details required for 4.3



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


[jira] [Assigned] (CLOUDSTACK-7347) [Automation] Unable to access VM trough ConsoleProxy

2014-08-19 Thread Santhosh Kumar Edukulla (JIRA)

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

Santhosh Kumar Edukulla reassigned CLOUDSTACK-7347:
---

Assignee: Rayees Namathponnan  (was: Santhosh Kumar Edukulla)

 [Automation] Unable to access VM trough ConsoleProxy
 

 Key: CLOUDSTACK-7347
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7347
 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: Rayees Namathponnan
Assignee: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.5.0

 Attachments: cloud.out


 Steps to reproduce 
 1) Deploy advanced zone in KVM 
 2) Deploy VM
 3) Access the vm trough console proxy 
 Result 
 Unable to access the VM trough console proxy, observed below error in Console 
 proxy cloud.log
 2014-08-14 15:40:38,525 ERROR [resource.consoleproxy.ConsoleProxyResource] 
 (Console Proxy GC Thread:null) Unable to send out load info due to Unable to 
 post agent control request as link is not available
 com.cloud.exception.AgentControlChannelException: Unable to post agent 
 control request as link is not available
   at com.cloud.agent.Agent.postRequest(Agent.java:690)
   at com.cloud.agent.Agent.postRequest(Agent.java:678)
   at 
 com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
   at 
 com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
 2014-08-14 15:40:38,525 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) Report load change : {
   connections: []
 }
 2014-08-14 15:40:41,110 ERROR [utils.nio.NioConnection] (Agent-Selector:null) 
 Unable to initialize the threads.
 java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection 
 closed with -1 on reading size.
   at com.cloud.utils.nio.NioClient.init(NioClient.java:87)
   at com.cloud.utils.nio.NioConnection.run(NioConnection.java:111)
   at java.lang.Thread.run(Thread.java:744)
 2014-08-14 15:40:43,526 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) connMap={}
 2014-08-14 15:40:43,526 INFO  [utils.exception.CSExceptionErrorCode] (Console 
 Proxy GC Thread:null) Could not find exception: 
 com.cloud.exception.AgentControlChannelException in error code list for 
 exceptions
 2014-08-14 15:40:43,526 ERROR [resource.consoleproxy.ConsoleProxyResource] 
 (Console Proxy GC Thread:null) Unable to send out load info due to Unable to 
 post agent control request as link is not available
 com.cloud.exception.AgentControlChannelException: Unable to post agent 
 control request as link is not available
   at com.cloud.agent.Agent.postRequest(Agent.java:690)
   at com.cloud.agent.Agent.postRequest(Agent.java:678)
   at 
 com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
   at 
 com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
 2014-08-14 15:40:43,527 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) Report load change : {
   connections: []
 }
 2014-08-14 15:40:46,110 INFO  [cloud.agent.Agent] (Agent-Handler-1:null) 
 Reconnecting...
 2014-08-14 15:40:46,111 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
 Connecting to 10.223.49.195:8250
 2014-08-14 15:40:48,527 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) connMap={}



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


[jira] [Commented] (CLOUDSTACK-7347) [Automation] Unable to access VM trough ConsoleProxy

2014-08-19 Thread Santhosh Kumar Edukulla (JIRA)

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

Santhosh Kumar Edukulla commented on CLOUDSTACK-7347:
-

Rayees,

Can you please confirm whether the issue is because of the commit mentioned? 
Otherwise, it was pushed only after passing CI. Please mention your findings 
accordingly.

Santhosh

 [Automation] Unable to access VM trough ConsoleProxy
 

 Key: CLOUDSTACK-7347
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7347
 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: Rayees Namathponnan
Assignee: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.5.0

 Attachments: cloud.out


 Steps to reproduce 
 1) Deploy advanced zone in KVM 
 2) Deploy VM
 3) Access the vm trough console proxy 
 Result 
 Unable to access the VM trough console proxy, observed below error in Console 
 proxy cloud.log
 2014-08-14 15:40:38,525 ERROR [resource.consoleproxy.ConsoleProxyResource] 
 (Console Proxy GC Thread:null) Unable to send out load info due to Unable to 
 post agent control request as link is not available
 com.cloud.exception.AgentControlChannelException: Unable to post agent 
 control request as link is not available
   at com.cloud.agent.Agent.postRequest(Agent.java:690)
   at com.cloud.agent.Agent.postRequest(Agent.java:678)
   at 
 com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
   at 
 com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
 2014-08-14 15:40:38,525 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) Report load change : {
   connections: []
 }
 2014-08-14 15:40:41,110 ERROR [utils.nio.NioConnection] (Agent-Selector:null) 
 Unable to initialize the threads.
 java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection 
 closed with -1 on reading size.
   at com.cloud.utils.nio.NioClient.init(NioClient.java:87)
   at com.cloud.utils.nio.NioConnection.run(NioConnection.java:111)
   at java.lang.Thread.run(Thread.java:744)
 2014-08-14 15:40:43,526 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) connMap={}
 2014-08-14 15:40:43,526 INFO  [utils.exception.CSExceptionErrorCode] (Console 
 Proxy GC Thread:null) Could not find exception: 
 com.cloud.exception.AgentControlChannelException in error code list for 
 exceptions
 2014-08-14 15:40:43,526 ERROR [resource.consoleproxy.ConsoleProxyResource] 
 (Console Proxy GC Thread:null) Unable to send out load info due to Unable to 
 post agent control request as link is not available
 com.cloud.exception.AgentControlChannelException: Unable to post agent 
 control request as link is not available
   at com.cloud.agent.Agent.postRequest(Agent.java:690)
   at com.cloud.agent.Agent.postRequest(Agent.java:678)
   at 
 com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
   at 
 com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
 2014-08-14 15:40:43,527 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) Report load change : {
   connections: []
 }
 2014-08-14 15:40:46,110 INFO  [cloud.agent.Agent] (Agent-Handler-1:null) 
 Reconnecting...
 2014-08-14 15:40:46,111 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
 Connecting to 10.223.49.195:8250
 2014-08-14 15:40:48,527 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) connMap={}



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


[jira] [Created] (CLOUDSTACK-7372) [vGPU] When a host is put in maintenance mode, vGPU enabled VMs failed to migrate to the other host in the cluster

2014-08-19 Thread Abhinav Roy (JIRA)
Abhinav Roy created CLOUDSTACK-7372:
---

 Summary: [vGPU] When a host is put in maintenance mode, vGPU 
enabled VMs failed to migrate to the other host in the cluster
 Key: CLOUDSTACK-7372
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7372
 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 + PV drivers
CS - 4.5.0
Reporter: Abhinav Roy
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.5.0


Steps :
==
1. Deploy an advanced zone CS setup with 2 XEN hosts in a cluster having same 
configuration and vGPU cards.
2. Create 2 VMs with vGPU offering on Host1
3. Put Host1 in maintenance mode

Expected behavior:
=
VMs should migrate to Host 2 and Host1 should go to maintenance state


Observed behavior :
=
VMs fail to migrate to Host2 with the following error and Host1 is stuck in 
prepareformaintenance state.

2014-08-18 19:16:00,608 DEBUG [c.c.a.ApiServlet] (catalina-exec-1:ctx-a55c13e9) 
===START===  10.144.7.6 -- GET  
command=prepareHostForMaintenanceid=f68de59b-3d28-452f-b82b-86fca83f6f16response=jsonsessionkey=XUBDEpbw7%2BbvhRUGB0j2dKXFW08%3D_=1408369336934
2014-08-18 19:16:00,651 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(catalina-exec-1:ctx-a55c13e9 ctx-5208dce9) submit async job-690, details: 
AsyncJobVO {id:690, userId: 2, accountId: 2, instanceType: Host, instanceId: 8, 
cmd: org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd, 
cmdInfo: 
{id:f68de59b-3d28-452f-b82b-86fca83f6f16,response:json,sessionkey:XUBDEpbw7+bvhRUGB0j2dKXFW08\u003d,ctxDetails:{\com.cloud.host.Host\:\f68de59b-3d28-452f-b82b-86fca83f6f16\},cmdEventType:MAINT.PREPARE,ctxUserId:2,httpmethod:GET,_:1408369336934,uuid:f68de59b-3d28-452f-b82b-86fca83f6f16,ctxAccountId:2,ctxStartEventId:983},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-08-18 19:16:00,653 DEBUG [c.c.a.ApiServlet] (catalina-exec-1:ctx-a55c13e9 
ctx-5208dce9) ===END===  10.144.7.6 -- GET  
command=prepareHostForMaintenanceid=f68de59b-3d28-452f-b82b-86fca83f6f16response=jsonsessionkey=XUBDEpbw7%2BbvhRUGB0j2dKXFW08%3D_=1408369336934
2014-08-18 19:16:00,654 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-3:ctx-5d223414 job-690) Add job-690 into job monitoring
2014-08-18 19:16:00,655 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-5d223414 job-690) Executing AsyncJobVO {id:690, userId: 
2, accountId: 2, instanceType: Host, instanceId: 8, cmd: 
org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd, cmdInfo: 
{id:f68de59b-3d28-452f-b82b-86fca83f6f16,response:json,sessionkey:XUBDEpbw7+bvhRUGB0j2dKXFW08\u003d,ctxDetails:{\com.cloud.host.Host\:\f68de59b-3d28-452f-b82b-86fca83f6f16\},cmdEventType:MAINT.PREPARE,ctxUserId:2,httpmethod:GET,_:1408369336934,uuid:f68de59b-3d28-452f-b82b-86fca83f6f16,ctxAccountId:2,ctxStartEventId:983},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-08-18 19:16:00,683 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-3:ctx-5d223414 job-690 ctx-4be20e99) Seq 
8-5623307084725485586: Sending  { Cmd , MgmtId: 213737702773493, via: 
8(cldstk-R720-66), Ver: v1, Flags: 100111, 
[{com.cloud.agent.api.MaintainCommand:{wait:0}}] }
2014-08-18 19:16:00,684 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-3:ctx-5d223414 job-690 ctx-4be20e99) Seq 
8-5623307084725485586: Executing:  { Cmd , MgmtId: 213737702773493, via: 
8(cldstk-R720-66), Ver: v1, Flags: 100111, 
[{com.cloud.agent.api.MaintainCommand:{wait:0}}] }
2014-08-18 19:16:00,684 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-30:ctx-d6521262) Seq 8-5623307084725485586: Executing request
2014-08-18 19:16:00,713 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-30:ctx-d6521262) Seq 8-5623307084725485586: Response Received:
2014-08-18 19:16:00,713 DEBUG [c.c.a.t.Request] (DirectAgent-30:ctx-d6521262) 
Seq 8-5623307084725485586: Processing:  { Ans: , MgmtId: 213737702773493, via: 
8, Ver: v1, Flags: 110, 
[{com.cloud.agent.api.MaintainAnswer:{willMigrate:true,result:true,wait:0}}]
 }
2014-08-18 19:16:00,713 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-3:ctx-5d223414 job-690 ctx-4be20e99) Seq 
8-5623307084725485586: Received:  { Ans: , MgmtId: 213737702773493, via: 8, 
Ver: v1, Flags: 110, { MaintainAnswer } }
2014-08-18 19:16:00,717 DEBUG [c.c.a.m.AgentAttache] 
(DirectAgent-30:ctx-d6521262) Seq 8-5623307084725485586: No more commands found
2014-08-18 19:16:00,725 DEBUG [c.c.r.ResourceState] 

[jira] [Commented] (CLOUDSTACK-7366) Baremetal agent is not including in RPM spec file

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

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

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

Commit 0dc5cb428787aadb193e9a23f1c375afbcc180da in cloudstack's branch 
refs/heads/master from [~frank.zhang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0dc5cb4 ]

CloudStackCLOUDSTACK-7366
Baremetal agent is not including in RPM spec file


 Baremetal agent is not including in RPM spec file
 -

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






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


[jira] [Commented] (CLOUDSTACK-4627) HA not working, User VM wasn't Migrated

2014-08-19 Thread Valery Ciareszka (JIRA)

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

Valery Ciareszka commented on CLOUDSTACK-4627:
--

worked for me in 4.2.1, seems to work in 4.3.0

 HA not working, User VM wasn't Migrated
 ---

 Key: CLOUDSTACK-4627
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4627
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, KVM, Management Server
Affects Versions: 4.2.0
 Environment: CentOS 6.3 64bit
Reporter: Naoki Sakamoto
Assignee: edison su
 Fix For: 4.2.1

 Attachments: 20130906_HA_SystemVM_Migration_OK_But_UserVM_NG.zip, 
 20130909_HA_UserVM_Migration_NG.zip


 1. We made one of KVM Host Power OFF by push power button of hardware for 
 High Availability Test.
 2. Vritual Router / Secodary Storage VM / Console Proxy VM is Migrated.
But User VM wasn't Migrated.



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


[jira] [Closed] (CLOUDSTACK-7133) [Automation] Failed to reboot Virtual Machine - Runtime Exception - Unable to Start VM

2014-08-19 Thread Chandan Purushothama (JIRA)

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

Chandan Purushothama closed CLOUDSTACK-7133.



Closing this ticket based on Koushik's comment. I will reopen this bug if it is 
seen later.

 [Automation] Failed to reboot Virtual Machine - Runtime Exception - Unable to 
 Start VM
 --

 Key: CLOUDSTACK-7133
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7133
 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: Chandan Purushothama
Assignee: Koushik Das
Priority: Critical
 Fix For: 4.5.0

 Attachments: management-server(1).zip


 =
 Runtime Exception during VM Reboot Job:
 =
 2014-07-11 15:10:51,329 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Work-Job-Executor-119:ctx-2cd21b46 job-420/job-422) Complete async job-422, 
 jobStatus: FAILED, resultCode: 0, result: 
 rO0ABXNyABpqYXZhLmxhbmcuUnVudGltZUV4Y2VwdGlvbp5fBkcKNIPlAgAAeHIAE2phdmEubGFuZy5FeGNlcHRpb27Q_R8-GjscxAIAAHhyABNqYXZhLmxhbmcuVGhyb3dhYmxl1cY1Jzl3uMsDAARMAAVjYXVzZXQAFUxqYXZhL2xhbmcvVGhyb3dhYmxlO0wADWRldGFpbE1lc3NhZ2V0ABJMamF2YS9sYW5nL1N0cmluZztbAApzdGFja1RyYWNldAAeW0xqYXZhL2xhbmcvU3RhY2tUcmFjZUVsZW1lbnQ7TAAUc3VwcHJlc3NlZEV4Y2VwdGlvbnN0ABBMamF2YS91dGlsL0xpc3Q7eHBxAH4AB3QAlkpvYiBmYWlsZWQgZHVlIHRvIGV4Y2VwdGlvbiBSZXNvdXJjZSBbSG9zdDoxXSBpcyB1bnJlYWNoYWJsZTogSG9zdCAxOiBVbmFibGUgdG8gc3RhcnQgaW5zdGFuY2UgZHVlIHRvIGNhbid0IGZpbmQgcmVhZHkgdGVtcGxhdGU6IDIwMyBmb3IgZGF0YSBjZW50ZXIgMXVyAB5bTGphdmEubGFuZy5TdGFja1RyYWNlRWxlbWVudDsCRio8PP0iOQIAAHhwDnNyABtqYXZhLmxhbmcuU3RhY2tUcmFjZUVsZW1lbnRhCcWaJjbdhQIABEkACmxpbmVOdW1iZXJMAA5kZWNsYXJpbmdDbGFzc3EAfgAETAAIZmlsZU5hbWVxAH4ABEwACm1ldGhvZE5hbWVxAH4ABHhwcnQAIGNvbS5jbG91ZC52bS5WbVdvcmtKb2JEaXNwYXRjaGVydAAYVm1Xb3JrSm9iRGlzcGF0Y2hlci5qYXZhdAAGcnVuSm9ic3EAfgALAAAB-3QAP29yZy5hcGFjaGUuY2xvdWRzdGFjay5mcmFtZXdvcmsuam9icy5pbXBsLkFzeW5jSm9iTWFuYWdlckltcGwkNXQAGEFzeW5jSm9iTWFuYWdlckltcGwuamF2YXQADHJ1bkluQ29udGV4dHNxAH4ACwAAADF0AD5vcmcuYXBhY2hlLmNsb3Vkc3RhY2subWFuYWdlZC5jb250ZXh0Lk1hbmFnZWRDb250ZXh0UnVubmFibGUkMXQAG01hbmFnZWRDb250ZXh0UnVubmFibGUuamF2YXQAA3J1bnNxAH4ACwAAADh0AEJvcmcuYXBhY2hlLmNsb3Vkc3RhY2subWFuYWdlZC5jb250ZXh0LmltcGwuRGVmYXVsdE1hbmFnZWRDb250ZXh0JDF0ABpEZWZhdWx0TWFuYWdlZENvbnRleHQuamF2YXQABGNhbGxzcQB-AAsAAABndABAb3JnLmFwYWNoZS5jbG91ZHN0YWNrLm1hbmFnZWQuY29udGV4dC5pbXBsLkRlZmF1bHRNYW5hZ2VkQ29udGV4dHEAfgAadAAPY2FsbFdpdGhDb250ZXh0c3EAfgALNXEAfgAdcQB-ABp0AA5ydW5XaXRoQ29udGV4dHNxAH4ACwAAAC50ADxvcmcuYXBhY2hlLmNsb3Vkc3RhY2subWFuYWdlZC5jb250ZXh0Lk1hbmFnZWRDb250ZXh0UnVubmFibGVxAH4AFnEAfgAXc3EAfgALAAAB0HEAfgARcQB-ABJxAH4AF3NxAH4ACwAAAdd0AC5qYXZhLnV0aWwuY29uY3VycmVudC5FeGVjdXRvcnMkUnVubmFibGVBZGFwdGVydAAORXhlY3V0b3JzLmphdmFxAH4AG3NxAH4ACwAAAU50ACRqYXZhLnV0aWwuY29uY3VycmVudC5GdXR1cmVUYXNrJFN5bmN0AA9GdXR1cmVUYXNrLmphdmF0AAhpbm5lclJ1bnNxAH4ACwAAAKZ0AB9qYXZhLnV0aWwuY29uY3VycmVudC5GdXR1cmVUYXNrcQB-AClxAH4AF3NxAH4ACwAABFZ0ACdqYXZhLnV0aWwuY29uY3VycmVudC5UaHJlYWRQb29sRXhlY3V0b3J0ABdUaHJlYWRQb29sRXhlY3V0b3IuamF2YXQACXJ1bldvcmtlcnNxAH4ACwAAAlt0AC5qYXZhLnV0aWwuY29uY3VycmVudC5UaHJlYWRQb29sRXhlY3V0b3IkV29ya2VycQB-AC9xAH4AF3NxAH4ACwAAAtJ0ABBqYXZhLmxhbmcuVGhyZWFkdAALVGhyZWFkLmphdmFxAH4AF3NyACZqYXZhLnV0aWwuQ29sbGVjdGlvbnMkVW5tb2RpZmlhYmxlTGlzdPwPJTG17I4QAgABTAAEbGlzdHEAfgAGeHIALGphdmEudXRpbC5Db2xsZWN0aW9ucyRVbm1vZGlmaWFibGVDb2xsZWN0aW9uGUIAgMte9x4CAAFMAAFjdAAWTGphdmEvdXRpbC9Db2xsZWN0aW9uO3hwc3IAE2phdmEudXRpbC5BcnJheUxpc3R4gdIdmcdhnQMAAUkABHNpemV4cAB3BAB4cQB-ADt4
 2014-07-11 15:10:51,338 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Work-Job-Executor-119:ctx-2cd21b46 job-420/job-422) Done executing 
 com.cloud.vm.VmWorkStart for job-422
 2014-07-11 15:10:51,343 DEBUG [c.c.v.UserVmManagerImpl] 
 (API-Job-Executor-108:ctx-d1b37d15 job-420 ctx-b9cc76f0) Unable to start VM 
 f1d98737-f934-4811-b7ef-402844e3b451
 java.lang.RuntimeException: Job failed due to exception Resource [Host:1] is 
 unreachable: Host 1: Unable to start instance due to can't find ready 
 template: 203 for data center 1
   at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:114)
   at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
   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-7132) [Automation] Failed to detach Volume from the VM due to RuntimeException: Unexpected exception

2014-08-19 Thread Chandan Purushothama (JIRA)

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

Chandan Purushothama closed CLOUDSTACK-7132.



Closing the bug based on Koushik's response. I will reopen it and provide more 
information next time when the bug is seen,

Thank you,
Chandan.

 [Automation] Failed to detach Volume from the VM due to RuntimeException: 
 Unexpected exception
 --

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

 Attachments: management-server(1).zip


 ==
 Unexpected Exception while detaching Volume from the VM:
 ==
 2014-07-11 17:28:06,154 WARN  [c.c.h.x.r.XenServerStorageProcessor] 
 (DirectAgent-143:ctx-bc033f6e) Failed dettach volume: 
 80f0f1cd-a1e7-4dec-b706-cebc3a1c6b5f
 2014-07-11 17:28:06,154 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-143:ctx-bc033f6e) Seq 1-3992722544640656559: Response Received: 
 2014-07-11 17:28:06,154 DEBUG [c.c.a.t.Request] 
 (DirectAgent-143:ctx-bc033f6e) Seq 1-3992722544640656559: Processing:  { Ans: 
 , MgmtId: 161135757057464, via: 1, Ver: v1, Flags: 10, 
 [{org.apache.cloudstack.storage.command.DettachAnswer:{result:false,details:Failed
  dettach volume: 80f0f1cd-a1e7-4dec-b706-cebc3a1c6b5f, due to The server 
 failed to handle your request, due to an internal error.  The given message 
 may give details useful for debugging the problem.,wait:0}}] }
 2014-07-11 17:28:06,154 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-45:ctx-0bbb5e9c job-1154/job-1155 ctx-41f3befc) Seq 
 1-3992722544640656559: Received:  { Ans: , MgmtId: 161135757057464, via: 1, 
 Ver: v1, Flags: 10, { DettachAnswer } }
 2014-07-11 17:28:06,154 ERROR [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-45:ctx-0bbb5e9c job-1154/job-1155 ctx-41f3befc) Invocation 
 exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Failed 
 to detach volume DATA-118 from VM VM-6ab214a7-7df9-4317-9564-4da0f5a58a86; 
 Failed dettach volume: 80f0f1cd-a1e7-4dec-b706-cebc3a1c6b5f, due to The 
 server failed to handle your request, due to an internal error.  The given 
 message may give details useful for debugging the problem.
 2014-07-11 17:28:06,155 INFO  [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-45:ctx-0bbb5e9c job-1154/job-1155 ctx-41f3befc) Rethrow 
 exception com.cloud.utils.exception.CloudRuntimeException: Failed to detach 
 volume DATA-118 from VM VM-6ab214a7-7df9-4317-9564-4da0f5a58a86; Failed 
 dettach volume: 80f0f1cd-a1e7-4dec-b706-cebc3a1c6b5f, due to The server 
 failed to handle your request, due to an internal error.  The given message 
 may give details useful for debugging the problem.
 2014-07-11 17:28:06,155 DEBUG [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-45:ctx-0bbb5e9c job-1154/job-1155) Done with run of VM 
 work job: com.cloud.storage.VmWorkDetachVolume for VM 118, job origin: 1154
 2014-07-11 17:28:06,155 ERROR [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-45:ctx-0bbb5e9c job-1154/job-1155) Unable to complete 
 AsyncJobVO {id:1155, userId: 2, accountId: 2, instanceType: null, instanceId: 
 null, cmd: com.cloud.storage.VmWorkDetachVolume, cmdInfo: 
 rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtEZXRhY2hWb2x1bWWG9F4D6zzUAwIAAUwACHZvbHVtZUlkdAAQTGphdmEvbGFuZy9Mb25nO3hyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAdnQAFFZvbHVtZUFwaVNlcnZpY2VJbXBsc3IADmphdmEubGFuZy5Mb25nO4vkkMyPI98CAAFKAAV2YWx1ZXhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cACW,
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 161135757057464, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: Fri Jul 11 17:23:04 UTC 2014}, job origin:1154
 com.cloud.utils.exception.CloudRuntimeException: Failed to detach volume 
 DATA-118 from VM VM-6ab214a7-7df9-4317-9564-4da0f5a58a86; Failed dettach 
 volume: 80f0f1cd-a1e7-4dec-b706-cebc3a1c6b5f, due to The server failed to 
 handle your request, due to an internal error.  The given message may give 
 details useful for debugging the problem.
   at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:1564)
   at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateDetachVolumeFromVM(VolumeApiServiceImpl.java:2525)
 

[jira] [Commented] (CLOUDSTACK-6634) DOC: update the ldap section of the admin guide

2014-08-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-6634:


Github user pdion891 commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/15#issuecomment-52720766
  
Karuturi,  you can close this pull request (I can't), it as been merged 
into 4.3 and master.
I've modify the highlight.

Thank you :)


 DOC: update the ldap section of the admin guide
 ---

 Key: CLOUDSTACK-6634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6634
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
  Labels: ldap
 Fix For: 4.4.0


 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.3/accounts.html#using-an-ldap-server-for-user-authentication
 there are changes/enhancements in the way ldap server is configured since 4.3 
 documentation needs to be updated with the latest info.
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+provisioning



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


[jira] [Commented] (CLOUDSTACK-5879) Document on how to use RabbitMq event bus with spring modularisation done in 4.3, also document how to use encrypted password in the config file

2014-08-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-5879:


Github user pdion891 commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/16#issuecomment-52720829
  
terbolous: I've push the PR, you can close it now (I can't). it is merge in 
master and 4.3 branches.

Thank you :)


 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file
 

 Key: CLOUDSTACK-5879
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5879
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Murali Reddy
Assignee: Radhika Nair
 Fix For: 4.5.0


 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file.
 From 4.3 RabbitMq event bus plug-in configuration need to be specified 
 differently (in 4.2 and 4.1 it was specified in componenetConext file) in 
 separate file. This doc bug is to get the necessary details required for 4.3



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


[jira] [Updated] (CLOUDSTACK-5879) Document on how to use RabbitMq event bus with spring modularisation done in 4.3, also document how to use encrypted password in the config file

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

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

Pierre-Luc Dion updated CLOUDSTACK-5879:


Assignee: (was: Radhika Nair)

 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file
 

 Key: CLOUDSTACK-5879
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5879
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Murali Reddy
 Fix For: 4.5.0


 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file.
 From 4.3 RabbitMq event bus plug-in configuration need to be specified 
 differently (in 4.2 and 4.1 it was specified in componenetConext file) in 
 separate file. This doc bug is to get the necessary details required for 4.3



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


[jira] [Resolved] (CLOUDSTACK-5879) Document on how to use RabbitMq event bus with spring modularisation done in 4.3, also document how to use encrypted password in the config file

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

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

Pierre-Luc Dion resolved CLOUDSTACK-5879.
-

   Resolution: Fixed
Fix Version/s: 4.4.0

[~webern] PR on cloudstack-docs-admin.

Regards,

 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file
 

 Key: CLOUDSTACK-5879
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5879
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Murali Reddy
 Fix For: 4.4.0, 4.5.0


 Document on how to use RabbitMq event bus with spring modularisation done in 
 4.3, also document how to use encrypted password in the config file.
 From 4.3 RabbitMq event bus plug-in configuration need to be specified 
 differently (in 4.2 and 4.1 it was specified in componenetConext file) in 
 separate file. This doc bug is to get the necessary details required for 4.3



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


[jira] [Resolved] (CLOUDSTACK-6634) DOC: update the ldap section of the admin guide

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

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

Pierre-Luc Dion resolved CLOUDSTACK-6634.
-

Resolution: Fixed

 DOC: update the ldap section of the admin guide
 ---

 Key: CLOUDSTACK-6634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6634
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
  Labels: ldap
 Fix For: 4.4.0


 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.3/accounts.html#using-an-ldap-server-for-user-authentication
 there are changes/enhancements in the way ldap server is configured since 4.3 
 documentation needs to be updated with the latest info.
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+provisioning



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


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

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

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

Pierre-Luc Dion updated CLOUDSTACK-7342:


Component/s: UI

 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, UI
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-7275) [Automation] NPE thrown in MS log while starting ConsoleProxy

2014-08-19 Thread Rajani Karuturi (JIRA)

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

Rajani Karuturi commented on CLOUDSTACK-7275:
-

since its tagged automation, I am assuming its seen when running a test case. 
Can you add marvin logs?

 [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: Management Server
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] [Commented] (CLOUDSTACK-6634) DOC: update the ldap section of the admin guide

2014-08-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-6634:


Github user karuturi closed the pull request at:

https://github.com/apache/cloudstack-docs-admin/pull/15


 DOC: update the ldap section of the admin guide
 ---

 Key: CLOUDSTACK-6634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6634
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
  Labels: ldap
 Fix For: 4.4.0


 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.3/accounts.html#using-an-ldap-server-for-user-authentication
 there are changes/enhancements in the way ldap server is configured since 4.3 
 documentation needs to be updated with the latest info.
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+provisioning



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


[jira] [Commented] (CLOUDSTACK-6634) DOC: update the ldap section of the admin guide

2014-08-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CLOUDSTACK-6634:


Github user karuturi commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/15#issuecomment-52734745
  
closing it as it is merged to upstream 


 DOC: update the ldap section of the admin guide
 ---

 Key: CLOUDSTACK-6634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6634
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
  Labels: ldap
 Fix For: 4.4.0


 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.3/accounts.html#using-an-ldap-server-for-user-authentication
 there are changes/enhancements in the way ldap server is configured since 4.3 
 documentation needs to be updated with the latest info.
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+provisioning



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


[jira] [Commented] (CLOUDSTACK-4587) VM is failing to deploy on a Legacy zone after adding zone wide primary storage and moving cluster wide primary storage to maintenance mode

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

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

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

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

CLOUDSTACK-4587. System VMs fail to start when the primary storage that has the 
System VMs is put into maintenance.
During VM start while configuring its disk devices, obtain the matching disk 
for a volume in storage
using both the volume's path and volume's datastore information.


 VM is failing to deploy on a Legacy zone after adding zone wide primary 
 storage and moving cluster wide primary storage to maintenance  mode
 

 Key: CLOUDSTACK-4587
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4587
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Assignee: Likitha Shetty
 Fix For: 4.4.0

 Attachments: failureloigs.rar, logs.rar, vmdeploylogs.rar


 Steps:
 1. Upgraded from 307 to 4.2 using VMWARE Cluster with Cluster level primary 
 storage 
 2. Add Zone wide primary storage after upgrade 
 3. Move the cluster level scope storage to Maintenance mode 
 4. Try to deploy new VM. 
 Observation:
 VM is failing to deploy on a Legacy zone after adding zone wide primary 
 storage and moving cluster wide primary storage to maintenance mode
 2013-09-01 14:21:10,323 DEBUG [cloud.network.NetworkManagerImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Network 
 id=207 is already implemented
 2013-09-01 14:21:10,354 DEBUG [network.guru.PodBasedNetworkGuru] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 Allocated a nic 
 NicProfile[119-35-4a8f547b-7bff-4b3f-ba10-b0146af4d1bb-10.102.195.111-null 
 for VM[DomainRouter|r-35-VM]
 2013-09-01 14:21:10,390 DEBUG [cloud.storage.VolumeManagerImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 Checking if we need to prepare 1 volumes for VM[DomainRouter|r-35-VM]
 2013-09-01 14:21:10,400 DEBUG [storage.image.TemplateDataFactoryImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 template 203 is already in store:2, type:Image
 2013-09-01 14:21:10,409 DEBUG [storage.image.TemplateDataFactoryImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 template 203 is already in store:203, type:Primary
 2013-09-01 14:21:10,410 DEBUG [storage.volume.VolumeServiceImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Found 
 template 203-2-3cfe22ca-3a33-39a0-bf5e-0dab154869fd in storage pool 203 with 
 VMTemplateStoragePool id: 11
 2013-09-01 14:21:10,421 DEBUG [storage.volume.VolumeServiceImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Acquire 
 lock on VMTemplateStoragePool 11 with timeout 3600 seconds
 2013-09-01 14:21:10,423 INFO  [storage.volume.VolumeServiceImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) lock is 
 acquired for VMTemplateStoragePool 11
 2013-09-01 14:21:10,431 DEBUG [storage.motion.AncientDataMotionStrategy] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE
 2013-09-01 14:21:10,519 DEBUG [storage.motion.AncientDataMotionStrategy] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) copy 
 object failed:
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:210)
 at 
 org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:411)
 at 
 org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:55)
 at 
 org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:440)
 at 
 org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:569)
 at 
 com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2536)
 at 
 com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888)
 at 
 

[jira] [Commented] (CLOUDSTACK-7371) [VMware] Enabling primary storage maintenance fails when storages are across cluster

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

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

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

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

CLOUDSTACK-7371. [VMware] Enabling primary storage maintenance fails when 
storages are across cluster.
1. While destroying a ROOT volume do the lookup of the associated VM under the 
DC and not just cluster.
2. In case of VMware, during VM start if a volume is being recreated no need to 
detach the old volume because
we now expunge it immediately and don't wait for the storage cleanup task to 
run.


 [VMware] Enabling primary storage maintenance fails when storages are across 
 cluster
 

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


 Have two primary storage across 2 clusters. Put the storage that has at least 
 one system vm into maintenance. The system vm will fail to start in the 
 second storage with the following error - 
 {noformat}
 2014-08-18 17:07:50,337 WARN  [c.c.h.v.r.VmwareResource] 
 (DirectAgent-134:ctx-440166e2 10.102.192.7, job-129/job-134, cmd: 
 StartCommand) StartCommand failed due to Exception: java.lang.RuntimeException
 Message: The name 's-2-VM' already exists.
 java.lang.RuntimeException: The name 's-2-VM' already exists.
 at 
 com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:335)
 at com.cloud.hypervisor.vmware.mo.HostMO.createVm(HostMO.java:559)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.createBlankVm(HypervisorHostHelper.java:1165)
 at 
 com.cloud.hypervisor.vmware.mo.HostMO.createBlankVm(HostMO.java:744)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1391)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:448)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:294)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
 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)
 {noformat}



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


[jira] [Resolved] (CLOUDSTACK-4587) VM is failing to deploy on a Legacy zone after adding zone wide primary storage and moving cluster wide primary storage to maintenance mode

2014-08-19 Thread Likitha Shetty (JIRA)

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

Likitha Shetty resolved CLOUDSTACK-4587.


   Resolution: Fixed
Fix Version/s: (was: 4.4.0)
   4.5.0

 VM is failing to deploy on a Legacy zone after adding zone wide primary 
 storage and moving cluster wide primary storage to maintenance  mode
 

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

 Attachments: failureloigs.rar, logs.rar, vmdeploylogs.rar


 Steps:
 1. Upgraded from 307 to 4.2 using VMWARE Cluster with Cluster level primary 
 storage 
 2. Add Zone wide primary storage after upgrade 
 3. Move the cluster level scope storage to Maintenance mode 
 4. Try to deploy new VM. 
 Observation:
 VM is failing to deploy on a Legacy zone after adding zone wide primary 
 storage and moving cluster wide primary storage to maintenance mode
 2013-09-01 14:21:10,323 DEBUG [cloud.network.NetworkManagerImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Network 
 id=207 is already implemented
 2013-09-01 14:21:10,354 DEBUG [network.guru.PodBasedNetworkGuru] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 Allocated a nic 
 NicProfile[119-35-4a8f547b-7bff-4b3f-ba10-b0146af4d1bb-10.102.195.111-null 
 for VM[DomainRouter|r-35-VM]
 2013-09-01 14:21:10,390 DEBUG [cloud.storage.VolumeManagerImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 Checking if we need to prepare 1 volumes for VM[DomainRouter|r-35-VM]
 2013-09-01 14:21:10,400 DEBUG [storage.image.TemplateDataFactoryImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 template 203 is already in store:2, type:Image
 2013-09-01 14:21:10,409 DEBUG [storage.image.TemplateDataFactoryImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 template 203 is already in store:203, type:Primary
 2013-09-01 14:21:10,410 DEBUG [storage.volume.VolumeServiceImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Found 
 template 203-2-3cfe22ca-3a33-39a0-bf5e-0dab154869fd in storage pool 203 with 
 VMTemplateStoragePool id: 11
 2013-09-01 14:21:10,421 DEBUG [storage.volume.VolumeServiceImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Acquire 
 lock on VMTemplateStoragePool 11 with timeout 3600 seconds
 2013-09-01 14:21:10,423 INFO  [storage.volume.VolumeServiceImpl] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) lock is 
 acquired for VMTemplateStoragePool 11
 2013-09-01 14:21:10,431 DEBUG [storage.motion.AncientDataMotionStrategy] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) 
 copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE
 2013-09-01 14:21:10,519 DEBUG [storage.motion.AncientDataMotionStrategy] 
 (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) copy 
 object failed:
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:210)
 at 
 org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:411)
 at 
 org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:55)
 at 
 org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:440)
 at 
 org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:569)
 at 
 com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2536)
 at 
 com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2740)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1872)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1972)
 at 
 

[jira] [Resolved] (CLOUDSTACK-7371) [VMware] Enabling primary storage maintenance fails when storages are across cluster

2014-08-19 Thread Likitha Shetty (JIRA)

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

Likitha Shetty resolved CLOUDSTACK-7371.


Resolution: Fixed

 [VMware] Enabling primary storage maintenance fails when storages are across 
 cluster
 

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


 Have two primary storage across 2 clusters. Put the storage that has at least 
 one system vm into maintenance. The system vm will fail to start in the 
 second storage with the following error - 
 {noformat}
 2014-08-18 17:07:50,337 WARN  [c.c.h.v.r.VmwareResource] 
 (DirectAgent-134:ctx-440166e2 10.102.192.7, job-129/job-134, cmd: 
 StartCommand) StartCommand failed due to Exception: java.lang.RuntimeException
 Message: The name 's-2-VM' already exists.
 java.lang.RuntimeException: The name 's-2-VM' already exists.
 at 
 com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:335)
 at com.cloud.hypervisor.vmware.mo.HostMO.createVm(HostMO.java:559)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.createBlankVm(HypervisorHostHelper.java:1165)
 at 
 com.cloud.hypervisor.vmware.mo.HostMO.createBlankVm(HostMO.java:744)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1391)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:448)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:294)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
 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)
 {noformat}



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