[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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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.
[ 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
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
[ 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.
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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)