[jira] [Created] (CLOUDSTACK-2289) Doc- Granular Global Param
Radhika Nair created CLOUDSTACK-2289: Summary: Doc- Granular Global Param Key: CLOUDSTACK-2289 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2289 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Reporter: Radhika Nair -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2288) NPE while creating volume from snapshot when the primary storage is in maintenance state
Sailaja Mada created CLOUDSTACK-2288: Summary: NPE while creating volume from snapshot when the primary storage is in maintenance state Key: CLOUDSTACK-2288 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2288 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Sailaja Mada Setup: Advanced Networking Zone, Xen 6.1 , MS - RHEL 6.3 Steps: 1. Deploy instance as ROOT admin 2. Create the snapshot for the ROOT volume of this instance 3. Put the only available primary storage to maintenance 4. Try to create the volume from this snapshot. Observation: NPE while creating volume from snapshot when the primary storage is in maintenance state 2013-04-30 12:05:56,653 DEBUG [cloud.api.ApiServlet] (catalina-exec-16:null) ===END=== 10.144.6.19 -- GET command=createVolume&response=json&sessionkey=mTrNgYbkndiHLZNAV%2BoAAzDOQFw%3D&snapshotid=79b17cda-71f7-4be9-9e7c-bedcb73a7106&name=newsnapvol1&_=1367303886423 2013-04-30 12:05:56,658 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-1:job-73) Executing org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd for job-73 2013-04-30 12:05:56,755 DEBUG [cloud.storage.StorageManagerImpl] (Job-Executor-1:job-73) Storage pool garbage collector found 0 templates to clean up in storage pool: PS1 2013-04-30 12:05:56,767 DEBUG [cloud.storage.StorageManagerImpl] (Job-Executor-1:job-73) Secondary storage garbage collector found 0 templates to cleanup on secondary storage host: nfs://10.102.192.100/cpg_vol/sailaja/masterxenss 2013-04-30 12:05:56,819 WARN [cloud.storage.StorageManagerImpl] (Job-Executor-1:job-73) Failed to cleanup snapshots for volume 15 due to can not find secondary storage VM agent for data center 1 2013-04-30 12:05:56,840 WARN [cloud.storage.StorageManagerImpl] (Job-Executor-1:job-73) Failed to cleanup snapshots for volume 18 due to can not find secondary storage VM agent for data center 1 2013-04-30 12:05:56,874 DEBUG [cloud.storage.StorageManagerImpl] (Job-Executor-1:job-73) Secondary storage garbage collector found 0 templates to cleanup on secondary storage host: nfs://10.102.192.100/cpg_vol/sailaja/masterxenss 2013-04-30 12:05:56,890 DEBUG [allocator.impl.UserConcentratedAllocator] (Job-Executor-1:job-73) There are no pods with enough memory/CPU capacity in zone Advzone1 2013-04-30 12:05:56,946 DEBUG [cloud.storage.VolumeManagerImpl] (Job-Executor-1:job-73) Failed to create volume: 28 java.lang.NullPointerException at com.cloud.storage.VolumeManagerImpl.createVolumeFromSnapshot(VolumeManagerImpl.java:537) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.createVolumeFromSnapshot(VolumeManagerImpl.java:597) at com.cloud.storage.VolumeManagerImpl.createVolume(VolumeManagerImpl.java:1014) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.createVolume(VolumeManagerImpl.java:180) at org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd.execute(CreateVolumeCmd.java:168) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-04-30 12:05:57,019 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-1:job-73) Complete async job-73, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to create a volume 2013-04-30 12:05:59,699 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) ===START=== 10.144.6.19 -- GET command=queryAsyncJobResult&jobId=bdd08ea3-cf7f-4369-9778-c32e6267ffe1&response=json&sessionkey=mTrNgYbkndiHLZNAV%2BoAAzDOQFw%3D&_=1367303889729 2013-04-30 12:05:59,729 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-12:null) Async job-73 completed 2013-04-30 12:05:59,747 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) ===END=== 10.144.6.19 -- GET command=queryAsyncJobResult&jobId=bdd08ea3-cf7f-4369-9778-c32e6267ffe1&response=json&sessionkey=mTrNgYbkndiHLZNAV%2BoAAzDOQFw%3D&_=1367303889729 -- This message is automatically gene
[jira] [Created] (CLOUDSTACK-2287) Automation:LDAP
sadhu suresh created CLOUDSTACK-2287: Summary: Automation:LDAP Key: CLOUDSTACK-2287 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2287 Project: CloudStack Issue Type: Task Security Level: Public (Anyone can view this level - this is the default.) Components: Test Reporter: sadhu suresh Assignee: sadhu suresh Automate the LDAP testcases -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-665) Health monitoring for HAProxy load balanced instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-665: -- Assignee: (was: Rajesh Battala) > Health monitoring for HAProxy load balanced instances > - > > Key: CLOUDSTACK-665 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-665 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Rajesh Battala > Fix For: Future > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-665) Health monitoring for HAProxy load balanced instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645310#comment-13645310 ] Rajesh Battala commented on CLOUDSTACK-665: --- I won't be able to work on this for 4.2, moving fix version to future > Health monitoring for HAProxy load balanced instances > - > > Key: CLOUDSTACK-665 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-665 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Rajesh Battala >Assignee: Rajesh Battala > Fix For: 4.1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-665) Health monitoring for HAProxy load balanced instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-665: -- Fix Version/s: (was: 4.1.0) Future > Health monitoring for HAProxy load balanced instances > - > > Key: CLOUDSTACK-665 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-665 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Rajesh Battala >Assignee: Rajesh Battala > Fix For: Future > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1680) collection of status of LB HealthChecks should be per device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-1680: --- Fix Version/s: (was: 4.2.0) Future > collection of status of LB HealthChecks should be per device > -- > > Key: CLOUDSTACK-1680 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1680 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Devices >Affects Versions: 4.2.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala >Priority: Minor > Fix For: Future > > > Health checks are collected for every LBrule from device, > Instead we can retrive the status of all LB rules in the device at one time > and then do filtering and update the db will reduce the number of network > calls to the LB Device. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-869) nTier Apps 2.0 : Support NetScalar as external LB provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-869: -- Status: Ready To Review (was: In Progress) > nTier Apps 2.0 : Support NetScalar as external LB provider > -- > > Key: CLOUDSTACK-869 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-869 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Rajesh Battala > Fix For: 4.2.0 > > > As part of supporting external physical devices to do FW & LB, > https://issues.apache.org/jira/browse/CLOUDSTACK-749 > NetScalarVpcProvider has to be implemented along with corresponding backend > scripts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2081) Volume which is added thru upload volume is failed to attach to the instance saying Volume state must be in Allocated, Ready or in Uploaded state( Though uploaded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-2081: -- Assignee: Rajesh Battala > Volume which is added thru upload volume is failed to attach to the instance > saying Volume state must be in Allocated, Ready or in Uploaded state( Though > uploaded Volume state is uploaded) > -- > > Key: CLOUDSTACK-2081 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2081 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: Sailaja Mada >Assignee: Rajesh Battala >Priority: Critical > Fix For: 4.2.0 > > > Setup : Advanced Networking Zone, Xen 6.1 With Latest master - RHEL 6.3 > Steps: > 1. Add volume by Upload volume > 2. After download of the volume from the given URL is completed , State of > the volume should be uploaded > 3. Try to attach to the instance . Uploaded > Observation : Volume which is added thru upload volume is failed to attach to > the instance saying Volume state must be in Allocated, Ready or in Uploaded > state( Though uploaded Volume state is uploaded) > Exception details are : > 2013-04-18 16:00:25,831 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) > ===END=== 10.144.6.19 -- GET > command=attachVolume&id=5a2980df-9469-437e-8ebc-8c609378e0f8&virtualMachineId=edb53e95-64c9-4313-9e69-c583125a15f0&response=json&sessionkey=ZjH0BVyOgpzu3L6OU%2B0Ufu7mUaU%3D&_=1366281145419 > 2013-04-18 16:00:25,834 DEBUG [cloud.async.AsyncJobManagerImpl] > (Job-Executor-21:job-21) Executing > org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for job-21 > 2013-04-18 16:00:25,891 ERROR [cloud.async.AsyncJobManagerImpl] > (Job-Executor-21:job-21) Unexpected exception while executing > org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd > com.cloud.exception.InvalidParameterValueException: Volume state must be in > Allocated, Ready or in Uploaded state > at > com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1689) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:164) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-04-18 16:00:25,892 DEBUG [cloud.async.AsyncJobManagerImpl] > (Job-Executor-21:job-21) Complete async job-21, jobStatus: 2, resultCode: > 530, result: Error Code: 530 Error text: Volume state must be in Allocated, > Ready or in Uploaded state > 5a2980df-9469-437e-8ebc-8c609378e0f8vol1be2df554-202e-4ebd-8422-2628e67dd661zone1DATADISK21474836482013-04-18T15:39:06+0530Uploadedadmin5bc9afe0-a809-11e2-8725-c2ae49691a00ROOTsharedXenServer63ec8d0d-647d-4c6a-8f66-644989820fd4CustomCustom > > DiskfalsetrueUpload > Complete0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2286) Volume created from snapshot state is in allocated state instead of Ready state which is letting Primary storage not to increment the resources
Sailaja Mada created CLOUDSTACK-2286: Summary: Volume created from snapshot state is in allocated state instead of Ready state which is letting Primary storage not to increment the resources Key: CLOUDSTACK-2286 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2286 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Sailaja Mada Priority: Critical Setup: Advanced Networking Zone, Xen 6.1 , MS - RHEL 6.3 Steps: 1. Deploy instance as ROOT admin 2. Create the snapshot for the ROOT volume of this instance 3. Create the volume from this snapshot. Observation : 1)Volume created from snapshot state is in allocated state instead of Ready state which is letting Primary storage not to increment the resources -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2220) SRX - By default, egress traffic is NOT BLOCKED from guest netowrk to public network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645261#comment-13645261 ] Jayapal Reddy commented on CLOUDSTACK-2220: --- It seems SRX pre configuration issue. Can you please check you SRX configuration security policies. Please attach the SRX configuration in the bug. > SRX - By default, egress traffic is NOT BLOCKED from guest netowrk to public > network > - > > Key: CLOUDSTACK-2220 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2220 > 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: MS ACS 4.2 build 4/24/13 7:48 PM revision: > 299cccf779f75c3ba04d9ec7303bed88394c3562 > host XS 6.0.2 >Reporter: angeline shen >Assignee: Jayapal Reddy >Priority: Critical > Fix For: 4.2.0 > > Attachments: management-server.log.gz > > > MS ACS 4.2 build 4/24/13 7:48 PM revision: > 299cccf779f75c3ba04d9ec7303bed88394c3562 > host XS 6.0.2 > 1. SRX network offering : isolated DHCP: virtual router DNS: virtual router > firewall: SRX userdata:virtual router sourceNAT: SRX staticNAT: SRX > portforward: SRX sourceNAT type: perzone > 2. domain: ROOT admin >domain: /d1 domain admin: d1domain >domain: /d2 user: d2user > 3. login: admin create VMs, allocate public IPs . > BUG: login any VM via console: able to ping www.google.com > login: d1domain repeat above steps >BUG: login any VM via console: able to ping www.google.com > login: d2user repeat above steps >BUG: login any VM via console: able to ping www.google.com -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2212) [Egress Rules] [Shared Network] Unable to configure egress rules as non-ROOT domain user
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-2212. --- Resolution: Fixed Currently the for shared networks Egress rules is not supported. With the below bug fix it throws error when you configured egress for shared networks. https://issues.apache.org/jira/browse/CLOUDSTACK-1794 I raised a feature bug for egress rules for shared networks. https://issues.apache.org/jira/browse/CLOUDSTACK-2208 > [Egress Rules] [Shared Network] Unable to configure egress rules as non-ROOT > domain user > > > Key: CLOUDSTACK-2212 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2212 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 > Environment: commit 0e2ffe72aa641f4551cae63fbc36454c5934342f >Reporter: venkata swamybabu budumuru >Assignee: Jayapal Reddy > Fix For: 4.2.0 > > Attachments: logs.tgz > > > Steps to Reproduce : > 1. Create an advanced zone with 1 Xen cluster > 2. Create a shared network offering with JuniperSRX servicing the firewall > related functionalities > select * from network_offerings >id: 17 > name: test > uuid: ed856a34-71e9-4bef-ae71-b4781fb57626 > unique_name: test > display_text: test > nw_rate: NULL > mc_rate: 10 > traffic_type: Guest > tags: NULL > system_only: 0 > specify_vlan: 1 > service_offering_id: NULL > conserve_mode: 0 > created: 2013-04-26 17:04:40 > removed: NULL > default: 0 > availability: Optional > dedicated_lb_service: 0 > shared_source_nat_service: 1 > sort_key: 0 > redundant_router_service: 0 > state: Enabled >guest_type: Shared >elastic_ip_service: 0 > eip_associate_public_ip: 0 >elastic_lb_service: 0 > specify_ip_ranges: 1 >inline: 0 > is_persistent: 0 > # select * from networks >id: 211 > name: SharedNet3 > uuid: 9aded0d9-f60c-4d06-af6d-aed9dad43b31 > display_text: SharedNet3 > traffic_type: Guest > broadcast_domain_type: Vlan > broadcast_uri: vlan://908 > gateway: 192.168.121.1 > cidr: 192.168.121.0/24 > mode: Dhcp > network_offering_id: 17 > physical_network_id: 201 >data_center_id: 2 > guru_name: DirectNetworkGuru > state: Implemented > related: 211 > domain_id: 1 >account_id: 1 > dns1: NULL > dns2: NULL > guru_data: NULL >set_fields: 0 > acl_type: Domain >network_domain: cs1cloud.internal >reservation_id: f0e990b9-c85e-4ff1-baa0-189f683406e5 >guest_type: Shared > restart_required: 0 > created: 2013-04-26 17:49:15 > removed: NULL > specify_ip_ranges: 1 >vpc_id: NULL > ip6_gateway: NULL > ip6_cidr: NULL > network_cidr: NULL > # mysql> select * from ntwk_service_map where network_id=211; > ++++---+-+ > | id | network_id | service| provider | created | > ++++---+-+ > | 25 |211 | Dhcp | VirtualRouter | 2013-04-26 17:49:15 | > | 22 |211 | Dns| VirtualRouter | 2013-04-26 17:49:15 | > | 21 |211 | Firewall | JuniperSRX| 2013-04-26 17:49:15 | > | 27 |211 | PortForwarding | JuniperSRX| 2013-04-26 17:49:15 | > | 23 |211 | SourceNat | JuniperSRX| 2013-04-26 17:49:15 | > | 24 |211 | StaticNat | JuniperSRX| 2013-04-26 17:49:15 | > | 26 |211 | UserData | VirtualRouter | 2013-04-26 17:49:15 | > 3. Create a new domain with at least one account with user role > 4. login as above user and try to create an egress rule > Observations: > - It fails with the following error in the logs. > 2013-04-26 15:01:57,880 DEBUG [cloud.user.AccountManagerImpl] > (Job-Executor-53:job-169) Access to Acct[45-dom1Acc1] granted to > Acct[45-dom1Acc1] by DomainChecker_EnhancerByCloudStack_4891655 > 2013-04-26 15:01:57,909 ERROR [cloud.async.AsyncJobManagerImpl]
[jira] [Resolved] (CLOUDSTACK-1794) We are allowed to create Egress rules for Shared networks.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy resolved CLOUDSTACK-1794.
---
Resolution: Fixed
Egress rules is not supported for shared networks
> We are allowed to create Egress rules for Shared networks.
> --
>
> Key: CLOUDSTACK-1794
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1794
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.1.0
> Environment: Build from 4.1
>Reporter: Sangeetha Hariharan
>Assignee: Jayapal Reddy
> Fix For: 4.1.0
>
>
> We are allowed to create Egress rules for Shared networks.
> Steps to reproduce the problem:
> Set up - Advanced Zone
> Create a shared network.
> From Network tab , select this shared network and go to Egress tab and create
> a egress rule.
> Creation of egress rule succeed.
> Expected Behavior:
> There is no support for egress rule in shared network. API should error out.
> apilog.log
> 2013-03-22 16:56:54,839 INFO [cloud.api.ApiServer] (catalina-exec-16:null)
> (userId=2 accountId=2 sessionId=FB9EC7CB6FF657012432A2067C3414B9)
> 10.217.252.128 -- GET
> command=createEgressFirewallRule&response=json&sessionkey=H%2Ffj8xnB4it%2BUnoyU6Q%2FM3uT4gA%3D&protocol=tcp&cidrlist=0.0.0.0%2F0&networkid=41305c7c-4206-4b3d-a5a3-b8c64d29d1b1&startport=22&endport=22&_=136415912
> 200 { "createegressfirewallruleresponse" :
> {"id":"3","jobid":"ba51e1c7-e6fc-48cf-8210-191e35a42a48"} }
> 2013-03-22 16:56:57,913 INFO [cloud.api.ApiServer] (catalina-exec-17:null)
> (userId=2 accountId=2 sessionId=FB9EC7CB6FF657012432A2067C3414B9)
> 10.217.252.128 -- GET
> command=queryAsyncJobResult&jobId=ba51e1c7-e6fc-48cf-8210-191e35a42a48&response=json&sessionkey=H%2Ffj8xnB4it%2BUnoyU6Q%2FM3uT4gA%3D&_=136419143
> 200 { "queryasyncjobresultresponse" :
> {"accountid":"b1b53b7e-8fed-11e2-89d9-06d4460004b1","userid":"b1b5e920-8fed-11e2-89d9-06d4460004b1","cmd":"org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"firewallrule":{"id":"f4aacb15-20e1-4ea1-af3f-e600c2373527","protocol":"tcp","startport":"22","endport":"22","networkid":212,"state":"Active","cidrlist":"0.0.0.0/0","tags":[]}},"created":"2013-03-22T16:56:54-0700","jobid":"ba51e1c7-e6fc-48cf-8210-191e35a42a48"}
> }
> management server log:
> 2013-03-22 16:56:54,835 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-16:null) submit async job-56, details: AsyncJobVO {id:56,
> userId: 2, accountId: 2, sessionKey: null, instanceType: null, instanceId: 3,
> cmd:
> org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"3","response":"json","sessionkey":"H/fj8xnB4it+UnoyU6Q/M3uT4gA\u003d","protocol":"tcp","ctxUserId":"2","cidrlist":"0.0.0.0/0","startport":"22","_":"136415912","ctxAccountId":"2","networkid":"41305c7c-4206-4b3d-a5a3-b8c64d29d1b1","ctxStartEventId":"140","endport":"22"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 206915885079359,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-03-22 16:56:54,836 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-8:job-56) Executing
> org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd
> for job-56
> 2013-03-22 16:56:54,839 DEBUG [cloud.api.ApiServlet] (catalina-exec-16:null)
> ===END=== 10.217.252.128 -- GET
> command=createEgressFirewallRule&response=json&sessionkey=H%2Ffj8xnB4it%2BUnoyU6Q%2FM3uT4gA%3D&protocol=tcp&cidrlist=0.0.0.0%2F0&networkid=41305c7c-4206-4b3d-a5a3-b8c64d29d1b1&startport=22&endport=22&_=136415912
> 2013-03-22 16:56:54,843 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-8:job-56) Sync job-56 execution on object network.212
> 2013-03-22 16:56:54,860 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-8:job-56) job
> org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd
> for job-56 was queued, processing the queue.
> 2013-03-22 16:56:54,876 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-8:job-56) Executing sync queue item: SyncQueueItemVO {id:9,
> queueId: 9, contentType: AsyncJob, contentId: 56, lastProcessMsid:
> 206915885079359, lastprocessNumber: 1, lastProcessTime: Fri Mar 22 16:56:54
> PDT 2013, created: Fri Mar 22 16:56:54 PDT 2013}
> 2013-03-22 16:56:54,878 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-8:job-56) Schedule queued job-56
> 2013-03-22 16:56:54,887 DEBUG [cloud.async.AsyncJobManagerIm
[jira] [Updated] (CLOUDSTACK-772) Document VMware vNetwork Distributed Virtual Switch support in CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-772: Assignee: Radhika Nair (was: Sateesh Chodapuneedi) Status: Open (was: Ready To Review) Provided review on 18th April in review board https://reviews.apache.org/r/10366/ > Document VMware vNetwork Distributed Virtual Switch support in CloudStack > - > > Key: CLOUDSTACK-772 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-772 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Radhika Nair > Fix For: 4.2.0 > > > Create documentation for VMware vNetwork Distributed Virtual Switch support > in CloudStack -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2285) [GSLB] addNetscalerLoadBalancer with GSLB functionality shouldn't be exposed in basic zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] venkata swamybabu budumuru updated CLOUDSTACK-2285: --- Attachment: api.log.tgz > [GSLB] addNetscalerLoadBalancer with GSLB functionality shouldn't be exposed > in basic zone > -- > > Key: CLOUDSTACK-2285 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2285 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 > Environment: commit 0e2ffe72aa641f4551cae63fbc36454c5934342f >Reporter: venkata swamybabu budumuru >Assignee: Murali Reddy > Fix For: 4.2.0 > > Attachments: api.log.tgz > > > Steps to reproduce : > 1. Have a basic zone setup with at least one XEN cluster using the offering > "DefaultSharedNetworkOfferingWithSGService" > 2. Try "addNetscalerLoadBalancer" with GSLB enabled > Observations: > (i) It gets added successfully. > command=addNetscalerLoadBalancer&physicalnetworkid=4dbe1d3c-1cee-4f88-aeca-45c4a8a76b4d&username=nsroot&password=nsroot&networkdevicetype=NetscalerVPXLoadBalancer&gslbprovider=true&gslbproviderpublicip=1.1.1.1&gslbproviderprivateip=1.1.1.1&url=https://10.147.54.5?publicinterface=1/1&privateinterface=1/2&numretries=2&lbdevicededicated=false&; > mysql> select id,name,networktype from data_center where id=1; > ++---+-+ > | id | name | networktype | > ++---+-+ > | 1 | zone1 | Basic | > ++---+-+ > mysql> select * from external_load_balancer_devices where id=2\G > *** 1. row *** > id: 2 >uuid: 8c467bfc-7ac3-410a-92d7-11e5853a5d79 > physical_network_id: 200 > provider_name: Netscaler > device_name: NetscalerVPXLoadBalancer >capacity: 50 >device_state: Enabled >allocation_state: Free >is_dedicated: 0 > is_managed: 0 > host_id: 15 > parent_host_id: 0 >is_gslb_provider: 1 > gslb_site_publicip: NULL > gslb_site_privateip: 1.1.1.1 > (ii) There is no need for enabling GSLB functionality in basic zones created > with above network offerings because there is no LB feature enabled in this > case. > May be having a check at the API level and allowing it only based on type of > zone will help in this case but, if we are supporting GSLB for ELB enabled > zones then we need to handle that situation as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2285) [GSLB] addNetscalerLoadBalancer with GSLB functionality shouldn't be exposed in basic zone
venkata swamybabu budumuru created CLOUDSTACK-2285: -- Summary: [GSLB] addNetscalerLoadBalancer with GSLB functionality shouldn't be exposed in basic zone Key: CLOUDSTACK-2285 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2285 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit 0e2ffe72aa641f4551cae63fbc36454c5934342f Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Fix For: 4.2.0 Steps to reproduce : 1. Have a basic zone setup with at least one XEN cluster using the offering "DefaultSharedNetworkOfferingWithSGService" 2. Try "addNetscalerLoadBalancer" with GSLB enabled Observations: (i) It gets added successfully. command=addNetscalerLoadBalancer&physicalnetworkid=4dbe1d3c-1cee-4f88-aeca-45c4a8a76b4d&username=nsroot&password=nsroot&networkdevicetype=NetscalerVPXLoadBalancer&gslbprovider=true&gslbproviderpublicip=1.1.1.1&gslbproviderprivateip=1.1.1.1&url=https://10.147.54.5?publicinterface=1/1&privateinterface=1/2&numretries=2&lbdevicededicated=false&; mysql> select id,name,networktype from data_center where id=1; ++---+-+ | id | name | networktype | ++---+-+ | 1 | zone1 | Basic | ++---+-+ mysql> select * from external_load_balancer_devices where id=2\G *** 1. row *** id: 2 uuid: 8c467bfc-7ac3-410a-92d7-11e5853a5d79 physical_network_id: 200 provider_name: Netscaler device_name: NetscalerVPXLoadBalancer capacity: 50 device_state: Enabled allocation_state: Free is_dedicated: 0 is_managed: 0 host_id: 15 parent_host_id: 0 is_gslb_provider: 1 gslb_site_publicip: NULL gslb_site_privateip: 1.1.1.1 (ii) There is no need for enabling GSLB functionality in basic zones created with above network offerings because there is no LB feature enabled in this case. May be having a check at the API level and allowing it only based on type of zone will help in this case but, if we are supporting GSLB for ELB enabled zones then we need to handle that situation as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2284) AWS Regions - Not able to add account/domain/user with same Id (External UUID) after deleting account/domain/user with this id.
Sangeetha Hariharan created CLOUDSTACK-2284:
---
Summary: AWS Regions - Not able to add account/domain/user with
same Id (External UUID) after deleting account/domain/user with this id.
Key: CLOUDSTACK-2284
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2284
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
Environment: Build from master
Reporter: Sangeetha Hariharan
Priority: Critical
Fix For: 4.2.0
AWS Regions - Not able to add account/domain/user with same Id (External UUID)
after deleting account/domain/user with this id.
Steps to reproduce the problem:
1. Add account/domain/user by passing External uuid in the accountid, userid
and domainid parameter to the createAccount/createDomain/createUser.
2. Creation of account/domain/user succeeds.
3. Delete the above created account/domain/user .
4. Deletion is successful.
5. Now try to Add account/domain/user by passing the same External uuid ( as
the one in step1 which are now deleted) in the accountid, userid and domainid
parameter to the createAccount/createDomain/createUser
Creation of account/domain/user fails with
api calls:
2013-04-29 18:49:44,694 INFO [cloud.api.ApiServer] (catalina-exec-5:null)
(userId=2 accountId=2 sessionId=null) 10.223.56
.66 -- GET
username=test-IUMDSH&domainid=2a50dd26-ad1d-11e2-acc8-068c76000429&firstname=Test&lastname=User&userid=user1&re
sponse=json&apiKey=sSPm7HTehsVp4DQ00Y0SIFaiQ9aabqIX5ty3AzqS2ciu-748BPIexxMfadefR-k3Q9iMCeYxerQ10aSf0h3oUw&command=createAc
count&accounttype=0&signature=mRKIJdxa3mnVWCABrFh57UAkCyI%3D&password=password&email=test%40test.com&accountid=account1
20
0 { "createaccountresponse" : { "account" :
{"id":"account1","name":"test-IUMDSH","accounttype":0,"domainid":"2a50dd26-ad
1d-11e2-acc8-068c76000429","domain":"ROOT","vmlimit":"20","vmtotal":0,"vmavailable":"20","iplimit":"20","iptotal":0,"ipava
ilable":"18","volumelimit":"20","volumetotal":0,"volumeavailable":"20","snapshotlimit":"20","snapshottotal":0,"snapshotava
ilable":"20","templatelimit":"20","templatetotal":0,"templateavailable":"20","projectlimit":"Unlimited","projecttotal":0,"
projectavailable":"Unlimited","networklimit":"20","networktotal":0,"networkavailable":"20","cpulimit":"40","cputotal":0,"c
puavailable":"40","memorylimit":"40960","memorytotal":0,"memoryavailable":"40960","primarystoragelimit":"200","primarystor
agetotal":0,"primarystorageavailable":"200","secondarystoragelimit":"400","secondarystoragetotal":0,"secondarystorageavail
able":"400","state":"enabled","user":[{"id":"user1","username":"test-IUMDSH","firstname":"Test","lastname":"User","email":
"t...@test.com","created":"2013-04-29T18:49:44-0700","state":"enabled","account":"test-IUMDSH","accounttype":0,"domainid":
"2a50dd26-ad1d-11e2-acc8-068c76000429","domain":"ROOT","accountid":"account1","iscallerchilddomain":false,"isdefault":fals
e,"jobstatus":0}],"isdefault":false,"jobstatus":0} } }
2013-04-29 20:16:14,970 INFO [cloud.api.ApiServer] (catalina-exec-7:null)
(userId=2 accountId=2 sessionId=null) 10.223.56.66 -- GET
username=test-EEZWQM&domainid=2a50dd26-ad1d-11e2-acc8-068c76000429&firstname=Test&lastname=User&userid=user1&response=json&apiKey=sSPm7HTehsVp4DQ00Y0SIFaiQ9aabqIX5ty3AzqS2ciu-748BPIexxMfadefR-k3Q9iMCeYxerQ10aSf0h3oUw&command=createAccount&accounttype=0&signature=2uJfDxGam6oUI9qsR2tTUGaIOhI%3D&password=password&email=test%40test.com&accountid=account1
530 Entity already exists:
2013-04-29 18:58:03,584 INFO [cloud.api.ApiServer] (catalina-exec-2:null)
(userId=2 accountId=2 sessionId=9F0E4DDB3C5B109C6624B295300677A4)
10.217.252.128 -- GET
command=deleteAccount&response=json&sessionkey=kVuw1w4mpRqpRWJmCzdR4yUOXKc%3D&id=account1&_=1367287126884
200 { "deleteaccountresponse" :
{"jobid":"d4124909-af04-47f8-bfff-818e39ab7eaf"} }
2013-04-29 20:16:14,970 INFO [cloud.api.ApiServer] (catalina-exec-7:null)
(userId=2 accountId=2 sessionId=null) 10.223.56.66 -- GET
username=test-EEZWQM&domainid=2a50dd26-ad1d-11e2-acc8-068c76000429&firstname=Test&lastname=User&userid=user1&response=json&apiKey=sSPm7HTehsVp4DQ00Y0SIFaiQ9aabqIX5ty3AzqS2ciu-748BPIexxMfadefR-k3Q9iMCeYxerQ10aSf0h3oUw&command=createAccount&accounttype=0&signature=2uJfDxGam6oUI9qsR2tTUGaIOhI%3D&password=password&email=test%40test.com&accountid=account1
530 Entity already exists:
mysql> select id,account_name,uuid,removed from account where uuid="account1";
++--+--+-+
| id | account_name | uuid | removed |
++--+--+-+
| 86 | test-IUMDSH | account1 | 2013-04-30 01:58:03 |
++--+--+-+
1 row in set (0.00 sec)
Management server logs:
2013-04-29 20:16:14,952 DEBUG [cloud.a
[jira] [Commented] (CLOUDSTACK-2054) [Automation]Failed to upload volume with NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645173#comment-13645173 ] Sailaja Mada commented on CLOUDSTACK-2054: -- Rayees, I tried with latest build upload volume worked fine. There are issues with this volume while attaching to the instance . This is tracked as a different defect . Can you please retry this operation and update the ticket. > [Automation]Failed to upload volume with NPE > > > Key: CLOUDSTACK-2054 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2054 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.2.0 > Environment: KVM and VMware >Reporter: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CLOUDSTACK-2054.rar > > > Found this issue while executing regression test case "test_upload_volumes.py" > Step 1 : Create master build, install and configure advanced zone > Step 2 : upload volume ".vhd" file , size 1 GB > Actual result > Upload failed with NPE > eryAsyncJobResult&jobId=960459e9-a299-4552-a56c-d11522271c4d&response=json&sessionkey=vp9T6C4z5OzLwUgMljRFFe2bUo0%3D&_=1366147860238 > 2013-04-16 17:34:00,975 ERROR [cloud.async.AsyncJobManagerImpl] > (Job-Executor-9:job-2285) Unexpected exception while executing > org.apache.cloudstack.api.command.user.volume.UploadVolumeCmd > java.lang.NumberFormatException: null > at java.lang.Long.parseLong(Long.java:401) > at java.lang.Long.parseLong(Long.java:478) > at com.cloud.utils.UriUtils.getRemoteSize(UriUtils.java:95) > at > com.cloud.storage.VolumeManagerImpl.validateVolume(VolumeManagerImpl.java:478) > at > com.cloud.storage.VolumeManagerImpl.uploadVolume(VolumeManagerImpl.java:377) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > com.cloud.storage.VolumeManagerImpl.uploadVolume(VolumeManagerImpl.java:175) > at > org.apache.cloudstack.api.command.user.volume.UploadVolumeCmd.execute(UploadVolumeCmd.java:121) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:164) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-04-16 17:34:00,976 DEBUG [cloud.async.AsyncJobManagerImpl] > (Job-Executor-9:job-2285) Complete async job-2285, jobStatus: 2, resultCode: > 530, result: Error Code: 530 Error text: null > 2013-04-16 17:34:01,620 DEBUG [storage.secondary.SecondaryStorageManagerImpl] > (secstorage-1:null) Zone 2 is ready to launch secondary storage VM > 2013-04-16 17:34:02,028 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] > (consoleproxy-1:null) Zone 2 is ready to launch console proxy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2279) Fail to clean up networks if expunge initially had a problem
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645108#comment-13645108 ] ASF subversion and git services commented on CLOUDSTACK-2279: - Commit a0dbf8909058dba202c057f5b9d589026399c6ef in branch refs/heads/internallb from Marcus Sorensen [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a0dbf89 ] Look for null pointer on account id before trying to update usage when releasing an IP. This seems to be possible if expunge fails at some point after freeing an IP, on subsequent expunge tries the IP is freed already and gets null pointer when looking for account id. BUG-ID: CLOUDSTACK-2279 Bugfix-for: 4.1,4.2 Signed-off-by: Marcus Sorensen 1367251304 -0600 > Fail to clean up networks if expunge initially had a problem > > > Key: CLOUDSTACK-2279 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2279 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0, 4.2.0 >Reporter: Marcus Sorensen >Assignee: Marcus Sorensen >Priority: Critical > Fix For: 4.1.0, 4.2.0 > > > Noticed today that I had some VMs stuck in expunging state. Looked into it > and found that expunge had failed for reasons that are cleared now, but > subsequent tries were failing because the IP was already released, and the > usage event was getting a null pointer when trying to look up the account. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645097#comment-13645097 ] Prachi Damle commented on CLOUDSTACK-2281: -- Marcus, do you still see as a blocker? Maybe we can lower the priority since the NPE fix unblocks the usecase. > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:job-9908) VM state transitted from :Stopped to Starting w
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645093#comment-13645093 ] Prachi Damle commented on CLOUDSTACK-2281: -- So given the process above, if planner returns poolId 204 in first pass (reserve), the poolId passed to the second pass (deploy) should be the same. But your logs show it to be 202. Hence was wondering about the volume_reservation entries in the DB > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013
[jira] [Commented] (CLOUDSTACK-2249) Automation: Add automtion for nTier Apps 2.0 Subtasks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645086#comment-13645086 ] Chandan Purushothama commented on CLOUDSTACK-2249: -- The Following N-Tier Features Test Plans are available at https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0 : 2.2 Load Balancing on all Tiers 2.3 Deployment of VM on a VPC Tier with one or more Shared Networks 2.6 Blacklist of Routes 2.14 Allow ACL on all level 4 protocols Test Plan 2.19 Add more than one Private GW to a VPC 2.20 Source NAT on Private Gateway 2.21 ACL on Private Gateway to the VPC FS of N-Tier Features are present at https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec > Automation: Add automtion for nTier Apps 2.0 Subtasks > - > > Key: CLOUDSTACK-2249 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2249 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sudha Ponnaganti > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645067#comment-13645067 ] Prachi Damle commented on CLOUDSTACK-2281: -- >>The part where I get lost is that even without triggering this bug, it looks >>like it goes into FirstFitPlanner, then advanceDeploy, then back into >>FirstFitPlanner. This is expected; the VM deployment is refactored and going through two stages: reserve and deploy. Earlier deploy used to take care of calling the planners and getting back a destination. Now we first do a reserve by calling planners and storing the destination the DB. Then the deploy gets called, and the reserved destination is passed back in. The deploy still calls the planners(to let other parts of code that arent yet refactored, work) - but planners don't do much now since the plan is already provided in this pass. > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645059#comment-13645059 ] Marcus Sorensen commented on CLOUDSTACK-2281: - I tried it about five times, and the result was the same each time. I only see 1 entry for vm_reservation_id 303 I only see 1 entry for 9c231db5-089b-4906-8ae8-d481c044cf55 in vm_reservation. The part where I get lost is that even without triggering this bug, it looks like it goes into FirstFitPlanner, then advanceDeploy, then back into FirstFitPlanner. > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(
[jira] [Updated] (CLOUDSTACK-2283) SRX - Delete Egress firewall rule failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angeline shen updated CLOUDSTACK-2283:
--
Attachment: management-server.log.gz
> SRX - Delete Egress firewall rule failed
>
>
> Key: CLOUDSTACK-2283
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2283
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MSACS 2.0 build 4/24/13 7:48 PM revision:
> 299cccf779f75c3ba04d9ec7303bed88394c3562
> host XS 6.0.2
>Reporter: angeline shen
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.gz
>
>
> MSACS 2.0 build 4/24/13 7:48 PM revision:
> 299cccf779f75c3ba04d9ec7303bed88394c3562
> host XS 6.0.2
> 1. SRX network offering : isolated DHCP: virtual router DNS: virtual router
> firewall: SRX userdata:virtual router sourceNAT: SRX staticNAT: SRX
> portforward: SRX sourceNAT type: perzone
> 2. advance zone, add SRX device for firewall.
>domain: ROOT admin
>create VM with network of above networking offering.
>Add egress ruleTCP port 22 22 for egress
> 3. Delete this egress rule failed:
> 2013-04-29 15:15:40,818 DEBUG [agent.transport.Request]
> (Job-Executor-24:job-19) Seq 5-1743912980: Received: { Ans: , MgmtId:
> 6655051826959, via: 5, Ver: v1, Flags: 10, { Answer } }
> 2013-04-29 15:15:40,818 DEBUG [agent.manager.AgentManagerImpl]
> (Job-Executor-24:job-19) Details from executing class
> com.cloud.agent.api.routing.SetFirewallRulesCommand: Exception:
> com.cloud.utils.exception.ExecutionException
> Message: Failed to open a private configuration.
> Stack: com.cloud.utils.exception.ExecutionException: Failed to open a private
> configuration.
> at
> com.cloud.network.resource.JuniperSrxResource.openConfiguration(JuniperSrxResource.java:617)
> at
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:827)
> at
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:869)
> at
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:869)
> at
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:821)
> at
> com.cloud.network.resource.JuniperSrxResource.executeRequest(JuniperSrxResource.java:349)
> 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-29 15:15:40,818 ERROR
> [cloud.network.ExternalFirewallDeviceManagerImpl] (Job-Executor-24:job-19)
> External firewall was unable to apply static nat rules to the SRX appliance
> in zone z1 due to: Exception: com.cloud.utils.exception.ExecutionException
> Message: Failed to open a private configuration.
> Stack: com.cloud.utils.exception.ExecutionException: Failed to open a private
> configuration.
> at
> com.cloud.network.resource.JuniperSrxResource.openConfiguration(JuniperSrxResource.java:617)
> at
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:827)
> at
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:869)
> at
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:869)
> at
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:821)
> at
> com.cloud.network.resource.JuniperSrxResource.executeRequest(JuniperSrxResource.java:349)
> 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$ScheduledFutureT
[jira] [Created] (CLOUDSTACK-2283) SRX - Delete Egress firewall rule failed
angeline shen created CLOUDSTACK-2283:
-
Summary: SRX - Delete Egress firewall rule failed
Key: CLOUDSTACK-2283
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2283
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.2.0
Environment: MSACS 2.0 build 4/24/13 7:48 PM revision:
299cccf779f75c3ba04d9ec7303bed88394c3562
host XS 6.0.2
Reporter: angeline shen
Assignee: Jayapal Reddy
Priority: Critical
Fix For: 4.2.0
MSACS 2.0 build 4/24/13 7:48 PM revision:
299cccf779f75c3ba04d9ec7303bed88394c3562
host XS 6.0.2
1. SRX network offering : isolated DHCP: virtual router DNS: virtual router
firewall: SRX userdata:virtual router sourceNAT: SRX staticNAT: SRX
portforward: SRX sourceNAT type: perzone
2. advance zone, add SRX device for firewall.
domain: ROOT admin
create VM with network of above networking offering.
Add egress ruleTCP port 22 22 for egress
3. Delete this egress rule failed:
2013-04-29 15:15:40,818 DEBUG [agent.transport.Request]
(Job-Executor-24:job-19) Seq 5-1743912980: Received: { Ans: , MgmtId:
6655051826959, via: 5, Ver: v1, Flags: 10, { Answer } }
2013-04-29 15:15:40,818 DEBUG [agent.manager.AgentManagerImpl]
(Job-Executor-24:job-19) Details from executing class
com.cloud.agent.api.routing.SetFirewallRulesCommand: Exception:
com.cloud.utils.exception.ExecutionException
Message: Failed to open a private configuration.
Stack: com.cloud.utils.exception.ExecutionException: Failed to open a private
configuration.
at
com.cloud.network.resource.JuniperSrxResource.openConfiguration(JuniperSrxResource.java:617)
at
com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:827)
at
com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:869)
at
com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:869)
at
com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:821)
at
com.cloud.network.resource.JuniperSrxResource.executeRequest(JuniperSrxResource.java:349)
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-29 15:15:40,818 ERROR [cloud.network.ExternalFirewallDeviceManagerImpl]
(Job-Executor-24:job-19) External firewall was unable to apply static nat rules
to the SRX appliance in zone z1 due to: Exception:
com.cloud.utils.exception.ExecutionException
Message: Failed to open a private configuration.
Stack: com.cloud.utils.exception.ExecutionException: Failed to open a private
configuration.
at
com.cloud.network.resource.JuniperSrxResource.openConfiguration(JuniperSrxResource.java:617)
at
com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:827)
at
com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:869)
at
com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:869)
at
com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:821)
at
com.cloud.network.resource.JuniperSrxResource.executeRequest(JuniperSrxResource.java:349)
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-0
[jira] [Assigned] (CLOUDSTACK-2282) Automation:Selenium: Configure headless mode
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar reassigned CLOUDSTACK-2282: -- Assignee: Parth Jagirdar > Automation:Selenium: Configure headless mode > > > Key: CLOUDSTACK-2282 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2282 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, UI >Affects Versions: 4.2.0 > Environment: NA >Reporter: Parth Jagirdar >Assignee: Parth Jagirdar > Fix For: 4.2.0 > > > Configure headless mode for Selenium automation using PhatomJS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645026#comment-13645026 ] Prachi Damle commented on CLOUDSTACK-2281: -- Or do you see duplicate entries in vm_reservation table for same uuid? > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:job-9908) VM state transitted from :Stopped to Starting with > event: StartRequestedvm's original
[jira] [Updated] (CLOUDSTACK-2282) Automation:Selenium: Configure headless mode
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar updated CLOUDSTACK-2282: --- Summary: Automation:Selenium: Configure headless mode (was: Automation:Seleium: Configure headless mode) > Automation:Selenium: Configure headless mode > > > Key: CLOUDSTACK-2282 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2282 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, UI >Affects Versions: 4.2.0 > Environment: NA >Reporter: Parth Jagirdar > Fix For: 4.2.0 > > > Configure headless mode for Selenium automation using PhatomJS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2282) Automation:Seleium: Configure headless mode
Parth Jagirdar created CLOUDSTACK-2282: -- Summary: Automation:Seleium: Configure headless mode Key: CLOUDSTACK-2282 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2282 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, UI Affects Versions: 4.2.0 Environment: NA Reporter: Parth Jagirdar Fix For: 4.2.0 Configure headless mode for Selenium automation using PhatomJS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644988#comment-13644988 ] Prachi Damle commented on CLOUDSTACK-2281: -- Weird. Is there any other volume_reservation for same vm_reservation_id or any entry with pool Id 202? Were you deploying VMs simultaneously? > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:job-9908) VM state tran
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644973#comment-13644973 ] Marcus Sorensen commented on CLOUDSTACK-2281: - Yes, I checked the reservation earlier as well and it looked correct: [root(marcus)@cloudcontrol1-test ~]# SELECT * FROM `cloud`.`vm_reservation` where vm_id = 6189;^C [root(marcus)@cloudcontrol1-test ~]# mysql -e 'SELECT * FROM `cloud`.`vm_reservation` where vm_id = 6189;' +-+--+---++++-+-+-+ | id | uuid | vm_id | data_center_id | pod_id | cluster_id | host_id | created | removed | +-+--+---++++-+-+-+ | 303 | 9c231db5-089b-4906-8ae8-d481c044cf55 | 6189 | 1 | 1 | 1 | 17 | 2013-04-29 19:25:49 | NULL| +-+--+---++++-+-+-+ [root(marcus)@cloudcontrol1-test ~]# mysql -e 'SELECT * FROM `cloud`.`volume_reservation`where vm_id = 6189;' +-+---+---+---+-+ | id | vm_reservation_id | vm_id | volume_id | pool_id | +-+---+---+---+-+ | 440 | 303 | 6189 | 10663 | 204 | +-+---+---+---+-+ > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644966#comment-13644966 ] Prachi Damle commented on CLOUDSTACK-2281: -- Thanks for the logs Marcus, can you please provide the DB output too. > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:job-9908) VM state transitted from :Stopped to Starting with > event: StartRequestedvm's original
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644945#comment-13644945 ] Prachi Damle commented on CLOUDSTACK-2281: -- Agreed. I spotted the missing check for fixing the NPE as well, and it will fix your situation for now as planner will go and choose another pool. But I need to figure out why the old poolId was being passed by the deploy - that seems to be the root cause. > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))
[jira] [Updated] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen updated CLOUDSTACK-2281: Attachment: job9908.txt job 9908 > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > Attachments: job9908.txt > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:job-9908) VM state transitted from :Stopped to Starting with > event: StartRequestedvm's original host id: null new host id: null host id > before state transition: null > 2013-04-
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644940#comment-13644940 ] Marcus Sorensen commented on CLOUDSTACK-2281: - Sure, will attach. I just submitted a patch that fixes the NPE, and it fixed the problem, but I think it's just a bandaid since in this case it looks like we choose pool 204, then the deploy decides it wants to use 202, but then finds it's invalid and selects a new one. I'd rather 202 not be passed in the first place, but I can't see where it's coming from. Still, this patch is enough I think to downgrade the bug, and it's probably a good sanity check to have anyway. https://reviews.apache.org/r/10842/ > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Jo
[jira] [Resolved] (CLOUDSTACK-2138) Web Client UI - Putting all translations files on master branch and automate with transifex upload/download
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber resolved CLOUDSTACK-2138. -- Resolution: Fixed Fix Version/s: 4.1.0 > Web Client UI - Putting all translations files on master branch and automate > with transifex upload/download > --- > > Key: CLOUDSTACK-2138 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2138 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Milamber >Assignee: Milamber > Labels: ui > Fix For: 4.1.0, 4.2.0 > > > This Jira ticket to follow this tasks: > Add missing translations relative to 4.1 version (resources files and > index.jsp) > Make alphabetical order for keys in messages_xx.properties > Convert all messages_xx.properties in ASCII with unicode > Add a double-backslash before quote ( \\' ) in messages_xx.properties for > some languages (to fix code errors in dictonary.jsp generated file) > Create a script to automate the conversion and communication with transifex > for upload/download (if it's possible with transifex client) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644917#comment-13644917 ] Prachi Damle commented on CLOUDSTACK-2281: -- Marcus, Also can you run following queries on your DB and paste the results here: That will be helpful to analyse the issue. Thank you! 1) SELECT * FROM `cloud`.`vm_reservation` where vm_id = 6189; 2) SELECT * FROM `cloud`.`volume_reservation`where vm_id = 6189; > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEB
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644881#comment-13644881 ] Prachi Damle commented on CLOUDSTACK-2281: -- Marcus, Can you please provide the entire log for job-9908? > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:job-9908) VM state transitted from :Stopped to Starting with > event: StartRequestedvm's original host id: null new host id: null host id > bef
[jira] [Assigned] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle reassigned CLOUDSTACK-2281: Assignee: Prachi Damle > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.1.0 > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:job-9908) VM state transitted from :Stopped to Starting with > event: StartRequestedvm's original host id: null new host id: null host id > before state transition: null > 2013-04-29 13:25:49,370 DEBUG [cloud.vm.VirtualMachineManagerImpl]
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644858#comment-13644858 ] Marcus Sorensen commented on CLOUDSTACK-2281: - As far as I can tell, the deployment planner returned the proper thing, and then the deployVirtualMachine was given an alternate plan. Your suggestion is worth looking into though. All volumes related to the removed primary storage were expunged prior to removing the primary storage. I don't know if it qualifies as a blocker or not, I just know that this test cluster is unable to deploy vms after what shouldn't be too uncommon of a scenario. > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Priority: Blocker > Fix For: 4.1.0 > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(I
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644853#comment-13644853 ] ASF IRC Bot commented on CLOUDSTACK-2281: - Comment from chipc via IRC: And is this actually a blocker severity? Does it still occur after the expunge interval has cleaned out the datastore in question? > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Priority: Blocker > Fix For: 4.1.0 > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:job-9908) VM state transitted from :Stopped to Starting with > event: StartRequest
[jira] [Commented] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644848#comment-13644848 ] ASF IRC Bot commented on CLOUDSTACK-2281: - Comment from chipc via IRC: Marcus, is it possible that the specific deployment planner in question doesn't exclude the appropriate states from it's selction list? > VM fails to deploy due to planner selecting deleted pool > > > Key: CLOUDSTACK-2281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Marcus Sorensen >Priority: Blocker > Fix For: 4.1.0 > > > Having trouble tracking this down. Here's what I did: > Created a 4.1 advanced zone > added primary storage A > deployed a template > deployed vms > added new primary storages > migrated VMs from primary storage A to others > removed initial primary storage A > try to deploy new vm from template, not working. It looks like the allocator > correctly finds and decides to use pool id 204, but somehow deployment is > actually attempted on deleted pool 202. See "Returning Deployment > Destination" and "DeploymentPlan is provided": > 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, > adding to list: 19 > 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning > 4 suitable hosts > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): > (10663,ROOT) > 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume > 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable > pools > 2013-04-29 13:25:49,302 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator has 1 pools to check for allocation > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 > 2013-04-29 13:25:49,304 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is localStorageAllocationNeeded? false > 2013-04-29 13:25:49,305 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) > Is storage pool shared? true > 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: > 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, > disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] > (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation > [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : > 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 > 2013-04-29 13:25:49,327 DEBUG > [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) > FirstFitStoragePoolAllocator returning 1 suitable storage pools > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Trying to find a potenial host and associated > storage pools from the suitable host/pool lists for this VM > 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable > storage pool for volume: ROOT > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Host: 17 can access pool: 204 > 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and > associated storage pools for this VM > 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:job-9908) Returning Deployment Destination: > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] > 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:job-9908) VM state transitted from :Stopped to Starting with > event: StartReq
[jira] [Created] (CLOUDSTACK-2281) VM fails to deploy due to planner selecting deleted pool
Marcus Sorensen created CLOUDSTACK-2281: --- Summary: VM fails to deploy due to planner selecting deleted pool Key: CLOUDSTACK-2281 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2281 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0 Reporter: Marcus Sorensen Priority: Blocker Fix For: 4.1.0 Having trouble tracking this down. Here's what I did: Created a 4.1 advanced zone added primary storage A deployed a template deployed vms added new primary storages migrated VMs from primary storage A to others removed initial primary storage A try to deploy new vm from template, not working. It looks like the allocator correctly finds and decides to use pool id 204, but somehow deployment is actually attempted on deleted pool 202. See "Returning Deployment Destination" and "DeploymentPlan is provided": 2013-04-29 13:25:49,293 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Found a suitable host, adding to list: 19 2013-04-29 13:25:49,294 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:job-9908 FirstFitRoutingAllocator) Host Allocator returning 4 suitable hosts 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:job-9908) Checking suitable pools for volume (Id, Type): (10663,ROOT) 2013-04-29 13:25:49,297 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:job-9908) We need to allocate new storagepool for this volume 2013-04-29 13:25:49,299 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:job-9908) Calling StoragePoolAllocators to find suitable pools 2013-04-29 13:25:49,302 DEBUG [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) Looking for pools in dc: 1 pod:1 cluster:1 2013-04-29 13:25:49,304 DEBUG [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) FirstFitStoragePoolAllocator has 1 pools to check for allocation 2013-04-29 13:25:49,304 DEBUG [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) Checking if storage pool is suitable, name: sansrv-row2-rack0 ,poolId: 204 2013-04-29 13:25:49,304 DEBUG [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) Is localStorageAllocationNeeded? false 2013-04-29 13:25:49,305 DEBUG [storage.allocator.AbstractStoragePoolAllocator] (Job-Executor-10:job-9908) Is storage pool shared? true 2013-04-29 13:25:49,309 DEBUG [cloud.storage.StorageManagerImpl] (Job-Executor-10:job-9908) Checking pool 204 for storage, totalSize: 11984676742758, usedBytes: 879609302221, usedPct: 0.07339449541286318, disable threshold: 0.85 2013-04-29 13:25:49,327 DEBUG [cloud.storage.StorageManagerImpl] (Job-Executor-10:job-9908) Checking pool: 204 for volume allocation [Vol[10663|vm=6189|ROOT]], maxSize : 11984676742758, totalAllocatedSize : 588879744000, askingSize : 8589934592, allocated disable threshold: 0.85 2013-04-29 13:25:49,327 DEBUG [storage.allocator.FirstFitStoragePoolAllocator] (Job-Executor-10:job-9908) FirstFitStoragePoolAllocator returning 1 suitable storage pools 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:job-9908) Trying to find a potenial host and associated storage pools from the suitable host/pool lists for this VM 2013-04-29 13:25:49,327 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:job-9908) Checking if host: 17 can access any suitable storage pool for volume: ROOT 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:job-9908) Host: 17 can access pool: 204 2013-04-29 13:25:49,330 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:job-9908) Found a potential host id: 17 name: ksrv2-000 and associated storage pools for this VM 2013-04-29 13:25:49,332 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:job-9908) Returning Deployment Destination: Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] : Dest[Zone(1)-Pod(1)-Cluster(1)-Host(17)-Storage(Volume(10663|ROOT-->Pool(204))] 2013-04-29 13:25:49,370 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:job-9908) VM state transitted from :Stopped to Starting with event: StartRequestedvm's original host id: null new host id: null host id before state transition: null 2013-04-29 13:25:49,370 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-10:job-9908) Successfully transitioned to start state for VM[User|marcus-deleteme] reservation id = dd7783f0-800a-481a-a407-88ec5262a397 2013-04-29 13:25:49,387 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-10:job-9908) Trying to deploy VM, vm has dcId: 1 and podId: null 2013-04-29 13:25:49,387 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-10:job-9908) advan
[jira] [Created] (CLOUDSTACK-2280) Automation: Ability to delete events and alerts
Sudha Ponnaganti created CLOUDSTACK-2280: Summary: Automation: Ability to delete events and alerts Key: CLOUDSTACK-2280 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2280 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sudha Ponnaganti -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2218) [web.context.ContextLoader] (main:null) Context initialization failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chip Childers resolved CLOUDSTACK-2218.
---
Resolution: Cannot Reproduce
I've been unable to reproduce this. Please provide more information about your
environment and / or setup process if this is still a problem using the HEAD
revision of the 4.1 branch.
> [web.context.ContextLoader] (main:null) Context initialization failed
> --
>
> Key: CLOUDSTACK-2218
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2218
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Install and Setup
>Affects Versions: 4.1.0
> Environment: ubuntu 12.04,kvm
>Reporter: terryye
>Priority: Critical
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> 2013-04-27 09:02:29,097 ERROR [web.context.ContextLoader] (main:null) Context
> initialization failed
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'consoleServlet': Injection of autowired dependencies failed;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Could not autowire field: com.cloud.vm.VirtualMachineManager
> com.cloud.servlet.ConsoleProxyServlet._vmMgr; nested exception is
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No matching
> bean of type [com.cloud.vm.VirtualMachineManager] found for dependency:
> expected at least 1 bean which qualifies as autowire candidate for this
> dependency. Dependency annotations: {@javax.inject.Inject()}
> at
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:287)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
> at
> org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383)
> at
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
> at
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4206)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4705)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601)
> at
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1079)
> at
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1002)
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065)
> at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBas
[jira] [Commented] (CLOUDSTACK-2218) [web.context.ContextLoader] (main:null) Context initialization failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644637#comment-13644637
]
Chip Childers commented on CLOUDSTACK-2218:
---
I don't understand what you mean when you write "Begin apply these fix". Did
you run into this with the latest code from the 4.1 branch?
> [web.context.ContextLoader] (main:null) Context initialization failed
> --
>
> Key: CLOUDSTACK-2218
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2218
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Install and Setup
>Affects Versions: 4.1.0
> Environment: ubuntu 12.04,kvm
>Reporter: terryye
>Priority: Critical
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> 2013-04-27 09:02:29,097 ERROR [web.context.ContextLoader] (main:null) Context
> initialization failed
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'consoleServlet': Injection of autowired dependencies failed;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Could not autowire field: com.cloud.vm.VirtualMachineManager
> com.cloud.servlet.ConsoleProxyServlet._vmMgr; nested exception is
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No matching
> bean of type [com.cloud.vm.VirtualMachineManager] found for dependency:
> expected at least 1 bean which qualifies as autowire candidate for this
> dependency. Dependency annotations: {@javax.inject.Inject()}
> at
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:287)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
> at
> org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383)
> at
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
> at
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4206)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4705)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601)
> at
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1079)
> at
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1002)
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065)
> at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)
> at
[jira] [Commented] (CLOUDSTACK-2035) Fix source NAT configuration with Cisco VNMC/ASA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644636#comment-13644636 ] Koushik Das commented on CLOUDSTACK-2035: - Out of office till 5/3. > Fix source NAT configuration with Cisco VNMC/ASA > > > Key: CLOUDSTACK-2035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.2.0 >Reporter: Koushik Das >Assignee: Koushik Das >Priority: Critical > Fix For: 4.2.0 > > > Fix source NAT configuration with Cisco VNMC/ASA -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2059) Support remove network over VMware deployments with dvSwitch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haroon abdelrahman updated CLOUDSTACK-2059: --- Priority: Critical (was: Major) > Support remove network over VMware deployments with dvSwitch > > > Key: CLOUDSTACK-2059 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2059 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi >Priority: Critical > Fix For: 4.2.0 > > > Remove network from user VM is supported in VMware only for standard > vSwitches. This need to be supported for dvSwitches as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2035) Fix source NAT configuration with Cisco VNMC/ASA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haroon abdelrahman updated CLOUDSTACK-2035: --- Priority: Critical (was: Major) > Fix source NAT configuration with Cisco VNMC/ASA > > > Key: CLOUDSTACK-2035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.2.0 >Reporter: Koushik Das >Assignee: Koushik Das >Priority: Critical > Fix For: 4.2.0 > > > Fix source NAT configuration with Cisco VNMC/ASA -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2169) Reset ASA 1000v appliance to factory setting as part of guest network cleanup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haroon abdelrahman updated CLOUDSTACK-2169: --- Priority: Critical (was: Major) > Reset ASA 1000v appliance to factory setting as part of guest network cleanup > - > > Key: CLOUDSTACK-2169 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2169 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.2.0 >Reporter: Koushik Das >Assignee: Koushik Das >Priority: Critical > Fix For: 4.2.0 > > > Expected behavior is that ASA 1000v should get cleaned up properly when > logical edge firewall is cleaned up in VNMC. But due to some issue with the > VNMC sometimes the cleanup doesn't happen. If the cleanup doesn't happen then > the ASA 1000v cannot be reused in a new guest network. > So the ASA 1000v needs to be cleaned up explicitly using some CLI commands. > As part of this SSH needs to be enabled on the ASA by the admin outside of CS > and store the SSH credentials with CS while registering ASA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2207) Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chip Childers resolved CLOUDSTACK-2207. --- Resolution: Fixed Nicolas: Please re-test. The version that you should set your system vm to is 3.0.5 for VMware system VMs. I "fixed" this by updating the release notes. > Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present > > > Key: CLOUDSTACK-2207 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2207 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.1.0 >Reporter: Nicolas Lamirault >Assignee: Chip Childers >Priority: Critical > Fix For: 4.1.0 > > > We're trying to upgrade from 2.2.14 to 4.1.0. > DatabaseUpgradeChecker failed : > 2013-04-26 12:11:45,205 ERROR [utils.component.ComponentContext] > (Timer-1:null) System integrity check failed. Refuse to startup > com.cloud.utils.exception.CloudRuntimeException: 3.0.0 VMware SystemVm > template not found. Cannot upgrade system Vms > at > com.cloud.upgrade.dao.Upgrade2214to30.updateSystemVms(Upgrade2214to30.java:713) > at > com.cloud.upgrade.dao.Upgrade2214to30.performDataMigration(Upgrade2214to30.java:82) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:258) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:379) > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:91) > at > com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > According to the documentation, there is no VMware SystemVm 3.0.0 to install. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2279) Fail to clean up networks if expunge initially had a problem
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644623#comment-13644623 ] ASF subversion and git services commented on CLOUDSTACK-2279: - Commit c7f43d8d69d46b8fbe3744b3ff7872ed959e713b in branch refs/heads/4.1 from Chip Childers [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7f43d8 ] Look for null pointer on account id before trying to update usage when releasing an IP. This seems to be possible if expunge fails at some point after freeing an IP, on subsequent expunge tries the IP is freed already and gets null pointer when looking for account id. BUG-ID: CLOUDSTACK-2279 Bugfix-for: 4.1,4.2 Signed-off-by: Marcus Sorensen 1367251304 -0600 > Fail to clean up networks if expunge initially had a problem > > > Key: CLOUDSTACK-2279 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2279 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0, 4.2.0 >Reporter: Marcus Sorensen >Assignee: Marcus Sorensen >Priority: Critical > Fix For: 4.1.0, 4.2.0 > > > Noticed today that I had some VMs stuck in expunging state. Looked into it > and found that expunge had failed for reasons that are cleared now, but > subsequent tries were failing because the IP was already released, and the > usage event was getting a null pointer when trying to look up the account. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2279) Fail to clean up networks if expunge initially had a problem
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chip Childers resolved CLOUDSTACK-2279. --- Resolution: Fixed > Fail to clean up networks if expunge initially had a problem > > > Key: CLOUDSTACK-2279 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2279 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0, 4.2.0 >Reporter: Marcus Sorensen >Assignee: Marcus Sorensen >Priority: Critical > Fix For: 4.1.0, 4.2.0 > > > Noticed today that I had some VMs stuck in expunging state. Looked into it > and found that expunge had failed for reasons that are cleared now, but > subsequent tries were failing because the IP was already released, and the > usage event was getting a null pointer when trying to look up the account. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-747) nTier Apps 2.0 : Internal Load Balancing between the tiers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-747: - Summary: nTier Apps 2.0 : Internal Load Balancing between the tiers (was: nTier Apps 2.0 : Load Balancing on all Tiers) Changed the issue subject to "Internal Load Balancing between the tiers" as this is what needs to be implemented to support LB on all the tiers. The example of deployment would be: 1) Create VPC with 2 tiers: Web and App 2) Provide public LB on Web tier 3) Create internal LB on the App tier, so the instances from the Web tier can access. FS link: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers > nTier Apps 2.0 : Internal Load Balancing between the tiers > --- > > Key: CLOUDSTACK-747 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-747 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Kishan Kavala >Assignee: Alena Prokharchyk > Fix For: 4.2.0 > > > This item is sub task (2.2) of > https://issues.apache.org/jira/browse/CLOUDSTACK-621 > Currently, Load Balancing VPC VR is only supported on one of the Tiers of an > nTier Application. With this release, CloudStack should support load > balancing on all tiers of an nTier application. > Use Case: Users would like to deploy a multi-tier application with the VR > load balancing each of the tiers. As a result, users would be able to provide > flexibility and elasticity at each tier of their application -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2207) Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chip Childers updated CLOUDSTACK-2207: -- Component/s: Doc Priority: Critical (was: Major) Assignee: Chip Childers > Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present > > > Key: CLOUDSTACK-2207 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2207 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.1.0 >Reporter: Nicolas Lamirault >Assignee: Chip Childers >Priority: Critical > Fix For: 4.1.0 > > > We're trying to upgrade from 2.2.14 to 4.1.0. > DatabaseUpgradeChecker failed : > 2013-04-26 12:11:45,205 ERROR [utils.component.ComponentContext] > (Timer-1:null) System integrity check failed. Refuse to startup > com.cloud.utils.exception.CloudRuntimeException: 3.0.0 VMware SystemVm > template not found. Cannot upgrade system Vms > at > com.cloud.upgrade.dao.Upgrade2214to30.updateSystemVms(Upgrade2214to30.java:713) > at > com.cloud.upgrade.dao.Upgrade2214to30.performDataMigration(Upgrade2214to30.java:82) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:258) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:379) > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:91) > at > com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > According to the documentation, there is no VMware SystemVm 3.0.0 to install. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2207) Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644618#comment-13644618 ] ASF subversion and git services commented on CLOUDSTACK-2207: - Commit 06371babe8b91c4dea7787eec5037ae780ac8226 in branch refs/heads/4.1 from Chip Childers [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=06371ba ] CLOUDSTACK-2207: Correcting the release notes to include the correct system VM template numbers for 2.x and 3.x to 4.1 upgrade instructions Signed-off-by: Chip Childers > Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present > > > Key: CLOUDSTACK-2207 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2207 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Nicolas Lamirault > Fix For: 4.1.0 > > > We're trying to upgrade from 2.2.14 to 4.1.0. > DatabaseUpgradeChecker failed : > 2013-04-26 12:11:45,205 ERROR [utils.component.ComponentContext] > (Timer-1:null) System integrity check failed. Refuse to startup > com.cloud.utils.exception.CloudRuntimeException: 3.0.0 VMware SystemVm > template not found. Cannot upgrade system Vms > at > com.cloud.upgrade.dao.Upgrade2214to30.updateSystemVms(Upgrade2214to30.java:713) > at > com.cloud.upgrade.dao.Upgrade2214to30.performDataMigration(Upgrade2214to30.java:82) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:258) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:379) > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:91) > at > com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > According to the documentation, there is no VMware SystemVm 3.0.0 to install. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2207) Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644607#comment-13644607 ] ASF IRC Bot commented on CLOUDSTACK-2207: - Comment from chipc via IRC: We need to s/systemvm-*-4.1.0/systemvm-*-3.0.0/gc in the release notes. > Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present > > > Key: CLOUDSTACK-2207 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2207 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Nicolas Lamirault > Fix For: 4.1.0 > > > We're trying to upgrade from 2.2.14 to 4.1.0. > DatabaseUpgradeChecker failed : > 2013-04-26 12:11:45,205 ERROR [utils.component.ComponentContext] > (Timer-1:null) System integrity check failed. Refuse to startup > com.cloud.utils.exception.CloudRuntimeException: 3.0.0 VMware SystemVm > template not found. Cannot upgrade system Vms > at > com.cloud.upgrade.dao.Upgrade2214to30.updateSystemVms(Upgrade2214to30.java:713) > at > com.cloud.upgrade.dao.Upgrade2214to30.performDataMigration(Upgrade2214to30.java:82) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:258) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:379) > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:91) > at > com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > According to the documentation, there is no VMware SystemVm 3.0.0 to install. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2279) Fail to clean up networks if expunge initially had a problem
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644600#comment-13644600 ] ASF subversion and git services commented on CLOUDSTACK-2279: - Commit a0dbf8909058dba202c057f5b9d589026399c6ef in branch refs/heads/master from Marcus Sorensen [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a0dbf89 ] Look for null pointer on account id before trying to update usage when releasing an IP. This seems to be possible if expunge fails at some point after freeing an IP, on subsequent expunge tries the IP is freed already and gets null pointer when looking for account id. BUG-ID: CLOUDSTACK-2279 Bugfix-for: 4.1,4.2 Signed-off-by: Marcus Sorensen 1367251304 -0600 > Fail to clean up networks if expunge initially had a problem > > > Key: CLOUDSTACK-2279 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2279 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0, 4.2.0 >Reporter: Marcus Sorensen >Assignee: Marcus Sorensen >Priority: Critical > Fix For: 4.1.0, 4.2.0 > > > Noticed today that I had some VMs stuck in expunging state. Looked into it > and found that expunge had failed for reasons that are cleared now, but > subsequent tries were failing because the IP was already released, and the > usage event was getting a null pointer when trying to look up the account. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2279) Fail to clean up networks if expunge initially had a problem
Marcus Sorensen created CLOUDSTACK-2279: --- Summary: Fail to clean up networks if expunge initially had a problem Key: CLOUDSTACK-2279 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2279 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0, 4.2.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Priority: Critical Fix For: 4.1.0, 4.2.0 Noticed today that I had some VMs stuck in expunging state. Looked into it and found that expunge had failed for reasons that are cleared now, but subsequent tries were failing because the IP was already released, and the usage event was getting a null pointer when trying to look up the account. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2207) Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644552#comment-13644552
]
Nicolas Lamirault commented on CLOUDSTACK-2207:
---
Hello,
This issue seems blocker ...
In file 'server/src/com/cloud/upgrade/dao/Upgrade2214to30.java',
DatabaseUpgrade depends on systemvm-vmware-3.0.0 :
//VMware
s_logger.debug("Updating VMware System Vms");
try {
//Get 3.0.0 VMware system Vm template Id
pstmt = conn.prepareStatement("select id from
`cloud`.`vm_template` where name = 'systemvm-vmware-3.0.0' and removed is
null");
rs = pstmt.executeQuery();
if(rs.next()){
long templateId = rs.getLong(1);
rs.close();
pstmt.close();
// change template type to SYSTEM
pstmt = conn.prepareStatement("update `cloud`.`vm_template`
set type='SYSTEM' where id = ?");
pstmt.setLong(1, templateId);
pstmt.executeUpdate();
pstmt.close();
// update templete ID of system Vms
pstmt = conn.prepareStatement("update `cloud`.`vm_instance`
set vm_template_id = ? where type <> 'User' and hypervisor_type = 'VMware'");
pstmt.setLong(1, templateId);
pstmt.executeUpdate();
pstmt.close();
} else {
if (VMware){
throw new CloudRuntimeException("3.0.0 VMware SystemVm
template not found. Cannot upgrade system Vms");
} else {
s_logger.warn("3.0.0 VMware SystemVm template not
found. VMware hypervisor is not used, so not failing upgrade");
}
}
} catch (SQLException e) {
throw new CloudRuntimeException("Error while updating VMware
systemVm template", e);
}
This upgrade (2.2.14 to 3.0) can't be done without this template.
> Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present
>
>
> Key: CLOUDSTACK-2207
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2207
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.1.0
>Reporter: Nicolas Lamirault
> Fix For: 4.1.0
>
>
> We're trying to upgrade from 2.2.14 to 4.1.0.
> DatabaseUpgradeChecker failed :
> 2013-04-26 12:11:45,205 ERROR [utils.component.ComponentContext]
> (Timer-1:null) System integrity check failed. Refuse to startup
> com.cloud.utils.exception.CloudRuntimeException: 3.0.0 VMware SystemVm
> template not found. Cannot upgrade system Vms
> at
> com.cloud.upgrade.dao.Upgrade2214to30.updateSystemVms(Upgrade2214to30.java:713)
> at
> com.cloud.upgrade.dao.Upgrade2214to30.performDataMigration(Upgrade2214to30.java:82)
> at
> com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:258)
> at
> com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:379)
> at
> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:91)
> at
> com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> According to the documentation, there is no VMware SystemVm 3.0.0 to install.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2138) Web Client UI - Putting all translations files on master branch and automate with transifex upload/download
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644521#comment-13644521 ] ASF subversion and git services commented on CLOUDSTACK-2138: - Commit 9ac03ffe076fb55598d5d846924191733b91ac16 in branch refs/heads/4.1 from [~milamber] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9ac03ff ] CLOUDSTACK-2138 - backport automate script to sync L10N resource files CS repo/transifex. First sync (upload source lang / download L10N resource files) > Web Client UI - Putting all translations files on master branch and automate > with transifex upload/download > --- > > Key: CLOUDSTACK-2138 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2138 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Milamber >Assignee: Milamber > Labels: ui > Fix For: 4.2.0 > > > This Jira ticket to follow this tasks: > Add missing translations relative to 4.1 version (resources files and > index.jsp) > Make alphabetical order for keys in messages_xx.properties > Convert all messages_xx.properties in ASCII with unicode > Add a double-backslash before quote ( \\' ) in messages_xx.properties for > some languages (to fix code errors in dictonary.jsp generated file) > Create a script to automate the conversion and communication with transifex > for upload/download (if it's possible with transifex client) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2278) TEST Ticket - Please Ignore
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644493#comment-13644493 ] ASF IRC Bot commented on CLOUDSTACK-2278: - Comment from Humbedooh via IRC: testing 1 2 3 4 > TEST Ticket - Please Ignore > --- > > Key: CLOUDSTACK-2278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2278 > Project: CloudStack > Issue Type: Wish > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chip Childers >Priority: Trivial > > We are going to test adding comments from irc with this ticket. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2207) Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644495#comment-13644495 ] Nicolas Lamirault commented on CLOUDSTACK-2207: --- I did as it says on page 50, installing a new system template : VMware Name: systemvm-vmware-4.1.0 Description: systemvm-vmware-4.1.0 URL: http://download.cloud.com/templates/burbank/burbank- systemvm-08012012.ova Zone: Choose the zone where this hypervisor is used Hypervisor: VMware Format: OVA OS Type: Debian GNU/Linux 5.0 (32-bit) Extractable: no Password Enabled: no Public: no Featured: no > Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present > > > Key: CLOUDSTACK-2207 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2207 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Nicolas Lamirault > Fix For: 4.1.0 > > > We're trying to upgrade from 2.2.14 to 4.1.0. > DatabaseUpgradeChecker failed : > 2013-04-26 12:11:45,205 ERROR [utils.component.ComponentContext] > (Timer-1:null) System integrity check failed. Refuse to startup > com.cloud.utils.exception.CloudRuntimeException: 3.0.0 VMware SystemVm > template not found. Cannot upgrade system Vms > at > com.cloud.upgrade.dao.Upgrade2214to30.updateSystemVms(Upgrade2214to30.java:713) > at > com.cloud.upgrade.dao.Upgrade2214to30.performDataMigration(Upgrade2214to30.java:82) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:258) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:379) > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:91) > at > com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > According to the documentation, there is no VMware SystemVm 3.0.0 to install. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2278) TEST Ticket - Please Ignore
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644494#comment-13644494 ] ASF IRC Bot commented on CLOUDSTACK-2278: - Comment from chipc via IRC: Thanks Humbedooh > TEST Ticket - Please Ignore > --- > > Key: CLOUDSTACK-2278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2278 > Project: CloudStack > Issue Type: Wish > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chip Childers >Priority: Trivial > > We are going to test adding comments from irc with this ticket. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2278) TEST Ticket - Please Ignore
Chip Childers created CLOUDSTACK-2278: - Summary: TEST Ticket - Please Ignore Key: CLOUDSTACK-2278 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2278 Project: CloudStack Issue Type: Wish Security Level: Public (Anyone can view this level - this is the default.) Reporter: Chip Childers Priority: Trivial We are going to test adding comments from irc with this ticket. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-847) [DOC] Document the ability to use multiple IP ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644482#comment-13644482 ] ASF subversion and git services commented on CLOUDSTACK-847: Commit 35b416616e451b984d85f198d721b8f0fdb3a47b in branch refs/heads/master from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=35b4166 ] CLOUDSTACK-847 api changes > [DOC] Document the ability to use multiple IP ranges > > > Key: CLOUDSTACK-847 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-847 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: David Nalley >Assignee: Radhika Nair > Fix For: 4.2.0 > > > Document the ability to make use of multiple IP ranges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2277) Add approriate message for the user informing about the absence of vm-tools when adding nics to vm on vmware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava updated CLOUDSTACK-2277: --- Description: When adding NICs to guest vm on vmware through addNicToVirtualMachine, vm tools must be installed on guestVms to allow hot nic plugin. This information should be made available to the user in logs. > Add approriate message for the user informing about the absence of vm-tools > when adding nics to vm on vmware > > > Key: CLOUDSTACK-2277 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2277 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, VMware >Affects Versions: 4.2.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > > When adding NICs to guest vm on vmware through addNicToVirtualMachine, vm > tools must be installed on guestVms to allow hot nic plugin. > This information should be made available to the user in logs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2277) Add approriate message for the user informing about the absence of vm-tools when adding nics to vm on vmware
Saksham Srivastava created CLOUDSTACK-2277: -- Summary: Add approriate message for the user informing about the absence of vm-tools when adding nics to vm on vmware Key: CLOUDSTACK-2277 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2277 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, VMware Affects Versions: 4.2.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-847) [DOC] Document the ability to use multiple IP ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644473#comment-13644473 ] ASF subversion and git services commented on CLOUDSTACK-847: Commit 02e5262a61d96393fcd3e6d9a3ec86db67428712 in branch refs/heads/master from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=02e5262 ] CLOUDSTACK-847 > [DOC] Document the ability to use multiple IP ranges > > > Key: CLOUDSTACK-847 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-847 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: David Nalley >Assignee: Radhika Nair > Fix For: 4.2.0 > > > Document the ability to make use of multiple IP ranges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-741) Granular Global Parameters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644470#comment-13644470 ] ASF subversion and git services commented on CLOUDSTACK-741: Commit deaf9106ca557a938edf25bee65cf6b4eb3ac03f in branch refs/heads/marvin_refactor from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=deaf910 ] CLOUDSTACK-741: Granular Global Parameters and adding fixes for CLOUDSTACK-2176, CLOUDSTACK-2198, CLOUDSTACK-2200 Adding the zone, cluster, account level parameters The parameters at scope (zone/cluster/pool/account) can be updated by updateConfiguration API with additional parameter zoneid/clusterid/accountid/storagepoolid Whenever these scoped parameters are used in CS they get value from the corresponding details table if not defined get value from global parameter. Same with the listConfiguration API with additional parameter zoneid/clusterid/accountid/storagepoolid > Granular Global Parameters > -- > > Key: CLOUDSTACK-741 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-741 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Manan Shah >Assignee: Harikrishna Patnala > Fix For: 4.2.0 > > > Requirements described at: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Granular+Global+Config+Parameters > Requirements discussion email thread link: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-702) Multiple IP Ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644471#comment-13644471 ] ASF subversion and git services commented on CLOUDSTACK-702: Commit b2fdd5e2a23b44e5976c7135632d1ca6ade57663 in branch refs/heads/marvin_refactor from [~sanjeevn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b2fdd5e ] CLOUDSTACK-702: Tests for Multiple IP Ranges 1. Adding a cidr in existing subnet 2. Adding a cidr in new subnet Signed-off-by: sanjeevneelarapu Signed-off-by: Prasanna Santhanam > Multiple IP Ranges > -- > > Key: CLOUDSTACK-702 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-702 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Manan Shah >Assignee: Bharat Kumar > Fix For: 4.2.0 > > > Requirements described at: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+Ranges > Requirements discussion email thread link: > http://markmail.org/search/?q=[ASFCS41]+Multiple+IP+Ranges+list%3Aorg.apache.incubator.cloudstack-dev -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2194) Upgrade from 2.2.14 to 4.1.0 failed due to encryption error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sebastien goasguen reassigned CLOUDSTACK-2194: -- Assignee: sebastien goasguen (was: edison su) > Upgrade from 2.2.14 to 4.1.0 failed due to encryption error > --- > > Key: CLOUDSTACK-2194 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2194 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Nicolas Lamirault >Assignee: sebastien goasguen >Priority: Blocker > Fix For: 4.1.0 > > > i'm trying to upgrade from 2.2.14 to 4.1.0. > After setting encryption like that : > $> cloud-setup-encryption -m cloudstackprp -k cloudstackprp > Preparing /etc/cloud/management/db.properties >[ OK ] > Processing encryption ... >[ OK ] > Finalizing setup ... > [ OK ] > CloudStack has successfully setup Encryption > I start Cloudstack. Output logs are here : http://pastebin.com/ZE99v90D > db.properties content is : > $> grep -v "#" /etc/cloudstack/management/db.properties|sort > cluster.node.IP=127.0.0.1 > cluster.servlet.port=9090 > db.awsapi.host=cloud-sql01-prp.cloud > db.awsapi.name=cloudbridge > db.awsapi.password=cloudstackprp > db.awsapi.port=3306 > db.awsapi.username=cloudstackprp > db.cloud.autoReconnect=true > db.cloud.encryption.type=file > db.cloud.encrypt.secret=ENC(dKaV+o5+JqtVi2tfo9xVn6eyUatFXwfZ) > db.cloud.host=cloud-sql01-prp.cloud > db.cloud.keyStore= > db.cloud.keyStorePassword= > db.cloud.maxActive=250 > db.cloud.maxIdle=30 > db.cloud.maxWait=1 > db.cloud.minEvictableIdleTimeMillis=24 > db.cloud.name=cloud > db.cloud.password=ENC(IhnVBWyQT2ES/YNjPleAz6GXHoGrVsvq) > db.cloud.poolPreparedStatements=false > db.cloud.port=3306 > db.cloud.testOnBorrow=true > db.cloud.testWhileIdle=true > db.cloud.timeBetweenEvictionRunsMillis=4 > db.cloud.trustStore= > db.cloud.trustStorePassword= > db.cloud.url.params=prepStmtCacheSize=517&cachePrepStmts=true > db.cloud.username=cloudstackprp > db.cloud.useSSL=false > db.cloud.validationQuery=SELECT 1 > db.simulator.autoReconnect=true > db.simulator.host=cloud-sql01-prp.cloud > db.simulator.maxActive=250 > db.simulator.maxIdle=30 > db.simulator.maxWait=1 > db.simulator.name=simulator > db.simulator.password=cloudstackprp > db.simulator.port=3306 > db.simulator.username=cloudstackprp > db.usage.autoReconnect=true > db.usage.host=cloud-sql01-prp.cloud > db.usage.maxActive=100 > db.usage.maxIdle=30 > db.usage.maxWait=1 > db.usage.name=cloud_usage > db.usage.password=ENC(K57vTmW5CYCKY5P0B4NoeUchMwBPb1Z3) > db.usage.port=3306 > db.usage.username=cloudstackprp > region.id=1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2207) Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644461#comment-13644461 ] Chip Childers commented on CLOUDSTACK-2207: --- Did you follow the instructions listed in the release notes to get the newer system VM? See the latest Apache_CloudStack-4.1.0-Release_Notes-en-US.pdf file from http://jenkins.cloudstack.org/job/docs-4.1-releasenotes/ . There is a section talking about the upgrade requiring changes to get the latest system VM images. > Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present > > > Key: CLOUDSTACK-2207 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2207 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Nicolas Lamirault > Fix For: 4.1.0 > > > We're trying to upgrade from 2.2.14 to 4.1.0. > DatabaseUpgradeChecker failed : > 2013-04-26 12:11:45,205 ERROR [utils.component.ComponentContext] > (Timer-1:null) System integrity check failed. Refuse to startup > com.cloud.utils.exception.CloudRuntimeException: 3.0.0 VMware SystemVm > template not found. Cannot upgrade system Vms > at > com.cloud.upgrade.dao.Upgrade2214to30.updateSystemVms(Upgrade2214to30.java:713) > at > com.cloud.upgrade.dao.Upgrade2214to30.performDataMigration(Upgrade2214to30.java:82) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:258) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:379) > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:91) > at > com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > According to the documentation, there is no VMware SystemVm 3.0.0 to install. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2276) NPE while attaching the volume to the instance which is created from ROOT Disk Snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644439#comment-13644439
]
Sailaja Mada commented on CLOUDSTACK-2276:
--
NPE is observed only when tried to attach the volume to the same instance[Which
root disk was used to create the snapshot and the snapshot to create volume).
> NPE while attaching the volume to the instance which is created from ROOT
> Disk Snapshot
> ---
>
> Key: CLOUDSTACK-2276
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2276
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Priority: Critical
>
> Setup: Advanced Networking Zone with Xen 6.1 , MS -RHEL 6.3
> Steps:
> 1. Deploy instance as ROOT admin
> 2. Create the snapshot from this instance ROOT disk
> 3. Create Volume from this snapshot
> 4. Try to attach this volume to the instance .
> Observation:
> NPE while attaching the volume to the instance which is created from ROOT
> Disk Snapshot
> 2013-04-29 16:51:02,412 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.144.6.19 -- GET
> command=attachVolume&id=3c8487fd-a30f-42d6-bc14-e19ec6c4090c&virtualMachineId=cc2a94bb-bdf0-4d36-9f2c-a501c75f53dd&response=json&sessionkey=50KnW0aaOd0wvF2hspe71pXsfqI%3D&_=1367234593280
> 2013-04-29 16:51:02,450 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-41:job-57) Executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for job-57
> 2013-04-29 16:51:02,528 DEBUG [cloud.storage.StorageManagerImpl]
> (Job-Executor-41:job-57) Checking pool: 1 for volume allocation
> [Vol[26|vm=null|DATADISK]], maxSize : 1759218630656, totalAllocatedSize :
> 108885410816, askingSize : 21474836480, allocated disable threshold: 0.85
> 2013-04-29 16:51:02,530 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-41:job-57) Trying to create
> org.apache.cloudstack.storage.volume.VolumeObject@28b8ef9e on
> org.apache.cloudstack.storage.datastore.DefaultPrimaryDataStore@57b82f5
> 2013-04-29 16:51:02,566 DEBUG [agent.transport.Request]
> (Job-Executor-41:job-57) Seq 1-1019093539: Sending { Cmd , MgmtId:
> 73143235720, via: 1, Ver: v1, Flags: 100111,
> [{"storage.CreateCommand":{"volId":26,"pool":{"id":1,"uuid":"ba45e9e1-5b6f-3005-a920-00c02a73d9e1","host":"10.102.192.100","path":"/cpg_vol/sailaja/masterxenps","port":2049,"type":"NetworkFilesystem"},"diskCharacteristics":{"size":21474836480,"tags":[],"type":"DATADISK","name":"VolumefromsnapshotofROOT15","useLocalStorage":false,"recreatable":true,"diskOfferingId":1,"volumeId":26},"templateUrl":"c2f7de45-83c8-40a8-9937-a450b0d8660a","wait":0}}]
> }
> 2013-04-29 16:51:02,577 DEBUG [agent.transport.Request]
> (Job-Executor-41:job-57) Seq 1-1019093539: Executing: { Cmd , MgmtId:
> 73143235720, via: 1, Ver: v1, Flags: 100111,
> [{"storage.CreateCommand":{"volId":26,"pool":{"id":1,"uuid":"ba45e9e1-5b6f-3005-a920-00c02a73d9e1","host":"10.102.192.100","path":"/cpg_vol/sailaja/masterxenps","port":2049,"type":"NetworkFilesystem"},"diskCharacteristics":{"size":21474836480,"tags":[],"type":"DATADISK","name":"VolumefromsnapshotofROOT15","useLocalStorage":false,"recreatable":true,"diskOfferingId":1,"volumeId":26},"templateUrl":"c2f7de45-83c8-40a8-9937-a450b0d8660a","wait":0}}]
> }
> 2013-04-29 16:51:02,592 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-343:null) Seq 1-1019093539: Executing request
> 2013-04-29 16:51:02,710 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-343:null) SR retrieved for ba45e9e1-5b6f-3005-a920-00c02a73d9e1
> 2013-04-29 16:51:02,726 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-343:null) Checking ba45e9e1-5b6f-3005-a920-00c02a73d9e1 or SR
> 527d8f70-7760-6381-04bf-2d7f86c7f037 on
> XS[40d72111-4e51-4bda-9d2a-65de0f1bebb5-10.102.192.13]
> 2013-04-29 16:51:02,809 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl]
> (consoleproxy-1:null) Zone 1 is ready to launch console proxy
> 2013-04-29 16:51:03,772 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-343:null) Succesfully created VDI for
> com.cloud.agent.api.storage.CreateCommand. Uuid =
> 2f8bfe2f-3cf4-4924-899d-0409c776430b
> 2013-04-29 16:51:03,773 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-343:null) Seq 1-1019093539: Response Received:
> 2013-04-29 16:51:03,773 DEBUG [agent.transport.Request]
> (DirectAgent-343:null) Seq 1-1019093539: Processing: { Ans: , MgmtId:
> 73143235720, via: 1, Ver: v1, Flags: 110,
> [{"storage.CreateAnswer":{"volume":{"id":26,"name":"VolumefromsnapshotofROOT15","mountPoint":"/cpg_vol/sailaja/masterxenps
[jira] [Assigned] (CLOUDSTACK-2107) Only scaling up memory(ram) in not triggering vm live migration ;Unable to scale vm due to Catch exception com.xensource.xenapi.Types$HostNotEnoughFreeMemory when s
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harikrishna Patnala reassigned CLOUDSTACK-2107:
---
Assignee: Harikrishna Patnala
> Only scaling up memory(ram) in not triggering vm live migration ;Unable to
> scale vm due to Catch exception
> com.xensource.xenapi.Types$HostNotEnoughFreeMemory when scaling VM:i-2-35-VM
> due to Not enough host memory is available to perform this operation
>
>
> Key: CLOUDSTACK-2107
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2107
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: prashant kumar mishra
>Assignee: Harikrishna Patnala
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: access_log.2013-04-19.txt, apilog.log, catalina.out,
> management-server.log, RamScaleUp.png
>
>
> For cpu scalup ,vms getting live migrated to other host in cluster if no
> resources are available on current host ,but not in case of RAM Scaleup
> Steps to reproduce
>
> 1-Create zone->pod->cluster with one host
> 2-Deploy vm so that no resource left on host
> 3-Add another host in same cluster
> 4- Try to scale up vm's ram (in new service offering keep cpu speed same as
> previous ,increase ram by 500 MB)
> Expected
> --
> since there is no resource left on current host vm should get live migrate to
> other available host and scaleup should be successful .
> Actual
> -
> scaleup failed due to not enough resource on current host,;CS did not try to
> live migrate vm to other host on cluster
> My observation
> --
> 1-VM are getting live migrated in case of cpu scale up if current host does
> not have resource
> 2-Tried to scaleup vm to service offering x failed but able to deploy a new
> vm with same service offering
> Service offering details
> --
> Tried to scaleup from SO 20 to SO 22
> 1-SO 22
> mysql> select * from service_offering_view where id=22 \G
> *** 1. row ***
>id: 22
> uuid: 528443f5-f044-4e64-b1e1-87f6c0136921
> name: smallcpu2ram
> display_text: smallcpu2ram
> created: 2013-04-18 18:48:17
> tags: NULL
> removed: NULL
> use_local_storage: 0
>system_use: 0
> cpu: 1
> speed: 1500
> ram_size: 1024
> nw_rate: NULL
> mc_rate: NULL
>ha_enabled: 0
> limit_cpu_use: 0
> host_tag: NULL
> default_use: 0
> vm_type: NULL
> sort_key: 0
> domain_id: NULL
> domain_uuid: NULL
> domain_name: NULL
> domain_path: NULL
> 1 row in set (0.00 sec)
> 2-SO 20
> mysql> select * from service_offering_view where id=20 \G
> *** 1. row ***
>id: 20
> uuid: 4bafd8c7-c8cc-42db-a630-61909556803b
> name: smallcpu2
> display_text: smallcpu2
> created: 2013-04-18 18:39:59
> tags: NULL
> removed: NULL
> use_local_storage: 0
>system_use: 0
> cpu: 1
> speed: 1500
> ram_size: 500
> nw_rate: NULL
> mc_rate: NULL
>ha_enabled: 0
> limit_cpu_use: 0
> host_tag: NULL
> default_use: 0
> vm_type: NULL
> sort_key: 5
> domain_id: NULL
> domain_uuid: NULL
> domain_name: NULL
> domain_path: NULL
> 1 row in set (0.00 sec)
> Snippet of MS Log
> ---
> 2013-04-19 07:40:58,312 DEBUG [agent.transport.Request] (DirectAgent-12:null)
> Seq 1-521863179: Processing: { Ans: , MgmtId: 7191687856187, via: 1, Ver:
> v1, Flags: 110, [{"ScaleVmAnswer":{"result":false,"details":"Catch exception
> com.xensource.xenapi.Types$HostNotEnoughFreeMemory when scaling VM:i-2-35-VM
> due to Not enough host memory is available to perform this
> operation","wait":0}}] }
> 2013-04-19 07:40:58,312 DEBUG [agent.transport.Request]
> (catalina-exec-6:null) Seq 1-521863179: Received: { Ans: , MgmtId:
> 7191687856187, via: 1, Ver: v1, Flags: 110, { ScaleVmAnswer } }
> 2013-04-19 07:40:58,312 ERROR [cloud.vm.VirtualMachineManagerImpl]
> (catalina-exec-6:null) Unable to scale vm due to Catch exception
> com.xensource.xenapi.Types$HostNotEnoughFreeMemory wh
[jira] [Commented] (CLOUDSTACK-2138) Web Client UI - Putting all translations files on master branch and automate with transifex upload/download
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644435#comment-13644435 ] ASF subversion and git services commented on CLOUDSTACK-2138: - Commit 8e5186daf1ffdf6a8c011dd803bd7b7094af1654 in branch refs/heads/master from [~milamber] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8e5186d ] CLOUDSTACK-2138 - Add Arabic L10N, fix a issue with sed on OSX, detab some lines > Web Client UI - Putting all translations files on master branch and automate > with transifex upload/download > --- > > Key: CLOUDSTACK-2138 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2138 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Milamber >Assignee: Milamber > Labels: ui > Fix For: 4.2.0 > > > This Jira ticket to follow this tasks: > Add missing translations relative to 4.1 version (resources files and > index.jsp) > Make alphabetical order for keys in messages_xx.properties > Convert all messages_xx.properties in ASCII with unicode > Add a double-backslash before quote ( \\' ) in messages_xx.properties for > some languages (to fix code errors in dictonary.jsp generated file) > Create a script to automate the conversion and communication with transifex > for upload/download (if it's possible with transifex client) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2276) NPE while attaching the volume to the instance which is created from ROOT Disk Snapshot
Sailaja Mada created CLOUDSTACK-2276:
Summary: NPE while attaching the volume to the instance which is
created from ROOT Disk Snapshot
Key: CLOUDSTACK-2276
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2276
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Storage Controller
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Priority: Critical
Setup: Advanced Networking Zone with Xen 6.1 , MS -RHEL 6.3
Steps:
1. Deploy instance as ROOT admin
2. Create the snapshot from this instance ROOT disk
3. Create Volume from this snapshot
4. Try to attach this volume to the instance .
Observation:
NPE while attaching the volume to the instance which is created from ROOT Disk
Snapshot
2013-04-29 16:51:02,412 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
===END=== 10.144.6.19 -- GET
command=attachVolume&id=3c8487fd-a30f-42d6-bc14-e19ec6c4090c&virtualMachineId=cc2a94bb-bdf0-4d36-9f2c-a501c75f53dd&response=json&sessionkey=50KnW0aaOd0wvF2hspe71pXsfqI%3D&_=1367234593280
2013-04-29 16:51:02,450 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-41:job-57) Executing
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for job-57
2013-04-29 16:51:02,528 DEBUG [cloud.storage.StorageManagerImpl]
(Job-Executor-41:job-57) Checking pool: 1 for volume allocation
[Vol[26|vm=null|DATADISK]], maxSize : 1759218630656, totalAllocatedSize :
108885410816, askingSize : 21474836480, allocated disable threshold: 0.85
2013-04-29 16:51:02,530 DEBUG [cloud.storage.VolumeManagerImpl]
(Job-Executor-41:job-57) Trying to create
org.apache.cloudstack.storage.volume.VolumeObject@28b8ef9e on
org.apache.cloudstack.storage.datastore.DefaultPrimaryDataStore@57b82f5
2013-04-29 16:51:02,566 DEBUG [agent.transport.Request]
(Job-Executor-41:job-57) Seq 1-1019093539: Sending { Cmd , MgmtId:
73143235720, via: 1, Ver: v1, Flags: 100111,
[{"storage.CreateCommand":{"volId":26,"pool":{"id":1,"uuid":"ba45e9e1-5b6f-3005-a920-00c02a73d9e1","host":"10.102.192.100","path":"/cpg_vol/sailaja/masterxenps","port":2049,"type":"NetworkFilesystem"},"diskCharacteristics":{"size":21474836480,"tags":[],"type":"DATADISK","name":"VolumefromsnapshotofROOT15","useLocalStorage":false,"recreatable":true,"diskOfferingId":1,"volumeId":26},"templateUrl":"c2f7de45-83c8-40a8-9937-a450b0d8660a","wait":0}}]
}
2013-04-29 16:51:02,577 DEBUG [agent.transport.Request]
(Job-Executor-41:job-57) Seq 1-1019093539: Executing: { Cmd , MgmtId:
73143235720, via: 1, Ver: v1, Flags: 100111,
[{"storage.CreateCommand":{"volId":26,"pool":{"id":1,"uuid":"ba45e9e1-5b6f-3005-a920-00c02a73d9e1","host":"10.102.192.100","path":"/cpg_vol/sailaja/masterxenps","port":2049,"type":"NetworkFilesystem"},"diskCharacteristics":{"size":21474836480,"tags":[],"type":"DATADISK","name":"VolumefromsnapshotofROOT15","useLocalStorage":false,"recreatable":true,"diskOfferingId":1,"volumeId":26},"templateUrl":"c2f7de45-83c8-40a8-9937-a450b0d8660a","wait":0}}]
}
2013-04-29 16:51:02,592 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-343:null) Seq 1-1019093539: Executing request
2013-04-29 16:51:02,710 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-343:null) SR retrieved for ba45e9e1-5b6f-3005-a920-00c02a73d9e1
2013-04-29 16:51:02,726 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-343:null) Checking ba45e9e1-5b6f-3005-a920-00c02a73d9e1 or SR
527d8f70-7760-6381-04bf-2d7f86c7f037 on
XS[40d72111-4e51-4bda-9d2a-65de0f1bebb5-10.102.192.13]
2013-04-29 16:51:02,809 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl]
(consoleproxy-1:null) Zone 1 is ready to launch console proxy
2013-04-29 16:51:03,772 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-343:null) Succesfully created VDI for
com.cloud.agent.api.storage.CreateCommand. Uuid =
2f8bfe2f-3cf4-4924-899d-0409c776430b
2013-04-29 16:51:03,773 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-343:null) Seq 1-1019093539: Response Received:
2013-04-29 16:51:03,773 DEBUG [agent.transport.Request] (DirectAgent-343:null)
Seq 1-1019093539: Processing: { Ans: , MgmtId: 73143235720, via: 1, Ver:
v1, Flags: 110,
[{"storage.CreateAnswer":{"volume":{"id":26,"name":"VolumefromsnapshotofROOT15","mountPoint":"/cpg_vol/sailaja/masterxenps","path":"2f8bfe2f-3cf4-4924-899d-0409c776430b","size":21474836480,"type":"DATADISK","storagePoolType":"NetworkFilesystem","storagePoolUuid":"ba45e9e1-5b6f-3005-a920-00c02a73d9e1","deviceId":0},"requestTemplateReload":false,"result":true,"wait":0}}]
}
2013-04-29 16:51:03,773 DEBUG [agent.transport.Request]
(Job-Executor-41:job-57) Seq 1-1019093539: Received: { Ans: , MgmtId:
73143235720, via: 1, Ver: v1, Flags: 110, { CreateAnswer } }
2013-04-29 16:51:03,777 DEBUG [agent.manager.AgentAttache]
(DirectAgent-343:null) Seq 1-1019093539: No m
[jira] [Assigned] (CLOUDSTACK-2113) There is no UI support for system VM scaleup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pranav Saxena reassigned CLOUDSTACK-2113: - Assignee: Pranav Saxena > There is no UI support for system VM scaleup > > > Key: CLOUDSTACK-2113 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2113 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra >Assignee: Pranav Saxena > Fix For: 4.2.0 > > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > UI supports are not available for system vms to scaleup -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2113) There is no UI support for system VM scaleup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pranav Saxena resolved CLOUDSTACK-2113. --- Resolution: Fixed UI support for system VMs to scale Up has been added now . > There is no UI support for system VM scaleup > > > Key: CLOUDSTACK-2113 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2113 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra >Assignee: Pranav Saxena > Fix For: 4.2.0 > > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > UI supports are not available for system vms to scaleup -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2146) system vm scaleup failed ;{ "scalevirtualmachineresponse" : {"errorcode":530,"cserrorcode":9999,"errortext":"Failed to scale vm"} }
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harikrishna Patnala reassigned CLOUDSTACK-2146:
---
Assignee: Harikrishna Patnala
> system vm scaleup failed ;{ "scalevirtualmachineresponse" :
> {"errorcode":530,"cserrorcode":,"errortext":"Failed to scale vm"} }
> ---
>
> Key: CLOUDSTACK-2146
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2146
> 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: Hyp:Xenserver ;commit
> "2057221f4f1fd5afde422b367fc416d4e44275cb"
>Reporter: prashant kumar mishra
>Assignee: Harikrishna Patnala
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: access_log.2013-04-23.txt, apilog.log, catalina.out,
> management-server.log, screenshot-1.jpg, SMlog, xensource.log
>
>
> Tried to scaleup system vms ,it failed with API response "{
> "scalevirtualmachineresponse" :
> {"errorcode":530,"cserrorcode":,"errortext":"Failed to scale vm"} }" and
> db got updated with new serivce offering .
> Steps to reproduce
> -
> 1-Create a system offering for console pvm say s1(ram= 1GB,cpu=1GHZ)
> 2-Scale up vm using API
> Expected
> ---
> VM should get scaled up to new SO
> Actual
>
> 1-Scaleup vm failed
> 2-New service offering got updated for console pvm in DB
> BD
> --
> mysql> select *from vm_instance where id=15\G;
> *** 1. row ***
> id: 15
>name: v-15-VM
>uuid: 0f8e8319-fdb3-4da1-b50c-aab2827d1c06
> instance_name: v-15-VM
> state: Running
> vm_template_id: 1
> guest_os_id: 133
> private_mac_address: 06:53:c8:00:00:03
> private_ip_address: 10.147.41.212
> pod_id: 1
> data_center_id: 1
> host_id: 5
>last_host_id: 5
>proxy_id: 15
> proxy_assign_time: 2013-04-23 11:37:51
>vnc_password: kEsfw5aA0VPlVqY3ohN7gWFN3Cr9BGFM41J+fcWpPTM=
> ha_enabled: 0
> limit_cpu_use: 0
>update_count: 7
> update_time: 2013-04-23 11:30:36
> created: 2013-04-23 11:24:07
> removed: NULL
>type: ConsoleProxy
> vm_type: ConsoleProxy
> account_id: 1
> domain_id: 1
> service_offering_id: 19
> reservation_id: d1cf507f-6a1f-4f3d-a380-59f57815a0b3
> hypervisor_type: XenServer
>disk_offering_id: NULL
> cpu: NULL
> ram: NULL
> owner: NULL
> speed: NULL
> host_name: NULL
>display_name: NULL
> desired_state: NULL
> 1 row in set (0.01 sec)
> mysql> select * from service_offering_view where id=19\G;
> *** 1. row ***
>id: 19
> uuid: b970c088-b4ba-4693-8a79-57ab84ad5c2b
> name: console
> display_text: console
> created: 2013-04-22 18:40:56
> tags: NULL
> removed: NULL
> use_local_storage: 0
>system_use: 1
> cpu: 1
> speed: 1000
> ram_size: 1024
> nw_rate: NULL
> mc_rate: NULL
>ha_enabled: 0
> limit_cpu_use: 0
> host_tag: NULL
> default_use: 0
> vm_type: consoleproxy
> sort_key: 0
> domain_id: NULL
> domain_uuid: NULL
> domain_name: NULL
> domain_path: NULL
> 1 row in set (0.00 sec)
> snippet of Management Server log
> --
> 2013-04-23 10:03:03,095 DEBUG [agent.transport.Request]
> (catalina-exec-24:null) Seq 5-264962068: Sending { Cmd , MgmtId:
> 7635042566263, via: 5, Ver: v1, Flags: 100111,
> [{"ScaleVmCommand":{"vm":{"id":1,"name":"v-15-VM","cpus":1,"speed":1000,"minRam":1024,"maxRam":1024,"rebootOnCrash":false,"enableHA":false,"limitCpuUse":false},"vmName":"v-15-VM","cpus":1,"speed":1000,"minRam":1024,"maxRam":1024,"wait":0}}]
> }
> 2013-04-23 10:03:03,096 DEBUG [agent.transport.Request]
> (catalina-exec-24:null) Seq 5-264962068: Executing: { Cmd , MgmtId:
> 7635042566263, via: 5, Ver: v1, Flags: 100111,
> [{"ScaleVmCommand":{"vm":{"id":1,"name":"v-15-VM","cpus":1,"speed":1000,"minRam":1024,"maxRam":1024,"rebootOnCrash":false,"enableHA":false,"limitCpuUse":false},"vmName":"v-15-VM","cpus":1,"speed":1000,"minRam":1024,"maxRam":1024,"wait":0}}]
> }
> 2013-04-23 10:03:03,097 DEBUG [agent.manager.DirectAgentAttache]
> (DirectA
[jira] [Commented] (CLOUDSTACK-2113) There is no UI support for system VM scaleup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644414#comment-13644414 ] ASF subversion and git services commented on CLOUDSTACK-2113: - Commit 6bf67c9f682740f22952a648d13e294cb97879c1 in branch refs/heads/master from [~pranav.sax...@citrix.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6bf67c9 ] CLOUDSTACK-2113:System VM scaleUp UI support > There is no UI support for system VM scaleup > > > Key: CLOUDSTACK-2113 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2113 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > UI supports are not available for system vms to scaleup -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2130) UpdateDefaultNicForVirtualMachine api should also create usage events for updating new default network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava reassigned CLOUDSTACK-2130: -- Assignee: Saksham Srivastava > UpdateDefaultNicForVirtualMachine api should also create usage events for > updating new default network > -- > > Key: CLOUDSTACK-2130 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2130 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Usage >Affects Versions: 4.2.0 > Environment: build: CloudStack-non-OSS-MASTER-232-rhel6.3 >Reporter: shweta agarwal >Assignee: Saksham Srivastava >Priority: Critical > Fix For: 4.2.0 > > > When we call UpdateDefaultNicForVirtualMachine we should call appropriate > usage events as well for updating information related to default nic for > proper usage calculation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2138) Web Client UI - Putting all translations files on master branch and automate with transifex upload/download
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644407#comment-13644407 ] ASF subversion and git services commented on CLOUDSTACK-2138: - Commit 0f2a249411635fff6e27092b2982dfe4a4e9c594 in branch refs/heads/master from [~milamber] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f2a249 ] CLOUDSTACK-2138 - add requirements in README to use sync-transifex-ui.sh script > Web Client UI - Putting all translations files on master branch and automate > with transifex upload/download > --- > > Key: CLOUDSTACK-2138 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2138 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Milamber >Assignee: Milamber > Labels: ui > Fix For: 4.2.0 > > > This Jira ticket to follow this tasks: > Add missing translations relative to 4.1 version (resources files and > index.jsp) > Make alphabetical order for keys in messages_xx.properties > Convert all messages_xx.properties in ASCII with unicode > Add a double-backslash before quote ( \\' ) in messages_xx.properties for > some languages (to fix code errors in dictonary.jsp generated file) > Create a script to automate the conversion and communication with transifex > for upload/download (if it's possible with transifex client) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2138) Web Client UI - Putting all translations files on master branch and automate with transifex upload/download
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644395#comment-13644395 ] ASF subversion and git services commented on CLOUDSTACK-2138: - Commit b633353fff295782a31db86f39f5b6b937b83377 in branch refs/heads/master from [~milamber] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b633353 ] CLOUDSTACK-2138 - first automate sync with Transifex. 1/ Upload the lastest EN resource file on Transifex. 2/ Download the lastest L10N resource file for "ca de_DE es fr_FR it_IT ja ko_KR nb_NO pt_BR ru_RU zh_CN" form Transifex to CS repo. > Web Client UI - Putting all translations files on master branch and automate > with transifex upload/download > --- > > Key: CLOUDSTACK-2138 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2138 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Milamber >Assignee: Milamber > Labels: ui > Fix For: 4.2.0 > > > This Jira ticket to follow this tasks: > Add missing translations relative to 4.1 version (resources files and > index.jsp) > Make alphabetical order for keys in messages_xx.properties > Convert all messages_xx.properties in ASCII with unicode > Add a double-backslash before quote ( \\' ) in messages_xx.properties for > some languages (to fix code errors in dictonary.jsp generated file) > Create a script to automate the conversion and communication with transifex > for upload/download (if it's possible with transifex client) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2207) Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Lamirault updated CLOUDSTACK-2207: -- Fix Version/s: 4.1.0 Affects Version/s: 4.1.0 > Upgrade from 2.2.14 to 4.1.0 failed due to system VM not present > > > Key: CLOUDSTACK-2207 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2207 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Nicolas Lamirault > Fix For: 4.1.0 > > > We're trying to upgrade from 2.2.14 to 4.1.0. > DatabaseUpgradeChecker failed : > 2013-04-26 12:11:45,205 ERROR [utils.component.ComponentContext] > (Timer-1:null) System integrity check failed. Refuse to startup > com.cloud.utils.exception.CloudRuntimeException: 3.0.0 VMware SystemVm > template not found. Cannot upgrade system Vms > at > com.cloud.upgrade.dao.Upgrade2214to30.updateSystemVms(Upgrade2214to30.java:713) > at > com.cloud.upgrade.dao.Upgrade2214to30.performDataMigration(Upgrade2214to30.java:82) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:258) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:379) > at > com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:91) > at > com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > According to the documentation, there is no VMware SystemVm 3.0.0 to install. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2138) Web Client UI - Putting all translations files on master branch and automate with transifex upload/download
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644393#comment-13644393 ] ASF subversion and git services commented on CLOUDSTACK-2138: - Commit 509cfa98567f3d64b6da8bcb50c3d18e6d2bc122 in branch refs/heads/master from [~milamber] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=509cfa9 ] CLOUDSTACK-2138 - add a sync-transifex-ui.sh script to automate the exchange between CloudStack L10N resource files and Transifex CS-UI resource files Signed-off-by: Milamber > Web Client UI - Putting all translations files on master branch and automate > with transifex upload/download > --- > > Key: CLOUDSTACK-2138 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2138 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Milamber >Assignee: Milamber > Labels: ui > Fix For: 4.2.0 > > > This Jira ticket to follow this tasks: > Add missing translations relative to 4.1 version (resources files and > index.jsp) > Make alphabetical order for keys in messages_xx.properties > Convert all messages_xx.properties in ASCII with unicode > Add a double-backslash before quote ( \\' ) in messages_xx.properties for > some languages (to fix code errors in dictonary.jsp generated file) > Create a script to automate the conversion and communication with transifex > for upload/download (if it's possible with transifex client) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2085) VM weight on xen remain same as before vmscaleup ;because "Add-To-VCPUs-Params-Live.sh" is not getting copied on xs host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala reassigned CLOUDSTACK-2085: --- Assignee: Harikrishna Patnala > VM weight on xen remain same as before vmscaleup ;because > "Add-To-VCPUs-Params-Live.sh" is not getting copied on xs host > - > > Key: CLOUDSTACK-2085 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2085 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.2.0 > > > Hypervisor Xen > Commit "2057221f4f1fd5afde422b367fc416d4e44275cb" > VM weight on xen is not getting changed after scaleup > Step to reproduce > > 1-Deployed a vm with service offering "small instance" (weight on xen 52) , > 2-Scaled up vm to service offering medium instance > Expected > - > after scale up VM should get weight according to new service offering > Actual > - > VM weight remain same as before scale up > Work around > --- > copy script "Add-To-VCPUs-Params-Live.sh" to /opt/xensource/bin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-301) Nexus 1000v DVS integration is not functional
[ https://issues.apache.org/jira/browse/CLOUDSTACK-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi resolved CLOUDSTACK-301. - Resolution: Fixed > Nexus 1000v DVS integration is not functional > - > > Key: CLOUDSTACK-301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: pre-4.0.0 >Reporter: Sailaja Mada >Assignee: Sateesh Chodapuneedi >Priority: Critical > Fix For: 4.2.0 > > Attachments: api-server.log, catalina.out, management-server.log > > > Setup: Management Server [ RHEL 6.3] ,VMWARE - ESXi5 , Nexus : > Nexus1000v.4.2.1.SV1.5.1 > Build :CloudStack-non-OSS-106.tar > Steps: > 1. Deploy VSM @ Vcenter > 2. Create port-profile sailajapp > 3. Set global setting vmware.use.nexus.vswitch to true > 4. Tried to configure advanced Zone with traffic lable as sailajapp > Observation: > It Failed to add Cluster with Nexus Switch . > ERROR Log: > 2012-10-09 14:10:04,301 INFO [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-23:null) Detected private network label : sailajapp > 2012-10-09 14:10:04,303 INFO [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-23:null) Detected public network label : sailajapp > 2012-10-09 14:10:04,305 INFO [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-23:null) Detected guest network label : sailajapp > 2012-10-09 14:10:04,310 INFO [vmware.manager.VmwareManagerImpl] > (catalina-exec-23:null) Found empty vsmMapVO. > 2012-10-09 14:10:04,313 DEBUG [vmware.resource.VmwareContextFactory] > (catalina-exec-23:null) initialize VmwareContext. url: > https://10.102.125.241/sdk/vimService, username: administrator, password: > f** > 2012-10-09 14:10:13,505 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] > (consoleproxy-1:null) Skip capacity scan due to there is no Primary Storage > UPintenance mode > 2012-10-09 14:10:14,053 DEBUG > [network.router.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:null) Found 0 routers. > 2012-10-09 14:10:19,354 INFO [vmware.manager.VmwareManagerImpl] > (catalina-exec-23:null) Calling prepareNetwork : > com.cloud.hypervisor.vmware.util.VmwareContext@40e83e52 > 2012-10-09 14:10:19,355 INFO [vmware.manager.VmwareManagerImpl] > (catalina-exec-23:null) Preparing Network on sailajapp > 2012-10-09 14:10:19,824 INFO [vmware.mo.HypervisorHostHelper] > (catalina-exec-23:null) Found Ethernet port profile sailajapp > 2012-10-09 14:10:20,298 INFO [vmware.mo.HypervisorHostHelper] > (catalina-exec-23:null) Port profile cloud.private.untagged.0.1-sailajapp not > found. > 2012-10-09 14:10:20,298 ERROR [vmware.mo.HypervisorHostHelper] > (catalina-exec-23:null) Failed to retrieve required credentials of Nexus VSM > from database. > 2012-10-09 14:10:20,301 WARN [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-23:null) Unable to connect to Vmware vSphere server. service > address: 10.102.125.241 > 2012-10-09 14:10:20,528 WARN [cloud.resource.ResourceManagerImpl] > (catalina-exec-23:null) Unable to find the server resources at > http://10.102.125.241/newdc/newcluster > 2012-10-09 14:10:20,574 WARN [api.commands.AddClusterCmd] > (catalina-exec-23:null) Exception: > com.cloud.exception.DiscoveryException: Unable to add the external cluster > at > com.cloud.resource.ResourceManagerImpl.discoverCluster(ResourceManagerImpl.java:487) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.api.commands.AddClusterCmd.execute(AddClusterCmd.java:153) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:543) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:422) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:63) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valv
[jira] [Commented] (CLOUDSTACK-957) Localization -- Add UK keyboard support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644376#comment-13644376 ] Sanjay Tripathi commented on CLOUDSTACK-957: The patch is available for review at : https://reviews.apache.org/r/10836/ > Localization -- Add UK keyboard support > --- > > Key: CLOUDSTACK-957 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-957 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VNC Proxy >Affects Versions: 4.1.0 >Reporter: Fang Wang >Assignee: Sanjay Tripathi > > Add UK keyboard support to Cloudstack -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-957) Localization -- Add UK keyboard support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-957: --- Status: Ready To Review (was: In Progress) > Localization -- Add UK keyboard support > --- > > Key: CLOUDSTACK-957 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-957 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VNC Proxy >Affects Versions: 4.1.0 >Reporter: Fang Wang >Assignee: Sanjay Tripathi > > Add UK keyboard support to Cloudstack -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2201) Failed to start MS after fresh installation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644374#comment-13644374 ] Srikanteswararao Talluri commented on CLOUDSTACK-2201: -- Is some one looking at this? > Failed to start MS after fresh installation > > > Key: CLOUDSTACK-2201 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2201 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 > Environment: CentOS 6.3 build > Branch master >Reporter: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CLOUDSTACK-2201.rar > > > Step 1 :Install MS from master branch build > Step 2 : execute > cloudstack-setup-databases cloud:password@localhost --deploy-as=root:password > cloudstack-setup-management > Actual result > Failed to management server, with below error in MS log > 2013-04-25 22:01:06,030 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (Timer-1:null) DB version = 4.0.0 Code Version = 4.2.0-SNAPSHOT > 2013-04-25 22:01:06,030 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (Timer-1:null) Database upgrade must be performed from 4.0.0 to 4.2.0-SNAPSHOT > 2013-04-25 22:01:06,030 ERROR [cloud.upgrade.DatabaseUpgradeChecker] > (Timer-1:null) The end upgrade version is actually at 4.1.0 but our > management server code version is at 4.2.0-SNAPSHOT > 2013-04-25 22:01:06,036 ERROR [utils.component.ComponentContext] > (Timer-1:null) System integrity check failed. Refuse to startup > Is it happening due to below check-in ? > Commit 099677a1244cd55fb98d3c40ee7881223dd9ac7c by chip.childers > CLOUDSTACK-2172: adding database upgrade to 4.1.0 in > PremiumDatabaseUpgradeChecker > Add migration to 4.1.0 in the PremiumDatabaseUpgradeChecker, like in the > DatabaseUpgradeChecker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2274) The detail view doesn't recover from loading status when trying to delete a zone with physical network on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isaac Chiang reassigned CLOUDSTACK-2274: Assignee: Isaac Chiang > The detail view doesn't recover from loading status when trying to delete a > zone with physical network on it > > > Key: CLOUDSTACK-2274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI > Environment: Mater >Reporter: Isaac Chiang >Assignee: Isaac Chiang >Priority: Minor > Labels: ui > Attachments: Screen Shot 2013-04-29 at 11.05.11 AM.png, Screen Shot > 2013-04-29 at 11.05.17 AM.png > > > When trying to delete a zone without removing the physical network first, it > shows an error message with "The zone is not deletable because there are pods > in this zone". Once you close the message dialog, the detail view wont > recover from loading stage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-492) Document procedure to choose default System Offering for System VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radhika Nair resolved CLOUDSTACK-492. - Resolution: Fixed > Document procedure to choose default System Offering for System VMs > --- > > Key: CLOUDSTACK-492 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-492 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 >Reporter: Kirk Kosinski >Assignee: Radhika Nair >Priority: Minor > Labels: adminguide > > While it is possible to manually change the System Offering for a particular > System VM, a CloudStack administrator may want to change the System Offering > used by default for System VMs. It would be useful for this procedure to be > documented. The following procedure works for me on CloudStack 3.0.2 and > 4.0.0-incubating. > 1. Create a new system offering with the desired settings. This can be done > via UI under the Service Offerings tab. > 2. Back up the database. > mysqldump -u root -p cloud | bzip2 > cloud_backup.sql.bz2 > 3. Open a mysql prompt to be able to run queries in later steps on the cloud > database. > mysql -u cloud -p cloud > 4. In the disk_offering table in the database, identify the original default > offering and the new offering you wish to be used by default. Make a note of > their id. > select id,name,unique_name,type from disk_offering; > 5. Set unique_name = NULL for the original default offering. It is important > to use the correct value for id. > update disk_offering set unique_name = NULL where id = 10; > 6. For the new offering you wish to be used by default, set unique_name = > 'Cloud.com-ConsoleProxy' (for the default CPVM offering) or > 'Cloud.com-SecondaryStorage' (for the default SSVM offering). > update disk_offering set unique_name = 'Cloud.com-ConsoleProxy' where id = > 16; > 7. Restart CloudStack. This is required because the default offerings are > loaded into memory at start-up. > service cloud-management restart > 8. Destroy the existing CPVM or SSVM and wait for it to be recreated. The new > CPVM or SSVM will be configured with the new offering. > Note that CLOUDSTACK-338 seems to be requesting that the string used in > unique_name be changed. When that happens, this procedure would need to be > updated with the correct string. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-1567) Document ability to delete events and alerts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radhika Nair resolved CLOUDSTACK-1567. -- Resolution: Fixed > Document ability to delete events and alerts > > > Key: CLOUDSTACK-1567 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1567 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: Radhika Nair >Priority: Minor > Fix For: 4.2.0 > > Attachments: events.html > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2275) Documentation for Egress Firewall Support
Radhika Nair created CLOUDSTACK-2275: Summary: Documentation for Egress Firewall Support Key: CLOUDSTACK-2275 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2275 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Reporter: Radhika Nair Assignee: Radhika Nair -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-958) Localization -- Add Japanese language keyboard support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi reassigned CLOUDSTACK-958: -- Assignee: Sanjay Tripathi (was: Anshul Gangwar) > Localization -- Add Japanese language keyboard support > --- > > Key: CLOUDSTACK-958 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-958 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VNC Proxy >Affects Versions: 4.1.0 >Reporter: Fang Wang >Assignee: Sanjay Tripathi > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-741) Granular Global Parameters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644367#comment-13644367 ] ASF subversion and git services commented on CLOUDSTACK-741: Commit deaf9106ca557a938edf25bee65cf6b4eb3ac03f in branch refs/heads/master from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=deaf910 ] CLOUDSTACK-741: Granular Global Parameters and adding fixes for CLOUDSTACK-2176, CLOUDSTACK-2198, CLOUDSTACK-2200 Adding the zone, cluster, account level parameters The parameters at scope (zone/cluster/pool/account) can be updated by updateConfiguration API with additional parameter zoneid/clusterid/accountid/storagepoolid Whenever these scoped parameters are used in CS they get value from the corresponding details table if not defined get value from global parameter. Same with the listConfiguration API with additional parameter zoneid/clusterid/accountid/storagepoolid > Granular Global Parameters > -- > > Key: CLOUDSTACK-741 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-741 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Manan Shah >Assignee: Harikrishna Patnala > Fix For: 4.2.0 > > > Requirements described at: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Granular+Global+Config+Parameters > Requirements discussion email thread link: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2274) The detail view doesn't recover from loading status when trying to delete a zone with physical network on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isaac Chiang updated CLOUDSTACK-2274: - Attachment: Screen Shot 2013-04-29 at 11.05.17 AM.png Screen Shot 2013-04-29 at 11.05.11 AM.png > The detail view doesn't recover from loading status when trying to delete a > zone with physical network on it > > > Key: CLOUDSTACK-2274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI > Environment: Mater >Reporter: Isaac Chiang >Priority: Minor > Labels: ui > Attachments: Screen Shot 2013-04-29 at 11.05.11 AM.png, Screen Shot > 2013-04-29 at 11.05.17 AM.png > > > When trying to delete a zone without removing the physical network first, it > shows an error message with "The zone is not deletable because there are pods > in this zone". Once you close the message dialog, the detail view wont > recover from loading stage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2274) The detail view doesn't recover from loading status when trying to delete a zone with physical network on it
Isaac Chiang created CLOUDSTACK-2274: Summary: The detail view doesn't recover from loading status when trying to delete a zone with physical network on it Key: CLOUDSTACK-2274 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2274 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Environment: Mater Reporter: Isaac Chiang Priority: Minor When trying to delete a zone without removing the physical network first, it shows an error message with "The zone is not deletable because there are pods in this zone". Once you close the message dialog, the detail view wont recover from loading stage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
