[jira] [Created] (CLOUDSTACK-4406) Remove cleanString() call for every API to improve performance - especially of the list APIs
Nitin Mehta created CLOUDSTACK-4406: --- Summary: Remove cleanString() call for every API to improve performance - especially of the list APIs Key: CLOUDSTACK-4406 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4406 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Nitin Mehta Priority: Critical Fix For: Future The cleanString() method is invoked for every API call to remove sensitive data, but this is invoked for every api even though it might or might not have it. This is not optimal as CS scales. We need a more optimized approach to remove such data -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-4133) hitting MySQLIntegrityConstraintViolationException for key 'i_template_spool_ref__template_id__pool_id' in case of parallel deployment
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-4133.
--
tried parallel deployment scenario for 5 times . didnt face any failure.
> hitting MySQLIntegrityConstraintViolationException for key
> 'i_template_spool_ref__template_id__pool_id' in case of parallel deployment
> ---
>
> Key: CLOUDSTACK-4133
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4133
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: xenserver advanced zone
>Reporter: shweta agarwal
>Assignee: Nitin Mehta
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.tar.gz
>
>
> Deploying 30 VMs in Parallel on xenserver host
> getting following exception ..though not consistently
> 2013-08-07 01:06:38,694 DEBUG [db.Transaction.Transaction]
> (Job-Executor-103:job-177 = [ 504ce7c1-ec29-4edb-9ef6-073c89f23f21 ]) Rolling
> back the transaction: Time = 11934 Name =
> -AsyncJobManagerImpl$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:896-Transaction.removeUpTo:839-Transaction.close:663-TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-PrimaryDataStoreImpl.create:239-VolumeServiceImpl.createBaseImageAsync:387-VolumeServiceImpl.createVolumeFromTemplateAsync:538-VolumeManagerImpl.recreateVolume:2488-VolumeManagerImpl.prepare:2545-VirtualMachineManagerImpl.advanceStart:934-VirtualMachineManagerImpl.start:624
> 2013-08-07 01:06:39,552 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-197:null) Seq 1-122749286: Response Received:
> 2013-08-07 01:06:39,553 DEBUG [agent.transport.Request]
> (DirectAgent-197:null) Seq 1-122749286: Processing: { Ans: , MgmtId:
> 7200344900649, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":true,"wait":0}}] }
> 2013-08-07 01:06:39,557 DEBUG [agent.transport.Request]
> (Job-Executor-121:job-195 = [ 23b53290-6961-4913-a5ba-31fdcb453a79 ]) Seq
> 1-122749286: Received: { Ans: , MgmtId: 7200344900649, via: 1, Ver: v1,
> Flags: 10, { Answer } }
> 2013-08-07 01:06:39,559 DEBUG [storage.datastore.PrimaryDataStoreImpl]
> (Job-Executor-120:job-194 = [ cac12fea-d3ed-4764-aee5-9e292b555024 ]) Failed
> to insert (templateId: 202, poolId: 2) to template_spool_ref
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1346)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl.create(PrimaryDataStoreImpl.java:239)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:387)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:538)
> at
> com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2488)
> at
> com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2545)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:934)
> at
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:624)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3408)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2968)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2954)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.
[jira] [Closed] (CLOUDSTACK-4172) Parallel deployment of vm fails when userdata is provided
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-4172.
--
Even I cant reproduce in my new setup
> Parallel deployment of vm fails when userdata is provided
> --
>
> Key: CLOUDSTACK-4172
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4172
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: xenserver advance zone
>Reporter: shweta agarwal
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: cloud-backup.dmp, management-server.log.tar.gz
>
>
> Repro steps:
> Set up - Advanced zone with 1 host (We all all the Vms to get deployed in
> this host).
> 1. Create an account.
> 2. Create network for this account.
> 3. Deploy a Vm in this network , so that the router for this network is
> already is running.
> 4. Deploy 30 - 50 Vms in parallel in this network by passing userdata.
> called 30 vm deployment call with userdata and all vm deployment failed with
> following exception
> 2013-08-07 21:53:34,410 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-87:job-836
> = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Applying userdata and password
> entry in network Ntwk[207|Guest|8]
> 2013-08-07 21:53:34,422 DEBUG [agent.transport.Request]
> (Job-Executor-87:job-836 = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Seq
> 1-122754475: Sending { Cmd , MgmtId: 7200344900649, via: 1, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.routing.SavePasswordCommand":{"password":"fnirq_cnffjbeq","vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}},{"com.cloud.agent.api.routing.VmDataCommand":{"vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}}]
> }
> 2013-08-07 21:53:34,422 DEBUG [agent.transport.Request]
> (Job-Executor-87:job-836 = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Seq
> 1-122754475: Executing: { Cmd , MgmtId: 7200344900649, via: 1, Ver: v1,
> Flags: 100011,
> [{"com.cloud.agent.api.routing.SavePasswordCommand":{"password":"fnirq_cnffjbeq","vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}},{"com.cloud.agent.api.routing.VmDataCommand":{"vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}}]
> }
> 2013-08-07 21:53:34,533 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-203:null) Seq 1-122754474: Executing request
> 2013-08-07 21:53:34,540 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-10:null) Ping from 3
> 2013-08-07 21:53:34,537 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-296:null) Seq 1-122754475: Executing request
> 2013-08-07 21:53:34,582 DEBUG [cloud.network.NetworkModelImpl]
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Service
> SecurityGroup is not supported in the network id=207
> 2013-08-07 21:53:34,582 DEBUG [cloud.network.NetworkModelImpl]
> (ApiServer-7:null) Service SecurityGroup is not supported in the network
> id=207
> 2013-08-07 21:53:34,586 DEBUG [cloud.network.NetworkModelImpl]
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Service
> SecurityGroup is not supported in the network id=207
> 2013-08-07 21:53:34,951 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Deploy
> avoids pods: null, clusters: null, hosts: null
> 2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ])
> DeploymentPlanner allocation algorithm:
> com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_392cf6b8@1c529aa0
> 2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Trying
> to allocate a host and storage pools from dc:1, pod:null,cluster:null,
> requested cpu: 128, requested ram: 134217728
> 2013-08-07 2
[jira] [Closed] (CLOUDSTACK-4253) [VMWARE] Failed to deploy one of the VM with NPE when tried deploy two VM's at the same time (While acquiring lock on Storage pool)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Mada closed CLOUDSTACK-4253.
This issue is not observed now. Hence closing the bug.
> [VMWARE] Failed to deploy one of the VM with NPE when tried deploy two VM's
> at the same time (While acquiring lock on Storage pool)
> ---
>
> Key: CLOUDSTACK-4253
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4253
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: edison su
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: apilog.log, apilog.log, db.dmp, db.sql,
> management-server.log, management-server.log
>
>
> Steps:
> 1. Configure ADv zone with Standard Vswitch with VMWARE cluster of 2 hosts.
> 2. Create an account
> 3. Tried to deploy VM using this account
> 4. When its created, tried to create one more instance
> Observation:
> 1. Second instance got created . But first instance failed to deploy with NPE:
> 2013-08-12 22:04:58,956 INFO [storage.volume.VolumeServiceImpl]
> (Job-Executor-49:job-112 = [ ad5f8d28-2cd7-4a4a-9dd5-91b92af66fc0 ]) Unable
> to acquire lock on VMTemplateStoragePool 10
> 2013-08-12 22:04:58,959 ERROR [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-49:job-112 = [ ad5f8d28-2cd7-4a4a-9dd5-91b92af66fc0 ]) Failed
> to start instance VM[User|cdcuser1i2]
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:416)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:538)
> at
> com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2493)
> at
> com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2550)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:884)
> at
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:574)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3402)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2962)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2948)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-12 22:04:58,962 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-48:job-111 = [ e68c85d0-363d-4976-a137-5f98636ffea2 ]) Asking
> BareMetalUserdata to prepare for
> Nic[66-31-2a3aba48-b63f-456b-be81-03f18bd9862a-10.1.1.199]
> 2013-08-12 22:04:58,967 DEBUG [cloud.network.NetworkModelImpl]
> (Job-Executor-48:job-111 = [ e68c85d0-363d-4976-a137-5f98636ffea2 ]) Service
> SecurityGroup is not supported in the network id=214
> 2013-08-12 22:04:58,969 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-48:job-111 = [ e68c85d0-363d-4976-a137-5f98636ffea2 ]) Checking
> if we need to prepare 1 volumes for VM[User|cdcuser1i1]
> 2013-08-12 22:04:58,973 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-49:job-112 = [ ad5f8d28-2cd7-4a4a-9dd5-91b92af66fc0 ]) Cleaning
> up resources for the vm VM[User|cdcuser1i2] in Starting state
> 2013-08-12 22:04:58,979 DEBUG [agent.transport.Request]
> (Job-Executor-49:job-112 = [ ad5f8d28-2cd7-4a4a-9dd5-91b92af66fc0 ]) Seq
> 8-104267875: Sending { Cmd , MgmtId: 90310994128556, via: 8, Ver:
[jira] [Updated] (CLOUDSTACK-4199) Redundant Virtual Router - no failover occur
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti updated CLOUDSTACK-4199:
-
Priority: Critical (was: Major)
> Redundant Virtual Router - no failover occur
>
>
> Key: CLOUDSTACK-4199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4199
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MSACS 4.2 campointernal build 341
> host XS 6.2
>Reporter: angeline shen
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: FAULT_logs.tgz, logs.tgz, management-server.log.gz,
> management-server.log.gz, MASTER_logs.tgz, Screenshot-CloudPlatform™ -
> Mozilla Firefox-3.png, Screenshot-CloudPlatform™ - Mozilla Firefox-4.png
>
>
> 1. create network offering 'egallowrvrnw1' with egress firewall policy :
> allow ,redundant router
>advance zone. create network of this offering.create guest VMs
>Verify ssh to VMs. VMs can ping other VMs in this network & reach
> internet
> 2. RVR MASTER r-37-VM
>RVR BACKUP r-38-VM
>stop r-37-VM
> Result:r-37-VMstate becomes UNKNOWN
> r-38-VMstate becomes FAULT
> no failover occur
> Cannot ssh to existing VMs
> 3. start r-37-VM.
> Result:r-37-VMstate becomes MASTER
> r-38-VMstate remains FAULT
> VMs can reach other VMs in same network.
> VMs cannot reach internet
> 4. stop r-37-VM
> r-37-VMstate becomes UNKNOWN
> r-38-VMstate becomes FAULT
> no failover occur
> Cannot ssh to existing VMs
> r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 1
> networks to update RvR status.
> 2013-08-08 19:22:44,763 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-37-VM, id: 37) just switch from MASTER to UNKNOWN
> 2013-08-08 19:22:44,768 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206273: Sending { Cmd ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckRouterCommand":{"a
> ccessDetails":{"router.ip":"169.254.3.245","router.name":"r-38-VM"},"wait":30}}]
> }
> 2013-08-08 19:22:44,769 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206273: Executing: { Cmd ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckRouterCommand":
> 2013-08-08 19:22:45,116 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-38-VM, id: 38) just switch from BACKUP to FAULT
> 2013-08-08 19:22:45,344 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-270:null) Seq 1-206274: Response Received:
> 2013-08-08 19:22:45,345 DEBUG [agent.transport.Request]
> (DirectAgent-270:null) Seq 1-206274: Processing: { Ans: , MgmtId:
> 7343890761426, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.CheckRouterAnswer":{"state":"FAULT","
> isBumped":false,"result":true,"details":"Status: FAULT (RTNETLINK answers: No
> such process)&Bumped: NO","wait":0}}] }
> 2013-08-08 19:22:45,345 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206274: Received: { Ans: ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 10, { CheckRouterAnswer } }
> 2013-08-08 19:22:45,345 DEBUG [agent.manager.AgentManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Details from executing class
> com.cloud.agent.api.CheckRouterCommand: Status: FAULT (RTNETLINK answers: No
> such process)&Bumped: N
> O
> 2013-08-08 19:22:45,349 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-38-VM, id: 38) just switch from BACKUP to FAULT
> 2013-08-08 19:22:46,781 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-13:null) Ping from 2
> 2013-08-08 19:22:47,125 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-12:null) Ping from 3
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4199) Redundant Virtual Router - no failover occur
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744702#comment-13744702
]
Sudha Ponnaganti commented on CLOUDSTACK-4199:
--
priority set to critical as this si failing even for Xen
> Redundant Virtual Router - no failover occur
>
>
> Key: CLOUDSTACK-4199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4199
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MSACS 4.2 campointernal build 341
> host XS 6.2
>Reporter: angeline shen
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: FAULT_logs.tgz, logs.tgz, management-server.log.gz,
> management-server.log.gz, MASTER_logs.tgz, Screenshot-CloudPlatform™ -
> Mozilla Firefox-3.png, Screenshot-CloudPlatform™ - Mozilla Firefox-4.png
>
>
> 1. create network offering 'egallowrvrnw1' with egress firewall policy :
> allow ,redundant router
>advance zone. create network of this offering.create guest VMs
>Verify ssh to VMs. VMs can ping other VMs in this network & reach
> internet
> 2. RVR MASTER r-37-VM
>RVR BACKUP r-38-VM
>stop r-37-VM
> Result:r-37-VMstate becomes UNKNOWN
> r-38-VMstate becomes FAULT
> no failover occur
> Cannot ssh to existing VMs
> 3. start r-37-VM.
> Result:r-37-VMstate becomes MASTER
> r-38-VMstate remains FAULT
> VMs can reach other VMs in same network.
> VMs cannot reach internet
> 4. stop r-37-VM
> r-37-VMstate becomes UNKNOWN
> r-38-VMstate becomes FAULT
> no failover occur
> Cannot ssh to existing VMs
> r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 1
> networks to update RvR status.
> 2013-08-08 19:22:44,763 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-37-VM, id: 37) just switch from MASTER to UNKNOWN
> 2013-08-08 19:22:44,768 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206273: Sending { Cmd ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckRouterCommand":{"a
> ccessDetails":{"router.ip":"169.254.3.245","router.name":"r-38-VM"},"wait":30}}]
> }
> 2013-08-08 19:22:44,769 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206273: Executing: { Cmd ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckRouterCommand":
> 2013-08-08 19:22:45,116 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-38-VM, id: 38) just switch from BACKUP to FAULT
> 2013-08-08 19:22:45,344 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-270:null) Seq 1-206274: Response Received:
> 2013-08-08 19:22:45,345 DEBUG [agent.transport.Request]
> (DirectAgent-270:null) Seq 1-206274: Processing: { Ans: , MgmtId:
> 7343890761426, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.CheckRouterAnswer":{"state":"FAULT","
> isBumped":false,"result":true,"details":"Status: FAULT (RTNETLINK answers: No
> such process)&Bumped: NO","wait":0}}] }
> 2013-08-08 19:22:45,345 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206274: Received: { Ans: ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 10, { CheckRouterAnswer } }
> 2013-08-08 19:22:45,345 DEBUG [agent.manager.AgentManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Details from executing class
> com.cloud.agent.api.CheckRouterCommand: Status: FAULT (RTNETLINK answers: No
> such process)&Bumped: N
> O
> 2013-08-08 19:22:45,349 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-38-VM, id: 38) just switch from BACKUP to FAULT
> 2013-08-08 19:22:46,781 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-13:null) Ping from 2
> 2013-08-08 19:22:47,125 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-12:null) Ping from 3
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4375) VM Migration is failing from one cluster to another cluster.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744696#comment-13744696
]
ASF subversion and git services commented on CLOUDSTACK-4375:
-
Commit 893d524d5704097fc5501e91a6822de7b7961035 in branch refs/heads/4.2 from
[~sateeshc]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=893d524 ]
CLOUDSTACK-4375 VM Migration is failing from one cluster to another cluster.
Updating the fix to cover one more scenario when user directly calls API
migrateVirtualMachineWithVolume.
If currentPool is accessible to destination host, skip calling allocators and
move on to next volume to process.
This means if user calls migrateVirtualMachineWithVolume API where all volumes
of VM are accessible on specified target host,
then API fails as there is no storage migration involved. Instead user should
call migrateVirtualMachine API.
Signed-off-by: Sateesh Chodapuneedi
> VM Migration is failing from one cluster to another cluster.
>
>
> Key: CLOUDSTACK-4375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4375
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps followed are as below:
> 1)Created a Advanced Zone VMware setup with two clusters C1 & c2.
> 2)C1 having 2 hosts H1 and H2 and C2 having single host H3.
> 3)Dedicated the Zone to Domain D1 having Account A1 and A2.
> 4)Dedicated the Host H2 to Account A1, where H1 has the system Vm's in it.
> 5)Created a VM not using the affinity group for the host,the Router VM came
> up on the host H1and the VM is created on host H3 of the cluster C2.
> 6)Now tried to migrate the VM from H3 to H1 the migration was successful.
> 7)Now tried to migrate the VM from H1 to H3 again the VM migration failed
> with the below error message
> "2013-08-17 03:13:59,447 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,488 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-2:null) submit async job-178 = [
> b9d65e31-7cdf-4ce5-b93c-440287d8523f ], details: AsyncJobVO {id:178, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null,
> cmdInfo:
> {"response":"json","sessionkey":"3O/KhJ6pMFCAfLTZtIqQOY6R6/4\u003d","virtualmachineid":"385b5edb-b6b2-4931-a4ab-8f9bd96acd14","cmdEventType":"VM.MIGRATE","hostid":"49537136-d44f-439a-937c-442ed74bd697","ctxUserId":"2","httpmethod":"GET","_":"1376669973550","ctxAccountId":"2","ctxStartEventId":"618"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6703101771911,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-17 03:13:59,489 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,491 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-178
> = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]
> 2013-08-17 03:13:59,528 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Migrating VM[User|kiran14] to
> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
> : Dest[Zone(3)-Pod(3)-Cluster(6)-Host(11)-Storage()]
> 2013-08-17 03:13:59,529 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]) Source
> and destination host are not in same cluster, unable to migrate to host: 11
> 2013-08-17 03:13:59,536 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
> com.cloud.utils.exception.CloudRuntimeException: Source and dest
[jira] [Resolved] (CLOUDSTACK-4375) VM Migration is failing from one cluster to another cluster.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi resolved CLOUDSTACK-4375.
--
Resolution: Fixed
> VM Migration is failing from one cluster to another cluster.
>
>
> Key: CLOUDSTACK-4375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4375
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps followed are as below:
> 1)Created a Advanced Zone VMware setup with two clusters C1 & c2.
> 2)C1 having 2 hosts H1 and H2 and C2 having single host H3.
> 3)Dedicated the Zone to Domain D1 having Account A1 and A2.
> 4)Dedicated the Host H2 to Account A1, where H1 has the system Vm's in it.
> 5)Created a VM not using the affinity group for the host,the Router VM came
> up on the host H1and the VM is created on host H3 of the cluster C2.
> 6)Now tried to migrate the VM from H3 to H1 the migration was successful.
> 7)Now tried to migrate the VM from H1 to H3 again the VM migration failed
> with the below error message
> "2013-08-17 03:13:59,447 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,488 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-2:null) submit async job-178 = [
> b9d65e31-7cdf-4ce5-b93c-440287d8523f ], details: AsyncJobVO {id:178, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null,
> cmdInfo:
> {"response":"json","sessionkey":"3O/KhJ6pMFCAfLTZtIqQOY6R6/4\u003d","virtualmachineid":"385b5edb-b6b2-4931-a4ab-8f9bd96acd14","cmdEventType":"VM.MIGRATE","hostid":"49537136-d44f-439a-937c-442ed74bd697","ctxUserId":"2","httpmethod":"GET","_":"1376669973550","ctxAccountId":"2","ctxStartEventId":"618"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6703101771911,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-17 03:13:59,489 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,491 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-178
> = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]
> 2013-08-17 03:13:59,528 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Migrating VM[User|kiran14] to
> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
> : Dest[Zone(3)-Pod(3)-Cluster(6)-Host(11)-Storage()]
> 2013-08-17 03:13:59,529 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]) Source
> and destination host are not in same cluster, unable to migrate to host: 11
> 2013-08-17 03:13:59,536 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
> com.cloud.utils.exception.CloudRuntimeException: Source and destination host
> are not in same cluster, unable to migrate to host: 11
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1452)
> at
> com.cloud.vm.UserVmManagerImpl.migrateVirtualMachine(UserVmManagerImpl.java:3981)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:147)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concu
[jira] [Closed] (CLOUDSTACK-4352) [VMWARE]Resize of offline (Detached} volumes to the same size is allowed from Cloudstack with which worker VM's are not getting deleted from VMWARE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada closed CLOUDSTACK-4352. This issue is fixed . Hence closing the bug. > [VMWARE]Resize of offline (Detached} volumes to the same size is allowed from > Cloudstack with which worker VM's are not getting deleted from VMWARE > --- > > Key: CLOUDSTACK-4352 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4352 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, VMware >Affects Versions: 4.2.0 >Reporter: Sailaja Mada >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.2.0 > > Attachments: apilog.log, dbdmp.sql, management-server.log, > resizevols.png > > > Steps: > 1. Configure Adv Zone with VMWARE > 2. Deploy VM > 3. Attach new DATA volume of 5 GB to this instance > 4. Detach the DATA volume > 5. Resize the volume to same size as 5 GB > Observation: > 1. Now we allow to resize offline volumes after the fix for : > CLOUDSTACK-4143) [VMWARE] Resize request sent for the volumes which are not > attached to the instance > 2. This fix will create worker VM when requested to resize offline volumes > and gets deleted after resize is completed > 3. But Resize of offline (Detached} volumes to the same size is allowed from > Cloudstack with which worker VM's are not getting deleted from VMWARE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4375) VM Migration is failing from one cluster to another cluster.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744692#comment-13744692
]
Sateesh Chodapuneedi commented on CLOUDSTACK-4375:
--
if currentPool is accessible to destination host, skip calling allocators and
move on to next volume to process.
This means if user calls migrateVirtualMachineWithVolume API where all volumes
of VM are accessible on specified target host, then API fails as there is no
storage migration involved. Instead user should call migrateVirtualMachine API.
We now warn user of each volume that doesn't require migration (accessible on
target host).
2013-08-20 04:16:20,517 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-2:job-40 = [ 793485ca-0a2f-4553-88f6-7e385d7c5f01 ]) Executing
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd
for job-40 = [ 793485ca-0a2f-4553-88f6-7e385d7c5f01 ]
2013-08-20 04:16:20,618 WARN [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-2:job-40 = [ 793485ca-0a2f-4553-88f6-7e385d7c5f01 ]) Volume
ROOT-5 will not be migrated as it's current storage pool is accessible on host
10.102.192.11
2013-08-20 04:16:20,625 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-2:job-40 = [ 793485ca-0a2f-4553-88f6-7e385d7c5f01 ]) Unexpected
exception while executing
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd
com.cloud.exception.InvalidParameterValueException: Migration of the vm
VM[User|m1]from host Host[-4-Routing] to destination host Host[-7-Routing]
doesn't involve migrating the volumes.
--
> VM Migration is failing from one cluster to another cluster.
>
>
> Key: CLOUDSTACK-4375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4375
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps followed are as below:
> 1)Created a Advanced Zone VMware setup with two clusters C1 & c2.
> 2)C1 having 2 hosts H1 and H2 and C2 having single host H3.
> 3)Dedicated the Zone to Domain D1 having Account A1 and A2.
> 4)Dedicated the Host H2 to Account A1, where H1 has the system Vm's in it.
> 5)Created a VM not using the affinity group for the host,the Router VM came
> up on the host H1and the VM is created on host H3 of the cluster C2.
> 6)Now tried to migrate the VM from H3 to H1 the migration was successful.
> 7)Now tried to migrate the VM from H1 to H3 again the VM migration failed
> with the below error message
> "2013-08-17 03:13:59,447 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,488 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-2:null) submit async job-178 = [
> b9d65e31-7cdf-4ce5-b93c-440287d8523f ], details: AsyncJobVO {id:178, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null,
> cmdInfo:
> {"response":"json","sessionkey":"3O/KhJ6pMFCAfLTZtIqQOY6R6/4\u003d","virtualmachineid":"385b5edb-b6b2-4931-a4ab-8f9bd96acd14","cmdEventType":"VM.MIGRATE","hostid":"49537136-d44f-439a-937c-442ed74bd697","ctxUserId":"2","httpmethod":"GET","_":"1376669973550","ctxAccountId":"2","ctxStartEventId":"618"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6703101771911,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-17 03:13:59,489 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,491 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-178
> = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]
> 2013-08-17 03:13:59,528 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Migrating VM[User|kiran14] to
> Dest[Zone(Id)-Pod(Id
[jira] [Reopened] (CLOUDSTACK-4375) VM Migration is failing from one cluster to another cluster.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi reopened CLOUDSTACK-4375:
--
Re-opening to include one more scenario cited by Prachi.
> VM Migration is failing from one cluster to another cluster.
>
>
> Key: CLOUDSTACK-4375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4375
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps followed are as below:
> 1)Created a Advanced Zone VMware setup with two clusters C1 & c2.
> 2)C1 having 2 hosts H1 and H2 and C2 having single host H3.
> 3)Dedicated the Zone to Domain D1 having Account A1 and A2.
> 4)Dedicated the Host H2 to Account A1, where H1 has the system Vm's in it.
> 5)Created a VM not using the affinity group for the host,the Router VM came
> up on the host H1and the VM is created on host H3 of the cluster C2.
> 6)Now tried to migrate the VM from H3 to H1 the migration was successful.
> 7)Now tried to migrate the VM from H1 to H3 again the VM migration failed
> with the below error message
> "2013-08-17 03:13:59,447 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,488 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-2:null) submit async job-178 = [
> b9d65e31-7cdf-4ce5-b93c-440287d8523f ], details: AsyncJobVO {id:178, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null,
> cmdInfo:
> {"response":"json","sessionkey":"3O/KhJ6pMFCAfLTZtIqQOY6R6/4\u003d","virtualmachineid":"385b5edb-b6b2-4931-a4ab-8f9bd96acd14","cmdEventType":"VM.MIGRATE","hostid":"49537136-d44f-439a-937c-442ed74bd697","ctxUserId":"2","httpmethod":"GET","_":"1376669973550","ctxAccountId":"2","ctxStartEventId":"618"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6703101771911,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-17 03:13:59,489 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,491 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-178
> = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]
> 2013-08-17 03:13:59,528 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Migrating VM[User|kiran14] to
> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
> : Dest[Zone(3)-Pod(3)-Cluster(6)-Host(11)-Storage()]
> 2013-08-17 03:13:59,529 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]) Source
> and destination host are not in same cluster, unable to migrate to host: 11
> 2013-08-17 03:13:59,536 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
> com.cloud.utils.exception.CloudRuntimeException: Source and destination host
> are not in same cluster, unable to migrate to host: 11
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1452)
> at
> com.cloud.vm.UserVmManagerImpl.migrateVirtualMachine(UserVmManagerImpl.java:3981)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:147)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(
[jira] [Closed] (CLOUDSTACK-2797) QA: Test Consistent use of refresh Button
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-2797. -- > QA: Test Consistent use of refresh Button > - > > Key: CLOUDSTACK-2797 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2797 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Parth Jagirdar > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2797) QA: Test Consistent use of refresh Button
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar resolved CLOUDSTACK-2797. Resolution: Fixed Verified, As per bug and In case of instances the destroyed status shows up without navigating away from the table/page. So consider this fixed. However as Mike observed and I too agree that in some pages apart from "Fetch Latest" for example "Refresh" button on templates page. When a template is being downloaded, user cannot actually see the progress in "%" unless page is refreshed. While this is ok but its good too have consistency across UI; i.e either use auto refresh or use refresh button. (Also Refresh button is less preferred due to increase in complexity on UI but dev can make decision based on complexity). > QA: Test Consistent use of refresh Button > - > > Key: CLOUDSTACK-2797 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2797 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Parth Jagirdar > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-1585) Enact a consistent use of the "Refresh" button
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-1585. -- Verified, As per bug and In case of instances the destroyed status shows up without navigating away from the table/page. So consider this fixed. However as Mike observed and I too agree that in some pages apart from "Fetch Latest" for example "Refresh" button on templates page. When a template is being downloaded, user cannot actually see the progress in "%" unless page is refreshed. While this is ok but its good too have consistency across UI; i.e either use auto refresh or use refresh button. (Also Refresh button is less preferred due to increase in complexity on UI but dev can make decision based on complexity). > Enact a consistent use of the "Refresh" button > -- > > Key: CLOUDSTACK-1585 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1585 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 > Environment: Chrome on Mac OS X 10.8.2 >Reporter: Mike Tutkowski >Assignee: Brian Federle >Priority: Minor > Fix For: 4.2.0 > > > From an e-mail exchange (newer of the two messages is on the top): > Brian Federle brian.fede...@citrix.com via incubator.apache.org > 3:41 PM (21 minutes ago) > to Pranav, cloudstack-dev > Yes, please make a feature request for this. Having a table listing refresh > should be fairly easy to implement; it is one of those things I wanted to fix > but keep forgetting to do ;) You can assign to me or Pranav. > -Brian > -Original Message- > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > Sent: Thursday, March 07, 2013 1:37 PM > To: cloudstack-...@incubator.apache.org > Subject: Question about "Refresh" buttons in the GUI > Hi, > I've noticed that some panels have a "Refresh" button and others don't (and > in at least one case, it's actually called "Fetch latest"). I wonder if we > would benefit from making this consistent across the GUI? For example, when > I destroy a VM, I don't actually see it disappear from the table it's in > until I click on another tab and then click back to the Instances tab. > Thoughts on this? Is this "worthy" of a JIRA ticket? > Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4021) [Automation] TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication failed to deploy VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744684#comment-13744684
]
Rayees Namathponnan commented on CLOUDSTACK-4021:
-
Automation running with 2 zones, look this this test cases trying to find empty
host in first zone alone; you cannot find empty host in first zone during
automation; we need to check for both zones before skipping the test.
> [Automation]
> TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication failed to
> deploy VM
> --
>
> Key: CLOUDSTACK-4021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4021
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.2.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Saksham Srivastava
> Fix For: 4.2.0
>
>
> Test case
> "integration.component.test_explicit_dedication.TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication"
> failing automation runs
> Error Message
> Execute cmd: asyncquery failed, due to: {errorcode : 533, errortext :
> u'Unable to create a deployment for
> VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity
> groups provided, there may not be sufficient capacity to follow them'}
> Stacktrace
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_explicit_dedication.py",
> line 204, in test_01_deploy_vm_with_explicit_dedication
> mode=self.services["mode"]
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 388, in create
> virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 614, in deployVirtualMachine
> response = self.connection.marvin_request(command,
> response_type=response, method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 230, in marvin_request
> response = self.poll(asyncJobId, response_type)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 91, in poll
> "asyncquery", asyncResonse.jobresult)
> cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
> 533, errortext : u'Unable to create a deployment for
> VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity
> groups provided, there may not be sufficient capacity to follow them'}
> Looks like test case trying to create VM eventhough there is no host with
> emplty VM
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4199) Redundant Virtual Router - no failover occur
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angeline shen updated CLOUDSTACK-4199:
--
Attachment: management-server.log.gz
> Redundant Virtual Router - no failover occur
>
>
> Key: CLOUDSTACK-4199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4199
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MSACS 4.2 campointernal build 341
> host XS 6.2
>Reporter: angeline shen
>Assignee: Sheng Yang
> Fix For: 4.2.0
>
> Attachments: FAULT_logs.tgz, logs.tgz, management-server.log.gz,
> management-server.log.gz, MASTER_logs.tgz, Screenshot-CloudPlatform™ -
> Mozilla Firefox-3.png, Screenshot-CloudPlatform™ - Mozilla Firefox-4.png
>
>
> 1. create network offering 'egallowrvrnw1' with egress firewall policy :
> allow ,redundant router
>advance zone. create network of this offering.create guest VMs
>Verify ssh to VMs. VMs can ping other VMs in this network & reach
> internet
> 2. RVR MASTER r-37-VM
>RVR BACKUP r-38-VM
>stop r-37-VM
> Result:r-37-VMstate becomes UNKNOWN
> r-38-VMstate becomes FAULT
> no failover occur
> Cannot ssh to existing VMs
> 3. start r-37-VM.
> Result:r-37-VMstate becomes MASTER
> r-38-VMstate remains FAULT
> VMs can reach other VMs in same network.
> VMs cannot reach internet
> 4. stop r-37-VM
> r-37-VMstate becomes UNKNOWN
> r-38-VMstate becomes FAULT
> no failover occur
> Cannot ssh to existing VMs
> r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 1
> networks to update RvR status.
> 2013-08-08 19:22:44,763 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-37-VM, id: 37) just switch from MASTER to UNKNOWN
> 2013-08-08 19:22:44,768 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206273: Sending { Cmd ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckRouterCommand":{"a
> ccessDetails":{"router.ip":"169.254.3.245","router.name":"r-38-VM"},"wait":30}}]
> }
> 2013-08-08 19:22:44,769 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206273: Executing: { Cmd ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckRouterCommand":
> 2013-08-08 19:22:45,116 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-38-VM, id: 38) just switch from BACKUP to FAULT
> 2013-08-08 19:22:45,344 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-270:null) Seq 1-206274: Response Received:
> 2013-08-08 19:22:45,345 DEBUG [agent.transport.Request]
> (DirectAgent-270:null) Seq 1-206274: Processing: { Ans: , MgmtId:
> 7343890761426, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.CheckRouterAnswer":{"state":"FAULT","
> isBumped":false,"result":true,"details":"Status: FAULT (RTNETLINK answers: No
> such process)&Bumped: NO","wait":0}}] }
> 2013-08-08 19:22:45,345 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206274: Received: { Ans: ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 10, { CheckRouterAnswer } }
> 2013-08-08 19:22:45,345 DEBUG [agent.manager.AgentManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Details from executing class
> com.cloud.agent.api.CheckRouterCommand: Status: FAULT (RTNETLINK answers: No
> such process)&Bumped: N
> O
> 2013-08-08 19:22:45,349 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-38-VM, id: 38) just switch from BACKUP to FAULT
> 2013-08-08 19:22:46,781 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-13:null) Ping from 2
> 2013-08-08 19:22:47,125 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-12:null) Ping from 3
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-240) Create-Tag feature is not avialable for VPN Customer Gateway
[ https://issues.apache.org/jira/browse/CLOUDSTACK-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744682#comment-13744682 ] Sudha Ponnaganti commented on CLOUDSTACK-240: - proposing to move this to next releaes as this is too late to fix the UI part. Can you pl mark it for future after review with community > Create-Tag feature is not avialable for VPN Customer Gateway > - > > Key: CLOUDSTACK-240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: pre-4.0.0 >Reporter: prashant kumar mishra >Priority: Minor > Fix For: 4.2.0 > > > There is no option to tag VPN Customer Gateway. > Steps to check > -- > -- > 1-Go to network tab > 2-From select view select VPN Customer Gateway > 3- Click on add VPN Customer Gateway > 5-Select the VPN Customer Gateway > 6-there is no option to create/add Tag for VPN Customer Gateway > Release Planning: > Dev List Discussion: Unknown > Functional Spec: N/A > Feature Branch: Unknown > Documentation: Not needed > QA: Needs to be tested -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4199) Redundant Virtual Router - no failover occur
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744681#comment-13744681 ] angeline shen commented on CLOUDSTACK-4199: --- Testing RVR using 8/19/13 latest build #465 MS10.223.195.52 host 10.223.50.3 XS 6.2 1. advance zone with XEN 6.2 cluster 2. create network offering with RVR enabled id: 17 name: rvrallow uuid: bc34384a-7704-4786-87cc-e5cc24f32dcf unique_name: rvrallow display_text: rvrallow nw_rate: NULL mc_rate: 10 traffic_type: Guest tags: NULL system_only: 0 specify_vlan: 0 service_offering_id: NULL conserve_mode: 0 created: 2013-08-19 22:34:41 removed: NULL default: 0 availability: Optional dedicated_lb_service: 1 shared_source_nat_service: 0 sort_key: 0 redundant_router_service: 1 state: Enabled guest_type: Isolated elastic_ip_service: 0 eip_associate_public_ip: 0 elastic_lb_service: 0 specify_ip_ranges: 0 inline: 0 is_persistent: 0 internal_lb: 0 public_lb: 1 egress_default_policy: 1 concurrent_connections: NULL 17 rows in set (0.00 sec) 3. As admin deploy VM using above nw offering rvrallow: id: 10 name: z1rvrallowadminV40 uuid: 16eb63bd-53fc-45a9-8d28-c77c82f86dc0 instance_name: i-2-10-VM state: Running vm_template_id: 5 guest_os_id: 12 private_mac_address: 02:00:63:30:00:06 private_ip_address: 10.1.1.23 pod_id: 1 data_center_id: 1 host_id: 1 last_host_id: 1 proxy_id: 2 proxy_assign_time: 2013-08-20 00:45:33 vnc_password: YGzUsIS8Z+37W9Udm2+S4zvsV07NT9bP ha_enabled: 1 limit_cpu_use: 0 update_count: 3 update_time: 2013-08-19 22:46:09 created: 2013-08-19 22:42:40 removed: NULL type: User vm_type: User account_id: 2 domain_id: 1 service_offering_id: 12 reservation_id: 3af80789-c7ea-47e8-a79b-8c1cc6b284de hypervisor_type: XenServer disk_offering_id: NULL cpu: NULL ram: NULL owner: 2 speed: 100 host_name: z1rvrallowadminV40 display_name: z1rvrallowadminV40 desired_state: NULL dynamically_scalable: 1 display_vm: 1 4. The above steps deployed RVR routers without any issues: id: 11 <=== MASTER name: r-11-VM uuid: 67bd2d37-cc5a-45ce-8cf7-74b06e1d9c8f instance_name: r-11-VM state: Running vm_template_id: 1 guest_os_id: 183 private_mac_address: 0e:00:a9:fe:02:c4 private_ip_address: 169.254.2.196 pod_id: 1 data_center_id: 1 host_id: 1 last_host_id: 1 proxy_id: NULL proxy_assign_time: NULL vnc_password: trOmaP4q+opdndMZM6Wayg4svTXwTje2WCbEWXYp8Ic= ha_enabled: 0 limit_cpu_use: 0 update_count: 29 update_time: 2013-08-20 02:25:07 created: 2013-08-19 22:42:41 removed: NULL type: DomainRouter vm_type: DomainRouter account_id: 2 domain_id: 1 service_offering_id: 7 reservation_id: c881947a-1737-410e-9d92-3b63268e6c53 hypervisor_type: XenServer disk_offering_id: NULL cpu: NULL ram: NULL owner: NULL speed: NULL host_name: NULL display_name: NULL desired_state: NULL dynamically_scalable: 0 display_vm: 1 *** 12. row *** id: 12 <=== BACKUP name: r-12-VM uuid: be11be35-d844-44fd-ae54-4656d9433855 instance_name: r-12-VM state: Running vm_template_id: 1 guest_os_id: 183 private_mac_address: 0e:00:a9:fe:02:12 private_ip_address: 169.254.2.18 pod_id: 1 data_center_id: 1 host_id: 1 last_host_id: 1 proxy_id: NULL proxy_assign_time: NULL vnc_password: DRNlYWFm2jI1JxaQSm6r2EHvPxT+JMCu5FDxW9QwUhQ= ha_enabled: 0 limit_cpu_use: 0 update_count: 11 update_time: 2013-08-19 22:45:57 created: 2013-08-19 22:42:41 removed: NULL type: DomainRouter
[jira] [Commented] (CLOUDSTACK-3765) [packaging][document] unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744663#comment-13744663 ] Animesh Chaturvedi commented on CLOUDSTACK-3765: This needs to be documented so bumping down severity > [packaging][document] unable to upgrade cp 4.2 build on centos5.5 > - > > Key: CLOUDSTACK-3765 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3765 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, Packaging >Affects Versions: 4.2.0 > Environment: Centos5.5 >Reporter: shweta agarwal >Assignee: Sudha Ponnaganti >Priority: Critical > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Release_Notes-en-US.pdf > > > When I am trying to install > http://repo-ccp.citrix.com/releases/ASF/rhel/5/4.2/CP4.2-dbupgrade-44-rhel5.tar.gz > > I am hitting JSVC dependency error > When I tried to install jsvc via rpm its also failing giving error > rpm -Uvh > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > Retrieving > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > warning: /var/tmp/rpm-xfer.qxSLPS: Header V3 RSA/SHA256 signature: NOKEY, key > ID c105b9de > error: Failed dependencies: > rpmlib(FileDigests) <= 4.6.0-1 is needed by > jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64 > rpmlib(PayloadIsXz) <= 5.2-1 is needed by > jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64 > Centos 5.5 repo does not contain any jsvc package > Infact at rpmfind location also JSVC package only exists for centos6.4 > http://rpmfind.net/linux/rpm2html/search.php?query=jsvc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-3765) [packaging][document] unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-3765: --- Priority: Critical (was: Blocker) > [packaging][document] unable to upgrade cp 4.2 build on centos5.5 > - > > Key: CLOUDSTACK-3765 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3765 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, Packaging >Affects Versions: 4.2.0 > Environment: Centos5.5 >Reporter: shweta agarwal >Assignee: Sudha Ponnaganti >Priority: Critical > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Release_Notes-en-US.pdf > > > When I am trying to install > http://repo-ccp.citrix.com/releases/ASF/rhel/5/4.2/CP4.2-dbupgrade-44-rhel5.tar.gz > > I am hitting JSVC dependency error > When I tried to install jsvc via rpm its also failing giving error > rpm -Uvh > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > Retrieving > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > warning: /var/tmp/rpm-xfer.qxSLPS: Header V3 RSA/SHA256 signature: NOKEY, key > ID c105b9de > error: Failed dependencies: > rpmlib(FileDigests) <= 4.6.0-1 is needed by > jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64 > rpmlib(PayloadIsXz) <= 5.2-1 is needed by > jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64 > Centos 5.5 repo does not contain any jsvc package > Infact at rpmfind location also JSVC package only exists for centos6.4 > http://rpmfind.net/linux/rpm2html/search.php?query=jsvc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2829) QA Allow specification of different VIF drivers per traffic type in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744661#comment-13744661 ] Dave Cahill commented on CLOUDSTACK-2829: - Hi Sudha, I tested the feature when it was initially created. I've been rebuilding my 4.2 environment over the past ~2 weeks to test again, but it's taking a long time (setup issues, build issues etc) - hopefully the env will be complete in next few days and I can update this ticket to confirm tested. My env is only partially complete so far, but it appears to be working. Thanks, Dave. > QA Allow specification of different VIF drivers per traffic type in KVM > --- > > Key: CLOUDSTACK-2829 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2829 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Dave Cahill > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2829) QA Allow specification of different VIF drivers per traffic type in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744655#comment-13744655 ] Sudha Ponnaganti commented on CLOUDSTACK-2829: -- David, Want to check if any testing has been done for this feature. Would like to close the task for 4.2 so checking thanks /sudha > QA Allow specification of different VIF drivers per traffic type in KVM > --- > > Key: CLOUDSTACK-2829 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2829 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Dave Cahill > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-950) QA - Ntier Apps 2.0 use same public IP for static NAT, PF and LB in VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti resolved CLOUDSTACK-950. - Resolution: Fixed > QA - Ntier Apps 2.0 use same public IP for static NAT, PF and LB in VPC > > > Key: CLOUDSTACK-950 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-950 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Sudha Ponnaganti > Fix For: 4.2.0 > > > core tasks that need to be done: > - review requirements/FS > - upload test plan/test cases > - get test cases reviewed > - add automation > - upload test results > - review documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-908) [QA] Test VPC new 8-tunnel VPN capability
[ https://issues.apache.org/jira/browse/CLOUDSTACK-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-908. --- Resolution: Fixed > [QA] Test VPC new 8-tunnel VPN capability > - > > Key: CLOUDSTACK-908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-908 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Reporter: David Nalley > Fix For: 4.2.0 > > > Test VPC new 8-tunnel VPN capability -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-950) QA - Ntier Apps 2.0 use same public IP for static NAT, PF and LB in VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-950. --- > QA - Ntier Apps 2.0 use same public IP for static NAT, PF and LB in VPC > > > Key: CLOUDSTACK-950 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-950 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Sudha Ponnaganti > Fix For: 4.2.0 > > > core tasks that need to be done: > - review requirements/FS > - upload test plan/test cases > - get test cases reviewed > - add automation > - upload test results > - review documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-921) QA - nTier Apps 2.0 Support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-921. --- > QA - nTier Apps 2.0 Support > --- > > Key: CLOUDSTACK-921 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-921 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Sudha Ponnaganti > Fix For: 4.2.0 > > > Master Task for all nTier App support -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-921) QA - nTier Apps 2.0 Support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti resolved CLOUDSTACK-921. - Resolution: Fixed > QA - nTier Apps 2.0 Support > --- > > Key: CLOUDSTACK-921 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-921 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Sudha Ponnaganti > Fix For: 4.2.0 > > > Master Task for all nTier App support -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-240) Create-Tag feature is not avialable for VPN Customer Gateway
[ https://issues.apache.org/jira/browse/CLOUDSTACK-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744651#comment-13744651 ] Sudha Ponnaganti commented on CLOUDSTACK-240: - Can this be pushed to next release?? We are almost at RC and not sure if this change should go in now. > Create-Tag feature is not avialable for VPN Customer Gateway > - > > Key: CLOUDSTACK-240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: pre-4.0.0 >Reporter: prashant kumar mishra >Priority: Minor > Fix For: 4.2.0 > > > There is no option to tag VPN Customer Gateway. > Steps to check > -- > -- > 1-Go to network tab > 2-From select view select VPN Customer Gateway > 3- Click on add VPN Customer Gateway > 5-Select the VPN Customer Gateway > 6-there is no option to create/add Tag for VPN Customer Gateway > Release Planning: > Dev List Discussion: Unknown > Functional Spec: N/A > Feature Branch: Unknown > Documentation: Not needed > QA: Needs to be tested -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-337) Create SELinux policy for KVM agent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744647#comment-13744647 ] Sudha Ponnaganti commented on CLOUDSTACK-337: - Is this planned for 4.2?? Need to address QA Task for it > Create SELinux policy for KVM agent > --- > > Key: CLOUDSTACK-337 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-337 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: David Nalley >Assignee: David Nalley > Fix For: 4.2.0 > > > We currently advise folks to disable SELinux, which is BAD. My plan is to > create a policy that we install at runtime. > I'll be using this ticket as a collection point for logs. > Release Planning: > Dev List Discussion: unknown > Functional Spec: N/A > Feature branch: unknown -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1000) QA - Plugin to provide Hyper V support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-1000: - Fix Version/s: (was: 4.2.0) Future > QA - Plugin to provide Hyper V support > -- > > Key: CLOUDSTACK-1000 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1000 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti > Fix For: Future > > > Need to post the following to ACS Wiki > - Unit Test Cases > - Functional test cases > - Test results -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2797) QA: Test Consistent use of refresh Button
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-2797: - Assignee: Parth Jagirdar > QA: Test Consistent use of refresh Button > - > > Key: CLOUDSTACK-2797 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2797 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Parth Jagirdar > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3010) [VMWare] [SharedNetworkWithServices] router VM deployment fails with error "Message: Invalid configuration for device '2'."
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744635#comment-13744635 ] Venkata Siva Vijayendra Bhamidipati commented on CLOUDSTACK-3010: - This happens only on shared networks, when the firewall and source NAT options are enabled using Virtual Router in the custom network offering. The mgmt layer isn't supplying a mac address to the guest network's NicVO. The db entry shows up like this: mysql> select * from nics where id=37\G; *** 1. row *** id: 37 uuid: 095616df-e95b-479b-a9f9-591a5db72b12 instance_id: 16 mac_address: NULL ip4_address: 10.8.1.1 netmask: 255.255.255.128 gateway: NULL ip_type: NULL broadcast_uri: vlan://2418 network_id: 209 mode: Dhcp state: Allocated strategy: Create reserver_name: DirectNetworkGuru reservation_id: NULL device_id: 0 update_time: 2013-08-19 12:54:37 isolation_uri: vlan://2418 ip6_address: NULL default_nic: 0 vm_type: DomainRouter created: 2013-08-19 16:06:10 removed: NULL ip6_gateway: NULL ip6_cidr: NULL secondary_ip: 0 display_nic: 1 1 row in set (0.00 sec) ERROR: No query specified mysql> The above NIC entries are made in allocateNic() in NetworkManagerImpl.java. This seems to be called when the guest VM is being setup/created, but not when the router VM is being created. Not clear where or why the guest mac address isn't being allocated for the router VM. This doesn't seem to be a vmware specific issue because it's all happening in the mgmt layers and afai can see, outside the vmware guru. > [VMWare] [SharedNetworkWithServices] router VM deployment fails with error > "Message: Invalid configuration for device '2'." > --- > > Key: CLOUDSTACK-3010 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3010 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: commit # 971c40d98e07ab6cddb8e6db5095c1acea935815 >Reporter: venkata swamybabu budumuru >Assignee: Venkata Siva Vijayendra Bhamidipati >Priority: Critical > Fix For: 4.2.0 > > Attachments: logs.setup1.tgz, logs.setup2.tgz, logs.tgz > > > Steps to reproduce : > 1. Have latest CloudStack setup with advanced zone using VMware cluster (1 > host added to the cluster) > 2. create a shared network with all services enabled > mysql> select * from network_offerings where id=14\G > *** 1. row *** >id: 14 > name: CustomSharedOffering > uuid: dbee9234-e443-4f00-827e-e9258bb0c209 > unique_name: CustomSharedOffering > display_text: CustomSharedOffering > nw_rate: NULL > mc_rate: 10 > traffic_type: Guest > tags: NULL > system_only: 0 > specify_vlan: 1 > service_offering_id: NULL > conserve_mode: 0 > created: 2013-06-14 14:34:10 > removed: NULL > default: 0 > availability: Optional > dedicated_lb_service: 1 > shared_source_nat_service: 0 > sort_key: 0 > redundant_router_service: 0 > state: Enabled >guest_type: Shared >elastic_ip_service: 0 > eip_associate_public_ip: 0 >elastic_lb_service: 0 > specify_ip_ranges: 1 >inline: 0 > is_persistent: 0 > internal_lb: 0 > public_lb: 1 > mysql> select * from ntwk_offering_service_map where network_offering_id=14; > ++-++---+-+ > | id | network_offering_id | service| provider | created > | > ++-++---+-+ > | 48 | 14 | Dhcp | VirtualRouter | 2013-06-14 > 14:34:10 | > | 52 | 14 | Dns| VirtualRouter | 2013-06-14 > 14:34:10 | > | 51 | 14 | Firewall | VirtualRouter | 2013-06-14 > 14:34:10 | > | 49 | 14 | Lb | VirtualRouter | 2013-06-14 > 14:34:10 | > | 53 | 14 | PortForwarding | VirtualRouter | 2013-06-14 > 14:34:10 | > | 46 | 14 | SourceNat | VirtualRouter | 2013-06
[jira] [Closed] (CLOUDSTACK-2998) UK: Exploring Testing - unexpected output occurred on Ctrl+Keypad, AltGR+Keypad and AltGR+ Numerics
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Minying Bao closed CLOUDSTACK-2998. --- Resolution: Unresolved Close “CLOUDSTACK-2998” as those keys are generally not used by end users. > UK: Exploring Testing - unexpected output occurred on Ctrl+Keypad, > AltGR+Keypad and AltGR+ Numerics > > > Key: CLOUDSTACK-2998 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2998 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VNC Proxy >Affects Versions: 4.2.0 > Environment: Build No.#396 > (CloudStack-non-OSS-MASTER-396-rhel6.3.tar.gz) > XenServer6.1 for Host Server, CentOS6.3 for NFS server and CloudStack-Mgr > Server, Win7-x86 for Client machine. >Reporter: Minying Bao > Fix For: 4.2.0 > > Attachments: Build#4.2-241-Exploring Testing_UK Keyboard_issues.xlsx, > Exploring Testing_UK Keyboard_issues.xlsx > > > Steps > 1. Setup the CloudStack environments with build 4.2#396. > 2. Bring UK Win-7 x86 VMs. > 3. Access the VM via Console Proxy from the UK client machines, choose the > "UK Keyboard" for Keyboard Option. > 4. Make a exploring testing of all the keys with UK keyboard. Just like > Ctrl+Keypad keys, AltGR+Keypad keys or AltGR+ Numeric keys like 1,2,3... > Expected Result > All the combination should not return any values. > Actual Result > Unexpected output or unexpected operation occurred on some Ctrl+Keypad keys, > AltGR+Keypad keys and AltGR+ Numerics. > Please refer to the details as attached Excel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4199) Redundant Virtual Router - no failover occur
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang reassigned CLOUDSTACK-4199:
--
Assignee: Sheng Yang
> Redundant Virtual Router - no failover occur
>
>
> Key: CLOUDSTACK-4199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4199
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MSACS 4.2 campointernal build 341
> host XS 6.2
>Reporter: angeline shen
>Assignee: Sheng Yang
> Fix For: 4.2.0
>
> Attachments: FAULT_logs.tgz, logs.tgz, management-server.log.gz,
> MASTER_logs.tgz, Screenshot-CloudPlatform™ - Mozilla Firefox-3.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox-4.png
>
>
> 1. create network offering 'egallowrvrnw1' with egress firewall policy :
> allow ,redundant router
>advance zone. create network of this offering.create guest VMs
>Verify ssh to VMs. VMs can ping other VMs in this network & reach
> internet
> 2. RVR MASTER r-37-VM
>RVR BACKUP r-38-VM
>stop r-37-VM
> Result:r-37-VMstate becomes UNKNOWN
> r-38-VMstate becomes FAULT
> no failover occur
> Cannot ssh to existing VMs
> 3. start r-37-VM.
> Result:r-37-VMstate becomes MASTER
> r-38-VMstate remains FAULT
> VMs can reach other VMs in same network.
> VMs cannot reach internet
> 4. stop r-37-VM
> r-37-VMstate becomes UNKNOWN
> r-38-VMstate becomes FAULT
> no failover occur
> Cannot ssh to existing VMs
> r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 1
> networks to update RvR status.
> 2013-08-08 19:22:44,763 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-37-VM, id: 37) just switch from MASTER to UNKNOWN
> 2013-08-08 19:22:44,768 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206273: Sending { Cmd ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckRouterCommand":{"a
> ccessDetails":{"router.ip":"169.254.3.245","router.name":"r-38-VM"},"wait":30}}]
> }
> 2013-08-08 19:22:44,769 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206273: Executing: { Cmd ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckRouterCommand":
> 2013-08-08 19:22:45,116 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-38-VM, id: 38) just switch from BACKUP to FAULT
> 2013-08-08 19:22:45,344 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-270:null) Seq 1-206274: Response Received:
> 2013-08-08 19:22:45,345 DEBUG [agent.transport.Request]
> (DirectAgent-270:null) Seq 1-206274: Processing: { Ans: , MgmtId:
> 7343890761426, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.CheckRouterAnswer":{"state":"FAULT","
> isBumped":false,"result":true,"details":"Status: FAULT (RTNETLINK answers: No
> such process)&Bumped: NO","wait":0}}] }
> 2013-08-08 19:22:45,345 DEBUG [agent.transport.Request]
> (RedundantRouterStatusMonitor-6:null) Seq 1-206274: Received: { Ans: ,
> MgmtId: 7343890761426, via: 1, Ver: v1, Flags: 10, { CheckRouterAnswer } }
> 2013-08-08 19:22:45,345 DEBUG [agent.manager.AgentManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Details from executing class
> com.cloud.agent.api.CheckRouterCommand: Status: FAULT (RTNETLINK answers: No
> such process)&Bumped: N
> O
> 2013-08-08 19:22:45,349 INFO
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RedundantRouterStatusMonitor-6:null) Redundant virtual router (name:
> r-38-VM, id: 38) just switch from BACKUP to FAULT
> 2013-08-08 19:22:46,781 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-13:null) Ping from 2
> 2013-08-08 19:22:47,125 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-12:null) Ping from 3
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (CLOUDSTACK-2824) API:MS:Ability to delete events and alerts-Auto Purge for Alerts doesn't work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar updated CLOUDSTACK-2824: --- Comment: was deleted (was: Sanjay, I observed that Auto Purge now works fine, however it applies only to new events and alerts after its set. For example we have events and alerts for 10th and 11th. And then we set the purge interval on 12th. now new purge will be applicable to only the events and alerts after 12th and not to previous entries in DB. Which I assume is an expected behavior. Pleas provide comments and re-open the bug if this is not the case. Closing for now. ) > API:MS:Ability to delete events and alerts-Auto Purge for Alerts doesn't work > - > > Key: CLOUDSTACK-2824 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2824 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.2.0 > Environment: Master >Reporter: Parth Jagirdar > Fix For: 4.2.0 > > > Auto Purge for Alerts doesn't work. However it works fine for Events. > Change the global setting for desired number of days and restart MS. > Observe that after set number of days elapsed, Alerts are still present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-2824) API:MS:Ability to delete events and alerts-Auto Purge for Alerts doesn't work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar reopened CLOUDSTACK-2824: Assignee: (was: Sanjay Tripathi) Sanjay, I observed that Auto Purge now works fine, however it applies only to new events and alerts after its set. For example we have events and alerts for 10th and 11th. And then we set the purge interval on 12th. now new purge will be applicable to only the events and alerts after 12th and not to previous entries in DB. Which I assume is an expected behavior. Pleas provide comments and re-open the bug if this is not the case. Closing for now. > API:MS:Ability to delete events and alerts-Auto Purge for Alerts doesn't work > - > > Key: CLOUDSTACK-2824 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2824 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.2.0 > Environment: Master >Reporter: Parth Jagirdar > > Auto Purge for Alerts doesn't work. However it works fine for Events. > Change the global setting for desired number of days and restart MS. > Observe that after set number of days elapsed, Alerts are still present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2824) API:MS:Ability to delete events and alerts-Auto Purge for Alerts doesn't work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar resolved CLOUDSTACK-2824. Resolution: Fixed Fix Version/s: 4.2.0 > API:MS:Ability to delete events and alerts-Auto Purge for Alerts doesn't work > - > > Key: CLOUDSTACK-2824 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2824 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.2.0 > Environment: Master >Reporter: Parth Jagirdar > Fix For: 4.2.0 > > > Auto Purge for Alerts doesn't work. However it works fine for Events. > Change the global setting for desired number of days and restart MS. > Observe that after set number of days elapsed, Alerts are still present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2824) API:MS:Ability to delete events and alerts-Auto Purge for Alerts doesn't work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-2824. -- Sanjay, I observed that Auto Purge now works fine, however it applies only to new events and alerts after its set. For example we have events and alerts for 10th and 11th. And then we set the purge interval on 12th. now new purge will be applicable to only the events and alerts after 12th and not to previous entries in DB. Which I assume is an expected behavior. Pleas provide comments and re-open the bug if this is not the case. Closing for now. > API:MS:Ability to delete events and alerts-Auto Purge for Alerts doesn't work > - > > Key: CLOUDSTACK-2824 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2824 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.2.0 > Environment: Master >Reporter: Parth Jagirdar > Fix For: 4.2.0 > > > Auto Purge for Alerts doesn't work. However it works fine for Events. > Change the global setting for desired number of days and restart MS. > Observe that after set number of days elapsed, Alerts are still present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4398) Physical size not being set in CopyCmdAnswer for TemplateTO in some of the cases breaking Template Usage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744573#comment-13744573 ] ASF subversion and git services commented on CLOUDSTACK-4398: - Commit 45b35aaeef9c9f938f57c9d0dbd65c67c4c3e406 in branch refs/heads/master from [~edison] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=45b35aa ] CLOUDSTACK-4398: get physical size of template if the template is stored in S3 > Physical size not being set in CopyCmdAnswer for TemplateTO in some of the > cases breaking Template Usage > - > > Key: CLOUDSTACK-4398 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4398 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: edison su >Priority: Critical > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4398) Physical size not being set in CopyCmdAnswer for TemplateTO in some of the cases breaking Template Usage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-4398. --- Resolution: Fixed > Physical size not being set in CopyCmdAnswer for TemplateTO in some of the > cases breaking Template Usage > - > > Key: CLOUDSTACK-4398 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4398 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: edison su >Priority: Critical > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4398) Physical size not being set in CopyCmdAnswer for TemplateTO in some of the cases breaking Template Usage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744572#comment-13744572 ] ASF subversion and git services commented on CLOUDSTACK-4398: - Commit bdfddc3e3d24279546f4a9d1b45822896c395c59 in branch refs/heads/4.2 from [~edison] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bdfddc3 ] CLOUDSTACK-4398: get physical size of template if the template is stored in S3 > Physical size not being set in CopyCmdAnswer for TemplateTO in some of the > cases breaking Template Usage > - > > Key: CLOUDSTACK-4398 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4398 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: edison su >Priority: Critical > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4395) [Object_store_refactor] Default template is not available for use to deploy vm in case of multi zone environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-4395. -- Resolution: Fixed > [Object_store_refactor] Default template is not available for use to deploy > vm in case of multi zone environment > > > Key: CLOUDSTACK-4395 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4395 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller, Template >Affects Versions: 4.2.0 > Environment: Latest build from ACS 4.2 > Multi-zone environment >Reporter: Sanjeev N >Assignee: Min Chen >Priority: Critical > Fix For: 4.2.0 > > Attachments: cloud.dmp, management-server.rar > > > Default template is not available for use to deploy vm in case of multi zone > environment > Steps to Reproduce: > > 1.Bring up CS initially with one zone say zone1 using xen cluster > 2.Wait for the system vms to come up and let the default xen cent os template > to download > 3.Add second zone say zone2 using vmware cluster > At this state SSVM in zone1 will initiate the centos system template and > default template download process. > 4.After SSVM is up in zone2 try to deploy guest vm in zone2 using default > centos template > Result: > === > VM deployment failed with error "The template 7 is not available for use" > Observations: > === > Entries in template_zone_ref table are as follows: > mysql> select * from template_zone_ref where template_id<9; > ++-+-+-+-+-+ > | id | zone_id | template_id | created | last_updated| > removed | > ++-+-+-+-+-+ > | 1 | 1 | 1 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 2 | 1 | 2 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 3 | 1 | 3 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 4 | 1 | 4 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 5 | 1 | 5 | 2013-08-16 11:31:50 | 2013-08-16 12:00:18 | > NULL| > | 6 | 1 | 7 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 7 | 1 | 8 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > ++-+-+-+-+-+ > All the templates have zone_id set to 1 even though cross-zones is set to > 1for all of these templates. > Attaching management server log file and cloud DB. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4395) [Object_store_refactor] Default template is not available for use to deploy vm in case of multi zone environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744564#comment-13744564 ] ASF subversion and git services commented on CLOUDSTACK-4395: - Commit c4f41f4a53d49e9b4ff2053f22dfa263be2d318c in branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c4f41f4 ] CLOUDSTACK-4395:[Object_store_refactor] Default template is not available for use to deploy vm in case of multi zone environment. > [Object_store_refactor] Default template is not available for use to deploy > vm in case of multi zone environment > > > Key: CLOUDSTACK-4395 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4395 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller, Template >Affects Versions: 4.2.0 > Environment: Latest build from ACS 4.2 > Multi-zone environment >Reporter: Sanjeev N >Assignee: Min Chen >Priority: Critical > Fix For: 4.2.0 > > Attachments: cloud.dmp, management-server.rar > > > Default template is not available for use to deploy vm in case of multi zone > environment > Steps to Reproduce: > > 1.Bring up CS initially with one zone say zone1 using xen cluster > 2.Wait for the system vms to come up and let the default xen cent os template > to download > 3.Add second zone say zone2 using vmware cluster > At this state SSVM in zone1 will initiate the centos system template and > default template download process. > 4.After SSVM is up in zone2 try to deploy guest vm in zone2 using default > centos template > Result: > === > VM deployment failed with error "The template 7 is not available for use" > Observations: > === > Entries in template_zone_ref table are as follows: > mysql> select * from template_zone_ref where template_id<9; > ++-+-+-+-+-+ > | id | zone_id | template_id | created | last_updated| > removed | > ++-+-+-+-+-+ > | 1 | 1 | 1 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 2 | 1 | 2 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 3 | 1 | 3 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 4 | 1 | 4 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 5 | 1 | 5 | 2013-08-16 11:31:50 | 2013-08-16 12:00:18 | > NULL| > | 6 | 1 | 7 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 7 | 1 | 8 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > ++-+-+-+-+-+ > All the templates have zone_id set to 1 even though cross-zones is set to > 1for all of these templates. > Attaching management server log file and cloud DB. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4395) [Object_store_refactor] Default template is not available for use to deploy vm in case of multi zone environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744562#comment-13744562 ] ASF subversion and git services commented on CLOUDSTACK-4395: - Commit ae7ec647d5fd26d055d42681769781b416cc7129 in branch refs/heads/4.2 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ae7ec64 ] CLOUDSTACK-4395:[Object_store_refactor] Default template is not available for use to deploy vm in case of multi zone environment. > [Object_store_refactor] Default template is not available for use to deploy > vm in case of multi zone environment > > > Key: CLOUDSTACK-4395 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4395 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller, Template >Affects Versions: 4.2.0 > Environment: Latest build from ACS 4.2 > Multi-zone environment >Reporter: Sanjeev N >Assignee: Min Chen >Priority: Critical > Fix For: 4.2.0 > > Attachments: cloud.dmp, management-server.rar > > > Default template is not available for use to deploy vm in case of multi zone > environment > Steps to Reproduce: > > 1.Bring up CS initially with one zone say zone1 using xen cluster > 2.Wait for the system vms to come up and let the default xen cent os template > to download > 3.Add second zone say zone2 using vmware cluster > At this state SSVM in zone1 will initiate the centos system template and > default template download process. > 4.After SSVM is up in zone2 try to deploy guest vm in zone2 using default > centos template > Result: > === > VM deployment failed with error "The template 7 is not available for use" > Observations: > === > Entries in template_zone_ref table are as follows: > mysql> select * from template_zone_ref where template_id<9; > ++-+-+-+-+-+ > | id | zone_id | template_id | created | last_updated| > removed | > ++-+-+-+-+-+ > | 1 | 1 | 1 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 2 | 1 | 2 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 3 | 1 | 3 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 4 | 1 | 4 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 5 | 1 | 5 | 2013-08-16 11:31:50 | 2013-08-16 12:00:18 | > NULL| > | 6 | 1 | 7 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > | 7 | 1 | 8 | 2013-08-16 11:31:50 | 2013-08-16 11:31:50 | > NULL| > ++-+-+-+-+-+ > All the templates have zone_id set to 1 even though cross-zones is set to > 1for all of these templates. > Attaching management server log file and cloud DB. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4405) (Upgrade) Migrate failed between existing hosts and new hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744555#comment-13744555 ] Sheng Yang commented on CLOUDSTACK-4405: Add Marcus to the issue since he is the original author. I think the better way is update the tags in the old host, but I am not sure if it's doable or not in KVM. > (Upgrade) Migrate failed between existing hosts and new hosts > - > > Key: CLOUDSTACK-4405 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4405 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0, 4.2.0 > Environment: CS 4.1 >Reporter: Wei Zhou >Assignee: Wei Zhou >Priority: Blocker > Fix For: 4.1.1, 4.2.0 > > > There are two hosts (cs-kvm001, cs-kvm002) in old 2.2.14 environment . > After upgrade from 2.2.14 to 4.1, I added two new hosts (cs-kvm003, > cs-kvm004). > The migration between cs-kvm001 and cs-kvm002, or cs-kvm003 and cs-kvm004 > succeed. > However, the migration from cs-kvm001/002 to the new hosts (cs-kvm003, > cs-kvm004) failed. > 2013-08-19 16:57:31,051 DEBUG [kvm.resource.BridgeVifDriver] > (agentRequest-Handler-1:null) nic=[Nic:Guest-10.11.110.231-vlan://110] > 2013-08-19 16:57:31,051 DEBUG [kvm.resource.BridgeVifDriver] > (agentRequest-Handler-1:null) creating a vlan dev and bridge for guest > traffic per traffic label cloudbr0 > 2013-08-19 16:57:31,051 DEBUG [utils.script.Script] > (agentRequest-Handler-1:null) Executing: /bin/bash -c brctl show | grep > cloudVirBr110 > 2013-08-19 16:57:31,063 DEBUG [utils.script.Script] > (agentRequest-Handler-1:null) Exit value is 1 > 2013-08-19 16:57:31,063 DEBUG [utils.script.Script] > (agentRequest-Handler-1:null) > 2013-08-19 16:57:31,063 DEBUG [kvm.resource.BridgeVifDriver] > (agentRequest-Handler-1:null) Executing: > /usr/share/cloudstack-common/scripts/vm/network/vnet/modifyvlan.sh -v 110 -p > em1 -b brem1-110 -o add > 2013-08-19 16:57:31,121 DEBUG [kvm.resource.BridgeVifDriver] > (agentRequest-Handler-1:null) Execution is successful. > 2013-08-19 16:57:31,122 DEBUG [kvm.resource.BridgeVifDriver] > (agentRequest-Handler-1:null) Set name-type for VLAN subsystem. Should be > visible in /proc/net/vlan/config > This is because the bridge name on old hosts are cloudVirBr110, and brem1-110 > on new hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2883) Add default network offering with Internal LB support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-2883. -- Verified. DefaultIsolatedNetworkOfferingForVpcNetworksWithInternalLB Gets Created. > Add default network offering with Internal LB support > - > > Key: CLOUDSTACK-2883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: 4.2.0 > > > Would make sense to have a default network offering with the Internal LB > support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2844) [VPC] [UI] - grey out "Internal LB" section on the tier where the feature is not enabled. The same for Public LB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-2844. -- Verified. > [VPC] [UI] - grey out "Internal LB" section on the tier where the feature is > not enabled. The same for Public LB > > > Key: CLOUDSTACK-2844 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2844 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Alena Prokharchyk >Assignee: Brian Federle > Fix For: 4.2.0 > > > When the Internal LB is not enabled on the tier, the tier view should have > "InternalLB" section greyed out and non-clickable. The same applies to Public > LB -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-240) Create-Tag feature is not avialable for VPN Customer Gateway
[ https://issues.apache.org/jira/browse/CLOUDSTACK-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744485#comment-13744485 ] Alena Prokharchyk commented on CLOUDSTACK-240: -- Java part is in; have to be implemented in the UI. > Create-Tag feature is not avialable for VPN Customer Gateway > - > > Key: CLOUDSTACK-240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: pre-4.0.0 >Reporter: prashant kumar mishra >Priority: Minor > Fix For: 4.2.0 > > > There is no option to tag VPN Customer Gateway. > Steps to check > -- > -- > 1-Go to network tab > 2-From select view select VPN Customer Gateway > 3- Click on add VPN Customer Gateway > 5-Select the VPN Customer Gateway > 6-there is no option to create/add Tag for VPN Customer Gateway > Release Planning: > Dev List Discussion: Unknown > Functional Spec: N/A > Feature Branch: Unknown > Documentation: Not needed > QA: Needs to be tested -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3295) [AWSAPI] User registration fails with http error code 500
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744412#comment-13744412 ] ASF subversion and git services commented on CLOUDSTACK-3295: - Commit 2ff8acd6d480b53f072fc1d7f7ba852d73c0b85c in branch refs/heads/4.1 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2ff8acd ] CLOUDSTACK-3295. Code should look for xes.keystore under cloud-awsapi-4.2.0-SNAPSHOT and not under generated-webapp. > [AWSAPI] User registration fails with http error code 500 > - > > Key: CLOUDSTACK-3295 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3295 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: AWSAPI >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.2.0 > > > Turn enable.ec2.api flag. > Register cloudstack user > --- > cloudstack-aws-api-register --apikey= --secretkey= > --cert= --url=http://:7080/awsapi > Output > > User registration failed with http error code: 500 > awsapi.log > --- > 2013-07-01 11:15:11,602 DEBUG [bridge.service.UserContext] > (catalina-exec-int-3:null) initializing a new [anonymous] UserContext! > 2013-07-01 11:15:11,603 ERROR [bridge.service.EC2RestServlet] > (catalina-exec-int-3:null) SetCertificate exception > /usr/share/cloudstack-management/webapps7080/awsapi/WEB-INF/classes/xes.keystore > (No such file or directory) > java.io.FileNotFoundException: > /usr/share/cloudstack-management/webapps7080/awsapi/WEB-INF/classes/xes.keystore > (No such file or directory) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:137) > at java.io.FileInputStream.(FileInputStream.java:96) > at > com.cloud.bridge.service.EC2RestServlet.setCertificate(EC2RestServlet.java:456) > at > com.cloud.bridge.service.EC2RestServlet.doGetOrPost(EC2RestServlet.java:297) > at > com.cloud.bridge.service.EC2RestServlet.doGet(EC2RestServlet.java:225) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) > at > org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) > at > org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) > at > org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) > at > com.cloud.bridge.service.EC2MainServlet.doGetOrPost(EC2MainServlet.java:105) > at > com.cloud.bridge.service.EC2MainServlet.doGet(EC2MainServlet.java:84) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) > at > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thre
[jira] [Commented] (CLOUDSTACK-2777) AWSAPI: build and packaging issue causing EC2 SOAP test failures
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744413#comment-13744413 ] ASF subversion and git services commented on CLOUDSTACK-2777: - Commit a71f41401ba5c04f213f170e76856723655a9204 in branch refs/heads/4.1 from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a71f414 ] Followup fix for CLOUDSTACK-2777, crypto.properties and xes.keystore moved to AWSAPI installation location and changed permission to 666 Conflicts: packaging/centos63/cloud.spec > AWSAPI: build and packaging issue causing EC2 SOAP test failures > > > Key: CLOUDSTACK-2777 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2777 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.2.0 >Reporter: Prachi Damle >Assignee: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > > awsapi webapp is not getting deployed on axis2 when management server is > started. > Following file is missing and causing this issue: > webapps7080/awsapi/WEB-INF/services/cloud-ec2.aar > I don’t see this file on a setup using rpm packages under: > /usr/share/cloudstack-bridge/webapps/awsapi/WEB-INF/services. So looks like > the .aar file is not being generated by the apache build. > Apache build should create this jar file [cloud-ec2.aar] too and package it > under webapps7080/awsapi/WEB-INF/services -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-946) QA - BigSwitch network plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744409#comment-13744409 ] Sudha Ponnaganti commented on CLOUDSTACK-946: - however has some testing been done. We need to resolve this ticket to get ready for RC for ACS 42 > QA - BigSwitch network plugin > - > > Key: CLOUDSTACK-946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-946 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.1.0 >Reporter: Sudha Ponnaganti >Assignee: Kanzhe Jiang > Fix For: 4.2.0 > > > core tasks that need to be done: > - review requirements/FS > - upload test plan/test cases > - get test cases reviewed > - add automation > - upload test results > - review documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3112) [AWSAPI] EC2 SOAP calls fail with an NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744411#comment-13744411 ] ASF subversion and git services commented on CLOUDSTACK-3112: - Commit 81d18dc081b9a322e06fe841cb110b19f07ae3fe in branch refs/heads/4.1 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=81d18dc ] CLOUDSTACK-3112. UserCredentials that is injected in AuthenticationHandler is not picked up > [AWSAPI] EC2 SOAP calls fail with an NPE > > > Key: CLOUDSTACK-3112 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3112 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: AWSAPI >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty > Fix For: 4.2.0 > > > Enable ec2 api flag. Use EC2 API Soap tool to run > ec2-describe-availability-zones. > Ouput - Server:unknown > 2013-06-21 14:51:59,200 DEBUG [auth.ec2.AuthenticationHandler] > (catalina-exec-int-1:null) X509 cert's uniqueId: > EMAILADDRESS=likithashe...@gmail.com, CN=localhost, OU=cpg, O=citrix, > L=bangalore, ST=karnataka, C=in, serial=18442984792527269479 > 2013-06-21 14:51:59,203 ERROR [auth.ec2.AuthenticationHandler] > (catalina-exec-int-1:null) EC2 Authentication Handler: > java.lang.NullPointerException > at > com.cloud.bridge.auth.ec2.AuthenticationHandler.invoke(AuthenticationHandler.java:125) > at org.apache.axis2.engine.Phase.invoke(Phase.java:318) > at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:254) > at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160) > at > org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173) > at > org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) > at > org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) > at > org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) > at > org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) > at > com.cloud.bridge.service.EC2MainServlet.doGetOrPost(EC2MainServlet.java:114) > at > com.cloud.bridge.service.EC2MainServlet.doPost(EC2MainServlet.java:89) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) > at > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2777) AWSAPI: build and packaging issue causing EC2 SOAP test failures
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744414#comment-13744414 ] ASF subversion and git services commented on CLOUDSTACK-2777: - Commit bc43784e013dd761f6b0ffad015584ac2f0bb750 in branch refs/heads/4.1 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bc43784 ] CLOUDSTACK-2777. Apache build should create jar file cloud-ec2.aar and package it under webapps7080/awsapi/WEB-INF/services > AWSAPI: build and packaging issue causing EC2 SOAP test failures > > > Key: CLOUDSTACK-2777 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2777 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.2.0 >Reporter: Prachi Damle >Assignee: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > > awsapi webapp is not getting deployed on axis2 when management server is > started. > Following file is missing and causing this issue: > webapps7080/awsapi/WEB-INF/services/cloud-ec2.aar > I don’t see this file on a setup using rpm packages under: > /usr/share/cloudstack-bridge/webapps/awsapi/WEB-INF/services. So looks like > the .aar file is not being generated by the apache build. > Apache build should create this jar file [cloud-ec2.aar] too and package it > under webapps7080/awsapi/WEB-INF/services -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-886) QA new storage subsystem
[ https://issues.apache.org/jira/browse/CLOUDSTACK-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti resolved CLOUDSTACK-886. - Resolution: Fixed > QA new storage subsystem > > > Key: CLOUDSTACK-886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-886 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Reporter: Chip Childers >Assignee: Sanjeev N > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-886) QA new storage subsystem
[ https://issues.apache.org/jira/browse/CLOUDSTACK-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-886. --- Test plan has been executed. Defects are being worked up on so closing task however will continue fixing defects > QA new storage subsystem > > > Key: CLOUDSTACK-886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-886 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Reporter: Chip Childers >Assignee: Sanjeev N > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-943) QA - S3 based secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744396#comment-13744396 ] Sudha Ponnaganti commented on CLOUDSTACK-943: - parent task is pushed to future so marking this also for future > QA - S3 based secondary storage > --- > > Key: CLOUDSTACK-943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-943 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Sanjeev N > Fix For: Future > > > - Review requirements/FS > - upload test plans/test cases to AFS > - get test plans reviewed > - Upload test results once testing commenses -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-943) QA - S3 based secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-943: Fix Version/s: (was: 4.2.0) Future > QA - S3 based secondary storage > --- > > Key: CLOUDSTACK-943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-943 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Sanjeev N > Fix For: Future > > > - Review requirements/FS > - upload test plans/test cases to AFS > - get test plans reviewed > - Upload test results once testing commenses -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2749) QA: Write test plan and execute Testplan for midonet network integration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-2749. > QA: Write test plan and execute Testplan for midonet network integration > > > Key: CLOUDSTACK-2749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2749 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Dave Cahill > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2749) QA: Write test plan and execute Testplan for midonet network integration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti resolved CLOUDSTACK-2749. -- Resolution: Fixed > QA: Write test plan and execute Testplan for midonet network integration > > > Key: CLOUDSTACK-2749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2749 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Dave Cahill > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2749) QA: Write test plan and execute Testplan for midonet network integration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744386#comment-13744386 ] Sudha Ponnaganti commented on CLOUDSTACK-2749: -- As test plan and testing is done by Dave and team, closing this task > QA: Write test plan and execute Testplan for midonet network integration > > > Key: CLOUDSTACK-2749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2749 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Dave Cahill > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2800) QA: New mapping model for CloudStack zone and Vmware datacenter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744381#comment-13744381 ] Sudha Ponnaganti commented on CLOUDSTACK-2800: -- Test plan is in progress - will post it today > QA: New mapping model for CloudStack zone and Vmware datacenter > > > Key: CLOUDSTACK-2800 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2800 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: angeline shen > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4338) [Automation] NullPointerException observed while deleting volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744366#comment-13744366
]
ASF subversion and git services commented on CLOUDSTACK-4338:
-
Commit 3c098c08763b3fc3bb4616d012f739079c438689 in branch refs/heads/master
from [~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3c098c0 ]
CLOUDSTACK-4338: fix NPE if create volume failed
> [Automation] NullPointerException observed while deleting volume
> -
>
> Key: CLOUDSTACK-4338
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4338
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, Automation, Volumes
>Affects Versions: 4.2.0
> Environment: Automation
> KVM
> 4.2
>Reporter: Rayees Namathponnan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2729_8_18_MS.rar, management-server.rar
>
>
> Below NullPointerException observed after complete regression automation
> 2013-08-14 02:13:57,007 DEBUG [agent.transport.Request]
> (AgentManager-Handler-6:null) Seq 2-1794246992: Processing: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result
> ":true,"wait":0}}] }
> 2013-08-14 02:13:57,007 DEBUG [agent.transport.Request]
> (Job-Executor-109:job-635 = [ dafa3d4b-a9f1-45e7-b13f-48cb1aace017 ]) Seq
> 2-1794246992: Received: { Ans: , MgmtId: 29066118877352, via: 2, Ver: v1,
> Flags: 10, {
> Answer } }
> 2013-08-14 02:13:57,008 DEBUG [storage.volume.VolumeObject]
> (Job-Executor-109:job-635 = [ dafa3d4b-a9f1-45e7-b13f-48cb1aace017 ]) Failed
> to update state
> java.lang.NullPointerException
> at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:99)
> at
> org.apache.cloudstack.storage.volume.VolumeObject.stateTransit(VolumeObject.java:153)
> at
> org.apache.cloudstack.storage.volume.VolumeObject.processEvent(VolumeObject.java:288)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.deleteVolumeCallback(VolumeServiceImpl.java:296)
> at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
> at
> org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120)
> at
> org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.deleteAsync(CloudStackPrimaryDataStoreDriverImpl.java:141)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.expungeVolumeAsync(VolumeServiceImpl.java:285)
> at
> com.cloud.storage.VolumeManagerImpl.cleanupVolumes(VolumeManagerImpl.java:2150)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:476)
> at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1599)
> at
> com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:616)
> at
> com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:547)
> at
> com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1276)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.region.RegionManagerImpl.deleteUserAccount(RegionManagerImpl.java:177)
> at
> org.apache.cloudstack.region.RegionServiceImpl.deleteUserAccount(RegionServiceImpl.java:118)
> at
> org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd.execute(DeleteAccountCmd.java:100)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.Th
[jira] [Commented] (CLOUDSTACK-4363) [VMware]Migration of data volume is throwing NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744367#comment-13744367
]
ASF subversion and git services commented on CLOUDSTACK-4363:
-
Commit 0040c4adef4f7b92aa63737a8f2c5405a07fabda in branch refs/heads/master
from [~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0040c4a ]
CLOUDSTACK-4363: fix possible NPE, if copy volume failed.
> [VMware]Migration of data volume is throwing NPE
> -
>
> Key: CLOUDSTACK-4363
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4363
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller
>Affects Versions: 4.2.0
>Reporter: manasaveloori
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log
>
>
> Steps:
> 1.Have a CS 4.2 with VMware host.
> 2.Have primary- 1 local and 2 shared(NFS) and secondary-NFS.
> 3.Create a shared data volume.
> 4.Migrate it to either shared primary or local primary.
> Observation.
> Migration of the volume is failing with NPE:
> 2013-08-16 19:13:13,754 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null)
> ===START=== 10.252.192.69 -- GET
> command=migrateVolume&storageid=9c5838f1-4874-4dea-b396-d318f56ff192&volumeid=53059246-e850-480a-9315-9fa647c9b17d&response=json&sessionkey=x3AM9LcYvZ%2FzkGJ8%2BLR2uNIPzOs%3D&_=1376641214226
> 2013-08-16 19:13:14,719 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-5:null) submit async job-33 = [
> 44dc9aa6-1655-4bfd-9252-f96cbc6b55eb ], details: AsyncJobVO {id:33, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"x3AM9LcYvZ/zkGJ8+LR2uNIPzOs\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"9c5838f1-4874-4dea-b396-d318f56ff192","httpmethod":"GET","volumeid":"53059246-e850-480a-9315-9fa647c9b17d","_":"1376641214226","ctxAccountId":"2","ctxStartEventId":"106"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 7067804893289,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-16 19:13:14,723 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null)
> ===END=== 10.252.192.69 -- GET
> command=migrateVolume&storageid=9c5838f1-4874-4dea-b396-d318f56ff192&volumeid=53059246-e850-480a-9315-9fa647c9b17d&response=json&sessionkey=x3AM9LcYvZ%2FzkGJ8%2BLR2uNIPzOs%3D&_=1376641214226
> 2013-08-16 19:13:14,727 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-33:job-33 = [ 44dc9aa6-1655-4bfd-9252-f96cbc6b55eb ]) Executing
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd for job-33 = [
> 44dc9aa6-1655-4bfd-9252-f96cbc6b55eb ]
> 2013-08-16 19:13:14,780 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-5:null) SeqA 2-786: Processing Seq 2-786: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-08-16 19:13:14,799 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-5:null) SeqA 2-786: Sending Seq 2-786: { Ans: ,
> MgmtId: 7067804893289, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-08-16 19:13:14,835 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-33:job-33 = [ 44dc9aa6-1655-4bfd-9252-f96cbc6b55eb ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-16 19:13:14,845 DEBUG [cache.allocator.StorageCacheRandomAllocator]
> (Job-Executor-33:job-33 = [ 44dc9aa6-1655-4bfd-9252-f96cbc6b55eb ]) Can't
> find staging storage in zone: 1
> 2013-08-16 19:13:14,973 DEBUG [agent.transport.Request]
> (Job-Executor-33:job-33 = [ 44dc9aa6-1655-4bfd-9252-f96cbc6b55eb ]) Seq
> 3-173277305: Sending { Cmd , MgmtId: 7067804893289, via: 3, Ver: v1, Flags:
> 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"53059246-e850-480a-9315-9fa647c9b17d","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f672eae0-b400-3767-808f-b787a5c04d5f","id":2,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/manasa/primaryVMw","port":2049}},"name":"shared","size":5368709120,"path":"1d3265f1faa2452e860d13bcd05c9ec7","volumeId":9,"accountId":2,"format":"OVA","id":
[jira] [Commented] (CLOUDSTACK-3229) Object_Store_Refactor - Snapshot fails on devcloud due to an internal error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744368#comment-13744368 ] ASF subversion and git services commented on CLOUDSTACK-3229: - Commit 1c96898ae1314521d32a557ec39bd745f0f4a709 in branch refs/heads/master from [~edison] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1c96898 ] CLOUDSTACK-3229: if delete snapshots on staging area failed, still treat backup snapshot as succeed. And modify snapshot delete logic on devcloud > Object_Store_Refactor - Snapshot fails on devcloud due to an internal error > --- > > Key: CLOUDSTACK-3229 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3229 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: DevCloud >Affects Versions: 4.2.0 > Environment: chrome on linux > devcloud > Cloudian or Amazon S3 Object store >Reporter: Thomas O'Dowd >Assignee: edison su >Priority: Blocker > Fix For: 4.2.0 > > Attachments: SMlog, SMlog.last_5000_lines.txt > > > Assuming initial devcloud state... > I added a cache for the S3 storage like this. > on devcloud machine as root: > # mkdir /opt/storage/cache > # vi /etc/exports (and append this line) > /opt/storage/cache *(rw,no_subtree_check,no_root_squash,fsid=) > # exportfs -a > On Mgmt server GUI: > 1. navigate to infrastructure -> secondary storage > 2. delete the NFS SS. > 3. add S3 storage for Cloudian (I used 6 as the timeouts - assuming > millis). I used the /opt/storage/cache thing as the s3 cache. > 4. nav to templates > 5. register a new template (I uploaded tinyLinux again as "mytiny" (5.3 > 64bit)). > 6. confirm with s3cmd that 2 objects are now on S3. > - s3 objects --- > template/tmpl/1/1/routing-1/acton-systemvm-02062012.vhd.bz2 > 2013-06-27T03:01:46.203Z None 140616708 "b533e7b65219439ee7fca0146ddd7ffa-27" > template/tmpl/2/201/201-2-ae9e9409-4c8e-3ad8-a62f-abec7a35fe26/tinylinux.vhd > 2013-06-27T03:04:06.730Z None 50430464 "4afac316e865adf74ca1a8039fae7399-10" > - s3 objects --- > 7. I restarted the management server at this point which actually resulted in > another object on S3. > - the new s3 object --- > template/tmpl/1/5/tiny Linux/ttylinux_pv.vhd 2013-06-27T03:43:26.494Z None > 50430464 "4afac316e865adf74ca1a8039fae7399-10" > - the new s3 object --- > 8. Go to instance and create a new choosing the "mytiny" template which we > registered. > 9. launch it after selecting all defaults. > 10. wait until it starts. > 11. nav to storage. I see ROOT-8. Click on this to open. > 12. click the camera to take the snapshot. > after a pause I get a popup > "Failed to create snapshot due to an internal error creating snapshot > for volume 8" > Also on the mgmt terminal I get the following log entry (only 1): > INFO [user.snapshot.CreateSnapshotCmd] (Job-Executor-8:job-16) VOLSS: > createSnapshotCmd starts:1372321251009 > If I check the "view snapshots" button under storage, I can however see the > snapshot. It says its on primary. I'm expecting it to go to secondary storage > though. Nothing is in the S3 logs and no snapshots. > If I try to delete that snapshot from here I get this error in the logs: > ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-12:job-20) Unexpected > exception while executing > org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd > com.cloud.utils.exception.CloudRuntimeException: Failed to delete > snapshot:com.cloud.exception.InvalidParameterValueException: Can't delete > snapshotshot 4 due to it is not in BackedUp Status > at > com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshot(SnapshotManagerImpl.java:513) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd.execute(DeleteSnapshotCmd.java:96) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.
[jira] [Commented] (CLOUDSTACK-4324) [Object_Store_Refactor] DB Exception while expunging the snapshot which was in Error state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744365#comment-13744365
]
ASF subversion and git services commented on CLOUDSTACK-4324:
-
Commit 4fd09cb344d254ef0437fec7e04e82e429f5cb39 in branch refs/heads/master
from [~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4fd09cb ]
CLOUDSTACK-4324: delete snapshot_store_ref, if create snapshot failed on
primary storage
> [Object_Store_Refactor] DB Exception while expunging the snapshot which was
> in Error state
> --
>
> Key: CLOUDSTACK-4324
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4324
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Storage Controller
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for secondary, NFS for staging and Local for primary storage
> Cluster: KVM
>Reporter: Sanjeev N
>Assignee: edison su
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, cloud.dmp, management-server.rar,
> management-server.rar
>
>
> DB Exception while expunging the snapshot which was in Error state
> Steps to Reproduce:
>
> 1. Bring up CS with kvm cluster using S3 for secondary, NFS for staging and
> Local for primary storage
> 2.Deploy guest vm with root and data disk
> 3.Configure recurring snapshot policy on root and data disk (eg:configure
> hourly on both to start almost at the same time)
> Result:
> ==
> On one of the disks snapshot creation failed (Not sure of this behaviour, so
> I have sent a mail to dev mailing list to confirm the expected behavior on
> kvm)
> StorageManager-Scavenger-1 tried to expunge the snapshot which was in error
> state due to above failure, however DBException observed during Transaction
> rollback.
> Following is the log snippet :
> ==
> 2013-08-14 05:51:43,900 DEBUG [storage.snapshot.SnapshotSchedulerImpl]
> (SnapshotPollTask:null) Scheduling 1 snapshot for volume 12 for schedule id:
> 1 at 2013-08-14 09:50:00 GMT
> 2013-08-14 05:51:43,975 DEBUG [cloud.async.AsyncJobManagerImpl]
> (SnapshotPollTask:null) submit async job-27 = [
> 1254eeae-f809-41bf-880f-289fe6127fcf ], details: AsyncJobVO {id:27, userId:
> 1, accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 3,
> cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"3","ctxUserId":"1","volumeid":"12","ctxAccountId":"2","ctxStartEventId":"1","policyid":"1"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-14 05:51:43,986 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-17:job-27 = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]) Executing
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-27
> = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]
> 2013-08-14 05:51:44,031 DEBUG [storage.snapshot.SnapshotSchedulerImpl]
> (SnapshotPollTask:null) Scheduling 1 snapshot for volume 13 for schedule id:
> 2 at 2013-08-14 09:51:00 GMT
> 2013-08-14 05:51:44,057 INFO [user.snapshot.CreateSnapshotCmd]
> (Job-Executor-17:job-27 = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]) VOLSS:
> createSnapshotCmd starts:1376473904057
> 2013-08-14 05:51:44,114 DEBUG [cloud.async.AsyncJobManagerImpl]
> (SnapshotPollTask:null) submit async job-28 = [
> ca95499a-3323-4fee-bb12-69a4df9285f3 ], details: AsyncJobVO {id:28, userId:
> 1, accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 4,
> cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"4","ctxUserId":"1","volumeid":"13","ctxAccountId":"2","ctxStartEventId":"1","policyid":"2"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-14 05:51:44,116 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-18:job-28 = [ ca95499a-3323-4fee-bb12-69a4df9285f3 ]) Executing
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-28
> = [ ca95499a-3323-4fee-bb12-69a4df9285f3 ]
> 2013-08-14 05:51:44,144 DEBUG [agent.transport.Request]
> (Job-Executor-17:job-27 = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]) Seq
> 1-1253835473: Sending { Cmd , MgmtId: 6615759585382, via: 1, Ver: v1,
[jira] [Commented] (CLOUDSTACK-4324) [Object_Store_Refactor] DB Exception while expunging the snapshot which was in Error state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744362#comment-13744362
]
ASF subversion and git services commented on CLOUDSTACK-4324:
-
Commit e7ac5d376f4942f93ae5827fd2dd775225cb7cb1 in branch refs/heads/4.2 from
[~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e7ac5d3 ]
CLOUDSTACK-4324: delete snapshot_store_ref, if create snapshot failed on
primary storage
> [Object_Store_Refactor] DB Exception while expunging the snapshot which was
> in Error state
> --
>
> Key: CLOUDSTACK-4324
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4324
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Storage Controller
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for secondary, NFS for staging and Local for primary storage
> Cluster: KVM
>Reporter: Sanjeev N
>Assignee: edison su
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, cloud.dmp, management-server.rar,
> management-server.rar
>
>
> DB Exception while expunging the snapshot which was in Error state
> Steps to Reproduce:
>
> 1. Bring up CS with kvm cluster using S3 for secondary, NFS for staging and
> Local for primary storage
> 2.Deploy guest vm with root and data disk
> 3.Configure recurring snapshot policy on root and data disk (eg:configure
> hourly on both to start almost at the same time)
> Result:
> ==
> On one of the disks snapshot creation failed (Not sure of this behaviour, so
> I have sent a mail to dev mailing list to confirm the expected behavior on
> kvm)
> StorageManager-Scavenger-1 tried to expunge the snapshot which was in error
> state due to above failure, however DBException observed during Transaction
> rollback.
> Following is the log snippet :
> ==
> 2013-08-14 05:51:43,900 DEBUG [storage.snapshot.SnapshotSchedulerImpl]
> (SnapshotPollTask:null) Scheduling 1 snapshot for volume 12 for schedule id:
> 1 at 2013-08-14 09:50:00 GMT
> 2013-08-14 05:51:43,975 DEBUG [cloud.async.AsyncJobManagerImpl]
> (SnapshotPollTask:null) submit async job-27 = [
> 1254eeae-f809-41bf-880f-289fe6127fcf ], details: AsyncJobVO {id:27, userId:
> 1, accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 3,
> cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"3","ctxUserId":"1","volumeid":"12","ctxAccountId":"2","ctxStartEventId":"1","policyid":"1"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-14 05:51:43,986 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-17:job-27 = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]) Executing
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-27
> = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]
> 2013-08-14 05:51:44,031 DEBUG [storage.snapshot.SnapshotSchedulerImpl]
> (SnapshotPollTask:null) Scheduling 1 snapshot for volume 13 for schedule id:
> 2 at 2013-08-14 09:51:00 GMT
> 2013-08-14 05:51:44,057 INFO [user.snapshot.CreateSnapshotCmd]
> (Job-Executor-17:job-27 = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]) VOLSS:
> createSnapshotCmd starts:1376473904057
> 2013-08-14 05:51:44,114 DEBUG [cloud.async.AsyncJobManagerImpl]
> (SnapshotPollTask:null) submit async job-28 = [
> ca95499a-3323-4fee-bb12-69a4df9285f3 ], details: AsyncJobVO {id:28, userId:
> 1, accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 4,
> cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"4","ctxUserId":"1","volumeid":"13","ctxAccountId":"2","ctxStartEventId":"1","policyid":"2"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-14 05:51:44,116 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-18:job-28 = [ ca95499a-3323-4fee-bb12-69a4df9285f3 ]) Executing
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-28
> = [ ca95499a-3323-4fee-bb12-69a4df9285f3 ]
> 2013-08-14 05:51:44,144 DEBUG [agent.transport.Request]
> (Job-Executor-17:job-27 = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]) Seq
> 1-1253835473: Sending { Cmd , MgmtId: 6615759585382, via: 1, Ver: v1, Fla
[jira] [Resolved] (CLOUDSTACK-4324) [Object_Store_Refactor] DB Exception while expunging the snapshot which was in Error state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-4324.
---
Resolution: Fixed
> [Object_Store_Refactor] DB Exception while expunging the snapshot which was
> in Error state
> --
>
> Key: CLOUDSTACK-4324
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4324
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Storage Controller
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for secondary, NFS for staging and Local for primary storage
> Cluster: KVM
>Reporter: Sanjeev N
>Assignee: edison su
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, cloud.dmp, management-server.rar,
> management-server.rar
>
>
> DB Exception while expunging the snapshot which was in Error state
> Steps to Reproduce:
>
> 1. Bring up CS with kvm cluster using S3 for secondary, NFS for staging and
> Local for primary storage
> 2.Deploy guest vm with root and data disk
> 3.Configure recurring snapshot policy on root and data disk (eg:configure
> hourly on both to start almost at the same time)
> Result:
> ==
> On one of the disks snapshot creation failed (Not sure of this behaviour, so
> I have sent a mail to dev mailing list to confirm the expected behavior on
> kvm)
> StorageManager-Scavenger-1 tried to expunge the snapshot which was in error
> state due to above failure, however DBException observed during Transaction
> rollback.
> Following is the log snippet :
> ==
> 2013-08-14 05:51:43,900 DEBUG [storage.snapshot.SnapshotSchedulerImpl]
> (SnapshotPollTask:null) Scheduling 1 snapshot for volume 12 for schedule id:
> 1 at 2013-08-14 09:50:00 GMT
> 2013-08-14 05:51:43,975 DEBUG [cloud.async.AsyncJobManagerImpl]
> (SnapshotPollTask:null) submit async job-27 = [
> 1254eeae-f809-41bf-880f-289fe6127fcf ], details: AsyncJobVO {id:27, userId:
> 1, accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 3,
> cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"3","ctxUserId":"1","volumeid":"12","ctxAccountId":"2","ctxStartEventId":"1","policyid":"1"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-14 05:51:43,986 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-17:job-27 = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]) Executing
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-27
> = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]
> 2013-08-14 05:51:44,031 DEBUG [storage.snapshot.SnapshotSchedulerImpl]
> (SnapshotPollTask:null) Scheduling 1 snapshot for volume 13 for schedule id:
> 2 at 2013-08-14 09:51:00 GMT
> 2013-08-14 05:51:44,057 INFO [user.snapshot.CreateSnapshotCmd]
> (Job-Executor-17:job-27 = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]) VOLSS:
> createSnapshotCmd starts:1376473904057
> 2013-08-14 05:51:44,114 DEBUG [cloud.async.AsyncJobManagerImpl]
> (SnapshotPollTask:null) submit async job-28 = [
> ca95499a-3323-4fee-bb12-69a4df9285f3 ], details: AsyncJobVO {id:28, userId:
> 1, accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 4,
> cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"4","ctxUserId":"1","volumeid":"13","ctxAccountId":"2","ctxStartEventId":"1","policyid":"2"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-14 05:51:44,116 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-18:job-28 = [ ca95499a-3323-4fee-bb12-69a4df9285f3 ]) Executing
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-28
> = [ ca95499a-3323-4fee-bb12-69a4df9285f3 ]
> 2013-08-14 05:51:44,144 DEBUG [agent.transport.Request]
> (Job-Executor-17:job-27 = [ 1254eeae-f809-41bf-880f-289fe6127fcf ]) Seq
> 1-1253835473: Sending { Cmd , MgmtId: 6615759585382, via: 1, Ver: v1, Flags:
> 100011,
> [{"org.apache.cloudstack.storage.command.CreateObjectCommand":{"data":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"volume":{"uuid":"47359dc7-5a36-4ab9-bc70-d4e6e694fe8b","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"a01b8b56-4987-4843-be07-e48f1c584498","id":1,"p
[jira] [Resolved] (CLOUDSTACK-4400) [object_store_refactor] Three entries for one template in template_store_ref when MS was restarting during template download
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-4400.
--
Resolution: Fixed
> [object_store_refactor] Three entries for one template in template_store_ref
> when MS was restarting during template download
>
>
> Key: CLOUDSTACK-4400
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4400
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Template
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Three entries for one template in template_store_ref when MS was restarting
> during template download.
> Restarting management server when the template download was in progress,
> created three entries in template_store_ref table for the same template and
> in UI tamplate Ready is set to No even though it is downloaded to S3
> Steps to Reproduce:
>
> 1.Bring up CS with two or three zones
> 2.Register template any one of the zones
> 3.Restart the management server when the template download was in progres
> Result:
> =
> After restart template sync initiated template download via all the SSVMs and
> created multiple intries in the template_store_ref for the same template.
> In UI template is not showing as ready even though it is download to S3 via
> one of the ssvms.
> Observations:
> =
> After management server restart, it found template 208 is not downlaoded
> 2013-08-19 08:54:01,695 INFO [storage.image.TemplateServiceImpl]
> (AgentConnectTaskPool-3:null) Template Sync did not find
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request
> download based on available hypervisor types
> 2013-08-19 08:54:01,709 INFO [storage.image.TemplateServiceImpl]
> (AgentConnectTaskPool-3:null) Removing leftover template
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table
> 2013-08-19 08:54:01,722 INFO [storage.image.TemplateServiceImpl]
> (AgentConnectTaskPool-6:null) Template Sync did not find
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request
> download based on available hypervisor types
> 2013-08-19 08:54:01,722 INFO [storage.image.TemplateServiceImpl]
> (AgentConnectTaskPool-6:null) Removing leftover template
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table
> 2013-08-19 08:54:01,735 INFO [storage.image.TemplateServiceImpl]
> (AgentConnectTaskPool-4:null) Template Sync did not find
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request
> download based on available hypervisor types
> 2013-08-19 08:54:01,735 INFO [storage.image.TemplateServiceImpl]
> (AgentConnectTaskPool-4:null) Removing leftover template
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table
> 2013-08-19 08:54:01,747 INFO [storage.image.TemplateServiceImpl]
> (AgentConnectTaskPool-6:null) Downloading template
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore
> 2013-08-19 08:54:01,751 INFO [storage.image.TemplateServiceImpl]
> (AgentConnectTaskPool-4:null) Downloading template
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore
> 2013-08-19 08:54:01,753 INFO [storage.image.TemplateServiceImpl]
> (AgentConnectTaskPool-3:null) Downloading template
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore
> 2013-08-19 08:54:02,068 DEBUG [storage.image.TemplateDataFactoryImpl]
> (AgentConnectTaskPool-4:null) template 208 is already in store:3, type:Image
> 2013-08-19 08:54:02,080 DEBUG [storage.image.TemplateDataFactoryImpl]
> (AgentConnectTaskPool-3:null) template 208 is already in store:3, type:Image
> 2013-08-19 08:54:02,069 DEBUG [storage.image.TemplateDataFactoryImpl]
> (AgentConnectTaskPool-6:null) template 208 is already in store:3, type:Image
> 2013-08-19 08:54:02,163 DEBUG [storage.image.BaseImageStoreDriverImpl]
> (AgentConnectTaskPool-6:null) Downloading template to data store 3
> 2013-08-19 08:54:02,164 DEBUG [storage.image.BaseImageStoreDriverImpl]
> (AgentConnectTaskPool-4:null) Downloading template to data store 3
> 2013-08-19 08:54:02,219 DEBUG [agent.transport.Request]
> (AgentConnectTaskPool-3:null) Seq 3-1325465607: Sending { Cmd , MgmtId:
> 6615759585382, via: 3, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.ReadyCommand":{"dcId":1,"hostId":3,"wait":0}}] }
> 2013-08-19 08:54:02,233 DEBUG [agent.transport.
[jira] [Resolved] (CLOUDSTACK-4370) [packaging]unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang resolved CLOUDSTACK-4370. - Resolution: Fixed > [packaging]unable to upgrade cp 4.2 build on centos5.5 > -- > > Key: CLOUDSTACK-4370 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4370 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.2.0 > Environment: Two advanced zone one xen and one vmware > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 > build : > CloudPlatform-4.2-4.2-78-rhel5 >Reporter: shweta agarwal >Assignee: frank zhang >Priority: Blocker > Fix For: 4.2.0 > > > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 failed with dependency missing > errors > Steps : > 1. Installed Management server and usage server of 3.0.4 patch 1 on centos5.5 > machine > 2. installed epel repo : rpm -Uvh > http://mirror.pnl.gov/epel/5/i386/epel-release-5-4.noarch.rpm > 3 installed jsvc :rpm -Uvh > http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > 4. untar 4.2 build and used U option > Getting dependency error : > Q) Quit > > U > Updating the CloudPlatform and its dependencies... > Loaded plugins: fastestmirror > Determining fastest mirrors > * addons: centos.excellmedia.net > * base: centos.excellmedia.net > * epel: epel.mirror.net.in > * extras: centos.excellmedia.net > * jpackage-generic: ftp.heanet.ie > * jpackage-generic-updates: ftp.heanet.ie > * updates: centos.excellmedia.net > addons >| 1.9 kB > 00:00 > addons/primary_db >| 1.1 kB > 00:00 > base >| 1.1 kB > 00:00 > base/primary >| 1.2 MB > 00:05 > base > > 3641/3641 > cloud-temp >| 951 B > 00:00 > epel >| 3.6 kB > 00:00 > epel/primary_db >| 3.8 MB > 00:06 > extras >| 2.1 kB > 00:00 > extras/primary_db >| 188 kB > 00:01 > jpackage-generic >| 2.3 kB > 00:00 > jpackage-generic/primary_db >| 1.0 MB > 00:10 > jpackage-generic-updates >| 2.3 kB > 00:00 > jpackage-generic-updates/primary_db >| 12 kB > 00:00 > updates >| 1.9 kB > 00:00 > updates/primary_db >| 602 kB > 00:02 > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package cloudstack-agent.x86_64 0:4.2.0-SNAPSHOT.el5 set to be updated > --> Processing Dependency: jna >= 3.2.4 for package: cloudstack-agent > --> Processing Dependency: qemu-kvm for package: cloudstack-agent > --> Processing Dependency: qemu-img for package: cloudstack-agent > --> Processing Dep
[jira] [Assigned] (CLOUDSTACK-4370) [packaging]unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang reassigned CLOUDSTACK-4370: --- Assignee: Rayees Namathponnan (was: frank zhang) > [packaging]unable to upgrade cp 4.2 build on centos5.5 > -- > > Key: CLOUDSTACK-4370 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4370 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.2.0 > Environment: Two advanced zone one xen and one vmware > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 > build : > CloudPlatform-4.2-4.2-78-rhel5 >Reporter: shweta agarwal >Assignee: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 failed with dependency missing > errors > Steps : > 1. Installed Management server and usage server of 3.0.4 patch 1 on centos5.5 > machine > 2. installed epel repo : rpm -Uvh > http://mirror.pnl.gov/epel/5/i386/epel-release-5-4.noarch.rpm > 3 installed jsvc :rpm -Uvh > http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > 4. untar 4.2 build and used U option > Getting dependency error : > Q) Quit > > U > Updating the CloudPlatform and its dependencies... > Loaded plugins: fastestmirror > Determining fastest mirrors > * addons: centos.excellmedia.net > * base: centos.excellmedia.net > * epel: epel.mirror.net.in > * extras: centos.excellmedia.net > * jpackage-generic: ftp.heanet.ie > * jpackage-generic-updates: ftp.heanet.ie > * updates: centos.excellmedia.net > addons >| 1.9 kB > 00:00 > addons/primary_db >| 1.1 kB > 00:00 > base >| 1.1 kB > 00:00 > base/primary >| 1.2 MB > 00:05 > base > > 3641/3641 > cloud-temp >| 951 B > 00:00 > epel >| 3.6 kB > 00:00 > epel/primary_db >| 3.8 MB > 00:06 > extras >| 2.1 kB > 00:00 > extras/primary_db >| 188 kB > 00:01 > jpackage-generic >| 2.3 kB > 00:00 > jpackage-generic/primary_db >| 1.0 MB > 00:10 > jpackage-generic-updates >| 2.3 kB > 00:00 > jpackage-generic-updates/primary_db >| 12 kB > 00:00 > updates >| 1.9 kB > 00:00 > updates/primary_db >| 602 kB > 00:02 > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package cloudstack-agent.x86_64 0:4.2.0-SNAPSHOT.el5 set to be updated > --> Processing Dependency: jna >= 3.2.4 for package: cloudstack-agent > --> Processing Dependency: qemu-kvm for package: cloudstack-agent > --> Processing Dependency: qemu-img for pa
[jira] [Assigned] (CLOUDSTACK-4370) [packaging]unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang reassigned CLOUDSTACK-4370: --- Assignee: frank zhang (was: Rayees Namathponnan) > [packaging]unable to upgrade cp 4.2 build on centos5.5 > -- > > Key: CLOUDSTACK-4370 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4370 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.2.0 > Environment: Two advanced zone one xen and one vmware > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 > build : > CloudPlatform-4.2-4.2-78-rhel5 >Reporter: shweta agarwal >Assignee: frank zhang >Priority: Blocker > Fix For: 4.2.0 > > > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 failed with dependency missing > errors > Steps : > 1. Installed Management server and usage server of 3.0.4 patch 1 on centos5.5 > machine > 2. installed epel repo : rpm -Uvh > http://mirror.pnl.gov/epel/5/i386/epel-release-5-4.noarch.rpm > 3 installed jsvc :rpm -Uvh > http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > 4. untar 4.2 build and used U option > Getting dependency error : > Q) Quit > > U > Updating the CloudPlatform and its dependencies... > Loaded plugins: fastestmirror > Determining fastest mirrors > * addons: centos.excellmedia.net > * base: centos.excellmedia.net > * epel: epel.mirror.net.in > * extras: centos.excellmedia.net > * jpackage-generic: ftp.heanet.ie > * jpackage-generic-updates: ftp.heanet.ie > * updates: centos.excellmedia.net > addons >| 1.9 kB > 00:00 > addons/primary_db >| 1.1 kB > 00:00 > base >| 1.1 kB > 00:00 > base/primary >| 1.2 MB > 00:05 > base > > 3641/3641 > cloud-temp >| 951 B > 00:00 > epel >| 3.6 kB > 00:00 > epel/primary_db >| 3.8 MB > 00:06 > extras >| 2.1 kB > 00:00 > extras/primary_db >| 188 kB > 00:01 > jpackage-generic >| 2.3 kB > 00:00 > jpackage-generic/primary_db >| 1.0 MB > 00:10 > jpackage-generic-updates >| 2.3 kB > 00:00 > jpackage-generic-updates/primary_db >| 12 kB > 00:00 > updates >| 1.9 kB > 00:00 > updates/primary_db >| 602 kB > 00:02 > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package cloudstack-agent.x86_64 0:4.2.0-SNAPSHOT.el5 set to be updated > --> Processing Dependency: jna >= 3.2.4 for package: cloudstack-agent > --> Processing Dependency: qemu-kvm for package: cloudstack-agent > --> Processing Dependency: qemu-img for package: c
[jira] [Commented] (CLOUDSTACK-4400) [object_store_refactor] Three entries for one template in template_store_ref when MS was restarting during template download
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744317#comment-13744317 ] Min Chen commented on CLOUDSTACK-4400: -- This bug only happens when we have multi-zone environments that share the same S3 secondary storage. Add lock during template/volume sync to make sure that only one thread can perform template/volume sync for an image store at a time. > [object_store_refactor] Three entries for one template in template_store_ref > when MS was restarting during template download > > > Key: CLOUDSTACK-4400 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4400 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: 4.2.0 > Environment: Latest build from ACS 4.2 branch >Reporter: Sanjeev N >Assignee: Min Chen >Priority: Critical > Fix For: 4.2.0 > > Attachments: cloud.dmp, management-server.rar > > > Three entries for one template in template_store_ref when MS was restarting > during template download. > Restarting management server when the template download was in progress, > created three entries in template_store_ref table for the same template and > in UI tamplate Ready is set to No even though it is downloaded to S3 > Steps to Reproduce: > > 1.Bring up CS with two or three zones > 2.Register template any one of the zones > 3.Restart the management server when the template download was in progres > Result: > = > After restart template sync initiated template download via all the SSVMs and > created multiple intries in the template_store_ref for the same template. > In UI template is not showing as ready even though it is download to S3 via > one of the ssvms. > Observations: > = > After management server restart, it found template 208 is not downlaoded > 2013-08-19 08:54:01,695 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-3:null) Template Sync did not find > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request > download based on available hypervisor types > 2013-08-19 08:54:01,709 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-3:null) Removing leftover template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table > 2013-08-19 08:54:01,722 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-6:null) Template Sync did not find > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request > download based on available hypervisor types > 2013-08-19 08:54:01,722 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-6:null) Removing leftover template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table > 2013-08-19 08:54:01,735 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-4:null) Template Sync did not find > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request > download based on available hypervisor types > 2013-08-19 08:54:01,735 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-4:null) Removing leftover template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table > 2013-08-19 08:54:01,747 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-6:null) Downloading template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore > 2013-08-19 08:54:01,751 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-4:null) Downloading template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore > 2013-08-19 08:54:01,753 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-3:null) Downloading template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore > 2013-08-19 08:54:02,068 DEBUG [storage.image.TemplateDataFactoryImpl] > (AgentConnectTaskPool-4:null) template 208 is already in store:3, type:Image > 2013-08-19 08:54:02,080 DEBUG [storage.image.TemplateDataFactoryImpl] > (AgentConnectTaskPool-3:null) template 208 is already in store:3, type:Image > 2013-08-19 08:54:02,069 DEBUG [storage.image.TemplateDataFactoryImpl] > (AgentConnectTaskPool-6:null) template 208 is already in store:3, type:Image > 2013-08-19 08:54:02,163 DEBUG [storage.image.BaseImageStoreDriverImpl] > (AgentConnectTaskPool-6:null) Downloading template to data store 3 > 2013-08-19 08:54:02,164 DEBUG [storage.image.BaseImageStoreDriverImpl] > (AgentConnectTaskPool-4:null) Downloading template to data store 3 > 2013-08-19 08:54:02,219
[jira] [Commented] (CLOUDSTACK-4370) [packaging]unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744316#comment-13744316 ] ASF subversion and git services commented on CLOUDSTACK-4370: - Commit c09bbd316c1e2648fe0a07fffb81befc6bb93d31 in branch refs/heads/master from [~rayeesn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c09bbd3 ] CLOUDSTACK-4370 - Upgrade failing due to depenency with cloudstack-agent, changed remove dependency from cloud-agent to cloud-common > [packaging]unable to upgrade cp 4.2 build on centos5.5 > -- > > Key: CLOUDSTACK-4370 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4370 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.2.0 > Environment: Two advanced zone one xen and one vmware > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 > build : > CloudPlatform-4.2-4.2-78-rhel5 >Reporter: shweta agarwal >Assignee: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 failed with dependency missing > errors > Steps : > 1. Installed Management server and usage server of 3.0.4 patch 1 on centos5.5 > machine > 2. installed epel repo : rpm -Uvh > http://mirror.pnl.gov/epel/5/i386/epel-release-5-4.noarch.rpm > 3 installed jsvc :rpm -Uvh > http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > 4. untar 4.2 build and used U option > Getting dependency error : > Q) Quit > > U > Updating the CloudPlatform and its dependencies... > Loaded plugins: fastestmirror > Determining fastest mirrors > * addons: centos.excellmedia.net > * base: centos.excellmedia.net > * epel: epel.mirror.net.in > * extras: centos.excellmedia.net > * jpackage-generic: ftp.heanet.ie > * jpackage-generic-updates: ftp.heanet.ie > * updates: centos.excellmedia.net > addons >| 1.9 kB > 00:00 > addons/primary_db >| 1.1 kB > 00:00 > base >| 1.1 kB > 00:00 > base/primary >| 1.2 MB > 00:05 > base > > 3641/3641 > cloud-temp >| 951 B > 00:00 > epel >| 3.6 kB > 00:00 > epel/primary_db >| 3.8 MB > 00:06 > extras >| 2.1 kB > 00:00 > extras/primary_db >| 188 kB > 00:01 > jpackage-generic >| 2.3 kB > 00:00 > jpackage-generic/primary_db >| 1.0 MB > 00:10 > jpackage-generic-updates >| 2.3 kB > 00:00 > jpackage-generic-updates/primary_db >| 12 kB > 00:00 > updates >| 1.9 kB > 00:00 > updates/primary_db >| 602 kB > 00:0
[jira] [Commented] (CLOUDSTACK-4400) [object_store_refactor] Three entries for one template in template_store_ref when MS was restarting during template download
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744314#comment-13744314 ] ASF subversion and git services commented on CLOUDSTACK-4400: - Commit 3937a7b5a554b0c6816cd37afe4e482bff48ec55 in branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3937a7b ] CLOUDSTACK-4400:[object_store_refactor] Three entries for one template in template_store_ref when MS was restarting during template download. > [object_store_refactor] Three entries for one template in template_store_ref > when MS was restarting during template download > > > Key: CLOUDSTACK-4400 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4400 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: 4.2.0 > Environment: Latest build from ACS 4.2 branch >Reporter: Sanjeev N >Assignee: Min Chen >Priority: Critical > Fix For: 4.2.0 > > Attachments: cloud.dmp, management-server.rar > > > Three entries for one template in template_store_ref when MS was restarting > during template download. > Restarting management server when the template download was in progress, > created three entries in template_store_ref table for the same template and > in UI tamplate Ready is set to No even though it is downloaded to S3 > Steps to Reproduce: > > 1.Bring up CS with two or three zones > 2.Register template any one of the zones > 3.Restart the management server when the template download was in progres > Result: > = > After restart template sync initiated template download via all the SSVMs and > created multiple intries in the template_store_ref for the same template. > In UI template is not showing as ready even though it is download to S3 via > one of the ssvms. > Observations: > = > After management server restart, it found template 208 is not downlaoded > 2013-08-19 08:54:01,695 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-3:null) Template Sync did not find > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request > download based on available hypervisor types > 2013-08-19 08:54:01,709 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-3:null) Removing leftover template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table > 2013-08-19 08:54:01,722 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-6:null) Template Sync did not find > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request > download based on available hypervisor types > 2013-08-19 08:54:01,722 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-6:null) Removing leftover template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table > 2013-08-19 08:54:01,735 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-4:null) Template Sync did not find > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request > download based on available hypervisor types > 2013-08-19 08:54:01,735 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-4:null) Removing leftover template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table > 2013-08-19 08:54:01,747 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-6:null) Downloading template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore > 2013-08-19 08:54:01,751 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-4:null) Downloading template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore > 2013-08-19 08:54:01,753 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-3:null) Downloading template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore > 2013-08-19 08:54:02,068 DEBUG [storage.image.TemplateDataFactoryImpl] > (AgentConnectTaskPool-4:null) template 208 is already in store:3, type:Image > 2013-08-19 08:54:02,080 DEBUG [storage.image.TemplateDataFactoryImpl] > (AgentConnectTaskPool-3:null) template 208 is already in store:3, type:Image > 2013-08-19 08:54:02,069 DEBUG [storage.image.TemplateDataFactoryImpl] > (AgentConnectTaskPool-6:null) template 208 is already in store:3, type:Image > 2013-08-19 08:54:02,163 DEBUG [storage.image.BaseImageStoreDriverImpl] > (AgentConnectTaskPool-6:null) Downloading template to data store 3 > 2013-08-19 08:54:02,164 DEBUG [storage.image.Bas
[jira] [Commented] (CLOUDSTACK-4370) [packaging]unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744315#comment-13744315 ] ASF subversion and git services commented on CLOUDSTACK-4370: - Commit 12f36b8dbbfd0f24ca35280215bbd6e797e985d1 in branch refs/heads/4.2 from [~rayeesn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=12f36b8 ] CLOUDSTACK-4370 - Upgrade failing due to depenency with cloudstack-agent, changed remove dependency from cloud-agent to cloud-common > [packaging]unable to upgrade cp 4.2 build on centos5.5 > -- > > Key: CLOUDSTACK-4370 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4370 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.2.0 > Environment: Two advanced zone one xen and one vmware > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 > build : > CloudPlatform-4.2-4.2-78-rhel5 >Reporter: shweta agarwal >Assignee: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 failed with dependency missing > errors > Steps : > 1. Installed Management server and usage server of 3.0.4 patch 1 on centos5.5 > machine > 2. installed epel repo : rpm -Uvh > http://mirror.pnl.gov/epel/5/i386/epel-release-5-4.noarch.rpm > 3 installed jsvc :rpm -Uvh > http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > 4. untar 4.2 build and used U option > Getting dependency error : > Q) Quit > > U > Updating the CloudPlatform and its dependencies... > Loaded plugins: fastestmirror > Determining fastest mirrors > * addons: centos.excellmedia.net > * base: centos.excellmedia.net > * epel: epel.mirror.net.in > * extras: centos.excellmedia.net > * jpackage-generic: ftp.heanet.ie > * jpackage-generic-updates: ftp.heanet.ie > * updates: centos.excellmedia.net > addons >| 1.9 kB > 00:00 > addons/primary_db >| 1.1 kB > 00:00 > base >| 1.1 kB > 00:00 > base/primary >| 1.2 MB > 00:05 > base > > 3641/3641 > cloud-temp >| 951 B > 00:00 > epel >| 3.6 kB > 00:00 > epel/primary_db >| 3.8 MB > 00:06 > extras >| 2.1 kB > 00:00 > extras/primary_db >| 188 kB > 00:01 > jpackage-generic >| 2.3 kB > 00:00 > jpackage-generic/primary_db >| 1.0 MB > 00:10 > jpackage-generic-updates >| 2.3 kB > 00:00 > jpackage-generic-updates/primary_db >| 12 kB > 00:00 > updates >| 1.9 kB > 00:00 > updates/primary_db >| 602 kB > 00:02 >
[jira] [Commented] (CLOUDSTACK-4400) [object_store_refactor] Three entries for one template in template_store_ref when MS was restarting during template download
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744307#comment-13744307 ] ASF subversion and git services commented on CLOUDSTACK-4400: - Commit 6f7fdac3ee730253754e95e4bb155200bd7723e7 in branch refs/heads/4.2 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6f7fdac ] CLOUDSTACK-4400:[object_store_refactor] Three entries for one template in template_store_ref when MS was restarting during template download. > [object_store_refactor] Three entries for one template in template_store_ref > when MS was restarting during template download > > > Key: CLOUDSTACK-4400 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4400 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: 4.2.0 > Environment: Latest build from ACS 4.2 branch >Reporter: Sanjeev N >Assignee: Min Chen >Priority: Critical > Fix For: 4.2.0 > > Attachments: cloud.dmp, management-server.rar > > > Three entries for one template in template_store_ref when MS was restarting > during template download. > Restarting management server when the template download was in progress, > created three entries in template_store_ref table for the same template and > in UI tamplate Ready is set to No even though it is downloaded to S3 > Steps to Reproduce: > > 1.Bring up CS with two or three zones > 2.Register template any one of the zones > 3.Restart the management server when the template download was in progres > Result: > = > After restart template sync initiated template download via all the SSVMs and > created multiple intries in the template_store_ref for the same template. > In UI template is not showing as ready even though it is download to S3 via > one of the ssvms. > Observations: > = > After management server restart, it found template 208 is not downlaoded > 2013-08-19 08:54:01,695 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-3:null) Template Sync did not find > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request > download based on available hypervisor types > 2013-08-19 08:54:01,709 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-3:null) Removing leftover template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table > 2013-08-19 08:54:01,722 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-6:null) Template Sync did not find > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request > download based on available hypervisor types > 2013-08-19 08:54:01,722 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-6:null) Removing leftover template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table > 2013-08-19 08:54:01,735 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-4:null) Template Sync did not find > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request > download based on available hypervisor types > 2013-08-19 08:54:01,735 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-4:null) Removing leftover template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table > 2013-08-19 08:54:01,747 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-6:null) Downloading template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore > 2013-08-19 08:54:01,751 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-4:null) Downloading template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore > 2013-08-19 08:54:01,753 INFO [storage.image.TemplateServiceImpl] > (AgentConnectTaskPool-3:null) Downloading template > 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore > 2013-08-19 08:54:02,068 DEBUG [storage.image.TemplateDataFactoryImpl] > (AgentConnectTaskPool-4:null) template 208 is already in store:3, type:Image > 2013-08-19 08:54:02,080 DEBUG [storage.image.TemplateDataFactoryImpl] > (AgentConnectTaskPool-3:null) template 208 is already in store:3, type:Image > 2013-08-19 08:54:02,069 DEBUG [storage.image.TemplateDataFactoryImpl] > (AgentConnectTaskPool-6:null) template 208 is already in store:3, type:Image > 2013-08-19 08:54:02,163 DEBUG [storage.image.BaseImageStoreDriverImpl] > (AgentConnectTaskPool-6:null) Downloading template to data store 3 > 2013-08-19 08:54:02,164 DEBUG [storage.image.BaseIm
[jira] [Commented] (CLOUDSTACK-4370) [packaging]unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744253#comment-13744253 ] Rayees Namathponnan commented on CLOUDSTACK-4370: - in Review stage https://reviews.apache.org/r/13664/ > [packaging]unable to upgrade cp 4.2 build on centos5.5 > -- > > Key: CLOUDSTACK-4370 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4370 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.2.0 > Environment: Two advanced zone one xen and one vmware > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 > build : > CloudPlatform-4.2-4.2-78-rhel5 >Reporter: shweta agarwal >Assignee: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 failed with dependency missing > errors > Steps : > 1. Installed Management server and usage server of 3.0.4 patch 1 on centos5.5 > machine > 2. installed epel repo : rpm -Uvh > http://mirror.pnl.gov/epel/5/i386/epel-release-5-4.noarch.rpm > 3 installed jsvc :rpm -Uvh > http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > 4. untar 4.2 build and used U option > Getting dependency error : > Q) Quit > > U > Updating the CloudPlatform and its dependencies... > Loaded plugins: fastestmirror > Determining fastest mirrors > * addons: centos.excellmedia.net > * base: centos.excellmedia.net > * epel: epel.mirror.net.in > * extras: centos.excellmedia.net > * jpackage-generic: ftp.heanet.ie > * jpackage-generic-updates: ftp.heanet.ie > * updates: centos.excellmedia.net > addons >| 1.9 kB > 00:00 > addons/primary_db >| 1.1 kB > 00:00 > base >| 1.1 kB > 00:00 > base/primary >| 1.2 MB > 00:05 > base > > 3641/3641 > cloud-temp >| 951 B > 00:00 > epel >| 3.6 kB > 00:00 > epel/primary_db >| 3.8 MB > 00:06 > extras >| 2.1 kB > 00:00 > extras/primary_db >| 188 kB > 00:01 > jpackage-generic >| 2.3 kB > 00:00 > jpackage-generic/primary_db >| 1.0 MB > 00:10 > jpackage-generic-updates >| 2.3 kB > 00:00 > jpackage-generic-updates/primary_db >| 12 kB > 00:00 > updates >| 1.9 kB > 00:00 > updates/primary_db >| 602 kB > 00:02 > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package cloudstack-agent.x86_64 0:4.2.0-SNAPSHOT.el5 set to be updated > --> Processing Dependency: jna >= 3.2.4 for package: cloudstack-agent > --> Processing Dependency: qemu-k
[jira] [Updated] (CLOUDSTACK-4370) [packaging]unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-4370: Status: Ready To Review (was: In Progress) > [packaging]unable to upgrade cp 4.2 build on centos5.5 > -- > > Key: CLOUDSTACK-4370 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4370 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.2.0 > Environment: Two advanced zone one xen and one vmware > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 > build : > CloudPlatform-4.2-4.2-78-rhel5 >Reporter: shweta agarwal >Assignee: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > > upgrade from 3.0.4 patch1 to 4.2 on centos 5.5 failed with dependency missing > errors > Steps : > 1. Installed Management server and usage server of 3.0.4 patch 1 on centos5.5 > machine > 2. installed epel repo : rpm -Uvh > http://mirror.pnl.gov/epel/5/i386/epel-release-5-4.noarch.rpm > 3 installed jsvc :rpm -Uvh > http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > 4. untar 4.2 build and used U option > Getting dependency error : > Q) Quit > > U > Updating the CloudPlatform and its dependencies... > Loaded plugins: fastestmirror > Determining fastest mirrors > * addons: centos.excellmedia.net > * base: centos.excellmedia.net > * epel: epel.mirror.net.in > * extras: centos.excellmedia.net > * jpackage-generic: ftp.heanet.ie > * jpackage-generic-updates: ftp.heanet.ie > * updates: centos.excellmedia.net > addons >| 1.9 kB > 00:00 > addons/primary_db >| 1.1 kB > 00:00 > base >| 1.1 kB > 00:00 > base/primary >| 1.2 MB > 00:05 > base > > 3641/3641 > cloud-temp >| 951 B > 00:00 > epel >| 3.6 kB > 00:00 > epel/primary_db >| 3.8 MB > 00:06 > extras >| 2.1 kB > 00:00 > extras/primary_db >| 188 kB > 00:01 > jpackage-generic >| 2.3 kB > 00:00 > jpackage-generic/primary_db >| 1.0 MB > 00:10 > jpackage-generic-updates >| 2.3 kB > 00:00 > jpackage-generic-updates/primary_db >| 12 kB > 00:00 > updates >| 1.9 kB > 00:00 > updates/primary_db >| 602 kB > 00:02 > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package cloudstack-agent.x86_64 0:4.2.0-SNAPSHOT.el5 set to be updated > --> Processing Dependency: jna >= 3.2.4 for package: cloudstack-agent > --> Processing Dependency: qemu-kvm for package: cloudstack-agent > --> Processing Dependency: qemu-img fo
[jira] [Closed] (CLOUDSTACK-3958) listProjectAccounts: remove irrelevant user info from the response
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Jagirdar closed CLOUDSTACK-3958.
--
Verified as a User. Response now is short and sweet. Closing the issue.
{ "listprojectaccountsresponse" : { "count":2 ,"projectaccount" : [
{"projectid":"f4f9c1a5-ac2a-4ba7-af2d-4711b6b8d679","project":"testproject","accountid":"e3292bf7-f7b2-4a4c-8608-8cb4f368f294","account":"test","accounttype":0,"role":"Admin","domainid":"269f202a-05ce-11e3-9b38-066a9a000451","domain":"ROOT"},
{"projectid":"f4f9c1a5-ac2a-4ba7-af2d-4711b6b8d679","project":"testproject","accountid":"3b15bc48-05cf-11e3-9b38-066a9a000451","account":"admin","accounttype":1,"role":"Regular","domainid":"269f202a-05ce-11e3-9b38-066a9a000451","domain":"ROOT"}
] } }
> listProjectAccounts: remove irrelevant user info from the response
> --
>
> Key: CLOUDSTACK-3958
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3958
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: Alena Prokharchyk
>Assignee: Alena Prokharchyk
> Fix For: 4.2.0
>
>
> No need to return user information in the listProjectAccounts info; return
> account information only as the user info can be extracted by executing
> listUsers&accountId command.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-1059) Stop cloudstack mailing list from stripping TO/CC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-1059. -- > Stop cloudstack mailing list from stripping TO/CC > - > > Key: CLOUDSTACK-1059 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1059 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sheng Yang >Assignee: David Nalley >Priority: Critical > > According to the discussion on > http://comments.gmane.org/gmane.comp.apache.cloudstack.devel/9216 > We would like to stop cloudstack mailing list from sending out mail with > stripped TO/CC, and would change to use TO/CC to keep people in thread. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4375) VM Migration is failing from one cluster to another cluster.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744239#comment-13744239
]
Prachi Damle commented on CLOUDSTACK-4375:
--
Sateesh,
If admin calls migrateVirtualMachineWithVolume using API and passes a
destination host then following case needs to be addressed:
You might also want to fix VirtualMachineManagerImpl ::
getPoolListForVolumesForMigration() to not find another pool if the currentpool
is accessible to the destination host.
Currently I see that we are trying to do so, but then we break after the first
allocator returns a non-empty poolList and this poolLIst may not contain the
currentPool. So we end up migarting teh volume to the first pool in the list.
So either we should loop through all allocators to get a complete list of pools
or better way is to first check if currentPool is accessible to destination
host before calling the allocators.
> VM Migration is failing from one cluster to another cluster.
>
>
> Key: CLOUDSTACK-4375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4375
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps followed are as below:
> 1)Created a Advanced Zone VMware setup with two clusters C1 & c2.
> 2)C1 having 2 hosts H1 and H2 and C2 having single host H3.
> 3)Dedicated the Zone to Domain D1 having Account A1 and A2.
> 4)Dedicated the Host H2 to Account A1, where H1 has the system Vm's in it.
> 5)Created a VM not using the affinity group for the host,the Router VM came
> up on the host H1and the VM is created on host H3 of the cluster C2.
> 6)Now tried to migrate the VM from H3 to H1 the migration was successful.
> 7)Now tried to migrate the VM from H1 to H3 again the VM migration failed
> with the below error message
> "2013-08-17 03:13:59,447 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,488 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-2:null) submit async job-178 = [
> b9d65e31-7cdf-4ce5-b93c-440287d8523f ], details: AsyncJobVO {id:178, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null,
> cmdInfo:
> {"response":"json","sessionkey":"3O/KhJ6pMFCAfLTZtIqQOY6R6/4\u003d","virtualmachineid":"385b5edb-b6b2-4931-a4ab-8f9bd96acd14","cmdEventType":"VM.MIGRATE","hostid":"49537136-d44f-439a-937c-442ed74bd697","ctxUserId":"2","httpmethod":"GET","_":"1376669973550","ctxAccountId":"2","ctxStartEventId":"618"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6703101771911,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-17 03:13:59,489 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,491 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-178
> = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]
> 2013-08-17 03:13:59,528 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Migrating VM[User|kiran14] to
> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
> : Dest[Zone(3)-Pod(3)-Cluster(6)-Host(11)-Storage()]
> 2013-08-17 03:13:59,529 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]) Source
> and destination host are not in same cluster, unable to migrate to host: 11
> 2013-08-17 03:13:59,536 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
> com.cloud.utils.exception.CloudRuntimeException: Source and destination host
> are not in
[jira] [Closed] (CLOUDSTACK-2639) Occasional error by restart network or virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-2639. -- > Occasional error by restart network or virtual router > - > > Key: CLOUDSTACK-2639 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2639 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.0 > > > Occasional error by restart network or virtual router > Sometime we faces occasional error by restart network or virtual router. > In case of restart network by API 200 times, we found 3 errors then, > in case of restart virtual router 200 times, we found 5 errors then. > The errors are found in management server log, job-130187 for instance. > > failed due to LoadBalancerConfigCommand on domain router 10.129.51.128 failed. > message: [WARNING] 348/024433 (3249) : config : 'option forwardfor' ignored > for > proxy '210_129_192_105-8080' as it requires HTTP mode. > > VR log's error is below: > > Dec 14 02:44:41 r-17544-VM cloud: Loadbalancer public interfaces = eth2 eth3 > eth4 > Dec 14 02:44:43 r-17544-VM cloud: New instance failed to start, resuming > previous one. > Dec 14 02:44:43 r-17544-VM cloud: Reconfiguring loadbalancer failed > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-1522) File lock mechanism cannot get correct order when two process want to get the lock in the same second
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-1522. -- > File lock mechanism cannot get correct order when two process want to get the > lock in the same second > - > > Key: CLOUDSTACK-1522 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1522 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.1.0 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.0 > > > The file lock mechanism is trying to provide a function that the lock > requester would get the lock in the order they requested. This is implemented > by using lock file's timestamp. > But in ext3, timestamp's precision is only in seconds, so when two requester > want to get the same lock in the same second, the order cannot be guaranteed. > This caused issue in redundant router, when keepalived detected MASTER > disappear then soon MASTER back again, keepalived would call switch to MASTER > script first, then immediately call switch to BACKUP script, which may result > in BACKUP script is called before MASTER script, since they're executed in > the same second. > File lock need to get high precision for determining the order of requester. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-3537) [UI] - when pass pageSize to the list* api calls, check against global config "default.page.size"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk reopened CLOUDSTACK-3537: --- > [UI] - when pass pageSize to the list* api calls, check against global config > "default.page.size" > - > > Key: CLOUDSTACK-3537 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3537 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Alena Prokharchyk >Assignee: Brian Federle > Fix For: 4.2.0 > > > Global config "default.page.size" defines max allowed pageSize for list* api > calls. If no pageSize specified in the call, then its being defaulted to this > global config. When pageSize is passed to the call, then it shouldn't be > greater than default.page.size. > The bug is: UI passed pageSize to the number of API calls w/o verifying > whether this number is less than default.page.size allows. And it ends up > with the errors on the API side "Page size can't exceed max allowed page size > value" > Suggested fix: when UI passes pageSize param to the list* API call: > * verify its value against default.page.size > * if its <=, pass it to the call > * if its >, then pass default.page.size to the call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-1653) Redundant router: check_heartbeat.sh malfunction caused by delayed cron job
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-1653. -- > Redundant router: check_heartbeat.sh malfunction caused by delayed cron job > --- > > Key: CLOUDSTACK-1653 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1653 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.0 > > > According to: https://bugzilla.redhat.com/show_bug.cgi?id=159441 > cron can only guarantee the minimum interval of execution jobs, so two check > of check_heartbeat.sh would possibly take more than 1 minutes. > Since keepalived should update keepalived.ts every 10 seconds, so if any of > two execution have gap less than 60 seconds, it should fail. > The current logic in the check_heartbeat.sh is wrong, which only guarantee > cron didn't delay, but not keepalived is alive. > This pass the original test because it was a NFS disconnecting test, in which > case disk is corrupted, so cron got delayed, means network is down. > Change the condition to less than 60(probably 30 is safer because seems > sometime cron has bug for not meeting the minimum interval requirement) > should works too. Because it should find out that keepalived is dead after > second time it was executed after NFS recovered. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-1170) Redundant router: MAC addresses are different for additional public nics
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-1170. -- > Redundant router: MAC addresses are different for additional public nics > > > Key: CLOUDSTACK-1170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1170 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.0 > > > We should allocate same MAC addresses for the same public ip(because in > VRRP’s RFC, they mentioned the interface should have the same MAC address). > We use some random bits in our generated MAC for “security reason”, result in > everytime we get these public address we would get a new MAC for it. > And all the additional nics are not recorded in the nic table, so there is no > way for us to track it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2681) When failed to apply port forwarding rules, message showed: "Failed to delete port forwarding rule"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-2681. -- > When failed to apply port forwarding rules, message showed: "Failed to delete > port forwarding rule" > --- > > Key: CLOUDSTACK-2681 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2681 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Minor > Fix For: 4.2.0 > > > Because after failed applying, mgmt server would try to revoke it, then > failed again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3537) [UI] - when pass pageSize to the list* api calls, check against global config "default.page.size"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744238#comment-13744238 ] Alena Prokharchyk commented on CLOUDSTACK-3537: --- No need to fix in 4.2, not critical. Punting to the future. > [UI] - when pass pageSize to the list* api calls, check against global config > "default.page.size" > - > > Key: CLOUDSTACK-3537 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3537 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Alena Prokharchyk >Assignee: Brian Federle > Fix For: 4.2.0 > > > Global config "default.page.size" defines max allowed pageSize for list* api > calls. If no pageSize specified in the call, then its being defaulted to this > global config. When pageSize is passed to the call, then it shouldn't be > greater than default.page.size. > The bug is: UI passed pageSize to the number of API calls w/o verifying > whether this number is less than default.page.size allows. And it ends up > with the errors on the API side "Page size can't exceed max allowed page size > value" > Suggested fix: when UI passes pageSize param to the list* API call: > * verify its value against default.page.size > * if its <=, pass it to the call > * if its >, then pass default.page.size to the call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-1066) Fix the scripts to generate systemvm template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-1066. -- > Fix the scripts to generate systemvm template > -- > > Key: CLOUDSTACK-1066 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1066 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1 >Reporter: Sheng Yang >Assignee: Rohit Yadav > Fix For: 4.2.0 > > > The buildsystemvm.sh is broken. There is no way for CloudStack to generate an > new systemvm template now. And we're unable to add new feature which depends > on systemvm template change. We need to fix it in 4.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-3537) [UI] - when pass pageSize to the list* api calls, check against global config "default.page.size"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-3537: -- Fix Version/s: (was: 4.2.0) Future > [UI] - when pass pageSize to the list* api calls, check against global config > "default.page.size" > - > > Key: CLOUDSTACK-3537 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3537 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Alena Prokharchyk >Assignee: Brian Federle > Fix For: Future > > > Global config "default.page.size" defines max allowed pageSize for list* api > calls. If no pageSize specified in the call, then its being defaulted to this > global config. When pageSize is passed to the call, then it shouldn't be > greater than default.page.size. > The bug is: UI passed pageSize to the number of API calls w/o verifying > whether this number is less than default.page.size allows. And it ends up > with the errors on the API side "Page size can't exceed max allowed page size > value" > Suggested fix: when UI passes pageSize param to the list* API call: > * verify its value against default.page.size > * if its <=, pass it to the call > * if its >, then pass default.page.size to the call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-3045) UI - Error "array2 is undefined" shown when try to add a host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang closed CLOUDSTACK-3045.
--
> UI - Error "array2 is undefined" shown when try to add a host
> --
>
> Key: CLOUDSTACK-3045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3045
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.2.0
>Reporter: Sheng Yang
>Assignee: Brian Federle
>Priority: Critical
> Fix For: 4.2.0
>
>
> Tried to add a host, UI would show "array2 is undefined" for firebugs, and
> the screen won't be updated anyway.
> Firebugs said:
> TypeError: array2 is undefined
> [Break On This Error]
> ...eURL("dedicateHost&hostId=" +hostId +"&domainId=" +args.data.domainId +
> array2.j...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2772) Redundant router: When redundant router recover happened, rebooted BACKUP doesn't have rules programmed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-2772. -- > Redundant router: When redundant router recover happened, rebooted BACKUP > doesn't have rules programmed > --- > > Key: CLOUDSTACK-2772 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2772 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.0 > > > When redundant router recover happened due to BACKUP's priority is not equal > to MASTER's priority - 1, rebooted BACKUP doesn't have rules programmed. > Command to block eth0 traffic on VR: > Block: > iptables -I INPUT -j DROP > iptables -I OUTPUT -j DROP > Unblock: > iptables -D INPUT -j DROP > iptables -D OUTPUT -j DROP > How to test: > 1. Start RvR. > 2. After two routers are both up, add some firewall rules. > 3. Run bumpup_priority.sh in MASTER router's root directory. > BACKUP router would be rebooted by mgmt server soon. After reboot, check if > it contained firewall rules. Also check if firewall rule commands are sent > after start up commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-2792. -- > Redundant router: Password is reset again after fail-over happened > -- > > Key: CLOUDSTACK-2792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.0 > > > Consider this scenario with RVR and "Password protected" VM: > > 1. Both Master and Backup is running. > 2. We reset the password on VM > 3. Both Master and Backup have password; for example say; "password1" > 4. VM boots up and requests for password; receives it from Master VR > 5. Master VR sets the password to Saved_Password and Backup VR continues to > keep "password1" > 6. Backup VR goes down; it had password as "password1" > 7. Maste VR is running > 8. We reset the password; so the password is only changed to Master VR (as > Backup VR is down); for example "password2" > 9. VM boots up and requests the password; gets it as "password2" > 10. Master VR sets the password to be Saved_Password > 11. Now Master VR goes down > 12. Backup VR was brought online (it still has "password1") > 13. Now we reboot the VM > 14. It sends a password request > 15. Backup VR (which is only available now; so is Master) sends the password > as > "password1" > User tries to login as "password2" and he cannot; unless we reset the password > again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2870) UI: The label of private vlan when creating private vlan network is wrong
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-2870. -- > UI: The label of private vlan when creating private vlan network is wrong > - > > Key: CLOUDSTACK-2870 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2870 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Jessica Wang > Fix For: 4.2.0 > > Attachments: pvlan.png > > > The label should be "Secondary Isolated VLAN ID", rather than "Private VLAN > ID". It's very confusion. > And it's better the field only shows when something like "Private VLAN" > checkbox is checked. > See the screenshot later. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3537) [UI] - when pass pageSize to the list* api calls, check against global config "default.page.size"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744237#comment-13744237 ] Alena Prokharchyk commented on CLOUDSTACK-3537: --- Brian, you can implement it on the admin UI by now, as Admin UI has the biggest number of entries returned, and its the place where you most likely will observe the problem. In the future, we can add default.page.size to the listCapabilities API response, and implement it in DomainAdmin/User UI. > [UI] - when pass pageSize to the list* api calls, check against global config > "default.page.size" > - > > Key: CLOUDSTACK-3537 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3537 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Alena Prokharchyk >Assignee: Brian Federle > Fix For: 4.2.0 > > > Global config "default.page.size" defines max allowed pageSize for list* api > calls. If no pageSize specified in the call, then its being defaulted to this > global config. When pageSize is passed to the call, then it shouldn't be > greater than default.page.size. > The bug is: UI passed pageSize to the number of API calls w/o verifying > whether this number is less than default.page.size allows. And it ends up > with the errors on the API side "Page size can't exceed max allowed page size > value" > Suggested fix: when UI passes pageSize param to the list* API call: > * verify its value against default.page.size > * if its <=, pass it to the call > * if its >, then pass default.page.size to the call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3357) network domain for a vpc is not propagated to the virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744234#comment-13744234 ] Sheng Yang commented on CLOUDSTACK-3357: Hi Daan, If the bug didn't show after my fix, you can close the bug as well. Thanks! > network domain for a vpc is not propagated to the virtual router > > > Key: CLOUDSTACK-3357 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3357 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.2, 4.1.0 >Reporter: Daan Hoogland >Assignee: Sheng Yang >Priority: Critical > Labels: integration-test > Fix For: 4.2.0 > > > network domain for a vpc is propagated to the database but not to the virtual > routers. > When creating a new VPC, a network domain is given .This domain would be > expected to be used in the dns resolution for hosts and be programmed into > /etc/dnsmasq.conf on the virtual router (containing the dns for that > network). That file is not touched at all, however. > Reproduce steps: > 1. Create VPC with domain "testdomain.internal" > 2. Create a network inside VPC. > 3. Create 2 VMs, named vm1 and vm2 in the network. > Two guest VMs are not able to ping each other using name, e.g. "ping vm1" in > vm2 failed. > Two guest VMs are not able to ping each other using name.domain, e.g. "ping > vm1.testdomain.internal" in vm2 failed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4375) VM Migration is failing from one cluster to another cluster.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744221#comment-13744221
]
ASF subversion and git services commented on CLOUDSTACK-4375:
-
Commit bdb8107c6180c21dfcc4fce446c2a53c4b50f40e in branch refs/heads/4.2 from
[~sateeshc]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bdb8107 ]
CLOUDSTACK-4375 VM Migration is failing from one cluster to another cluster.
listHostsForMigrationOfVM is being called when user attempts to move a VM to
other host. This is trying to find list of suitable storage pools that are
attached to each of the suitable hosts for the VM.
Currently the selection of target storage pools for each volume of the VM is
left to storage pool allocators.
But user might want to leave his volume unmoved/intact If it is on a zone wide
storage pool.
This would be more efficient while migrating VM as storage live migration is
not required and VM continues to use volumes on same storage pool as before.
Hence idea is to set same storage pool as target pool for each of the volume if
the volume is already on zone wide storage pool.
A comparison of source pool of volume against target pool of volume yields the
information if storage migration is required for the VM to move to target host
or not.
Based on that information apropriate API migrateVM or migrateVmWithVolume could
be decided.
Signed-off-by: Sateesh Chodapuneedi
> VM Migration is failing from one cluster to another cluster.
>
>
> Key: CLOUDSTACK-4375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4375
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps followed are as below:
> 1)Created a Advanced Zone VMware setup with two clusters C1 & c2.
> 2)C1 having 2 hosts H1 and H2 and C2 having single host H3.
> 3)Dedicated the Zone to Domain D1 having Account A1 and A2.
> 4)Dedicated the Host H2 to Account A1, where H1 has the system Vm's in it.
> 5)Created a VM not using the affinity group for the host,the Router VM came
> up on the host H1and the VM is created on host H3 of the cluster C2.
> 6)Now tried to migrate the VM from H3 to H1 the migration was successful.
> 7)Now tried to migrate the VM from H1 to H3 again the VM migration failed
> with the below error message
> "2013-08-17 03:13:59,447 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,488 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-2:null) submit async job-178 = [
> b9d65e31-7cdf-4ce5-b93c-440287d8523f ], details: AsyncJobVO {id:178, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null,
> cmdInfo:
> {"response":"json","sessionkey":"3O/KhJ6pMFCAfLTZtIqQOY6R6/4\u003d","virtualmachineid":"385b5edb-b6b2-4931-a4ab-8f9bd96acd14","cmdEventType":"VM.MIGRATE","hostid":"49537136-d44f-439a-937c-442ed74bd697","ctxUserId":"2","httpmethod":"GET","_":"1376669973550","ctxAccountId":"2","ctxStartEventId":"618"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6703101771911,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-17 03:13:59,489 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,491 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-178
> = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]
> 2013-08-17 03:13:59,528 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Migrating VM[User|kiran14] to
> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
> : Dest[Zone(3)-Pod(3)-Cluster(6)-Host(11)-Storage()]
> 2013-08-17 03:13:59,529 INFO [cloud.vm.V
[jira] [Resolved] (CLOUDSTACK-4375) VM Migration is failing from one cluster to another cluster.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi resolved CLOUDSTACK-4375.
--
Resolution: Fixed
Assignee: Sateesh Chodapuneedi (was: Prachi Damle)
> VM Migration is failing from one cluster to another cluster.
>
>
> Key: CLOUDSTACK-4375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4375
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps followed are as below:
> 1)Created a Advanced Zone VMware setup with two clusters C1 & c2.
> 2)C1 having 2 hosts H1 and H2 and C2 having single host H3.
> 3)Dedicated the Zone to Domain D1 having Account A1 and A2.
> 4)Dedicated the Host H2 to Account A1, where H1 has the system Vm's in it.
> 5)Created a VM not using the affinity group for the host,the Router VM came
> up on the host H1and the VM is created on host H3 of the cluster C2.
> 6)Now tried to migrate the VM from H3 to H1 the migration was successful.
> 7)Now tried to migrate the VM from H1 to H3 again the VM migration failed
> with the below error message
> "2013-08-17 03:13:59,447 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,488 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-2:null) submit async job-178 = [
> b9d65e31-7cdf-4ce5-b93c-440287d8523f ], details: AsyncJobVO {id:178, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null,
> cmdInfo:
> {"response":"json","sessionkey":"3O/KhJ6pMFCAfLTZtIqQOY6R6/4\u003d","virtualmachineid":"385b5edb-b6b2-4931-a4ab-8f9bd96acd14","cmdEventType":"VM.MIGRATE","hostid":"49537136-d44f-439a-937c-442ed74bd697","ctxUserId":"2","httpmethod":"GET","_":"1376669973550","ctxAccountId":"2","ctxStartEventId":"618"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6703101771911,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-17 03:13:59,489 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.101.255.76 -- GET
> command=migrateVirtualMachine&hostid=49537136-d44f-439a-937c-442ed74bd697&virtualmachineid=385b5edb-b6b2-4931-a4ab-8f9bd96acd14&response=json&sessionkey=3O%2FKhJ6pMFCAfLTZtIqQOY6R6%2F4%3D&_=1376669973550
> 2013-08-17 03:13:59,491 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-178
> = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]
> 2013-08-17 03:13:59,528 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Migrating VM[User|kiran14] to
> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
> : Dest[Zone(3)-Pod(3)-Cluster(6)-Host(11)-Storage()]
> 2013-08-17 03:13:59,529 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ]) Source
> and destination host are not in same cluster, unable to migrate to host: 11
> 2013-08-17 03:13:59,536 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-119:job-178 = [ b9d65e31-7cdf-4ce5-b93c-440287d8523f ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
> com.cloud.utils.exception.CloudRuntimeException: Source and destination host
> are not in same cluster, unable to migrate to host: 11
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1452)
> at
> com.cloud.vm.UserVmManagerImpl.migrateVirtualMachine(UserVmManagerImpl.java:3981)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:147)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAda
[jira] [Closed] (CLOUDSTACK-4146) [upgrade][2.2.13 -> 2.2.14 -> 4.2][KVM] After upgrade creation of volumes from snapshots (which were created before upgrade) is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinav Roy closed CLOUDSTACK-4146.
---
closing the issue after fix validation
> [upgrade][2.2.13 -> 2.2.14 -> 4.2][KVM] After upgrade creation of volumes
> from snapshots (which were created before upgrade) is failing
> ---
>
> Key: CLOUDSTACK-4146
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4146
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Snapshot, Upgrade
>Affects Versions: 4.2.0
> Environment: upgrade from 2.2.13 (rhel 6.1 build) -> 2.2.14 (rhel 6.1
> build) -> 4.2 (rhel 6.2 build)
> MS : CentOS 6.1
> KVM : CentOS 6.1
>Reporter: Abhinav Roy
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: CS-4146.zip
>
>
> steps :
>
> 1. Deploy CS 2.2.13 advanced zone setup with KVM.
> 2. Create VMs, template,snapshots, domains, accounts etc
> 3. Upgrade the management server and agent to 2.2.14
> 4. Create VMs , templates, snapshots, domain, accounts etc.
> 5. Have some VMs in stopped state
> 6. Upgrade the management server and agent to 4.2
> Expected behaviour :
> ===
> After upgrade we should be able to create volumes from the sanpshots which
> were created before upgrade
> Observed behaviour:
> ===
> 1. After upgrade i was able to create volumes from snapshots which were
> create after upgrade
> 2. But creation of volumes from the sanpshots which were created before
> upgrade is failing.
> 2013-08-07 16:38:39,245 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-10:job-65 = [ db7e5dca-3771-4a82-a72d-574c7e96d5e6 ]) copyAsync
> inspecting src type SNAPSHOT copyAsync inspecting dest type VOLUME
> 2013-08-07 16:38:39,264 DEBUG [agent.transport.Request]
> (Job-Executor-10:job-65 = [ db7e5dca-3771-4a82-a72d-574c7e96d5e6 ]) Seq
> 3-1516699752: Sending { Cmd , MgmtId: 226870599129537, via: 3, Ver: v1,
> Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/2/9//snapshots/1/2/9/i-2-9-VM_ROOT-9_20130805162236","volume":{"uuid":"9","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"9fb7c84b-bfff-3ca2-9fc0-f50181c6b1f0","id":201,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/abhinav/kvm-pri2","port":2049}},"name":"ROOT-9","size":8589934592,"path":"c11c7a12-e9c7-495d-955b-6e814bb5b24f","volumeId":9,"vmName":"i-2-9-VM","accountId":2,"format":"QCOW2","id":9,"hypervisorType":"KVM"},"dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/abhinav/kvm-sec-old","_role":"Image"}},"vmName":"i-2-9-VM","name":"i-2-9-VM_ROOT-9_20130805162236","hypervisorType":"KVM","id":2}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e3c99b55-b322-4c67-bef0-0dff0bd50e79","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"9fb7c84b-bfff-3ca2-9fc0-f50181c6b1f0","id":201,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/abhinav/kvm-pri2","port":2049}},"name":"volfromsnap-root7-2213","size":8589934592,"volumeId":34,"accountId":2,"format":"QCOW2","id":34,"hypervisorType":"None"}},"executeInSequence":false,"wait":10800}}]
> }
> 2013-08-07 16:38:39,467 DEBUG [agent.transport.Request]
> (AgentManager-Handler-6:null) Seq 3-1516699752: Processing: { Ans: , MgmtId:
> 226870599129537, via: 3, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: internal error '/bin/mount
> 10.102.192.100:/cpg_vol/abhinav/kvm-sec-old/snapshots/2/9/snapshots/1/2/9
> /mnt/790b44cf-2022-3b27-8270-390d8e309290' exited with non-zero status 32 and
> signal 0: mount.nfs: access denied by server while mounting
> 10.102.192.100:/cpg_vol/abhinav/kvm-sec-old/snapshots/2/9/snapshots/1/2/9\n","wait":0}}]
> }
> 2013-08-07 16:38:39,467 DEBUG [agent.transport.Request]
> (Job-Executor-10:job-65 = [ db7e5dca-3771-4a82-a72d-574c7e96d5e6 ]) Seq
> 3-1516699752: Received: { Ans: , MgmtId: 226870599129537, via: 3, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-07 16:38:39,474 WARN
> [storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-10:job-65 = [
> db7e5dca-3771-4a82-a72d-574c7e96d5e6 ]) Unsupported data object (VOLUME,
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@4dcf4d
[jira] [Closed] (CLOUDSTACK-4147) [upgrade][2.2.13 -> 2.2.14 -> 4.2][KVM] After upgrade, creation of templates from snapshots (which were created before upgrade) is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinav Roy closed CLOUDSTACK-4147.
---
closing the issue after fix validation
> [upgrade][2.2.13 -> 2.2.14 -> 4.2][KVM] After upgrade, creation of templates
> from snapshots (which were created before upgrade) is failing
> --
>
> Key: CLOUDSTACK-4147
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4147
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Snapshot, Upgrade
>Affects Versions: 4.2.0
> Environment: upgrade from 2.2.13 (rhel 6.1 build) -> 2.2.14 (rhel 6.1
> build) -> 4.2 (rhel 6.2 build)
> MS : CentOS 6.1
> KVM : CentOS 6.1
>Reporter: Abhinav Roy
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: CS-4147.zip
>
>
> steps :
>
> 1. Deploy CS 2.2.13 advanced zone setup with KVM.
> 2. Create VMs, template,snapshots, domains, accounts etc
> 3. Upgrade the management server and agent to 2.2.14
> 4. Create VMs , templates, snapshots, domain, accounts etc.
> 5. Have some VMs in stopped state
> 6. Upgrade the management server and agent to 4.2
> Expected behaviour :
> ===
> After upgrade we should be able to create templates from the snapshots which
> were created before upgrade
> Observed behaviour:
> ===
> 1. After upgrade i was able to create templates from snapshots which were
> created after upgrade.
> 2. But creation of templates from the snapshots which were created before
> upgrade is failing.
> 2013-08-07 16:54:05,080 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
> ===END=== 10.144.7.7 -- GET
> command=createTemplate&response=json&sessionkey=JlSNYQnYlmttQqoFIKL%2B%2B3wyyb4%3D&snapshotid=2&name=tempfromsnap-root9-2213&displayText=tempfromsnap-root9-2213&osTypeId=112&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1375874413043
> 2013-08-07 16:54:05,082 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-13:job-68 = [ 26b13614-69a4-4491-aa04-a4b3d3e9c88c ]) Executing
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd for job-68
> = [ 26b13614-69a4-4491-aa04-a4b3d3e9c88c ]
> 2013-08-07 16:54:05,114 DEBUG [storage.image.TemplateDataFactoryImpl]
> (Job-Executor-13:job-68 = [ 26b13614-69a4-4491-aa04-a4b3d3e9c88c ]) template
> 209 is already in store:4, type:Image
> 2013-08-07 16:54:05,124 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-13:job-68 = [ 26b13614-69a4-4491-aa04-a4b3d3e9c88c ]) copyAsync
> inspecting src type SNAPSHOT copyAsync inspecting dest type TEMPLATE
> 2013-08-07 16:54:05,155 DEBUG [agent.transport.Request]
> (Job-Executor-13:job-68 = [ 26b13614-69a4-4491-aa04-a4b3d3e9c88c ]) Seq
> 7-1280901161: Sending { Cmd , MgmtId: 226870599129537, via: 7, Ver: v1,
> Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/2/9//snapshots/1/2/9/i-2-9-VM_ROOT-9_20130805162236","volume":{"uuid":"9","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"9fb7c84b-bfff-3ca2-9fc0-f50181c6b1f0","id":201,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/abhinav/kvm-pri2","port":2049}},"name":"ROOT-9","size":8589934592,"path":"c11c7a12-e9c7-495d-955b-6e814bb5b24f","volumeId":9,"vmName":"i-2-9-VM","accountId":2,"format":"QCOW2","id":9,"hypervisorType":"KVM"},"dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/abhinav/kvm-sec-old","_role":"Image"}},"vmName":"i-2-9-VM","name":"i-2-9-VM_ROOT-9_20130805162236","hypervisorType":"KVM","id":2}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/2/209","uuid":"28e40538-5ce0-492b-8fd6-496c3cb03c2a","id":209,"format":"RAW","accountId":2,"hvm":true,"displayText":"tempfromsnap-root9-2213","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/abhinav/kvm-sec-old","_role":"Image"}},"name":"24f7e0d06-b196-3209-bac2-c13ee9059513","hypervisorType":"KVM"}},"executeInSequence":false,"wait":10800}}]
> }
> 2013-08-07 16:54:05,329 DEBUG [agent.transport.Request]
> (AgentManager-Handler-4:null) Seq 7-1280901161: Processing: { Ans: , MgmtId:
> 226870599129537, via: 7, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"java.lang.NullPointerException\n\tat
>
> com.cloud.storage.template.TemplateLocation.addFormat(TemplateLocation.java:193)\n\tat
>
> org.apache.cloudstack.storag
