[jira] [Created] (CLOUDSTACK-9727) Password reset discrepancy in RVR when one of the Router is not in Running state.
Bharat Kumar created CLOUDSTACK-9727: Summary: Password reset discrepancy in RVR when one of the Router is not in Running state. Key: CLOUDSTACK-9727 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9727 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.9.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.9.2.0 - Deploy an instance and place " cloud-set-guest-password " script in the /etc/init.d location and provide the executable permission. - Create a template from the above VM. - Create a new network offering with RVR enabled. - Deploy a new VM from the above created template and select the above RVR offering. - Ensure that the password script is sucessfuly running. - Put the backup router in stopped state and ensure only master is running. - Now stop the VM and and Reset the password. - DO not start the VM , Now Stop the current Master and start the Back up. - Now the Back Up would be the Master. Now start the VM. Observations: - The password is saved onto only Master which is in stopped state now or either in backup if we start it. - The current Master which was back up earlier do not have the new password. Hence user cannot now login with the new password. - In this scenario there is disperancy in the password stored on both the RVR's. The only way to sync both the passwords now is , ensure both the RVR are running and reset the password on VM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9726) state of the rvr dose not change to update failed when updating rvrs in sequence to a new offering fails.
Bharat Kumar created CLOUDSTACK-9726: Summary: state of the rvr dose not change to update failed when updating rvrs in sequence to a new offering fails. Key: CLOUDSTACK-9726 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9726 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.9.0 state of the rvr dose not change to update failed when updating rvrs in sequence to a new offering fails. Create two Network offerings - RVR1 , RVR2 with RVR enabled. Deploy an instance by selecting RVR1 offering for the new Network and ensure virtual routers are deployed and are in Running State. Update the network by setting the parameter Updateinsequence to true with offering ID RVR2. While the Network update is in progress , put the Primary Storage in Maintenance Mode. Observations: Pre-Network Update states : VR 1 - UPdate Complete , VR 2 - Update in Progress States after Host in maintenance mode : Routers moved to stopped state. VR 1 - Update needed , VR 2 , VR3 : Update in Progress . States after cancelling maintenance mode: VR 1 - Update needed , VR 2 , VR 3 : Update in Progress . Events shows Network update to new offering failed and following exceptions are seen in logs . Execpetion during host in maintenance mode : 2016-01-01 08:44:44,453 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-21:ctx-96b2541b job-49/job-56) (logid:b50e7b75) Remove job-56 from job monitoring 2016-01-01 08:44:44,458 DEBUG [c.c.n.NetworkModelImpl] (API-Job-Executor-23:ctx-febc4ccc job-49 ctx-82bfdcbd) (logid:b50e7b75) Service SecurityGroup is not supported in the network id=205 2016-01-01 08:44:44,470 WARN [c.c.n.NetworkServiceImpl] (API-Job-Executor-23:ctx-febc4ccc job-49 ctx-82bfdcbd) (logid:b50e7b75) Failed to implement network Ntwk[205|Guest|17] elements and resources as a part of network update due to com.cloud.exception.AgentUnavailableException: Resource [Host:1] is unreachable: Host 1: Unable to send class com.cloud.agent.api.routing.AggregationControlCommand because agent perf04 is in maintenance mode at com.cloud.agent.manager.AgentAttache.checkAvailability(AgentAttache.java:165) at com.cloud.agent.manager.ClusteredAgentAttache.checkAvailability(ClusteredAgentAttache.java:82) at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:346) at com.cloud.agent.manager.ClusteredAgentAttache.send(ClusteredAgentAttache.java:141) at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:395) at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:457) at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:974) at com.cloud.network.router.NetworkHelperImpl.sendCommandsToRouter(NetworkHelperImpl.java:180) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.aggregationExecution(VirtualNetworkApplianceManagerImpl.java:2765) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.prepareAggregatedExecution(VirtualNetworkApplianceManagerImpl.java:2778) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy218.prepareAggregatedExecution(Unknown Source) at com.cloud.network.element.VirtualRouterElement.prepareAggregatedExecution(VirtualRouterElement.java:1271) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1135) at com.cloud.network.NetworkServiceImpl.updateGuestNetwork(NetworkServiceImpl.java:2379) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl
[jira] [Created] (CLOUDSTACK-9725) Failed to update VPC Network during N/w offering Upgrade which doesnt have ACL service Enabled. check if acl service provider is configured when network is assoc
Bharat Kumar created CLOUDSTACK-9725: Summary: Failed to update VPC Network during N/w offering Upgrade which doesnt have ACL service Enabled. check if acl service provider is configured when network is associated with a acl. Key: CLOUDSTACK-9725 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9725 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.9.0 - Create a VPC set up with default Offering : " Default VPC offering ". - Create a tier T1 with default offering : " Offering for Isolated Vpc networks with Source Nat service enabled". - Perform few operation such as Deploy instance , configure Public IP etc. - CReate a new VPC network offering (vpc1) which doesnt have ' Network ACL' service enabled. - Now try to Update the offering ID of T1 with the new offering (vpc1). Observations : - Since this is a network offering degrade ( i.e it doesnt have Network ACL service as compared to the existing default offering ) it throws a status message saying [ " The new offering:vpc1 will remove the following services [NetworkACL, PortForwarding, StaticNat, UserData, Vpn]along with all the related configuration currently in use. will not proceed with the network update.set forced parameter to true for forcing an update.] - after issuing an API with forced parameter set to true following is the exception observed : - When a tier is created with a VPC network offering which doesnt have ACL service enabled : following error message is observed " Cannot apply NetworkACL. Network Offering does not support NetworkACL service " 2016-01-04 16:42:01,140 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-244:ctx-056cc899) (logid:877ad8b1) Seq 6-5478347471719527904: Response Received: 2016-01-04 16:42:01,143 DEBUG [c.c.a.t.Request] (DirectAgent-244:ctx-056cc899) (logid:877ad8b1) Seq 6-5478347471719527904: Processing: { Ans: , MgmtId: 7203499016310, via: 6(10.147.28.36), Ver: v1, Flags: 10, [{"com.cloud.agent.api.Answer":{"result":true,"details":"Command aggregation started","wait":0}}] } 2016-01-04 16:42:01,143 DEBUG [c.c.a.t.Request] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) Seq 6-5478347471719527904: Received: { Ans: , MgmtId: 7203499016310, via: 6(10.147.28.36), Ver: v1, Flags: 10, { Answer } } 2016-01-04 16:42:01,144 DEBUG [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) Reprogramming network Ntwk[222|Guest|20] as a part of network implement 2016-01-04 16:42:01,197 DEBUG [c.c.n.f.FirewallManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) There are no firewall rules to apply 2016-01-04 16:42:01,267 DEBUG [c.c.n.r.RulesManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) There are no static nat to apply for network id=222 2016-01-04 16:42:01,274 DEBUG [c.c.n.f.FirewallManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) There are no firewall rules to apply 2016-01-04 16:42:01,304 DEBUG [c.c.n.r.RulesManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) There are no port forwarding rules to apply for network id=222 2016-01-04 16:42:01,321 DEBUG [c.c.n.r.RulesManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) There are no static nat rules to apply for network id=222 2016-01-04 16:42:01,391 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) Applying load balancer rules of scheme Public in network id=222 2016-01-04 16:42:01,394 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) There are no Load Balancing Rules to forward to the network elements 2016-01-04 16:42:01,405 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) Applying load balancer rules of scheme Internal in network id=222 2016-01-04 16:42:01,407 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) There are no Load Balancing Rules to forward to the network elements 2016-01-04 16:42:01,578 DEBUG [c.c.n.v.NetworkACLManagerImpl] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) Unable to find NetworkACL service provider for network: 222 2016-01-04 16:42:01,589 WARN [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) Failed to reapply network ACLs as a part of of network id=222 restart 2016-01-04 16:42:01,627 WA
[jira] [Resolved] (CLOUDSTACK-7922) CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7922. -- Resolution: Duplicate > CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the > size of template does not fail > > > Key: CLOUDSTACK-7922 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7922 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: Future > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7939) when a template is deleted and copied over again the removed column is not updated properly.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar closed CLOUDSTACK-7939. Resolution: Duplicate > when a template is deleted and copied over again the removed column is not > updated properly. > > > Key: CLOUDSTACK-7939 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7939 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8851) Redundant VR getting started in the same cluster or host even when there are suitable hosts available.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar closed CLOUDSTACK-8851. Resolution: Fixed > Redundant VR getting started in the same cluster or host even when there are > suitable hosts available. > -- > > Key: CLOUDSTACK-8851 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8851 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Bharat Kumar >Assignee: Bharat Kumar > > Issue > = > Redundant VR getting started in the same cluster or some time in same host > CloudStack often starts both of redundant VRs in same Cluster and what is > worse, Cloudstack sometimes starts both of redundant VRs in same host. if due > to some reason if this host gets effected both the redundant routes get > effected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9667) Enable resourcecount.check.interval by default
Bharat Kumar created CLOUDSTACK-9667: Summary: Enable resourcecount.check.interval by default Key: CLOUDSTACK-9667 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9667 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.9.2.0 Issue. In cloud stack there is a thread with runs at regular interval and updates the resource count. The interval at with this runs is specified by resourcecount.check.interval global config. This is set to zero by default, which means it will never run and so the count of public Ips is not updated. Fix: Made the default value 300 seconds. This will run the resource count update thread thread every 300 seconds by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9666) Add configuration validation for the config drive global settings
Bharat Kumar created CLOUDSTACK-9666: Summary: Add configuration validation for the config drive global settings Key: CLOUDSTACK-9666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9666 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.9.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9665) List hosts api dose not report correct cpu and memory usage
Bharat Kumar created CLOUDSTACK-9665: Summary: List hosts api dose not report correct cpu and memory usage Key: CLOUDSTACK-9665 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9665 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.9.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.9.2.0 List hosts API dose not consider the overcommit ratios at cluster level. This results in in correct calculation of resources by list host API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9641) In KVM SSVM and CPVM may use the old cmdline data, if we fail to fetch the new cmdline in the first pass.
Bharat Kumar created CLOUDSTACK-9641: Summary: In KVM SSVM and CPVM may use the old cmdline data, if we fail to fetch the new cmdline in the first pass. Key: CLOUDSTACK-9641 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9641 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.9.0.1 we backup the old cmdline when we stop the VM, so when the VM starts it will try to get the cmdline and will not be able to use the old cmdline data. This change will be made in the stop command. This will not effect the reboots, as reboot command is a separate command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9640) In KVM SSVM and CPVM may use the old cmdline data, if we fail to fetch the new cmdline in the first pass.
Bharat Kumar created CLOUDSTACK-9640: Summary: In KVM SSVM and CPVM may use the old cmdline data, if we fail to fetch the new cmdline in the first pass. Key: CLOUDSTACK-9640 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9640 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.9.0.1 we backup the old cmdline when we stop the VM, so when the VM starts it will try to get the cmdline and will not be able to use the old cmdline data. This change will be made in the stop command. This will not effect the reboots, as reboot command is a separate command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9638) Problems caused when inputting double-byte numbers for custom compute offerings
Bharat Kumar created CLOUDSTACK-9638: Summary: Problems caused when inputting double-byte numbers for custom compute offerings Key: CLOUDSTACK-9638 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9638 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.9.0.1 When creating a VM with a custom compute offering, CloudPlatform allows the input of double-byte numbers. The VM will be created but listVirtualMachines will subsequently fail with an exception. The problem seems to be with the value of detail_value for the associated entry in the user_vm_view table. If you manually change it to a regular number the issue is resolved. Double-byte numbers should either be considered invalid for custom offerings and rejected, or listVMs should work when they are used for a VM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9318) test_privategw_acl is failing intermittently.
Bharat Kumar created CLOUDSTACK-9318: Summary: test_privategw_acl is failing intermittently. Key: CLOUDSTACK-9318 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9318 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.9.0 Reporter: Bharat Kumar Priority: Critical Fix For: 4.9.0 The test test_privategw_acl.py is failing intermittently. This because it tries to use a vlan which is already in use. Need to add a check to see if a vlan is already in use or read the need vlan from the test_data.py file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-9035: - Description: we send the save password command to both the VRs in a rvr enabled network, But the password gets saved only in the master VR. This happens because the password server is not running in the backup. Because of this if someone resets the password of a VM and starts it when the backup becomes master. Then the password of the user VM will not change, because the save password command was not successful. was: we send the save password command to both the VRs in a rvr enabled network, But the password gets saved only in the master VR. This happens because the password server is not running in the backup. Because of this if someone resets the password of a VM and starts it when the backup becomes master. Then the password of the user VM will not change, because the save password was not successful. > Password file is stored only with Master when we Reset Password on the VM. > -- > > Key: CLOUDSTACK-9035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Priority: Blocker > Fix For: 4.6.0 > > > we send the save password command to both the VRs in a rvr enabled network, > But the password gets saved only in the master VR. This happens because the > password server is not running in the backup. > Because of this if someone resets the password of a VM and starts it when the > backup becomes master. Then the password of the user VM will not change, > because the save password command was not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-9035: - Description: we send the save password command to both the VRs in a rvr enabled network, But the password gets saved only in the master VR. This happens because the password server is not running in the backup. Because of this if someone resets the password of a VM and starts it when the backup becomes master. Then the password of the user VM will not change, because the save password was not successful. was: we send the save password command to both the vr in a rvr enabled network, But the password gets saved only in the master VR. This happens because the password server is not running in the backup. Because of this if someone resets the password of a VM and starts it when the backup becomes master. Then the password of the user VM will not change, because the save password was not successful. > Password file is stored only with Master when we Reset Password on the VM. > -- > > Key: CLOUDSTACK-9035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Priority: Blocker > Fix For: 4.6.0 > > > we send the save password command to both the VRs in a rvr enabled network, > But the password gets saved only in the master VR. This happens because the > password server is not running in the backup. > Because of this if someone resets the password of a VM and starts it when the > backup becomes master. Then the password of the user VM will not change, > because the save password was not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.
Bharat Kumar created CLOUDSTACK-9035: Summary: Password file is stored only with Master when we Reset Password on the VM. Key: CLOUDSTACK-9035 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.6.0 Reporter: Bharat Kumar Priority: Blocker Fix For: 4.6.0 we send the save password command to both the vr in a rvr enabled network, But the password gets saved only in the master VR. This happens because the password server is not running in the backup. Because of this if someone resets the password of a VM and starts it when the backup becomes master. Then the password of the user VM will not change, because the save password was not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8902) Restart Network fails in EIP/ELB zone
Bharat Kumar created CLOUDSTACK-8902: Summary: Restart Network fails in EIP/ELB zone Key: CLOUDSTACK-8902 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8902 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Environment: Basic XS Zone with EIP/LB. In an EIP zone, restarting a network with cleanup option checked , is failing with NumberFormatException. 2015-07-13 10:52:29,819 DEBUG [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-52:ctx-c6499039 job-100 ctx-4281c3af) (logid:7b32a53a) Sending network shutdown to Netscaler 2015-07-13 10:52:29,825 WARN [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-52:ctx-c6499039 job-100 ctx-4281c3af) (logid:7b32a53a) Unable to complete shutdown of the network elements due to element: Netscaler java.lang.NumberFormatException: For input string: "untagged" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:441) at java.lang.Long.parseLong(Long.java:483) at com.cloud.network.ExternalLoadBalancerDeviceManagerImpl.manageGuestNetworkWithExternalLoadBalancer(ExternalLoadBalancerDeviceManagerImpl.java:1013) at com.cloud.network.element.NetscalerElement.shutdown(NetscalerElement.java:223) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkElementsAndResources(NetworkOrchestrator.java:2251) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2553) at com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1910) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy164.restartNetwork(Unknown Source) at org.apache.cloudstack.api.command.user.network.RestartNetworkCmd.execute(RestartNetworkCmd.java:95) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:132) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:549) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:500) 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:722) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8799) fix CsRedundant.py to handle public interfaces and default routes when changing state.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-8799. -- Resolution: Fixed Fix Version/s: 4.6.0 > fix CsRedundant.py to handle public interfaces and default routes when > changing state. > -- > > Key: CLOUDSTACK-8799 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8799 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Blocker > Fix For: 4.6.0 > > > When the Vr changes state to backup we need bring all the public interfaces > down. Similarly when it changes state to master we have bring all the public > interfaces up and add the default routes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8860) Improve error messages in VM deployment code path
Bharat Kumar created CLOUDSTACK-8860: Summary: Improve error messages in VM deployment code path Key: CLOUDSTACK-8860 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8860 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.6.0 Reporter: Bharat Kumar Assignee: Bharat Kumar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8857) 'listProjects' doesn't return tags 'vmstopped' or 'vmrunning' when their value is zero
Bharat Kumar created CLOUDSTACK-8857: Summary: 'listProjects' doesn't return tags 'vmstopped' or 'vmrunning' when their value is zero Key: CLOUDSTACK-8857 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8857 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Bharat Kumar Assignee: Bharat Kumar 'listProjects' doesn't return tags 'vmstopped' or 'vmrunning' when their value is zero. Eg: API result when 1 vm is stopped and 0 vms are running: curl -s 'http://127.0.0.1:8096/api?command=listProjects&account=admin&domainid=10513804-76ec-11e4-924f-065db297' 2>/dev/null | xmllint --format - -o 1 a811d7e1-3ec7-4dda-92c4-4792200f38cf abc abc 10513804-76ec-11e4-924f-065db297 ROOT admin Active 20 1 19 20 0 20 40 1 39 40960 512 40448 200 2 198 400 0 400 20 1 19 20 1 4 20 1 19 20 0 20 20 1 19 1 The above response should have a tag 0, which is missing, similar when the zero vms are stopped, vmstopped would be missing. When there are no VMs in the project neither of these tags are in the response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8856) Primary Storage Used(type tag with value 2) related tag is not showing in listCapacity api response
Bharat Kumar created CLOUDSTACK-8856: Summary: Primary Storage Used(type tag with value 2) related tag is not showing in listCapacity api response Key: CLOUDSTACK-8856 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8856 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Bharat Kumar Assignee: Bharat Kumar Actual behavior: Primary Storage Used(type tag with value 2) related tag is showing in listCapacity api response when 'sortby=Usage' parameter is removed in listCapacity api. Expected behavior: Primary Storage Used(type tag with value 2) related tag should be shown in listCapacity api response when 'sortby=Usage' parameter is included in listCapacity api. Steps to reproduce: 1.Login cloudstack as admin and launch one vm successfully. 2.Make sure that firebug tool is enable and navigate to Dashboard. 3.Right click on 'listCapacity' api and select 'Copy Location'. 4.Remove 'response=json' parameter from above copied url and paste the modified url in new tab. 5.Check for 'type tag with value 2' in 'listCapcity' api xml response. listCapacity API Command: http://10.81.29.87/client/api?command=listCapacity&sessionkey=Qp0XOEUVLrZHBZrQp7ame96IzXE%3D&fetchLatest=true&sortBy=usage&_=1417697306264 Response: - 9 - 5 25cb4986-c286-4937-a0ec-b290307eaa4f XenRT-Zone-0 3 5 60 - 4 25cb4986-c286-4937-a0ec-b290307eaa4f XenRT-Zone-0 3 15 20 - 7 25cb4986-c286-4937-a0ec-b290307eaa4f XenRT-Zone-0 1 5 20 - 6 25cb4986-c286-4937-a0ec-b290307eaa4f XenRT-Zone-0 227751755776 4395909513216 5.18 - 0 25cb4986-c286-4937-a0ec-b290307eaa4f XenRT-Zone-0 2952790016 124470096896 2.37 - 1 25cb4986-c286-4937-a0ec-b290307eaa4f XenRT-Zone-0 2000 100800 1.98 - 3 25cb4986-c286-4937-a0ec-b290307eaa4f XenRT-Zone-0 29339156480 8791819026432 0.33 - 9 25cb4986-c286-4937-a0ec-b290307eaa4f XenRT-Zone-0 8388608 981911732224 0 - 19 25cb4986-c286-4937-a0ec-b290307eaa4f XenRT-Zone-0 0 0 0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8855) Improve Error Message for Host Alert State
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8855: - Summary: Improve Error Message for Host Alert State (was: Improved Error Message for Host Alert State) > Improve Error Message for Host Alert State > -- > > Key: CLOUDSTACK-8855 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8855) Improved Error Message for Host Alert State
Bharat Kumar created CLOUDSTACK-8855: Summary: Improved Error Message for Host Alert State Key: CLOUDSTACK-8855 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Bharat Kumar Assignee: Bharat Kumar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8852) Cloudstack Database shows that management server is UP when it is actually stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8852: - Summary: Cloudstack Database shows that management server is UP when it is actually stopped (was: CCP Database shows that management server is UP when it is actually stopped ) > Cloudstack Database shows that management server is UP when it is actually > stopped > --- > > Key: CLOUDSTACK-8852 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8852 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: Future > > > Stopped the cloudstack-management service on the CCP host > Checked from the DB server using the command select * from mshost and it > shows the status is up > mysql> select * from mshost; > ++-+---+--+---+-+---+--+-+-+-+ > | id | msid | runid | name | state | version | service_ip | service_port | > last_update | removed | alert_count | > ++-+---+--+---+-+---+--+-+-+-+ > | 1 | 108626471636843 | 1413421031361 | management.sunil.com | Up | 4.3.0.0 | > 10.104.12.210 | 9090 | 2014-10-16 01:14:21 | NULL | 0 | > ++-+---+--+---+-+---+--+-+-+-+ > 1 row in set (0.00 sec) > Shut down the management server and in the database still it shows the > status as ‘Up’. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8852) CCP Database shows that management server is UP when it is actually stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8852: - Summary: CCP Database shows that management server is UP when it is actually stopped (was: CCP Database shows that management server is UP when it is actually stopped from the CCP GUI) > CCP Database shows that management server is UP when it is actually stopped > > > Key: CLOUDSTACK-8852 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8852 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: Future > > > Stopped the cloudstack-management service on the CCP host > Checked from the DB server using the command select * from mshost and it > shows the status is up > mysql> select * from mshost; > ++-+---+--+---+-+---+--+-+-+-+ > | id | msid | runid | name | state | version | service_ip | service_port | > last_update | removed | alert_count | > ++-+---+--+---+-+---+--+-+-+-+ > | 1 | 108626471636843 | 1413421031361 | management.sunil.com | Up | 4.3.0.0 | > 10.104.12.210 | 9090 | 2014-10-16 01:14:21 | NULL | 0 | > ++-+---+--+---+-+---+--+-+-+-+ > 1 row in set (0.00 sec) > Shut down the management server and in the database still it shows the > status as ‘Up’. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8852) CCP Database shows that management server is UP when it is actually stopped from the CCP GUI
Bharat Kumar created CLOUDSTACK-8852: Summary: CCP Database shows that management server is UP when it is actually stopped from the CCP GUI Key: CLOUDSTACK-8852 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8852 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: Future Stopped the cloudstack-management service on the CCP host Checked from the DB server using the command select * from mshost and it shows the status is up mysql> select * from mshost; ++-+---+--+---+-+---+--+-+-+-+ | id | msid | runid | name | state | version | service_ip | service_port | last_update | removed | alert_count | ++-+---+--+---+-+---+--+-+-+-+ | 1 | 108626471636843 | 1413421031361 | management.sunil.com | Up | 4.3.0.0 | 10.104.12.210 | 9090 | 2014-10-16 01:14:21 | NULL | 0 | ++-+---+--+---+-+---+--+-+-+-+ 1 row in set (0.00 sec) Shut down the management server and in the database still it shows the status as ‘Up’. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8851) Redundant VR getting started in the same cluster or host even when there are suitable hosts available.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8851: - Description: Issue = Redundant VR getting started in the same cluster or some time in same host CloudStack often starts both of redundant VRs in same Cluster and what is worse, Cloudstack sometimes starts both of redundant VRs in same host. if due to some reason if this host gets effected both the redundant routes get effected. was: Issue = Redundant VR getting started in the same cluster or some time in same host CloudStack often starts both of redundant VRs in same Cluster. And what is worse, Cloudstack sometimes starts both of redundant VRs in same host. if due to some reason if this host gets effected both the redundant routes get effected. > Redundant VR getting started in the same cluster or host even when there are > suitable hosts available. > -- > > Key: CLOUDSTACK-8851 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8851 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Bharat Kumar >Assignee: Bharat Kumar > > Issue > = > Redundant VR getting started in the same cluster or some time in same host > CloudStack often starts both of redundant VRs in same Cluster and what is > worse, Cloudstack sometimes starts both of redundant VRs in same host. if due > to some reason if this host gets effected both the redundant routes get > effected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8851) Redundant VR getting started in the same cluster or host even when there are suitable hosts available.
Bharat Kumar created CLOUDSTACK-8851: Summary: Redundant VR getting started in the same cluster or host even when there are suitable hosts available. Key: CLOUDSTACK-8851 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8851 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Bharat Kumar Assignee: Bharat Kumar Issue = Redundant VR getting started in the same cluster or some time in same host CloudStack often starts both of redundant VRs in same Cluster. And what is worse, Cloudstack sometimes starts both of redundant VRs in same host. if due to some reason if this host gets effected both the redundant routes get effected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8837) Read from the file system to get the state of the interface instead of using subprocess command.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8837: - Summary: Read from the file system to get the state of the interface instead of using subprocess command. (was: read from the file system to get the state of the interface instead of using subprocess command.) > Read from the file system to get the state of the interface instead of using > subprocess command. > > > Key: CLOUDSTACK-8837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8837 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar > Fix For: Future > > > Hi, > The subprocess method of python should be use only when there is no other > alternative. we can avoid using it to find state of the interface. > use cat /sys/class/net/eth0/operstate and python file I/O instead of ip link > show command to get the sate of the device or to list the devices that are > available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8837) read from the file system to get the state of the interface instead of using subprocess command.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8837: - Issue Type: Improvement (was: Bug) > read from the file system to get the state of the interface instead of using > subprocess command. > > > Key: CLOUDSTACK-8837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8837 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar > Fix For: Future > > > Hi, > The subprocess method of python should be use only when there is no other > alternative. we can avoid using it to find state of the interface. > use cat /sys/class/net/eth0/operstate and python file I/O instead of ip link > show command to get the sate of the device or to list the devices that are > available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8837) read from the file system to get the state of the interface instead of using subprocess command.
Bharat Kumar created CLOUDSTACK-8837: Summary: read from the file system to get the state of the interface instead of using subprocess command. Key: CLOUDSTACK-8837 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8837 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.6.0 Reporter: Bharat Kumar Fix For: Future Hi, The subprocess method of python should be use only when there is no other alternative. we can avoid using it to find state of the interface. use cat /sys/class/net/eth0/operstate and python file I/O instead of ip link show command to get the sate of the device or to list the devices that are available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8799) fix CsRedundant.py to handle public interfaces and default routes when changing state.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8799: - Status: Reviewable (was: In Progress) > fix CsRedundant.py to handle public interfaces and default routes when > changing state. > -- > > Key: CLOUDSTACK-8799 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8799 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Blocker > > When the Vr changes state to backup we need bring all the public interfaces > down. Similarly when it changes state to master we have bring all the public > interfaces up and add the default routes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8798) fix the keepalived configuration in rvr.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8798: - Status: Reviewable (was: In Progress) > fix the keepalived configuration in rvr. > > > Key: CLOUDSTACK-8798 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8798 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Blocker > > currently in the keepalived.confg the virtual ip addresses that is configured > is incorrect it has to be the gateway ip of the corresponding guest network. > Also the auth password generated is different for each of the rvr. The auth > password need to be same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8804) configure routes only in case of public networks when using vpc network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8804: - Priority: Critical (was: Major) > configure routes only in case of public networks when using vpc network. > > > Key: CLOUDSTACK-8804 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8804 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > In CsAddress.py the process() method adds routes to all the network types > which are not of type control, This should be fixed to add routes only in > case of public networks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8804) configure routes only in case of public networks when using vpc network.
Bharat Kumar created CLOUDSTACK-8804: Summary: configure routes only in case of public networks when using vpc network. Key: CLOUDSTACK-8804 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8804 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.6.0 Reporter: Bharat Kumar Assignee: Bharat Kumar In CsAddress.py the process() method adds routes to all the network types which are not of type control, This should be fixed to add routes only in case of public networks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8799) fix CsRedundant.py to handle public interfaces and default routes when changing state.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8799: - Priority: Critical (was: Major) > fix CsRedundant.py to handle public interfaces and default routes when > changing state. > -- > > Key: CLOUDSTACK-8799 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8799 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > When the Vr changes state to backup we need bring all the public interfaces > down. Similarly when it changes state to master we have bring all the public > interfaces up and add the default routes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8798) fix the keepalived configuration in rvr.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8798: - Priority: Critical (was: Major) > fix the keepalived configuration in rvr. > > > Key: CLOUDSTACK-8798 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8798 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > currently in the keepalived.confg the virtual ip addresses that is configured > is incorrect it has to be the gateway ip of the corresponding guest network. > Also the auth password generated is different for each of the rvr. The auth > password need to be same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8799) fix CsRedundant.py to handle public interfaces and default routes when changing state.
Bharat Kumar created CLOUDSTACK-8799: Summary: fix CsRedundant.py to handle public interfaces and default routes when changing state. Key: CLOUDSTACK-8799 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8799 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.6.0 Reporter: Bharat Kumar Assignee: Bharat Kumar When the Vr changes state to backup we need bring all the public interfaces down. Similarly when it changes state to master we have bring all the public interfaces up and add the default routes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8798) fix the keepalived configuration in rvr.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8798: - Fix Version/s: (was: 4.6.0) > fix the keepalived configuration in rvr. > > > Key: CLOUDSTACK-8798 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8798 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > > currently in the keepalived.confg the virtual ip addresses that is configured > is incorrect it has to be the gateway ip of the corresponding guest network. > Also the auth password generated is different for each of the rvr. The auth > password need to be same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8798) fix the keepalived configuration in rvr.
Bharat Kumar created CLOUDSTACK-8798: Summary: fix the keepalived configuration in rvr. Key: CLOUDSTACK-8798 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8798 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.6.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.6.0 currently in the keepalived.confg the virtual ip addresses that is configured is incorrect it has to be the gateway ip of the corresponding guest network. Also the auth password generated is different for each of the rvr. The auth password need to be same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8751) Minimise VR downtime during network update
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8751: - Description: Currently we use redundant virtual router enabled networks to prevent network outage even if one of the virtual router fails. This is achieved by using redundant virtual routers along with VRRP protocol. This has increased the network robustness. However updating a network with new network offering involves some downtime due to Vr restarts. In case of redundant VR based networks we can sequence the network update operations to update the backup first and then update the master while master's operations are being handled by backup, this way i think we can minimise the downtime. Link to FS https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61310469 was:Currently we use redundant virtual router enabled networks to prevent network outage even if one of the virtual router fails. This is achieved by using redundant virtual routers along with VRRP protocol. This has increased the network robustness. However updating a network with new network offering involves some downtime due to Vr restarts. In case of redundant VR based networks we can sequence the network update operations to update the backup first and then update the master while master's operations are being handled by backup, this way i think we can minimise the downtime. > Minimise VR downtime during network update > -- > > Key: CLOUDSTACK-8751 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8751 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Bharat Kumar >Assignee: Bharat Kumar > > Currently we use redundant virtual router enabled networks to prevent network > outage even if one of the virtual router fails. This is achieved by using > redundant virtual routers along with VRRP protocol. This has increased the > network robustness. However updating a network with new network offering > involves some downtime due to Vr restarts. In case of redundant VR based > networks we can sequence the network update operations to update the backup > first and then update the master while master's operations are being handled > by backup, this way i think we can minimise the downtime. > Link to FS > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61310469 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8751) Minimise VR downtime during network update
Bharat Kumar created CLOUDSTACK-8751: Summary: Minimise VR downtime during network update Key: CLOUDSTACK-8751 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8751 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Bharat Kumar Assignee: Bharat Kumar Currently we use redundant virtual router enabled networks to prevent network outage even if one of the virtual router fails. This is achieved by using redundant virtual routers along with VRRP protocol. This has increased the network robustness. However updating a network with new network offering involves some downtime due to Vr restarts. In case of redundant VR based networks we can sequence the network update operations to update the backup first and then update the master while master's operations are being handled by backup, this way i think we can minimise the downtime. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar reassigned CLOUDSTACK-8725: Assignee: Bharat Kumar > RVR functionality is broken in case of isolated networks, conntrackd fails to > start. > > > Key: CLOUDSTACK-8725 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > I tried setting up a rvr enabled isolated network. In the startup logs of the > router i can see that conntrackd is failing to start. Below are the startup > logs > [info] Setting console screen modes. > setterm: cannot (un)set powersave mode: Invalid argument > [info] Skipping font and keymap setup (handled by console-setup). > [] Loading IPsec SA/SP database: > [ ok etc/ipsec-tools.conf. > INIT: Entering runlevel: 2 > [info] Using makefile-style concurrent boot in runlevel 2. > [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm. > [ ok ] Loading iptables rules... IPv4... IPv6...done. > [ ok ] Starting rpcbind daemon...[] Already running.. > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > open-vm-tools: not starting as this is not a VMware VM > [ ok ] Starting enhanced syslogd: rsyslogd. > [] Starting ACPI services...RTNETLINK1 answers: No such file or directory > acpid: error talking to the kernel via netlink > . ok > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [ ok ] Starting DNS forwarder and DHCP server: dnsmasq. > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > . ok > [ ok ] Starting periodic command scheduler: cron. > [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [FAIL] Starting keepalived: keepalived failed! > [ ok ] Starting NTP server: ntpd. > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [ ok ] Starting the system activity data collector: sadc. > Detecting Linux distribution version: OK > Starting xe daemon: OK > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > httpd (pid 3351) already running > . ok > [FAIL] Starting keepalived: keepalived failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > Failed > [ ok ] Stopping NFS common utilities: idmapd statd. > -On router. > root@r-93-VM:~# service conntrackd restart > [] Stopping conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8725: - Fix Version/s: 4.6.0 > RVR functionality is broken in case of isolated networks, conntrackd fails to > start. > > > Key: CLOUDSTACK-8725 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.6.0 > > > I tried setting up a rvr enabled isolated network. In the startup logs of the > router i can see that conntrackd is failing to start. Below are the startup > logs > [info] Setting console screen modes. > setterm: cannot (un)set powersave mode: Invalid argument > [info] Skipping font and keymap setup (handled by console-setup). > [] Loading IPsec SA/SP database: > [ ok etc/ipsec-tools.conf. > INIT: Entering runlevel: 2 > [info] Using makefile-style concurrent boot in runlevel 2. > [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm. > [ ok ] Loading iptables rules... IPv4... IPv6...done. > [ ok ] Starting rpcbind daemon...[] Already running.. > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > open-vm-tools: not starting as this is not a VMware VM > [ ok ] Starting enhanced syslogd: rsyslogd. > [] Starting ACPI services...RTNETLINK1 answers: No such file or directory > acpid: error talking to the kernel via netlink > . ok > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [ ok ] Starting DNS forwarder and DHCP server: dnsmasq. > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > . ok > [ ok ] Starting periodic command scheduler: cron. > [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [FAIL] Starting keepalived: keepalived failed! > [ ok ] Starting NTP server: ntpd. > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [ ok ] Starting the system activity data collector: sadc. > Detecting Linux distribution version: OK > Starting xe daemon: OK > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > httpd (pid 3351) already running > . ok > [FAIL] Starting keepalived: keepalived failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > Failed > [ ok ] Stopping NFS common utilities: idmapd statd. > -On router. > root@r-93-VM:~# service conntrackd restart > [] Stopping conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8725: - Summary: RVR functionality is broken in case of isolated networks, conntrackd fails to start. (was: RVR functionality is broken in case of isolated networks, conntrckd fails to start.) > RVR functionality is broken in case of isolated networks, conntrackd fails to > start. > > > Key: CLOUDSTACK-8725 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Priority: Critical > > I tried setting up a rvr enabled isolated network. In the startup logs of the > router i can see that conntrackd is failing to start. Below are the startup > logs > [info] Setting console screen modes. > setterm: cannot (un)set powersave mode: Invalid argument > [info] Skipping font and keymap setup (handled by console-setup). > [] Loading IPsec SA/SP database: > [ ok etc/ipsec-tools.conf. > INIT: Entering runlevel: 2 > [info] Using makefile-style concurrent boot in runlevel 2. > [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm. > [ ok ] Loading iptables rules... IPv4... IPv6...done. > [ ok ] Starting rpcbind daemon...[] Already running.. > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > open-vm-tools: not starting as this is not a VMware VM > [ ok ] Starting enhanced syslogd: rsyslogd. > [] Starting ACPI services...RTNETLINK1 answers: No such file or directory > acpid: error talking to the kernel via netlink > . ok > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [ ok ] Starting DNS forwarder and DHCP server: dnsmasq. > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > . ok > [ ok ] Starting periodic command scheduler: cron. > [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [FAIL] Starting keepalived: keepalived failed! > [ ok ] Starting NTP server: ntpd. > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [ ok ] Starting the system activity data collector: sadc. > Detecting Linux distribution version: OK > Starting xe daemon: OK > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > httpd (pid 3351) already running > . ok > [FAIL] Starting keepalived: keepalived failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > Failed > [ ok ] Stopping NFS common utilities: idmapd statd. > -On router. > root@r-93-VM:~# service conntrackd restart > [] Stopping conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrckd fails to start.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8725: - Description: I tried setting up a rvr enabled isolated network. In the startup logs of the router i can see that conntrackd is failing to start. Below are the startup logs [info] Setting console screen modes. setterm: cannot (un)set powersave mode: Invalid argument [info] Skipping font and keymap setup (handled by console-setup). [] Loading IPsec SA/SP database: [ ok etc/ipsec-tools.conf. INIT: Entering runlevel: 2 [info] Using makefile-style concurrent boot in runlevel 2. [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm. [ ok ] Loading iptables rules... IPv4... IPv6...done. [ ok ] Starting rpcbind daemon...[] Already running.. sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory open-vm-tools: not starting as this is not a VMware VM [ ok ] Starting enhanced syslogd: rsyslogd. [] Starting ACPI services...RTNETLINK1 answers: No such file or directory acpid: error talking to the kernel via netlink . ok [] Starting conntrackdERROR: parsing config file in line (102), symbol 'Multicast': syntax error failed! [ ok ] Starting DNS forwarder and DHCP server: dnsmasq. [] Starting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 10.1.1.247 for ServerName . ok [ ok ] Starting periodic command scheduler: cron. [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy 'cloud-default' as it requires HTTP mode. [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy 'cloud-default' as it requires HTTP mode. . ok [FAIL] Starting keepalived: keepalived failed! [ ok ] Starting NTP server: ntpd. [ ok ] Starting OpenBSD Secure Shell server: sshd. [ ok ] Starting the system activity data collector: sadc. Detecting Linux distribution version: OK Starting xe daemon: OK [ ok ] Starting OpenBSD Secure Shell server: sshd. [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy 'cloud-default' as it requires HTTP mode. . ok [] Starting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 10.1.1.247 for ServerName httpd (pid 3351) already running . ok [FAIL] Starting keepalived: keepalived failed! [] Starting conntrackdERROR: parsing config file in line (102), symbol 'Multicast': syntax error failed! sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory Failed [ ok ] Stopping NFS common utilities: idmapd statd. -On router. root@r-93-VM:~# service conntrackd restart [] Stopping conntrackdERROR: parsing config file in line (102), symbol 'Multicast': syntax error failed! [] Starting conntrackdERROR: parsing config file in line (102), symbol 'Multicast': syntax error failed! was: I tried setting up a rvr enabled isolated network. In the startup logs of the router i can see that conntrackd is failing to start. Below are the startup logs [info] Setting console screen modes. setterm: cannot (un)set powersave mode: Invalid argument [info] Skipping font and keymap setup (handled by console-setup). [] Loading IPsec SA/SP database: [ ok etc/ipsec-tools.conf. INIT: Entering runlevel: 2 [info] Using makefile-style concurrent boot in runlevel 2. [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm. [ ok ] Loading iptables rules... IPv4... IPv6...done. [ ok ] Starting rpcbind daemon...[] Already running.. sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory open-vm-tools: not starting as this is not a VMware VM [ ok ] Starting enhanced syslogd: rsyslogd. [] Starting ACPI services...RTNETLINK1 answers: No such file or directory acpid: error talking to the kernel via netlink . ok [] Starting conntrackdERROR: parsing config file in line (102), symbol 'Multicast': syntax error failed! [ ok ] Starting DNS forwarder and DHCP server: dnsmasq. [] Starting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 10.1.1.247 for ServerName . ok [ ok ] Starting periodic command scheduler: cron. [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignor
[jira] [Created] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrckd fails to start.
Bharat Kumar created CLOUDSTACK-8725: Summary: RVR functionality is broken in case of isolated networks, conntrckd fails to start. Key: CLOUDSTACK-8725 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.6.0 Reporter: Bharat Kumar Priority: Critical I tried setting up a rvr enabled isolated network. In the startup logs of the router i can see that conntrackd is failing to start. Below are the startup logs [info] Setting console screen modes. setterm: cannot (un)set powersave mode: Invalid argument [info] Skipping font and keymap setup (handled by console-setup). [] Loading IPsec SA/SP database: [ ok etc/ipsec-tools.conf. INIT: Entering runlevel: 2 [info] Using makefile-style concurrent boot in runlevel 2. [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm. [ ok ] Loading iptables rules... IPv4... IPv6...done. [ ok ] Starting rpcbind daemon...[] Already running.. sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory open-vm-tools: not starting as this is not a VMware VM [ ok ] Starting enhanced syslogd: rsyslogd. [] Starting ACPI services...RTNETLINK1 answers: No such file or directory acpid: error talking to the kernel via netlink . ok [] Starting conntrackdERROR: parsing config file in line (102), symbol 'Multicast': syntax error failed! [ ok ] Starting DNS forwarder and DHCP server: dnsmasq. [] Starting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 10.1.1.247 for ServerName . ok [ ok ] Starting periodic command scheduler: cron. [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy 'cloud-default' as it requires HTTP mode. [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy 'cloud-default' as it requires HTTP mode. . ok [FAIL] Starting keepalived: keepalived failed! [ ok ] Starting NTP server: ntpd. [ ok ] Starting OpenBSD Secure Shell server: sshd. [ ok ] Starting the system activity data collector: sadc. Detecting Linux distribution version: OK Starting xe daemon: OK [ ok ] Starting OpenBSD Secure Shell server: sshd. [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy 'cloud-default' as it requires HTTP mode. . ok [] Starting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 10.1.1.247 for ServerName httpd (pid 3351) already running . ok [FAIL] Starting keepalived: keepalived failed! [] Starting conntrackdERROR: parsing config file in line (102), symbol 'Multicast': syntax error failed! sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory Failed [ ok ] Stopping NFS common utilities: idmapd statd. root@r-93-VM:~# service conntrackd restart [] Stopping conntrackdERROR: parsing config file in line (102), symbol 'Multicast': syntax error failed! [] Starting conntrackdERROR: parsing config file in line (102), symbol 'Multicast': syntax error failed! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8360) Install issue: RPM install failing with a DB error message
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14394246#comment-14394246 ] Bharat Kumar commented on CLOUDSTACK-8360: -- might happen in a upgraded setup. not sure though, Found iso_id1 field in the schema-307to410.sql. Did not find a cleanup attempt in the schema-307to410-cleanup.sql. > Install issue: RPM install failing with a DB error message > -- > > Key: CLOUDSTACK-8360 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8360 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Priority: Blocker > > Built the Master branch RPMs and using the RPMs to install returned the > following message in management server log: > ERROR [c.c.u.d.Upgrade410to420] (main:null) > migrateDatafromIsoIdInVolumesTable:Exception:Unknown column 'iso_id1' in > 'field list' > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column > 'iso_id1' in 'field list' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:525) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) > at com.mysql.jdbc.Util.getInstance(Util.java:386) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8353: - Description: There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or earlier. fix was added in libvirt 1.1.1 The fix requires enabling the "hv_relaxed" option for the affected VMs. (was: There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or earlier. fix was added in RHEL 6.5. The fix requires enabling the "hv_relaxed" option for the affected VMs. ) > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.6.0 > > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
Bharat Kumar created CLOUDSTACK-8353: Summary: Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP Key: CLOUDSTACK-8353 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.6.0 There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or earlier. fix was added in RHEL 6.5. The fix requires enabling the "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7710) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7710. -- Resolution: Duplicate > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Bharat Kumar > Fix For: 4.5.1 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6873) [Automation] Ability to execute tests in sequence
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-6873. -- Resolution: Fixed > [Automation] Ability to execute tests in sequence > - > > Key: CLOUDSTACK-6873 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6873 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Koushik Das >Assignee: Bharat Kumar > Fix For: 4.5.1 > > > Currently BVT/regression tests are executed in parallel by the test > infrastructure. It needs to be enhanced to add capability to execute a > selective set of tests in sequence. > Specific scenario is tests that uses simulator mocks. These mocks are scoped > to a zone, pod, cluster or host. Once defined any tests targeting a specific > host will execute as per the mocks defined. Now in the current framework it > is not possible to prevent existing tests from going to a specific host. As a > result there needs to be a capability to execute a specific set of test cases > in sequence. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7939) when a template is deleted and copied over again the removed column is not updated properly.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7939: - Summary: when a template is deleted and copied over again the removed column is not updated properly. (was: when a template is deleted an copied over again the removed column is not updated properly.) > when a template is deleted and copied over again the removed column is not > updated properly. > > > Key: CLOUDSTACK-7939 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7939 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7939) when a template is deleted an copied over again the removed column is not updated properly.
Bharat Kumar created CLOUDSTACK-7939: Summary: when a template is deleted an copied over again the removed column is not updated properly. Key: CLOUDSTACK-7939 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7939 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7300: - Status: Open (was: Reviewable) > Cannot create Snapshot on KVM > - > > Key: CLOUDSTACK-7300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot >Affects Versions: 4.4.0 > Environment: KVM on CentOS >Reporter: Prieur Leary >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.4.1 > > > Cannot create volume Snapshots on KVM. > 1. Creating a Snapshot says successful. > 2. When viewing the actual Snapshot, it shows "Error" status. > 3. Management Server Logs the error below. > 4. It seems the Snapshot is attempting to be copied to a path that is not > mounted (Sec Storage Snapshots). > 5. Have restarted Agent, SSVM, and management server. Has not corrected. > -- > 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed > to create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup > c498663d-5986-4ee1-a864-bf99a7fab48d for disk > /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 > to /m$ > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.Del > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.r
[jira] [Comment Edited] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213475#comment-14213475 ] Bharat Kumar edited comment on CLOUDSTACK-7501 at 11/15/14 9:39 AM: if we do not mention any default hypervisor, Cloudstack tries to start a SSVM on different hypervisor after some retries. While creating a new SSVM vm we select the hypervisor type. If there is more than one hypervisor available for deployment we shuffle the list and pick one. Note: In case of CPVM we do not do this unless the CPVM is destroyed. was (Author: bharat.kumar): if we do not mention any default hypervisor, Cloudstack tries to start a vm on different hypervisor after some retries. While creating a new system vm we select the hypervisor type. If there is more than one hypervisor available for deployment we shuffle the list and pick one. > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7501. -- Resolution: Fixed > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213475#comment-14213475 ] Bharat Kumar commented on CLOUDSTACK-7501: -- if we do not mention any default hypervisor, Cloudstack tries to start a vm on different hypervisor after some retries. While creating a new system vm we select the hypervisor type. If there is more than one hypervisor available for deployment we shuffle the list and pick one. > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7300: - Status: Reviewable (was: In Progress) > Cannot create Snapshot on KVM > - > > Key: CLOUDSTACK-7300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot >Affects Versions: 4.4.0 > Environment: KVM on CentOS >Reporter: Prieur Leary >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.4.1 > > > Cannot create volume Snapshots on KVM. > 1. Creating a Snapshot says successful. > 2. When viewing the actual Snapshot, it shows "Error" status. > 3. Management Server Logs the error below. > 4. It seems the Snapshot is attempting to be copied to a path that is not > mounted (Sec Storage Snapshots). > 5. Have restarted Agent, SSVM, and management server. Has not corrected. > -- > 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed > to create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup > c498663d-5986-4ee1-a864-bf99a7fab48d for disk > /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 > to /m$ > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.Del > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at
[jira] [Resolved] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7004. -- Resolution: Cannot Reproduce > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7004: - Fix Version/s: (was: 4.4.0) > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7922) CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7922: - Fix Version/s: (was: 4.5.0) > CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the > size of template does not fail > > > Key: CLOUDSTACK-7922 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7922 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.4.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7922) CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
Bharat Kumar created CLOUDSTACK-7922: Summary: CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail Key: CLOUDSTACK-7922 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7922 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Automation, KVM Affects Versions: 4.4.0 Environment: KVM Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.4.0, 4.5.0 Deploy a VM with parameter rootdisksize less than the template size. API should throw error for this but it succeeds. Although the root disk size of deployed VM is equal to template size in this case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212097#comment-14212097 ] Bharat Kumar commented on CLOUDSTACK-7004: -- could not reproduce on 4.5 > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.4.0, 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14211941#comment-14211941 ] Bharat Kumar commented on CLOUDSTACK-7300: -- not an issue in 4.5, Snapshots are working. > Cannot create Snapshot on KVM > - > > Key: CLOUDSTACK-7300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot >Affects Versions: 4.4.0 > Environment: KVM on CentOS >Reporter: Prieur Leary >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.4.1 > > > Cannot create volume Snapshots on KVM. > 1. Creating a Snapshot says successful. > 2. When viewing the actual Snapshot, it shows "Error" status. > 3. Management Server Logs the error below. > 4. It seems the Snapshot is attempting to be copied to a path that is not > mounted (Sec Storage Snapshots). > 5. Have restarted Agent, SSVM, and management server. Has not corrected. > -- > 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed > to create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup > c498663d-5986-4ee1-a864-bf99a7fab48d for disk > /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 > to /m$ > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.Del > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) > at sun.reflect.Nat
[jira] [Resolved] (CLOUDSTACK-5700) [Vmsync] - kvm- "paused" state of Vm is not synced to CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5700. -- Resolution: Fixed > [Vmsync] - kvm- "paused" state of Vm is not synced to CS. > - > > Key: CLOUDSTACK-5700 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5700 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Bharat Kumar > Fix For: 4.4.0, 4.5.0 > > > [Vmsync] - kvm - "paused" state of Vm is not synced to CS. > Steps to reproduce the problem: > PreReq: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack , Suspend an existing VM using the following command: > virsh suspend > Vmsync does not detect the "paused" state of a VM. CS reports the real state > of this VM as "running" > 2013-12-31 18:44:20,977 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Found 6 VMs for host 2 > 2013-12-31 18:44:20,990 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Both states are Running for > VM[User|TestVM-1] > [root@Rack3Host14 ~]# virsh list > IdName State > > 2 r-4-VM running > 5 i-3-6-VM running > 6 i-3-5-VM running > 7 s-9-VM running > 9 i-3-8-VM running > 10i-3-3-VM paused -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5700) [Vmsync] - kvm- "paused" state of Vm is not synced to CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14211939#comment-14211939 ] Bharat Kumar commented on CLOUDSTACK-5700: -- Hi, Cloudstack considers paused VMs as running by design. > [Vmsync] - kvm- "paused" state of Vm is not synced to CS. > - > > Key: CLOUDSTACK-5700 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5700 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Bharat Kumar > Fix For: 4.4.0, 4.5.0 > > > [Vmsync] - kvm - "paused" state of Vm is not synced to CS. > Steps to reproduce the problem: > PreReq: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack , Suspend an existing VM using the following command: > virsh suspend > Vmsync does not detect the "paused" state of a VM. CS reports the real state > of this VM as "running" > 2013-12-31 18:44:20,977 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Found 6 VMs for host 2 > 2013-12-31 18:44:20,990 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Both states are Running for > VM[User|TestVM-1] > [root@Rack3Host14 ~]# virsh list > IdName State > > 2 r-4-VM running > 5 i-3-6-VM running > 6 i-3-5-VM running > 7 s-9-VM running > 9 i-3-8-VM running > 10i-3-3-VM paused -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7348) [Automation] InvalidParameter Exception with stacktrace in MS log wile executing scale vm.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206461#comment-14206461 ] Bharat Kumar commented on CLOUDSTACK-7348: -- review request link https://reviews.apache.org/r/27868/ > [Automation] InvalidParameter Exception with stacktrace in MS log wile > executing scale vm. > -- > > Key: CLOUDSTACK-7348 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > This issue observed during automation run, there are many InvalidParameter > Exception with stacktrace, this should be handled properly > 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] > (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END=== > 10.223.240.194 -- GET > > jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ& > command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D > 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while > executi > ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin > com.cloud.exception.InvalidParameterValueException: This operation not > permitted for this hypervisor of the vm > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) -- This message was sent by Atlassi
[jira] [Updated] (CLOUDSTACK-7348) [Automation] InvalidParameter Exception with stacktrace in MS log wile executing scale vm.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7348: - Summary: [Automation] InvalidParameter Exception with stacktrace in MS log wile executing scale vm. (was: [Automation] ) > [Automation] InvalidParameter Exception with stacktrace in MS log wile > executing scale vm. > -- > > Key: CLOUDSTACK-7348 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > This issue observed during automation run, there are many InvalidParameter > Exception with stacktrace, this should be handled properly > 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] > (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END=== > 10.223.240.194 -- GET > > jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ& > command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D > 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while > executi > ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin > com.cloud.exception.InvalidParameterValueException: This operation not > permitted for this hypervisor of the vm > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) -- This message was se
[jira] [Updated] (CLOUDSTACK-7348) [Automation] InvalidParameter Exception with stacktrace in MS log wile executing scale vm.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7348: - Status: Reviewable (was: In Progress) > [Automation] InvalidParameter Exception with stacktrace in MS log wile > executing scale vm. > -- > > Key: CLOUDSTACK-7348 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > This issue observed during automation run, there are many InvalidParameter > Exception with stacktrace, this should be handled properly > 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] > (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END=== > 10.223.240.194 -- GET > > jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ& > command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D > 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while > executi > ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin > com.cloud.exception.InvalidParameterValueException: This operation not > permitted for this hypervisor of the vm > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7348) [Automation]
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7348: - Summary: [Automation] (was: [Automation] InvalidParameter Exception with stacktrace in MS log) > [Automation] > - > > Key: CLOUDSTACK-7348 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > This issue observed during automation run, there are many InvalidParameter > Exception with stacktrace, this should be handled properly > 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] > (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END=== > 10.223.240.194 -- GET > > jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ& > command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D > 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while > executi > ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin > com.cloud.exception.InvalidParameterValueException: This operation not > permitted for this hypervisor of the vm > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-5700) [Vmsync] - kvm- "paused" state of Vm is not synced to CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar reassigned CLOUDSTACK-5700: Assignee: Bharat Kumar > [Vmsync] - kvm- "paused" state of Vm is not synced to CS. > - > > Key: CLOUDSTACK-5700 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5700 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Bharat Kumar > Fix For: 4.4.0, 4.5.0 > > > [Vmsync] - kvm - "paused" state of Vm is not synced to CS. > Steps to reproduce the problem: > PreReq: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack , Suspend an existing VM using the following command: > virsh suspend > Vmsync does not detect the "paused" state of a VM. CS reports the real state > of this VM as "running" > 2013-12-31 18:44:20,977 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Found 6 VMs for host 2 > 2013-12-31 18:44:20,990 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Both states are Running for > VM[User|TestVM-1] > [root@Rack3Host14 ~]# virsh list > IdName State > > 2 r-4-VM running > 5 i-3-6-VM running > 6 i-3-5-VM running > 7 s-9-VM running > 9 i-3-8-VM running > 10i-3-3-VM paused -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7763) Reservations for VMware VMs remain after dynamic scaling completes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7763. -- Resolution: Fixed > Reservations for VMware VMs remain after dynamic scaling completes > -- > > Key: CLOUDSTACK-7763 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7763 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > When using the dynamic scaling feature for VMware VMs, a reservation is > configured on the VM, however it is not removed once the scaling completes > successfully. This is happening even though vmware.reserve.cpu/mem parameters > are false for the cluster and in Global Settings. The reservation is removed > if you subsequently stop/start the VM. > REPRO STEPS > == > 1) Deploy a VM from a dynamically scalable template. > 2) When it is up and running, notice the lack of any configured reservations. > 3) Scale up the VM by changing to a Compute Offering with more CPU/RAM. > 4) After it succeeds, notice the reservations are still applied. > 5) Stop and start the VM. > 6) Notice that the reservations have been removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7760) Data disk size is not considering for primary storage resource limit check
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7760. -- Resolution: Fixed > Data disk size is not considering for primary storage resource limit check > -- > > Key: CLOUDSTACK-7760 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7760 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > During VM deployment and while choosing CUSTOM disk offering for data disk, > the size of the data disk is not considered for checking resource limit of > primary storage. > size += _diskOfferingDao.findById(diskOfferingId).getDiskSize(); > _resourceLimitMgr.checkResourceLimit(owner, ResourceType.primary_storage, new > Long (size)); > getDiskSize() method returns 0 in case of custom disk offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7376) passwd_server attempts to start but terminates with the exit code 137
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7376. -- Resolution: Fixed > passwd_server attempts to start but terminates with the exit code 137 > - > > Key: CLOUDSTACK-7376 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7376 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > "Trying to add a non-contiguous IP range to an existing guest network, upon > creation of an instance in the new range, the virtual router is updated with > a new sub-interface but the passwd_server service (for serving passwords) is > not running. > If the script /opt/cloud/bin/passwd_server is run manually, then the service > starts successfully and passwords can be served. > If we reboot the virtual router via the CloudPlatform GUI, then it powers > back up with the subinterface, but the passwd_server service is not running. > Checking /var/log/cloud.log, the passwd_server attempts to start but > terminates with the exit code 137, which from a quick google appears to be a > SIGKILL termination. > Steps to reproduce the issue > i) Create a Shared Network in CCP and deploy a VM in the network. > ii) Now add additional IP range to the same shared network. > iii) Deploy a new VM in the additional IP range ( you can exhaust the first > IP range to achieve this). > iv) Once the new VM is deployed. Stop/start or restart the Router. > The password server will fail to come up and following the entries in the logs > In /var/log/cloud.log from VR > /opt/cloud/bin/passwd_server_ip: line 32: 3161 Killed socat > -lf /var/log/cloud.log TCP4-LISTEN:8080,reuseaddr,fork,crnl,bind=$addr > SYSTEM:"/opt/cloud/bin/serve_password.sh \"\$SOCAT_PEERADDR\"" > Also, There is no issue in starting the service manually after ssh into the > Router. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7571) changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7571. -- Resolution: Fixed > changing value of cpu/mem.overprovisioning.factor for xen cluster is not > affecting total memory at zone level > - > > Key: CLOUDSTACK-7571 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7571 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > steps to reproduce > == > 1-prepare a CS3.6 setup with vmware and xen cluster > 2-set mem.overprovisioning.factor=3 and cpu.overprovisioning.factor=2 > 2-upgrade it to CCP4.3 > 3-record total memory and cpu at zone level > 4-change cpu/memory overprovisioning for xen server cluster to some valid > value > expected > = > at zone level total memory should get changed , depends on overprovisioning > value > Actual > === > 1-total memory is not getting changed at zone level > 2-but total memory/cpu of xen cluster is getting changed with > overprovisioning factor > My observation > == > 1-if i change overspovisioning factor of vmware cluster total memory is > getting changed > 2-In fresh setup with one xen cluster i did not see this problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7536) user vm can get a gateway ip in case of shared network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7536. -- Resolution: Fixed > user vm can get a gateway ip in case of shared network. > --- > > Key: CLOUDSTACK-7536 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7536 > 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: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > steps to reproduce. > 1.) create a shared network with the following details. > gateway 10.136.10.1 > netmask 255.255.255.0 > guest ip range 10.136.10.1 to 10.136.10.20 (note that the gateway ip is > a part of the guest ip range.) > 2.) deploy a vm > the gateway ip gets allocated to a uservm. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar reassigned CLOUDSTACK-7300: Assignee: Bharat Kumar > Cannot create Snapshot on KVM > - > > Key: CLOUDSTACK-7300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot >Affects Versions: 4.4.0 > Environment: KVM on CentOS >Reporter: Prieur Leary >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.4.1 > > > Cannot create volume Snapshots on KVM. > 1. Creating a Snapshot says successful. > 2. When viewing the actual Snapshot, it shows "Error" status. > 3. Management Server Logs the error below. > 4. It seems the Snapshot is attempting to be copied to a path that is not > mounted (Sec Storage Snapshots). > 5. Have restarted Agent, SSVM, and management server. Has not corrected. > -- > 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed > to create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup > c498663d-5986-4ee1-a864-bf99a7fab48d for disk > /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 > to /m$ > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.Del > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.ref
[jira] [Resolved] (CLOUDSTACK-7755) Systems VMs restarting continuously on KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7755. -- Resolution: Cannot Reproduce > Systems VMs restarting continuously on KVM host > --- > > Key: CLOUDSTACK-7755 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7755 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, SystemVM >Affects Versions: 4.5.0 > Environment: Latest 4.5 build. with kvm host. >Reporter: Pavan Kumar Bandarupally >Assignee: Bharat Kumar >Priority: Blocker > Fix For: 4.5.0 > > Attachments: agent.log, management-server.log > > > After initial zone creation the system VMs are up for some time and are > continuously rebooting for some reason. There is no exception in the logs at > all. There is just a VM start command and start answer. > We can't do any operations if the system VMs are rebooting continuously. > Attached MS log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7755) Systems VMs restarting continuously on KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar reassigned CLOUDSTACK-7755: Assignee: Bharat Kumar (was: Kishan Kavala) > Systems VMs restarting continuously on KVM host > --- > > Key: CLOUDSTACK-7755 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7755 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, SystemVM >Affects Versions: 4.5.0 > Environment: Latest 4.5 build. with kvm host. >Reporter: Pavan Kumar Bandarupally >Assignee: Bharat Kumar >Priority: Blocker > Fix For: 4.5.0 > > Attachments: agent.log, management-server.log > > > After initial zone creation the system VMs are up for some time and are > continuously rebooting for some reason. There is no exception in the logs at > all. There is just a VM start command and start answer. > We can't do any operations if the system VMs are rebooting continuously. > Attached MS log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7763) Reservations for VMware VMs remain after dynamic scaling completes
Bharat Kumar created CLOUDSTACK-7763: Summary: Reservations for VMware VMs remain after dynamic scaling completes Key: CLOUDSTACK-7763 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7763 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 When using the dynamic scaling feature for VMware VMs, a reservation is configured on the VM, however it is not removed once the scaling completes successfully. This is happening even though vmware.reserve.cpu/mem parameters are false for the cluster and in Global Settings. The reservation is removed if you subsequently stop/start the VM. REPRO STEPS == 1) Deploy a VM from a dynamically scalable template. 2) When it is up and running, notice the lack of any configured reservations. 3) Scale up the VM by changing to a Compute Offering with more CPU/RAM. 4) After it succeeds, notice the reservations are still applied. 5) Stop and start the VM. 6) Notice that the reservations have been removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7760) Data disk size is not considering for primary storage resource limit check
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7760: - Status: Reviewable (was: In Progress) > Data disk size is not considering for primary storage resource limit check > -- > > Key: CLOUDSTACK-7760 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7760 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > During VM deployment and while choosing CUSTOM disk offering for data disk, > the size of the data disk is not considered for checking resource limit of > primary storage. > size += _diskOfferingDao.findById(diskOfferingId).getDiskSize(); > _resourceLimitMgr.checkResourceLimit(owner, ResourceType.primary_storage, new > Long (size)); > getDiskSize() method returns 0 in case of custom disk offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7760) Data disk size is not considering for primary storage resource limit check
Bharat Kumar created CLOUDSTACK-7760: Summary: Data disk size is not considering for primary storage resource limit check Key: CLOUDSTACK-7760 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7760 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 During VM deployment and while choosing CUSTOM disk offering for data disk, the size of the data disk is not considered for checking resource limit of primary storage. size += _diskOfferingDao.findById(diskOfferingId).getDiskSize(); _resourceLimitMgr.checkResourceLimit(owner, ResourceType.primary_storage, new Long (size)); getDiskSize() method returns 0 in case of custom disk offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7536) user vm can get a gateway ip in case of shared network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146188#comment-14146188 ] Bharat Kumar commented on CLOUDSTACK-7536: -- https://reviews.apache.org/r/25991/ > user vm can get a gateway ip in case of shared network. > --- > > Key: CLOUDSTACK-7536 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7536 > 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: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > steps to reproduce. > 1.) create a shared network with the following details. > gateway 10.136.10.1 > netmask 255.255.255.0 > guest ip range 10.136.10.1 to 10.136.10.20 (note that the gateway ip is > a part of the guest ip range.) > 2.) deploy a vm > the gateway ip gets allocated to a uservm. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7536) user vm can get a gateway ip in case of shared network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7536: - Status: Reviewable (was: In Progress) > user vm can get a gateway ip in case of shared network. > --- > > Key: CLOUDSTACK-7536 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7536 > 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: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > steps to reproduce. > 1.) create a shared network with the following details. > gateway 10.136.10.1 > netmask 255.255.255.0 > guest ip range 10.136.10.1 to 10.136.10.20 (note that the gateway ip is > a part of the guest ip range.) > 2.) deploy a vm > the gateway ip gets allocated to a uservm. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7571) changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level
Bharat Kumar created CLOUDSTACK-7571: Summary: changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level Key: CLOUDSTACK-7571 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7571 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 steps to reproduce == 1-prepare a CS3.6 setup with vmware and xen cluster 2-set mem.overprovisioning.factor=3 and cpu.overprovisioning.factor=2 2-upgrade it to CCP4.3 3-record total memory and cpu at zone level 4-change cpu/memory overprovisioning for xen server cluster to some valid value expected = at zone level total memory should get changed , depends on overprovisioning value Actual === 1-total memory is not getting changed at zone level 2-but total memory/cpu of xen cluster is getting changed with overprovisioning factor My observation == 1-if i change overspovisioning factor of vmware cluster total memory is getting changed 2-In fresh setup with one xen cluster i did not see this problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7155) Re-copying templates to other zones doesn't work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7155. -- Resolution: Fixed > Re-copying templates to other zones doesn't work > > > Key: CLOUDSTACK-7155 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7155 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > Steps to reproduce. > 1. Create a new template. > 2. Copy template to another zone. > 3. Delete just created copy. > 4. Reissue copy command > DB record shows as removed in template_zone_ref table causing the deployment > to fail in that zone. > mysql> select * from template_zone_ref where template_id=2755; > -+ > id zone_id template_id created last_updatedremoved > -+ > 4033 1 27552013-11-25 20:12:52 2013-11-25 20:12:52 NULL > 4034 2 27552013-11-25 20:21:33 2013-11-25 20:24:04 > 2013-11-25 20:24:04 > 4046 6 27552013-11-26 20:08:18 2013-11-26 20:09:16 > 2013-11-26 20:09:16 > -+ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7156) List templates API returns destroyed templates when recopying the template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar closed CLOUDSTACK-7156. Resolution: Not a Problem > List templates API returns destroyed templates when recopying the template. > --- > > Key: CLOUDSTACK-7156 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7156 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > when we recopy a template multiple entries are created in the > template_store_ref. As a result when we recopy a template and list the > templates we might get a incorrect response which says the template download > failed even thought it got copied successfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7156) List templates API returns destroyed templates when recopying the template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7156: - Status: Open (was: Reviewable) The implementation has changed, This fix is not required in 4.5 > List templates API returns destroyed templates when recopying the template. > --- > > Key: CLOUDSTACK-7156 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7156 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > when we recopy a template multiple entries are created in the > template_store_ref. As a result when we recopy a template and list the > templates we might get a incorrect response which says the template download > failed even thought it got copied successfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7158) listCapacity API missing types for certain zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7158. -- Resolution: Fixed > listCapacity API missing types for certain zones > > > Key: CLOUDSTACK-7158 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7158 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > Issue > > listCapacity only shows type 2 & 6 when for certain zones. If zone id is > specified all types are shown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7536) user vm can get a gateway ip in case of shared network.
Bharat Kumar created CLOUDSTACK-7536: Summary: user vm can get a gateway ip in case of shared network. Key: CLOUDSTACK-7536 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7536 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: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 steps to reproduce. 1.) create a shared network with the following details. gateway 10.136.10.1 netmask 255.255.255.0 guest ip range 10.136.10.1 to 10.136.10.20 (note that the gateway ip is a part of the guest ip range.) 2.) deploy a vm the gateway ip gets allocated to a uservm. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPoin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-6099: - Status: Reviewable (was: In Progress) > live migration is failing for vm deployed using dynaic compute offerings with > NPE;unhandled exception executing api command: findHostsForMigration > java.lang.NullPointerException > - > > Key: CLOUDSTACK-6099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0, 4.4.0, 4.3.1, 4.4.1 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > Steps to reproduce > === > 1-Prepare CS setup with xen 6.2 ,two host in a cluster > 2-create a custom service offering > 3-deploy a vm with custom service offering > 4-try to migrate vm > Expected > = > vm should get migrate successfully > Actual > == > Migrate vm is failing with NPE > observation > === > migrate vm is working fine for vms deployed with regular compute offering > Log > === > 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume > allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize > : 115238502400, askingSize : 0, allocated disable threshold: 0.85 > 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator > returning 1 suitable storage pools > 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to > check for allocation: [Host[-4-Routing]] > 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation > after prioritization: [Host[-4-Routing]] > 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing > api command: findHostsForMigration > java.lang.NullPointerException > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) > at > com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy210.listHostsForMigrationOfVM(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) > at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servle
[jira] [Created] (CLOUDSTACK-7376) passwd_server attempts to start but terminates with the exit code 137
Bharat Kumar created CLOUDSTACK-7376: Summary: passwd_server attempts to start but terminates with the exit code 137 Key: CLOUDSTACK-7376 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7376 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 "Trying to add a non-contiguous IP range to an existing guest network, upon creation of an instance in the new range, the virtual router is updated with a new sub-interface but the passwd_server service (for serving passwords) is not running. If the script /opt/cloud/bin/passwd_server is run manually, then the service starts successfully and passwords can be served. If we reboot the virtual router via the CloudPlatform GUI, then it powers back up with the subinterface, but the passwd_server service is not running. Checking /var/log/cloud.log, the passwd_server attempts to start but terminates with the exit code 137, which from a quick google appears to be a SIGKILL termination. Steps to reproduce the issue i) Create a Shared Network in CCP and deploy a VM in the network. ii) Now add additional IP range to the same shared network. iii) Deploy a new VM in the additional IP range ( you can exhaust the first IP range to achieve this). iv) Once the new VM is deployed. Stop/start or restart the Router. The password server will fail to come up and following the entries in the logs In /var/log/cloud.log from VR /opt/cloud/bin/passwd_server_ip: line 32: 3161 Killed socat -lf /var/log/cloud.log TCP4-LISTEN:8080,reuseaddr,fork,crnl,bind=$addr SYSTEM:"/opt/cloud/bin/serve_password.sh \"\$SOCAT_PEERADDR\"" Also, There is no issue in starting the service manually after ssh into the Router. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7335) Automation:integration.smoke.test_templates.TestTemplates.test_06_copy_template Failed
Bharat Kumar created CLOUDSTACK-7335: Summary: Automation:integration.smoke.test_templates.TestTemplates.test_06_copy_template Failed Key: CLOUDSTACK-7335 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7335 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 Below TC Failed in CI Run Automation:integration.smoke.test_templates.TestTemplates.test_06_copy_template Failed Log File Path Below : http://nfs1.lab.vmops.com/automation//ccp-4.5/kvm/kvm__Log_15774.zip Failure Message: Job failed: {jobprocstatus : 0, created : u'2014-08-10T18:16:33-0700', jobresult : {errorcode : 530, errortext : u'Failed to copy template'} , cmd : u'org.apache.cloudstack.api.command.admin.template.CopyTemplateCmdByAdmin', userid : u'a7abf822-20ef-11e4-b052-00163e5d4a0e', jobstatus : 2, jobid : u'fde11b0d-af9a-45e0-962f-5af9d2bacf6d', jobresultcode : 530, jobinstanceid : u'a89d6284-2c2d-4ff4-a356-925f992bf43c', jobresulttype : u'object', jobinstancetype : u'Template', accountid : u'a7abc352-20ef-11e4-b052-00163e5d4a0e'} >> begin captured stdout << - === TestName: test_06_copy_template | Status : EXCEPTION === - >> end captured stdout << -- >> begin captured logging << test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: STARTED : TC: test_06_copy_template ::: test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: Copy template from Zone: a54cb8bf-9060-445a-bb45-98f3e0a07bfd to ba915df8-d4ef-4901-848b-e8d8257ba830 test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: Payload: {'sourcezoneid': u'a54cb8bf-9060-445a-bb45-98f3e0a07bfd', 'apiKey': u'mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtw', 'id': u'a89d6284-2c2d-4ff4-a356-925f992bf43c', 'command': 'copyTemplate', 'signature': 'kFETVPXF0CRW1R+SRw60s/WjG3U=', 'destzoneid': u'ba915df8-d4ef-4901-848b-e8d8257ba830', 'response': 'json'} test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: Sending GET Cmd : copyTemplate=== requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 172.16.88.28 requests.packages.urllib3.connectionpool: DEBUG: "GET /client/api?sourcezoneid=a54cb8bf-9060-445a-bb45-98f3e0a07bfd&apiKey=mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtw&destzoneid=ba915df8-d4ef-4901-848b-e8d8257ba830&command=copyTemplate&signature=kFETVPXF0CRW1R%2BSRw60s%2FWjG3U%3D&response=json&id=a89d6284-2c2d-4ff4-a356-925f992bf43c HTTP/1.1" 200 77 test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: === Jobid: fde11b0d-af9a-45e0-962f-5af9d2bacf6d Started === test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: Payload: {'signature': 'qlhp3LhXoNOXP3MeHVgc+aLpoKg=', 'apiKey': u'mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtw', 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': u'fde11b0d-af9a-45e0-962f-5af9d2bacf6d'} test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: Sending GET Cmd : queryAsyncJobResult=== requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 172.16.88.28 requests.packages.urllib3.connectionpool: DEBUG: "GET /client/api?jobid=fde11b0d-af9a-45e0-962f-5af9d2bacf6d&apiKey=mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtw&command=queryAsyncJobResult&response=json&signature=qlhp3LhXoNOXP3MeHVgc%2BaLpoKg%3D HTTP/1.1" 200 434 test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: Response : {jobprocstatus : 0, created : u'2014-08-10T18:16:33-0700', cmd : u'org.apache.cloudstack.api.command.admin.template.CopyTemplateCmdByAdmin', userid : u'a7abf822-20ef-11e4-b052-00163e5d4a0e', jobstatus : 0, jobid : u'fde11b0d-af9a-45e0-962f-5af9d2bacf6d', jobresultcode : 0, jobinstanceid : u'a89d6284-2c2d-4ff4-a356-925f992bf43c', jobinstancetype : u'Template', accountid : u'a7abc352-20ef-11e4-b052-00163e5d4a0e'} test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: === JobId:fde11b0d-af9a-45e0-962f-5af9d2bacf6d is Still Processing, Will TimeOut in:3595 test_06_copy_template (integration.smoke.test_templates.TestTemplates): DEBUG: Payload: {'signature': 'qlhp3LhXoNOXP3MeHVgc+aLpoKg=', 'apiKey': u'mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtw', 'co
[jira] [Updated] (CLOUDSTACK-7156) List templates API returns destroyed templates when recopying the template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7156: - Status: Reviewable (was: In Progress) > List templates API returns destroyed templates when recopying the template. > --- > > Key: CLOUDSTACK-7156 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7156 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > when we recopy a template multiple entries are created in the > template_store_ref. As a result when we recopy a template and list the > templates we might get a incorrect response which says the template download > failed even thought it got copied successfully. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7158) listCapacity API missing types for certain zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7158: - Status: Reviewable (was: In Progress) > listCapacity API missing types for certain zones > > > Key: CLOUDSTACK-7158 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7158 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > Issue > > listCapacity only shows type 2 & 6 when for certain zones. If zone id is > specified all types are shown. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7158) listCapacity API missing types for certain zones
Bharat Kumar created CLOUDSTACK-7158: Summary: listCapacity API missing types for certain zones Key: CLOUDSTACK-7158 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7158 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 Issue listCapacity only shows type 2 & 6 when for certain zones. If zone id is specified all types are shown. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7156) List templates API returns destroyed templates when recopying the template.
Bharat Kumar created CLOUDSTACK-7156: Summary: List templates API returns destroyed templates when recopying the template. Key: CLOUDSTACK-7156 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7156 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 when we recopy a template multiple entries are created in the template_store_ref. As a result when we recopy a template and list the templates we might get a incorrect response which says the template download failed even thought it got copied successfully. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7155) Re-copying templates to other zones doesn't work
Bharat Kumar created CLOUDSTACK-7155: Summary: Re-copying templates to other zones doesn't work Key: CLOUDSTACK-7155 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7155 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 Steps to reproduce. 1. Create a new template. 2. Copy template to another zone. 3. Delete just created copy. 4. Reissue copy command DB record shows as removed in template_zone_ref table causing the deployment to fail in that zone. mysql> select * from template_zone_ref where template_id=2755; -+ id zone_id template_id created last_updatedremoved -+ 4033 1 27552013-11-25 20:12:52 2013-11-25 20:12:52 NULL 4034 2 27552013-11-25 20:21:33 2013-11-25 20:24:04 2013-11-25 20:24:04 4046 6 27552013-11-26 20:08:18 2013-11-26 20:09:16 2013-11-26 20:09:16 -+ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7026) mark the test_01_primary_storage_iscsi as test that requires hardware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7026. -- Resolution: Fixed > mark the test_01_primary_storage_iscsi as test that requires hardware > - > > Key: CLOUDSTACK-7026 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7026 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)