[jira] [Commented] (CLOUDSTACK-3489) Failed to start VR due to error in finalizeStart with KVM hypervisor
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826311#comment-13826311
]
Ammar Shareef commented on CLOUDSTACK-3489:
---
We also faced the same issue after we over provisioned RAM in management
settings to a factor of 4. The SSVM and CP RAM was reduced by a factor of 4. So
we reverted back the factor to 1 and the routers started successfully. Let me
know if it helps.
> Failed to start VR due to error in finalizeStart with KVM hypervisor
>
>
> Key: CLOUDSTACK-3489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3489
> 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: Latest build from ACS 4.2 branch.
> Zone: Advanced with KVM cluster
> Stoarage: S3 and Local storage
>Reporter: Sanjeev N
>Assignee: Kishan Kavala
> Fix For: 4.2.0
>
> Attachments: management-server.rar
>
>
> Failed to start VR due to error in finalizeStart with KVM hypervisor:
> KVM routing template being used:
> systemvmtemplate-2013-06-25-master-kvm.qcow2.bz2
> Steps to Reproduce:
>
> 1.Bring up CS in advanced zone with KVM cluster
> 2.Use s3 as the secondary storage and Local storage as the primary storage
> 3.Use default cent os template to deploy guest vm
> Observations:
> ===
> VR was started as part of vm deployment process and it remained in starting
> state for a while. However later it was stopped with following exceptions:
> com.cloud.exception.AgentUnavailableException: Resource [Host:4] is
> unreachable: Host 4: Unable to start instance due to Unable to start
> VM[DomainRouter|r-13-VM] due to error in finalizeStart, not retrying
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:944)
> at
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:557)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2727)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1867)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouter(VirtualNetworkApplianceManagerImpl.java:3124)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouter(VirtualNetworkApplianceManagerImpl.java:3074)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.admin.router.StartRouterCmd.execute(StartRouterCmd.java:110)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> 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:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> Caused by: com.cloud.utils.exception.ExecutionException: Unable to start
> VM[DomainRouter|r-13-VM] due to error in finalizeStart, not retrying
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:911)
> ... 19 more
> 2013-07-12 02:38:24,430 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-8:job-32 = [ c1b6d349-4797-484e-a2e0-dfacce3c6209 ]) Complete
> async job-32 = [ c1b6d349-4797-484e-a2e0-dfacce3c6209 ], jobStatus: 2,
> resultCode: 530, result: Error Code: 530 Error text: Resource [Host:4] is
> unreachable: Host 4: Unable to start instance due to Unable to start
> VM[DomainRouter|r-13-VM] due to error in finalizeStart, not retrying
> Few more log snippets from mgmt server log file:
> 2013-07-12 02:36:21,128 DEBUG [agent.transport.Request]
> (AgentManager-Handler-4:null) Seq 4-691668978: Processing: { Ans: , MgmtId:
> 6615759585382, via: 4, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":13,"name":"r-13-VM","type":"DomainRouter","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (32-bit)","bootArgs":" template=domP name=r-13-VM
> eth2ip=10.147.48.5 eth2mask=255.255.255.0 gateway=10.147.48.1 eth0ip=10.1.1.1
> eth0mask=
[jira] [Created] (CLOUDSTACK-5201) component.test_base_image_updation.TestBaseImageUpdate.test_04_reoccuring_snapshot_rules Failed with "Failed to get snapshots list"
Gaurav Aradhye created CLOUDSTACK-5201: -- Summary: component.test_base_image_updation.TestBaseImageUpdate.test_04_reoccuring_snapshot_rules Failed with "Failed to get snapshots list" Key: CLOUDSTACK-5201 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5201 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.3.0 The test case failed due to schedule in recurring snapshot policy is not defined correctly -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5202) [Hyper-V] Too many mount points created for secondary storage in management server
Sowmya Krishnan created CLOUDSTACK-5202: --- Summary: [Hyper-V] Too many mount points created for secondary storage in management server Key: CLOUDSTACK-5202 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5202 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Storage Controller Environment: 4.3, Hyper-v, Advanced zone Reporter: Sowmya Krishnan Priority: Minor Too many mount points are created in management server after secondary storage has been created. I didn't notice any issues due to this, but it's not very desirable to have too many mounts for any reason. Here's how it is in my current setup: [root@localhost ~]# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/hda1 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.1c876101 type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.10333ac9 type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.3f64ab1b type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.302d837e type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.33ef7f2c type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.47f1b0e5 type cifs (rw,mand) [root@localhost ~]# mysql> select * from image_store\G *** 1. row *** id: 1 name: secondary image_provider_name: NFS protocol: cifs url: cifs://10.102.192.101/sowmya/secondaryhyperv?user=sowmya&password=freebsd@123&domain=BLR data_center_id: 1 scope: ZONE role: Image uuid: 17efa163-1c1a-4e60-ab16-c4a0bf683836 parent: ee32aadd-b9ec-32a4-8242-9b1c7cb5ccf4 created: 2013-11-13 10:49:42 removed: NULL total_size: NULL used_bytes: NULL 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5202) [Hyper-V] Too many mount points created for secondary storage in management server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sowmya Krishnan updated CLOUDSTACK-5202: Description: Too many mount points are created in management server after secondary storage has been created. I didn't notice any issues due to this, but it's not very desirable to have too many mounts for any reason. Here's how it is in my current setup: [root@localhost ~]# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/hda1 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.1c876101 type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.10333ac9 type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.3f64ab1b type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.302d837e type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.33ef7f2c type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.47f1b0e5 type cifs (rw,mand) [root@localhost ~]# mysql> select * from image_store\G *** 1. row *** id: 1 name: secondary image_provider_name: NFS protocol: cifs url: cifs://10.102.192.101/sowmya/secondaryhyperv?user=sowmya&password=&domain=BLR data_center_id: 1 scope: ZONE role: Image uuid: 17efa163-1c1a-4e60-ab16-c4a0bf683836 parent: ee32aadd-b9ec-32a4-8242-9b1c7cb5ccf4 created: 2013-11-13 10:49:42 removed: NULL total_size: NULL used_bytes: NULL 1 row in set (0.00 sec) was: Too many mount points are created in management server after secondary storage has been created. I didn't notice any issues due to this, but it's not very desirable to have too many mounts for any reason. Here's how it is in my current setup: [root@localhost ~]# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/hda1 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.1c876101 type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.10333ac9 type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.3f64ab1b type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.302d837e type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.33ef7f2c type cifs (rw,mand) //10.102.192.101/sowmya/secondaryhyperv on /mnt/64538137909171.47f1b0e5 type cifs (rw,mand) [root@localhost ~]# mysql> select * from image_store\G *** 1. row *** id: 1 name: secondary image_provider_name: NFS protocol: cifs url: cifs://10.102.192.101/sowmya/secondaryhyperv?user=sowmya&password=freebsd@123&domain=BLR data_center_id: 1 scope: ZONE role: Image uuid: 17efa163-1c1a-4e60-ab16-c4a0bf683836 parent: ee32aadd-b9ec-32a4-8242-9b1c7cb5ccf4 created: 2013-11-13 10:49:42 removed: NULL total_size: NULL used_bytes: NULL 1 row in set (0.00 sec) > [Hyper-V] Too many mount points created for secondary storage in management > server > -- > > Key: CLOUDSTACK-5202 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5202 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller > Environment: 4.3, Hyper-v, Advanced zone >Reporter: Sowmya Krishnan >Priority: Minor > Labels: hyper-V, > > Too many mount points are created in management server after secondary > storage has been created. I didn't notice any issues due to this, but it's > not very desirable to have too many mounts for any reason. Here's how it is > in my current setup: > [root@localhost ~]# mount > /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) > proc on /proc
[jira] [Assigned] (CLOUDSTACK-3449) Configuration of Hyper-V System VMs Missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-3449: -- Assignee: Rajesh Battala > Configuration of Hyper-V System VMs Missing > --- > > Key: CLOUDSTACK-3449 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3449 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: Future > Environment: Hyper-V hypervisors >Reporter: Donal Lafferty >Assignee: Rajesh Battala > Labels: bootargs, hyper-V,, systemvm, > > Background: > System VMs are passed their configuration details in the 'bootArgs' field of > the StartCommand used to create and start them. For instance, with > XenServer, the vm.set_PV_args command is used. > When the SystemVM is launched, the cloud-early-config script reads this > information and sets up the system VM accordingly. > Problem: > The current SystemVM does not process its configuration when running on a > Hyper-V hypervisor. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5203) Leverage native XS HA capabilities for user VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das reassigned CLOUDSTACK-5203: --- Assignee: Koushik Das > Leverage native XS HA capabilities for user VMs > --- > > Key: CLOUDSTACK-5203 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5203 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: XS 6.2 and above >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: Future > > > Leverage native XS HA capabilities for user VMs for XS 6.2 and above. System > VMs would still be HAd using `existing CS logic. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5203) Leverage native XS HA capabilities for user VMs
Koushik Das created CLOUDSTACK-5203: --- Summary: Leverage native XS HA capabilities for user VMs Key: CLOUDSTACK-5203 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5203 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: XS 6.2 and above Reporter: Koushik Das Fix For: Future Leverage native XS HA capabilities for user VMs for XS 6.2 and above. System VMs would still be HAd using `existing CS logic. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5204) component.test_routers.TestRouterStopCreatePF.test_01_RouterStopCreatePF fails with SSH connection error
Ashutosk Kelkar created CLOUDSTACK-5204: --- Summary: component.test_routers.TestRouterStopCreatePF.test_01_RouterStopCreatePF fails with SSH connection error Key: CLOUDSTACK-5204 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5204 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Fix For: 4.3.0 The test case failed with SSH Access failed for 10.x.x.x: SSH connection has Failed. Waited 600s. Error is Connection Failed -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5198) Cannot register SSH key through the ReST API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe updated CLOUDSTACK-5198: --- Priority: Minor (was: Critical) Issue Type: Improvement (was: Bug) > Cannot register SSH key through the ReST API > > > Key: CLOUDSTACK-5198 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5198 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.1.0 >Reporter: Christophe >Priority: Minor > > I get a strange error with CS 4.1: User Key Error : Received value for > parameter publickey is invalid, contains illegal ASCII non-printable > characters > I used that with CS 3. Is there any issue about ssk key registration through > the rest API? > It looks like the problem was introduced by > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ed06c16 and quite > similar to https://issues.apache.org/jira/browse/CLOUDSTACK-3362. > Thanks for any help (fix, workaround), > Christophe. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5198) Cannot register SSH key through the ReST API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826481#comment-13826481 ] Christophe commented on CLOUDSTACK-5198: I got the problem the publickey sent had a carriage return character at the end. This character caused the error. Checking keys to remove carriage returns before sending solves the problem. Should carriage returns be also managed by CloudStack API? > Cannot register SSH key through the ReST API > > > Key: CLOUDSTACK-5198 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5198 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.1.0 >Reporter: Christophe >Priority: Critical > > I get a strange error with CS 4.1: User Key Error : Received value for > parameter publickey is invalid, contains illegal ASCII non-printable > characters > I used that with CS 3. Is there any issue about ssk key registration through > the rest API? > It looks like the problem was introduced by > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ed06c16 and quite > similar to https://issues.apache.org/jira/browse/CLOUDSTACK-3362. > Thanks for any help (fix, workaround), > Christophe. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4585) [VMWare] [Upgrade] Failed to start instance after reverting the VM snapshot on a Private Zone which was created prior to upgrade
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti closed CLOUDSTACK-4585.
> [VMWare] [Upgrade] Failed to start instance after reverting the VM snapshot
> on a Private Zone which was created prior to upgrade
> -
>
> Key: CLOUDSTACK-4585
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4585
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot
>Affects Versions: 4.2.1
>Reporter: Sudha Ponnaganti
>Assignee: Kelven Yang
>Priority: Blocker
> Fix For: 4.2.1
>
>
> I have an upgraded setup from 307 Patch B to 4.2 . I have one VMWARE private
> zone before upgrade.
>
> After upgrade I created VM snapshot for one of the instance In this zone.
> Later reverted to this VM snapshot. Now VM’s are failing to start saying
> “Unable to create a deployment for VM[User|host13i1], Please check the
> affinity groups provided, there may not be sufficient capacity to follow them”
>
>
> =
>
>
> 2013-08-31 20:33:16,949 WARN [vmware.resource.VmwareResource]
> (DirectAgent-452:10.102.192.13) StartCommand failed due to Exception:
> java.lang.RuntimeException
> Message: Invalid configuration for device '0'.
>
> java.lang.RuntimeException: Invalid configuration for device '0'.
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:835)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.tearDownDevices(VirtualMachineMO.java:1643)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2675)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:519)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> 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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> 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)
> 2013-08-31 20:33:16,952 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-452:null) Seq 12-1859846507: Response Received:
> 2013-08-31 20:33:16,953 DEBUG [agent.transport.Request]
> (DirectAgent-452:null) Seq 12-1859846507: Processing: { Ans: , MgmtId:
> 227594284004867, via: 12, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":38,"name":"i-3-38-VM","bootloader":"HVM","type":"User","cpus":1,"minSpeed":200,"maxSpeed":200,"minRam":536870912,"maxRam":536870912,"hostName":"host13i1","arch":"x86_64","os":"CentOS
> 5.3
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"425de971cf2ec463","params":{"nicAdapter":"E1000","vmware.reserve.cpu":"false","nestedVirtualizationFlag":"false","Message.ReservedCapacityFreed.Flag":"false","rootDiskController":"ide","vmware.reserve.mem":"false"},"uuid":"d51c5b43-0201-4095-8b4c-643df2b2f4e2","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"499111c0-9bb3-4921-a370-0c8f5de8579b","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"5bf1f4d7-b301-39f1-85dc-c0af114d68b4","id":203,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/zwps1","port":2049}},"name":"ROOT-38","size":2147483648,"path":"ROOT-38-03","volumeId":47,"vmName":"i-3-38-VM","accountId":3,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[5bf1f4d7b30139f185dcc0af114d68b4]
> i-3-38-VM/ROOT-38.vmdk\",\"[5bf1f4d7b30139f185dcc0af114d68b4]
> 56c533304ae43a5dbba19a88ee7cea6c/56c533304ae43a5dbba19a88ee7cea6c.vmdk\"]}","format":"OVA","id":47,"hypervisorType":"VMware"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRate
[jira] [Assigned] (CLOUDSTACK-4856) Optimize on the # of control commands sent by MS to HV host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang reassigned CLOUDSTACK-4856: -- Assignee: Sheng Yang > Optimize on the # of control commands sent by MS to HV host > --- > > Key: CLOUDSTACK-4856 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4856 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: pre-4.0.0, 4.1.0, 4.2.0 >Reporter: Koushik Das >Assignee: Sheng Yang > Fix For: 4.3.0 > > > This is a placeholder bug for all control commands whose count can be > minimized by doing some optimisation. > 1. CheckRouterCommand > This is used for checking status of redundant VR and is send for each router > at regular intervals. Instead of sending individual commands to each VR, > these can be batched for all routers residing on the same host. > This is a general idea and can be extended to other such commands as well. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4856) Optimize on the # of control commands sent by MS to HV host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826700#comment-13826700 ] Sheng Yang commented on CLOUDSTACK-4856: A pair of RvR would be distributed on different hosts, and only update one host at time would likely cause chaos in consistency of RvR status. E.g. The switch over happen, and the first host contained old BACKUP which already switch to the MASTER. Then the update status of the host would return MASTER. At this time, we haven't updated host of the old MASTER yet, so we don't know if the states of RvR are both up to date. And we would see two MASTER in the network as the result. That's the reason why we always update one pair of RvR(not individually one of them), which we can know after update complete, we would know the latest status of RvR in the network. This make things more simple. > Optimize on the # of control commands sent by MS to HV host > --- > > Key: CLOUDSTACK-4856 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4856 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: pre-4.0.0, 4.1.0, 4.2.0 >Reporter: Koushik Das > Fix For: 4.3.0 > > > This is a placeholder bug for all control commands whose count can be > minimized by doing some optimisation. > 1. CheckRouterCommand > This is used for checking status of redundant VR and is send for each router > at regular intervals. Instead of sending individual commands to each VR, > these can be batched for all routers residing on the same host. > This is a general idea and can be extended to other such commands as well. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-2140) Host is still marked as being in "Up" state when the host is shutdown (when there are no more hosts in the cluster)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-2140:
Component/s: Management Server
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster)
> ---
>
> Key: CLOUDSTACK-2140
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2140
> 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, 4.2.1
> Environment: build from master
>Reporter: Sangeetha Hariharan
>Assignee: Koushik Das
> Fix For: Future
>
> Attachments: management-server.rar
>
>
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster.
> Set up:
> Advanced zone.
> 3 hosts in a cluster ( in my case host id - 7 ,8 ,9 ).
> I did not have any problems when host 8 and host 9 where shutdown.
> When I tried to shutdown host 7 , I see the host still being in "Up" state ,
> even after the management server detected that it is not able to connect with
> this host.
> Following exception seen in management server logs:
> 2013-04-22 14:48:18,350 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-350:null) localLogout has problem Failed to read server's
> response: connect timed out
> 2013-04-22 14:48:18,350 WARN [xen.resource.CitrixResourceBase]
> (DirectAgent-350:null) Unable to stop i-3-45-VM due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
> slave 10.223.59.4 to 10.223.59.2 due to org.apache.xmlrpc.XmlRpcException:
> Failed to read server's response: connect timed out
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5583)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:3728)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:474)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> 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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> 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)
> 2013-04-22 14:48:18,364 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-350:null) Seq 9-72160431: Response Received:
> 2013-04-22 14:48:18,370 DEBUG [agent.transport.Request]
> (DirectAgent-350:null) Seq 9-72160431: Processing: { Ans: , MgmtId:
> 7508777239729, via: 9, Ver: v1, Flags: 110,
> [{"StopAnswer":{"result":false,"details":"Exception:
> com.cloud.utils.exception.CloudRuntimeException\nMessage: Unable to reset
> master of slave 10.223.59.4 to 10.223.59.2 due to
> org.apache.xmlrpc.XmlRpcException: Failed to read server's response: connect
> timed out\nStack: com.cloud.utils.exception.CloudRuntimeException: Unable to
> reset master of slave 10.223.59.4 to 10.223.59.2 due to
> org.apache.xmlrpc.XmlRpcException: Failed to read server's response: connect
> timed out\n\tat
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5583)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:3728)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:474)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenS
[jira] [Commented] (CLOUDSTACK-2140) Host is still marked as being in "Up" state when the host is shutdown (when there are no more hosts in the cluster)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826803#comment-13826803
]
Sangeetha Hariharan commented on CLOUDSTACK-2140:
-
I see the same issue when I was testing the following use case:
Basic Zone with 2 Xenserver 6.2 hosts in cluster.
In my case , both the hosts rebooted at the same time ( probably because of a
failed heartbeat to storage).
The hosts in the management server continued to be in "Up" state.
But the Vms were marked as being in "Stopped" state by Vm sync.
When I tried to strat the VMs , the Vms were started successfully. But we were
not able to program any SG rules, Following exception seen in management server
logs:
2013-11-18 19:54:56,816 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-278:null) callHostPlugin failed for cmd: network_rules with args
seqno: 4, vmIP: 10.223.50.223, deflated: true, secIps: 0:, vmID: 60, vmMAC:
06:d1:2c:00:00:1c, vmName: i-2-60-VM, rules:
eJzztMpMzi2w0jUEIQM9MNQ30PFzjQhR8LQqSS6wMrSyNDAwwJQrTcElBwBskRQZ, signature:
8ccf4bc05a5c732547c37605cb869041, due to There was a failure communicating
with the plugin.
2013-11-18 19:54:56,817 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-278:null) Seq 4-891945632: Exception Caught while executing command
com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for cmd:
network_rules with args seqno: 4, vmIP: 10.223.50.223, deflated: true, secIps:
0:, vmID: 60, vmMAC: 06:d1:2c:00:00:1c, vmName: i-2-60-VM, rules:
eJzztMpMzi2w0jUEIQM9MNQ30PFzjQhR8LQqSS6wMrSyNDAwwJQrTcElBwBskRQZ, signature:
8ccf4bc05a5c732547c37605cb869041, due to There was a failure communicating
with the plugin.
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4181)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5775)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:565)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
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)
2013-11-18 19:54:56,818 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-278:null) Seq 4-891945632: Response Received:
2013-11-18 19:54:56,818 DEBUG [agent.transport.Request] (DirectAgent-278:null)
Seq 4-891945632: Processing: { Ans: , MgmtId: 7261447522054, via: 4, Ver: v1,
Flags: 110,
[{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
callHostPlugin failed for cmd: network_rules with args seqno: 4, vmIP:
10.223.50.223, deflated: true, secIps: 0:, vmID: 60, vmMAC: 06:d1:2c:00:00:1c,
vmName: i-2-60-VM, rules:
eJzztMpMzi2w0jUEIQM9MNQ30PFzjQhR8LQqSS6wMrSyNDAwwJQrTcElBwBskRQZ, signature:
8ccf4bc05a5c732547c37605cb869041, due to There was a failure communicating
with the plugin.","wait":0}}] }
The workaround for this case was to force reconnect the hosts and once again
stop and start all the Vms.
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster)
> ---
>
> Key: CLOUDSTACK-2140
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2140
> 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, 4.2.1
> Environment: build from master
>Reporter: Sangeetha Hariharan
>Assignee: Koushik Das
> Fix For: Future
>
> Attachments: management-server.rar
>
>
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster.
> Set up:
> Advanced zone.
> 3 hosts in a cluster ( in my case hos
[jira] [Updated] (CLOUDSTACK-2140) Host is still marked as being in "Up" state when the host is shutdown (when there are no more hosts in the cluster)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-2140:
Priority: Critical (was: Major)
Bumping up the priority of this issue , since in case of basic zone we actually
see failures in programming the SG rules when Vms are started after both the
hosts in a cluster get rebooted at the same time.
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster)
> ---
>
> Key: CLOUDSTACK-2140
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2140
> 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, 4.2.1
> Environment: build from master
>Reporter: Sangeetha Hariharan
>Assignee: Koushik Das
>Priority: Critical
> Fix For: Future
>
> Attachments: management-server.rar
>
>
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster.
> Set up:
> Advanced zone.
> 3 hosts in a cluster ( in my case host id - 7 ,8 ,9 ).
> I did not have any problems when host 8 and host 9 where shutdown.
> When I tried to shutdown host 7 , I see the host still being in "Up" state ,
> even after the management server detected that it is not able to connect with
> this host.
> Following exception seen in management server logs:
> 2013-04-22 14:48:18,350 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-350:null) localLogout has problem Failed to read server's
> response: connect timed out
> 2013-04-22 14:48:18,350 WARN [xen.resource.CitrixResourceBase]
> (DirectAgent-350:null) Unable to stop i-3-45-VM due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
> slave 10.223.59.4 to 10.223.59.2 due to org.apache.xmlrpc.XmlRpcException:
> Failed to read server's response: connect timed out
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5583)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:3728)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:474)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> 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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> 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)
> 2013-04-22 14:48:18,364 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-350:null) Seq 9-72160431: Response Received:
> 2013-04-22 14:48:18,370 DEBUG [agent.transport.Request]
> (DirectAgent-350:null) Seq 9-72160431: Processing: { Ans: , MgmtId:
> 7508777239729, via: 9, Ver: v1, Flags: 110,
> [{"StopAnswer":{"result":false,"details":"Exception:
> com.cloud.utils.exception.CloudRuntimeException\nMessage: Unable to reset
> master of slave 10.223.59.4 to 10.223.59.2 due to
> org.apache.xmlrpc.XmlRpcException: Failed to read server's response: connect
> timed out\nStack: com.cloud.utils.exception.CloudRuntimeException: Unable to
> reset master of slave 10.223.59.4 to 10.223.59.2 due to
> org.apache.xmlrpc.XmlRpcException: Failed to read server's response: connect
> timed out\n\tat
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5583)\n\tat
>
> com
[jira] [Assigned] (CLOUDSTACK-2140) Host is still marked as being in "Up" state when the host is shutdown (when there are no more hosts in the cluster)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan reassigned CLOUDSTACK-2140:
---
Assignee: Anthony Xu (was: Koushik Das)
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster)
> ---
>
> Key: CLOUDSTACK-2140
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2140
> 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, 4.2.1
> Environment: build from master
>Reporter: Sangeetha Hariharan
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: Future
>
> Attachments: management-server.rar
>
>
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster.
> Set up:
> Advanced zone.
> 3 hosts in a cluster ( in my case host id - 7 ,8 ,9 ).
> I did not have any problems when host 8 and host 9 where shutdown.
> When I tried to shutdown host 7 , I see the host still being in "Up" state ,
> even after the management server detected that it is not able to connect with
> this host.
> Following exception seen in management server logs:
> 2013-04-22 14:48:18,350 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-350:null) localLogout has problem Failed to read server's
> response: connect timed out
> 2013-04-22 14:48:18,350 WARN [xen.resource.CitrixResourceBase]
> (DirectAgent-350:null) Unable to stop i-3-45-VM due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
> slave 10.223.59.4 to 10.223.59.2 due to org.apache.xmlrpc.XmlRpcException:
> Failed to read server's response: connect timed out
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5583)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:3728)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:474)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> 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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> 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)
> 2013-04-22 14:48:18,364 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-350:null) Seq 9-72160431: Response Received:
> 2013-04-22 14:48:18,370 DEBUG [agent.transport.Request]
> (DirectAgent-350:null) Seq 9-72160431: Processing: { Ans: , MgmtId:
> 7508777239729, via: 9, Ver: v1, Flags: 110,
> [{"StopAnswer":{"result":false,"details":"Exception:
> com.cloud.utils.exception.CloudRuntimeException\nMessage: Unable to reset
> master of slave 10.223.59.4 to 10.223.59.2 due to
> org.apache.xmlrpc.XmlRpcException: Failed to read server's response: connect
> timed out\nStack: com.cloud.utils.exception.CloudRuntimeException: Unable to
> reset master of slave 10.223.59.4 to 10.223.59.2 due to
> org.apache.xmlrpc.XmlRpcException: Failed to read server's response: connect
> timed out\n\tat
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5583)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:3728)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:474)\n\t
[jira] [Created] (CLOUDSTACK-5205) System vm startup scripts calculate jvm memory wrong
John E Vincent created CLOUDSTACK-5205: -- Summary: System vm startup scripts calculate jvm memory wrong Key: CLOUDSTACK-5205 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5205 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Reporter: John E Vincent While attempting to provision beefier system vms, we discovered this bug. The `_run.sh` script in the system vm calculates jvm memory based on 80% of the total memory on the system. This is great up until the point 80% of memory goes above ~1.9G. The system vm templates are all 32-bit and so calculating the size too high will cause the agent jvm to fail to start. The fix is pretty simple with a final sanity check: if [ $maxmem -gt 1900 ] then maxmem=1900 fi -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-2140) Host is still marked as being in "Up" state when the host is shutdown (when there are no more hosts in the cluster)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Xu reassigned CLOUDSTACK-2140:
--
Assignee: (was: Anthony Xu)
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster)
> ---
>
> Key: CLOUDSTACK-2140
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2140
> 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, 4.2.1
> Environment: build from master
>Reporter: Sangeetha Hariharan
>Priority: Critical
> Fix For: Future
>
> Attachments: management-server.rar
>
>
> Host is still marked as being in "Up" state when the host is shutdown (when
> there are no more hosts in the cluster.
> Set up:
> Advanced zone.
> 3 hosts in a cluster ( in my case host id - 7 ,8 ,9 ).
> I did not have any problems when host 8 and host 9 where shutdown.
> When I tried to shutdown host 7 , I see the host still being in "Up" state ,
> even after the management server detected that it is not able to connect with
> this host.
> Following exception seen in management server logs:
> 2013-04-22 14:48:18,350 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-350:null) localLogout has problem Failed to read server's
> response: connect timed out
> 2013-04-22 14:48:18,350 WARN [xen.resource.CitrixResourceBase]
> (DirectAgent-350:null) Unable to stop i-3-45-VM due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
> slave 10.223.59.4 to 10.223.59.2 due to org.apache.xmlrpc.XmlRpcException:
> Failed to read server's response: connect timed out
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5583)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:3728)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:474)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> 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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> 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)
> 2013-04-22 14:48:18,364 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-350:null) Seq 9-72160431: Response Received:
> 2013-04-22 14:48:18,370 DEBUG [agent.transport.Request]
> (DirectAgent-350:null) Seq 9-72160431: Processing: { Ans: , MgmtId:
> 7508777239729, via: 9, Ver: v1, Flags: 110,
> [{"StopAnswer":{"result":false,"details":"Exception:
> com.cloud.utils.exception.CloudRuntimeException\nMessage: Unable to reset
> master of slave 10.223.59.4 to 10.223.59.2 due to
> org.apache.xmlrpc.XmlRpcException: Failed to read server's response: connect
> timed out\nStack: com.cloud.utils.exception.CloudRuntimeException: Unable to
> reset master of slave 10.223.59.4 to 10.223.59.2 due to
> org.apache.xmlrpc.XmlRpcException: Failed to read server's response: connect
> timed out\n\tat
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5583)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:3728)\n\tat
>
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:474)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServer56Resourc
[jira] [Commented] (CLOUDSTACK-4793) Improve VR Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827034#comment-13827034 ] ASF subversion and git services commented on CLOUDSTACK-4793: - Commit 2dcb3ca1aa084391eb8c511c36cc6921b2b7b26c in branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2dcb3ca ] CLOUDSTACK-4793: UI > Virtual Routers > add new action "Upgrade Router to Newer Template" on top of listView. > Improve VR Upgrade > -- > > Key: CLOUDSTACK-4793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.3.0 > > Attachments: jessica_UI_change_1.jpg, jessica_UI_change_2.jpg > > > Give admin control to sequence the upgrade of the cloud by: > Infrastructure hierarchy: by Cluster, Pod, and Zone etc. > Administrative hierarchy: by Tenant or Domain > Minimize service interruption to users > Improve the speed of the upgrade time by making as many upgrade operations in > parallel as possible -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4793) Improve VR Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827035#comment-13827035 ] ASF subversion and git services commented on CLOUDSTACK-4793: - Commit d6a38c238a32a60d2838a6f9a0863480a3609788 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d6a38c2 ] CLOUDSTACK-4793: UI > Virtual Routers > add new action "Upgrade Router to Newer Template" on top of listView. > Improve VR Upgrade > -- > > Key: CLOUDSTACK-4793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.3.0 > > Attachments: jessica_UI_change_1.jpg, jessica_UI_change_2.jpg > > > Give admin control to sequence the upgrade of the cloud by: > Infrastructure hierarchy: by Cluster, Pod, and Zone etc. > Administrative hierarchy: by Tenant or Domain > Minimize service interruption to users > Improve the speed of the upgrade time by making as many upgrade operations in > parallel as possible -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4793) Improve VR Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-4793: - Attachment: UI_change_upgradeRouter_5B.jpg UI_change_upgradeRouter_5.jpg UI_change_upgradeRouter_4C_if_error_happens.jpg UI_change_upgradeRouter_4B.jpg UI_change_upgradeRouter_4.jpg UI_change_upgradeRouter_3D_if_error_happens.jpg UI_change_upgradeRouter_3C_if_error_happens.jpg UI_change_upgradeRouter_3B.jpg UI_change_upgradeRouter_3.jpg UI_change_upgradeRouter_2B.jpg UI_change_upgradeRouter_2.jpg UI_change_upgradeRouter_1.jpg > Improve VR Upgrade > -- > > Key: CLOUDSTACK-4793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.3.0 > > Attachments: UI_change_upgradeRouter_1.jpg, > UI_change_upgradeRouter_2.jpg, UI_change_upgradeRouter_2B.jpg, > UI_change_upgradeRouter_3.jpg, UI_change_upgradeRouter_3B.jpg, > UI_change_upgradeRouter_3C_if_error_happens.jpg, > UI_change_upgradeRouter_3D_if_error_happens.jpg, > UI_change_upgradeRouter_4.jpg, UI_change_upgradeRouter_4B.jpg, > UI_change_upgradeRouter_4C_if_error_happens.jpg, > UI_change_upgradeRouter_5.jpg, UI_change_upgradeRouter_5B.jpg, > jessica_UI_change_1.jpg, jessica_UI_change_2.jpg > > > Give admin control to sequence the upgrade of the cloud by: > Infrastructure hierarchy: by Cluster, Pod, and Zone etc. > Administrative hierarchy: by Tenant or Domain > Minimize service interruption to users > Improve the speed of the upgrade time by making as many upgrade operations in > parallel as possible -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4793) Improve VR Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-4793: - Attachment: jessica-log-2013-11-19.tar.gz jessica-database-dump-2013-11-19.sql > Improve VR Upgrade > -- > > Key: CLOUDSTACK-4793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.3.0 > > Attachments: UI_change_upgradeRouter_1.jpg, > UI_change_upgradeRouter_2.jpg, UI_change_upgradeRouter_2B.jpg, > UI_change_upgradeRouter_3.jpg, UI_change_upgradeRouter_3B.jpg, > UI_change_upgradeRouter_3C_if_error_happens.jpg, > UI_change_upgradeRouter_3D_if_error_happens.jpg, > UI_change_upgradeRouter_4.jpg, UI_change_upgradeRouter_4B.jpg, > UI_change_upgradeRouter_4C_if_error_happens.jpg, > UI_change_upgradeRouter_5.jpg, UI_change_upgradeRouter_5B.jpg, > jessica-database-dump-2013-11-19.sql, jessica-log-2013-11-19.tar.gz, > jessica_UI_change_1.jpg, jessica_UI_change_2.jpg > > > Give admin control to sequence the upgrade of the cloud by: > Infrastructure hierarchy: by Cluster, Pod, and Zone etc. > Administrative hierarchy: by Tenant or Domain > Minimize service interruption to users > Improve the speed of the upgrade time by making as many upgrade operations in > parallel as possible -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (CLOUDSTACK-4793) Improve VR Upgrade
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang reopened CLOUDSTACK-4793:
--
Kishan,
Sending zoneid or podid to upgradeRouterTemplate API does get asyncjobs back,
but sending clusterid to upgradeRouterTemplate API does NOT get asyncjobs back:
http://10.215.3.26:8080/client/api?command=upgradeRouterTemplate&response=json&sessionkey=5ODyEIpK15MAvFVuhEvJgcmeWUs%3D&zoneid=3bfdd7d1-134a-4d75-8621-0ccfc8641660&_=1384900590465
{
"upgraderoutertemplateresponse": {
"count": 3,
"asyncjobs": [
{
"jobid": "6082b528-e424-49ce-83ab-9e05aab62ce7"
},
{
"jobid": "c1b33ea9-a228-4cff-b098-ce97011424d5"
},
{
"jobid": "8f290e2a-7318-4440-b248-bc65df896bf1"
}
]
}
}
http://10.215.3.26:8080/client/api?command=upgradeRouterTemplate&response=json&sessionkey=5ODyEIpK15MAvFVuhEvJgcmeWUs%3D&podid=43838533-65b8-42b4-a91e-83ee9ef31fd6&_=1384900636903
{
"upgraderoutertemplateresponse": {
"count": 3,
"asyncjobs": [
{
"jobid": "4f65e1ea-fbbc-40ef-a130-044a44857e5e"
},
{
"jobid": "f79f2b1d-eb79-41cb-a795-14af869d1bc9"
},
{
"jobid": "9d92b383-e324-428c-bc54-3044a01a5dbf"
}
]
}
}
http://10.215.3.26:8080/client/api?command=upgradeRouterTemplate&response=json&sessionkey=5ODyEIpK15MAvFVuhEvJgcmeWUs%3D&clusterid=602ea7f9-1b2f-47f2-be41-975594bc55f3&_=1384899940848
{
"upgraderoutertemplateresponse": {}
}
You can get my UI change (as attached screenshots
"UI_change_upgradeRouter_xxx") in latest code of 4.3 branch.
I also attached my database dump(jessica-database-dump-2013-11-19.sql) and log
files(jessica-log-2013-11-19.tzr.gz).
Jessica
> Improve VR Upgrade
> --
>
> Key: CLOUDSTACK-4793
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Kishan Kavala
>Assignee: Kishan Kavala
> Fix For: 4.3.0
>
> Attachments: UI_change_upgradeRouter_1.jpg,
> UI_change_upgradeRouter_2.jpg, UI_change_upgradeRouter_2B.jpg,
> UI_change_upgradeRouter_3.jpg, UI_change_upgradeRouter_3B.jpg,
> UI_change_upgradeRouter_3C_if_error_happens.jpg,
> UI_change_upgradeRouter_3D_if_error_happens.jpg,
> UI_change_upgradeRouter_4.jpg, UI_change_upgradeRouter_4B.jpg,
> UI_change_upgradeRouter_4C_if_error_happens.jpg,
> UI_change_upgradeRouter_5.jpg, UI_change_upgradeRouter_5B.jpg,
> jessica-database-dump-2013-11-19.sql, jessica-log-2013-11-19.tar.gz,
> jessica_UI_change_1.jpg, jessica_UI_change_2.jpg
>
>
> Give admin control to sequence the upgrade of the cloud by:
> Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
> Administrative hierarchy: by Tenant or Domain
> Minimize service interruption to users
> Improve the speed of the upgrade time by making as many upgrade operations in
> parallel as possible
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-5206) Admin should have the ability to control the external facing id of their resources
Nitin Mehta created CLOUDSTACK-5206: --- Summary: Admin should have the ability to control the external facing id of their resources Key: CLOUDSTACK-5206 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5206 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: Future -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5206) Admin should have the ability to control the external facing id of their resources
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827071#comment-13827071 ] Nitin Mehta commented on CLOUDSTACK-5206: - Admin should have the ability to control the external facing id of their resources (first class objects). This is important say in case of emergencies when he/she wants to recover their resources. For this I propose that all the resource creation/updation API's need to be altered to take in the custom resource id in case the admin wants a custom id. Please note following for the custom ids :- This is an optional field and if not set, CS will use its custom logic to assign the resource id. They have to be unique for the particular type of resource. They will have to follow the UUID format. This is external Id change only and MS refers to all the objects through the DB ids > Admin should have the ability to control the external facing id of their > resources > -- > > Key: CLOUDSTACK-5206 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5206 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4793) Improve VR Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827158#comment-13827158 ] ASF subversion and git services commented on CLOUDSTACK-4793: - Commit a4d6c10cbea5616992461403f4f8ea7429f0747a in branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4d6c10 ] CLOUDSTACK-4793: UI > Virtual Routers > add new action "Upgrade Router to Newer Template" in detailView. > Improve VR Upgrade > -- > > Key: CLOUDSTACK-4793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.3.0 > > Attachments: UI_change_upgradeRouter_1.jpg, > UI_change_upgradeRouter_2.jpg, UI_change_upgradeRouter_2B.jpg, > UI_change_upgradeRouter_3.jpg, UI_change_upgradeRouter_3B.jpg, > UI_change_upgradeRouter_3C_if_error_happens.jpg, > UI_change_upgradeRouter_3D_if_error_happens.jpg, > UI_change_upgradeRouter_4.jpg, UI_change_upgradeRouter_4B.jpg, > UI_change_upgradeRouter_4C_if_error_happens.jpg, > UI_change_upgradeRouter_5.jpg, UI_change_upgradeRouter_5B.jpg, > UI_change_upgradeSingleRouter_1.jpg, UI_change_upgradeSingleRouter_2.jpg, > UI_change_upgradeSingleRouter_3.jpg, > UI_change_upgradeSingleRouter_4_if_error_happens.jpg, > UI_change_upgradeSingleRouter_5_if_error_happens.jpg, > jessica-database-dump-2013-11-19.sql, jessica-log-2013-11-19.tar.gz, > jessica_UI_change_1.jpg, jessica_UI_change_2.jpg > > > Give admin control to sequence the upgrade of the cloud by: > Infrastructure hierarchy: by Cluster, Pod, and Zone etc. > Administrative hierarchy: by Tenant or Domain > Minimize service interruption to users > Improve the speed of the upgrade time by making as many upgrade operations in > parallel as possible -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4793) Improve VR Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827161#comment-13827161 ] ASF subversion and git services commented on CLOUDSTACK-4793: - Commit 829f1db6e8c2d28a032c49b0a2a69b4cfe7dbfdd in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=829f1db ] CLOUDSTACK-4793: UI > Virtual Routers > add new action "Upgrade Router to Newer Template" in detailView. > Improve VR Upgrade > -- > > Key: CLOUDSTACK-4793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.3.0 > > Attachments: UI_change_upgradeRouter_1.jpg, > UI_change_upgradeRouter_2.jpg, UI_change_upgradeRouter_2B.jpg, > UI_change_upgradeRouter_3.jpg, UI_change_upgradeRouter_3B.jpg, > UI_change_upgradeRouter_3C_if_error_happens.jpg, > UI_change_upgradeRouter_3D_if_error_happens.jpg, > UI_change_upgradeRouter_4.jpg, UI_change_upgradeRouter_4B.jpg, > UI_change_upgradeRouter_4C_if_error_happens.jpg, > UI_change_upgradeRouter_5.jpg, UI_change_upgradeRouter_5B.jpg, > UI_change_upgradeSingleRouter_1.jpg, UI_change_upgradeSingleRouter_2.jpg, > UI_change_upgradeSingleRouter_3.jpg, > UI_change_upgradeSingleRouter_4_if_error_happens.jpg, > UI_change_upgradeSingleRouter_5_if_error_happens.jpg, > jessica-database-dump-2013-11-19.sql, jessica-log-2013-11-19.tar.gz, > jessica_UI_change_1.jpg, jessica_UI_change_2.jpg > > > Give admin control to sequence the upgrade of the cloud by: > Infrastructure hierarchy: by Cluster, Pod, and Zone etc. > Administrative hierarchy: by Tenant or Domain > Minimize service interruption to users > Improve the speed of the upgrade time by making as many upgrade operations in > parallel as possible -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4793) Improve VR Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-4793: - Attachment: UI_change_upgradeSingleRouter_5_if_error_happens.jpg UI_change_upgradeSingleRouter_4_if_error_happens.jpg UI_change_upgradeSingleRouter_3.jpg UI_change_upgradeSingleRouter_2.jpg UI_change_upgradeSingleRouter_1.jpg > Improve VR Upgrade > -- > > Key: CLOUDSTACK-4793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.3.0 > > Attachments: UI_change_upgradeRouter_1.jpg, > UI_change_upgradeRouter_2.jpg, UI_change_upgradeRouter_2B.jpg, > UI_change_upgradeRouter_3.jpg, UI_change_upgradeRouter_3B.jpg, > UI_change_upgradeRouter_3C_if_error_happens.jpg, > UI_change_upgradeRouter_3D_if_error_happens.jpg, > UI_change_upgradeRouter_4.jpg, UI_change_upgradeRouter_4B.jpg, > UI_change_upgradeRouter_4C_if_error_happens.jpg, > UI_change_upgradeRouter_5.jpg, UI_change_upgradeRouter_5B.jpg, > UI_change_upgradeSingleRouter_1.jpg, UI_change_upgradeSingleRouter_2.jpg, > UI_change_upgradeSingleRouter_3.jpg, > UI_change_upgradeSingleRouter_4_if_error_happens.jpg, > UI_change_upgradeSingleRouter_5_if_error_happens.jpg, > jessica-database-dump-2013-11-19.sql, jessica-log-2013-11-19.tar.gz, > jessica_UI_change_1.jpg, jessica_UI_change_2.jpg > > > Give admin control to sequence the upgrade of the cloud by: > Infrastructure hierarchy: by Cluster, Pod, and Zone etc. > Administrative hierarchy: by Tenant or Domain > Minimize service interruption to users > Improve the speed of the upgrade time by making as many upgrade operations in > parallel as possible -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4693) UI - "Add guest Network" from Network page - Should list only physical network that has guest traffic type.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan closed CLOUDSTACK-4693.
---
Tested with latest build from 4.2.1.
Created a zone with 3 physical networks:
network1 had management and storage traffic
network2 had public traffic
network3 had guest traffic
When trying to create a network for the above zone , only network3 was listed
in the Physical Network drop down,
Following are the API calls made by UI:
http://10.223.195.103:8080/client/api?command=listPhysicalNetworks&response=json&sessionkey=34IhnepKGK%2FKr85g8QOuzGUv7c8%3D&zoneid=3dc05f1d-dc74-4aae-b9ee-38773cd6eee0&_=1384909053125
{ "listphysicalnetworksresponse" : { "count":3 ,"physicalnetwork" : [
{"id":"f46e58c5-5b39-4e0d-a5e4-7df1a24f9dcd","name":"Physical Network
1","broadcastdomainrange":"ZONE","zoneid":"3dc05f1d-dc74-4aae-b9ee-38773cd6eee0","state":"Enabled","isolationmethods":"VLAN"},
{"id":"d261ab59-cc6f-4d4c-9899-32fda03dbe7d","name":"Physical Network
2","broadcastdomainrange":"ZONE","zoneid":"3dc05f1d-dc74-4aae-b9ee-38773cd6eee0","state":"Enabled","isolationmethods":"VLAN"},
{"id":"7340060e-aef2-4bc2-9bed-2fc3001f177a","name":"Physical Network
3","broadcastdomainrange":"ZONE","zoneid":"3dc05f1d-dc74-4aae-b9ee-38773cd6eee0","state":"Enabled","vlan":"12-15","isolationmethods":"VLAN"}
] } }
http://10.223.195.103:8080/client/api?command=listTrafficTypes&response=json&sessionkey=34IhnepKGK%2FKr85g8QOuzGUv7c8%3D&physicalnetworkid=f46e58c5-5b39-4e0d-a5e4-7df1a24f9dcd&_=1384909053251
{ "listtraffictypesresponse" : { "count":2 ,"traffictype" : [
{"id":"b48fd451-c609-4c4a-8e7a-b7e282b9f12c","traffictype":"Management","physicalnetworkid":"f46e58c5-5b39-4e0d-a5e4-7df1a24f9dcd","xennetworklabel":"cloud-mgmt"},
{"id":"7264d1b0-1f5c-4fad-818f-e189255d9786","traffictype":"Storage","physicalnetworkid":"f46e58c5-5b39-4e0d-a5e4-7df1a24f9dcd","xennetworklabel":"cloud-st
http://10.223.195.103:8080/client/api?command=listTrafficTypes&response=json&sessionkey=34IhnepKGK%2FKr85g8QOuzGUv7c8%3D&physicalnetworkid=d261ab59-cc6f-4d4c-9899-32fda03dbe7d&_=1384909056399
{ "listtraffictypesresponse" : { "count":1 ,"traffictype" : [
{"id":"47ac4940-6023-4d52-aea1-85b6035e1125","traffictype":"Public","physicalnetworkid":"d261ab59-cc6f-4d4c-9899-32fda03dbe7d","xennetworklabel":"cloud-public"}
] } }
http://10.223.195.103:8080/client/api?command=listTrafficTypes&response=json&sessionkey=34IhnepKGK%2FKr85g8QOuzGUv7c8%3D&physicalnetworkid=7340060e-aef2-4bc2-9bed-2fc3001f177a&_=1384909056477
{ "listtraffictypesresponse" : { "count":1 ,"traffictype" : [
{"id":"a53fb4b1-e630-4da5-bed1-24428d01ad16","traffictype":"Guest","physicalnetworkid":"7340060e-aef2-4bc2-9bed-2fc3001f177a","xennetworklabel":"cloud-guest"}
] } }
> UI - "Add guest Network" from Network page - Should list only physical
> network that has guest traffic type.
>
>
> Key: CLOUDSTACK-4693
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4693
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: Build from 4.2-forward
>Reporter: Sangeetha Hariharan
>Assignee: Jessica Wang
> Fix For: 4.2.1
>
>
> Use "Add guest Network" from Network page .
> In this page we have “Physical Network” drop down which lists all the
> physical network that includes storage/management/public/guest traffic type.
> Following is the API call made:
> http://10.223.240.160:8080/client/api?command=listPhysicalNetworks&response=json&sessionkey=4Xt2OZIdOBK4kvtp%2BRWMau%2B%2Bj0I%3D&zoneid=7ba002d6-d608-478d-98e4-ce71787a97d5&_=1379444555319
> We should be listing only Physical Networks that have guest traffic type.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-5207) jdbc.exceptions are observed when both Master 1 and master 2 goes down and comes back.
Kiran Koneti created CLOUDSTACK-5207: Summary: jdbc.exceptions are observed when both Master 1 and master 2 goes down and comes back. Key: CLOUDSTACK-5207 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5207 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Kiran Koneti Priority: Critical Fix For: 4.3.0 1)I have created a replication db with 2 masters say M1 and M2. 2)The CS setup came up and both the db's are in sync. 3)now i made the M1 down and the M2 was made the master and the operations of CS were normal. 4)Now i made the M2 also down and the db of the CS could not be accessed. 5)Later i made the M1 up and then M2.The data sync happened properly but there is an error message which is constantly shown in the MS log and it is as below: "2013-11-20 11:34:50,938 ERROR [c.c.u.d.ConnectionConcierge] (ConnectionConcierge-1:ctx-7c449525) Unable to keep the db connection for LockMaster1 com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed. Connection closed after inability to pick valid new connection during fail-over. at sun.reflect.GeneratedConstructorAccessor25.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1014) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:988) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:974) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:919) at com.mysql.jdbc.LoadBalancingConnectionProxy.invoke(LoadBalancingConnectionProxy.java:532) at com.mysql.jdbc.FailoverConnectionProxy.invoke(FailoverConnectionProxy.java:136) at $Proxy19.prepareStatement(Unknown Source) at org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:281) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:313) at com.cloud.utils.db.ConnectionConcierge$ConnectionConciergeManager.testValidity(ConnectionConcierge.java:148) at com.cloud.utils.db.ConnectionConcierge$ConnectionConciergeManager$1.runInContext(ConnectionConcierge.java:211) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) 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 was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5208) upgrade from 3.0.6 to 4.3 is not throwing any exception if new System VM template is not registered with proper name
shweta agarwal created CLOUDSTACK-5208: -- Summary: upgrade from 3.0.6 to 4.3 is not throwing any exception if new System VM template is not registered with proper name Key: CLOUDSTACK-5208 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5208 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.3.0 Environment: upgrade from 3.0.6 to 4.3 Reporter: shweta agarwal Priority: Blocker Fix For: 4.3.0 Created a 3.0.6 setup Registered new system vm templates with name systemvm-xenserver-4.3 instead of 4.2 performed upgrade and restarted Ms Bug: Didn't hit any exception /error of new system template not found And after than even start/stop system vm is restarting system vm with old template . Destroying and recreating system vm is also recreating system vm with old templates -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5209) No notification is given either in the UI nor in the MS logs if the Master 2 goes down for the DBHA.
Kiran Koneti created CLOUDSTACK-5209: Summary: No notification is given either in the UI nor in the MS logs if the Master 2 goes down for the DBHA. Key: CLOUDSTACK-5209 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5209 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Kiran Koneti Priority: Critical Fix For: 4.3.0 I have create a DB replication with 2 masters and the CS setup is up with the same.Now when the M1 is up and the CS operations are running normally and if the M2 goes down there is no chance to know that the M2 is gone.There are no notifications either in the UI nor in the MS logs. Note:Even when the M1 goes down there is a notification only in the logs and no notification in the UI . It would be good to have an alert in the UI as watching logs all the time may not be possible. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4585) [VMWare] [Upgrade] Failed to start instance after reverting the VM snapshot on a Private Zone which was created prior to upgrade
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-4585:
---
Attachment: cloud306.dmp
management-server.log.2013-11-19.tar.gz
cloud-after-upgrade.dmp
> [VMWare] [Upgrade] Failed to start instance after reverting the VM snapshot
> on a Private Zone which was created prior to upgrade
> -
>
> Key: CLOUDSTACK-4585
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4585
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot
>Affects Versions: 4.2.1
>Reporter: Sudha Ponnaganti
>Assignee: Kelven Yang
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: cloud-after-upgrade.dmp, cloud306.dmp,
> management-server.log.2013-11-19.tar.gz
>
>
> I have an upgraded setup from 307 Patch B to 4.2 . I have one VMWARE private
> zone before upgrade.
>
> After upgrade I created VM snapshot for one of the instance In this zone.
> Later reverted to this VM snapshot. Now VM’s are failing to start saying
> “Unable to create a deployment for VM[User|host13i1], Please check the
> affinity groups provided, there may not be sufficient capacity to follow them”
>
>
> =
>
>
> 2013-08-31 20:33:16,949 WARN [vmware.resource.VmwareResource]
> (DirectAgent-452:10.102.192.13) StartCommand failed due to Exception:
> java.lang.RuntimeException
> Message: Invalid configuration for device '0'.
>
> java.lang.RuntimeException: Invalid configuration for device '0'.
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:835)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.tearDownDevices(VirtualMachineMO.java:1643)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2675)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:519)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> 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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> 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)
> 2013-08-31 20:33:16,952 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-452:null) Seq 12-1859846507: Response Received:
> 2013-08-31 20:33:16,953 DEBUG [agent.transport.Request]
> (DirectAgent-452:null) Seq 12-1859846507: Processing: { Ans: , MgmtId:
> 227594284004867, via: 12, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":38,"name":"i-3-38-VM","bootloader":"HVM","type":"User","cpus":1,"minSpeed":200,"maxSpeed":200,"minRam":536870912,"maxRam":536870912,"hostName":"host13i1","arch":"x86_64","os":"CentOS
> 5.3
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"425de971cf2ec463","params":{"nicAdapter":"E1000","vmware.reserve.cpu":"false","nestedVirtualizationFlag":"false","Message.ReservedCapacityFreed.Flag":"false","rootDiskController":"ide","vmware.reserve.mem":"false"},"uuid":"d51c5b43-0201-4095-8b4c-643df2b2f4e2","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"499111c0-9bb3-4921-a370-0c8f5de8579b","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"5bf1f4d7-b301-39f1-85dc-c0af114d68b4","id":203,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/zwps1","port":2049}},"name":"ROOT-38","size":2147483648,"path":"ROOT-38-03","volumeId":47,"vmName":"i-3-38-VM","accountId":3,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[5bf1f4d7b30139f185dcc0af114d68b4]
> i-3-38-VM/ROOT-38.vmdk\",\"[5bf1f4d7b30139f185dcc0af114d68b4]
> 56c533304ae43a5dbba19a88ee7cea6c/56c533304ae43a5dbba19a88ee7cea6c.vmdk\"]}","format":"OVA","id":4
[jira] [Updated] (CLOUDSTACK-5208) upgrade from 3.0.6 to 4.3 is not throwing any exception if new System VM template is not registered with proper name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-5208: --- Attachment: cloud306.dmp management-server.log.2013-11-19.tar.gz cloud-after-upgrade.dmp > upgrade from 3.0.6 to 4.3 is not throwing any exception if new System VM > template is not registered with proper name > > > Key: CLOUDSTACK-5208 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5208 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.3.0 > Environment: upgrade from 3.0.6 to 4.3 >Reporter: shweta agarwal >Priority: Blocker > Fix For: 4.3.0 > > Attachments: cloud-after-upgrade.dmp, cloud306.dmp, > management-server.log.2013-11-19.tar.gz > > > Created a 3.0.6 setup > Registered new system vm templates with name systemvm-xenserver-4.3 instead > of 4.2 > performed upgrade > and restarted Ms > Bug: > Didn't hit any exception /error of new system template not found > And after than even start/stop system vm is restarting system vm with old > template . Destroying and recreating system vm is also recreating system vm > with old templates -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5208) upgrade from 3.0.6 to 4.3 is not throwing any exception if new System VM template is not registered with proper name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827381#comment-13827381 ] shweta agarwal commented on CLOUDSTACK-5208: with the fix of this bug https://issues.apache.org/jira/browse/CLOUDSTACK-4585 Commit ae231444bc885ee5e9a5d4bb3003bef651c849d6 in branch refs/heads/master from Kelven Yang [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ae23144 ] CLOUDSTACK-4585: make run-time datastore folder migration, VM snapshot, bug in root disk controller type carried from previous version work under upgrade situation that part of code is commented which throws exception on not finding system vm template > upgrade from 3.0.6 to 4.3 is not throwing any exception if new System VM > template is not registered with proper name > > > Key: CLOUDSTACK-5208 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5208 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.3.0 > Environment: upgrade from 3.0.6 to 4.3 >Reporter: shweta agarwal >Priority: Blocker > Fix For: 4.3.0 > > Attachments: cloud-after-upgrade.dmp, cloud306.dmp, > management-server.log.2013-11-19.tar.gz > > > Created a 3.0.6 setup > Registered new system vm templates with name systemvm-xenserver-4.3 instead > of 4.2 > performed upgrade > and restarted Ms > Bug: > Didn't hit any exception /error of new system template not found > And after than even start/stop system vm is restarting system vm with old > template . Destroying and recreating system vm is also recreating system vm > with old templates -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5210) Need Support for the Hyper-V for the Report sockets CS-4908
Kiran Koneti created CLOUDSTACK-5210: Summary: Need Support for the Hyper-V for the Report sockets CS-4908 Key: CLOUDSTACK-5210 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5210 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Kiran Koneti For the report sockets feature we need to provide support for the Hyper-V hypervisor.The support is not yet added. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5212) Need Support for the LXC for the Report sockets CS-4908
Kiran Koneti created CLOUDSTACK-5212: Summary: Need Support for the LXC for the Report sockets CS-4908 Key: CLOUDSTACK-5212 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5212 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Kiran Koneti Priority: Blocker For the report sockets feature we need to provide support for the LXC hypervisor.The support is not yet added. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5210) Need Support for the Hyper-V for the Report sockets CS-4908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Koneti updated CLOUDSTACK-5210: - Priority: Blocker (was: Major) > Need Support for the Hyper-V for the Report sockets CS-4908 > --- > > Key: CLOUDSTACK-5210 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5210 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kiran Koneti >Priority: Blocker > > For the report sockets feature we need to provide support for the Hyper-V > hypervisor.The support is not yet added. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5211) Need Support for the OVM for the Report sockets CS-4908
Kiran Koneti created CLOUDSTACK-5211: Summary: Need Support for the OVM for the Report sockets CS-4908 Key: CLOUDSTACK-5211 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5211 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Kiran Koneti Priority: Blocker For the report sockets feature we need to provide support for the OVM hypervisor.The support is not yet added. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-3190) action events message published on 'event bus' should of the UUID of the entity for which event generated and event type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-3190: - Assignee: (was: Murali Reddy) > action events message published on 'event bus' should of the UUID of the > entity for which event generated and event type > > > Key: CLOUDSTACK-3190 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3190 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 > Environment: action events message published on 'event bus' should > have the UUID of the entity for which event generated and entity type > details. as well > Events bus framework with current AMQP default implementation, has routing > key with format 'Eventsource.EventCategory.EventType.EntityType.EntityUUID'. > For action events, EntityUUDI is not populated. Fix would required to ensure > entity UUID is used in forming the routing key. >Reporter: Murali Reddy > Labels: newbie > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5205) System vm startup scripts calculate jvm memory wrong
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827404#comment-13827404 ] Prasanna Santhanam commented on CLOUDSTACK-5205: Thanks! Do you think you can submit a patch for this? Please post it on reviewboard.apache.org. Patches left in JIRA tickets generally don't get noticed by the concerned contributors. Here's some guidelines : https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Guidelines > System vm startup scripts calculate jvm memory wrong > > > Key: CLOUDSTACK-5205 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5205 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.2.0 >Reporter: John E Vincent > > While attempting to provision beefier system vms, we discovered this bug. > The `_run.sh` script in the system vm calculates jvm memory based on 80% of > the total memory on the system. This is great up until the point 80% of > memory goes above ~1.9G. The system vm templates are all 32-bit and so > calculating the size too high will cause the agent jvm to fail to start. > The fix is pretty simple with a final sanity check: > if [ $maxmem -gt 1900 ] > then > maxmem=1900 > fi -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5213) SSVM downloads templates if sec storage is not mounted/available
Bjoern Teipel created CLOUDSTACK-5213: - Summary: SSVM downloads templates if sec storage is not mounted/available Key: CLOUDSTACK-5213 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5213 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.1 Environment: CentOS 6.4, NFS secondary storage Reporter: Bjoern Teipel Priority: Minor The SSVM is currently downloading templates, even the secondary storage like in my case NFS is not mounted. That causes the disk to fill up. Expected behavior is not to download the templates and possibly update the status to "Download paused, secondary storage unavailable" -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-3190) action events message published on 'event bus' should have the UUID of the entity for which event generated and event type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-3190: - Summary: action events message published on 'event bus' should have the UUID of the entity for which event generated and event type (was: action events message published on 'event bus' should of the UUID of the entity for which event generated and event type) > action events message published on 'event bus' should have the UUID of the > entity for which event generated and event type > -- > > Key: CLOUDSTACK-3190 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3190 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 > Environment: action events message published on 'event bus' should > have the UUID of the entity for which event generated and entity type > details. as well > Events bus framework with current AMQP default implementation, has routing > key with format 'Eventsource.EventCategory.EventType.EntityType.EntityUUID'. > For action events, EntityUUDI is not populated. Fix would required to ensure > entity UUID is used in forming the routing key. >Reporter: Murali Reddy > Labels: newbie > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5119) F5 plugin : VLAN provisioning broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827405#comment-13827405
]
Bjoern Teipel commented on CLOUDSTACK-5119:
---
The F5 LTM Virtual Edition has known issues when it comes to Ethernet link
detection. Whenever a VLAN is provisioned through icontrol, it generates a
error message that the link media is invalid. I guess that causes cloudstack or
icontrol to stop the VLAN provisioning
> F5 plugin : VLAN provisioning broken
>
>
> Key: CLOUDSTACK-5119
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5119
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Network Devices
>Affects Versions: 4.2.1
> Environment: BigIP VE LTM 11.4.1
> icontrol 11.4.1 Java plugin from f5.com (used their jar archive)
> CentOS 6.4 KVM Hypervisor
> Cloudstack 4.2.1 branch from 11/9/13
>Reporter: Bjoern Teipel
>Priority: Critical
>
> Cloudstack wants to provision a VLAN to spin up the first VR but it just
> bails out, what ever I do. Even worse it makes no sense, the VLAN is created
> on the F5 so I guess there is just a bug going on :
> Error Message cloudstack :
> 2013-11-09 22:03:49,041 DEBUG [agent.transport.Request]
> (Job-Executor-25:job-71 = [ 081a9bd4-6d4d-40d2-9868-48f6aca0116e ]) Seq
> 7-671875076: Sending { Cmd , MgmtId: 110493122496, via: 7, Ver: v1, Flags:
> 100011, [{"com.cloud.agent.api.ro
> uting.IpAssocCommand":{"ipAddresses":[{"accountId":1,"sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":false,"vlanId":"651","vlanGateway":"10.161.2.168","vlanNetmask":"255.255.254.0","networkRate":200}],"accessDetails":{},"wait":
> 0}}] }
> 2013-11-09 22:03:49,041 DEBUG [agent.transport.Request]
> (Job-Executor-25:job-71 = [ 081a9bd4-6d4d-40d2-9868-48f6aca0116e ]) Seq
> 7-671875076: Executing: { Cmd , MgmtId: 110493122496, via: 7, Ver: v1,
> Flags: 100011, [{"com.cloud.agent.api
> .routing.IpAssocCommand":{"ipAddresses":[{"accountId":1,"sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":false,"vlanId":"651","vlanGateway":"10.161.2.168","vlanNetmask":"255.255.254.0","networkRate":200}],"accessDetails":{},"wai
> t":0}}] }
> 2013-11-09 22:03:49,042 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-220:null) Seq 7-671875076: Executing request
> 2013-11-09 22:03:49,316 DEBUG [network.resource.F5BigIpResource]
> (DirectAgent-220:null) Creating a guest VLAN with tag 651
> 2013-11-09 22:03:49,398 ERROR [network.resource.F5BigIpResource]
> (DirectAgent-220:null) Failed to execute IPAssocCommand due to
> com.cloud.utils.exception.ExecutionException: Failed to create vlan with tag
> 651
> 2013-11-09 22:03:49,467 ERROR [network.resource.F5BigIpResource]
> (DirectAgent-220:null) Retrying IpAssocCommand. Number of retries remaining: 1
> 2013-11-09 22:03:49,662 DEBUG [network.resource.F5BigIpResource]
> (DirectAgent-220:null) Creating a guest VLAN with tag 651
> 2013-11-09 22:03:49,685 ERROR [network.resource.F5BigIpResource]
> (DirectAgent-220:null) Exception caught in
> Networking::urn:iControl:Networking/VLAN::create()
> Exception: Common::OperationFailed
> primary_error_code : 16908390 (0x01020066)
> secondary_error_code : 0
> error_string : 01020066:3: The requested VLAN
> (/Common/vlan-651) already exists in partition Common.
> 2013-11-09 22:03:49,685 ERROR [network.resource.F5BigIpResource]
> (DirectAgent-220:null) Failed to execute IPAssocCommand due to
> com.cloud.utils.exception.ExecutionException: Exception caught in
> Networking::urn:iControl:Networking/VLAN::c
> reate()
> Exception: Common::OperationFailed
> primary_error_code : 16908390 (0x01020066)
> secondary_error_code : 0
> error_string : 01020066:3: The requested VLAN
> (/Common/vlan-651) already exists in partition Common.
> 2013-11-09 22:03:49,701 DEBUG [storage.secondary.SecondaryStorageManagerImpl]
> (secstorage-1:null) Zone 1 is ready to launch secondary storage VM
> 2013-11-09 22:03:49,765 ERROR [network.resource.F5BigIpResource]
> (DirectAgent-220:null) Retrying IpAssocCommand. Number of retries remaining: 0
> 2013-11-09 22:03:49,910 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl]
> (consoleproxy-1:null) Zone 1 is ready to launch console proxy
> 2013-11-09 22:03:49,956 DEBUG [network.resource.F5BigIpResource]
> (DirectAgent-220:null) Creating a guest VLAN with tag 651
> 2013-11-09 22:03:49,976 ERROR [network.resource.F5BigIpResource]
> (DirectAgent-220:null) Exception caught in
> Networking::urn:iControl:Networking/VLAN::create()
> Exception: Common::OperationFailed
> primary_error_code : 16908390 (0x01020066)
> secondary_error_code : 0
>
[jira] [Commented] (CLOUDSTACK-5133) few templates lost, cause can not download and launch vm from that
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827412#comment-13827412 ] huangtao87 commented on CLOUDSTACK-5133: installed inotify on ssvm ,and find the time of template vhd been deleted check the log found at cloudstack 2013-11-15 06:02:17,348 WARN [storage.template.UploadManagerImpl] (agentRequest-Handler-1:null) handleDeleteEntityDownloadURLCommand Path:template/tmpl/3/324/bdda7f65-a049-4853-a247-cdbedc0fc348.vhd Type:VOLUME the type is volume, is that right ?caused vhd missing?is that a bug of cloudstack 4.2? thanks > few templates lost, cause can not download and launch vm from that > --- > > Key: CLOUDSTACK-5133 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5133 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 > Environment: cloudstack 4.2 > xenserver 6.2 >Reporter: huangtao87 >Priority: Critical > Labels: lost, missing, template > > used this version for a while, when i gonna download template, report error. > then i try to find in ssvm and secondary storage. > root@s-1-VM:~# cd /var/www/html/userdata/ > root@s-1-VM:/var/www/html/userdata# ls -l > f6b31479-7fd8-4ffb-b978-2f3490576704.vhd > lrwxrwxrwx 1 root root 113 Nov 11 07:58 > f6b31479-7fd8-4ffb-b978-2f3490576704.vhd -> > /mnt/SecStorage/59ee7371-e695-3ae4-afd6-01640d61a49b/template/tmpl/3/305/29c49727-eb59-4781-978e-342e9c00a944.vhd > root@s-1-VM:/var/www/html/userdata# > root@s-1-VM:/var/www/html/userdata# > root@s-1-VM:/var/www/html/userdata# cd > /mnt/SecStorage/59ee7371-e695-3ae4-afd6-01640d61a49b/template/tmpl/3/305/ > root@s-1-VM:/mnt/SecStorage/59ee7371-e695-3ae4-afd6-01640d61a49b/template/tmpl/3/305# > ls > template.properties *** no templatefile** > root@s-1-VM:/mnt/SecStorage/59ee7371-e695-3ae4-afd6-01640d61a49b/template/tmpl/3/305# > > i check the logs, there is no information why it has been delete. BTW, in > cloudstack web UI ,that template is already there and status is ready. > there is a Warn in log below: > 2013-11-07 11:09:51,863 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-476:null) Error while collecting disk stats from : > You gave an invalid object reference. The object may have recently been > deleted. The class parameter gives the type of reference given, and the > handle parameter echoes the bad value given. > at com.xensource.xenapi.Types.checkResponse(Types.java:209) > at com.xensource.xenapi.Connection.dispatch(Connection.java:368) > at > com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) > at com.xensource.xenapi.VBDMetrics.getIoReadKbs(VBDMetrics.java:210) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2749) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2649) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:493) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73) > at > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:104) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > 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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > 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) > > why does this happen? -- This message was sent by Atlassian JIRA (v6.1#6144)
