[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
[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
[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 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] [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] [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] [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-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] [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-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-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=admin=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=Qp0XOEUVLrZHBZrQp7ame96IzXE%3D=true=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] [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] [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] [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-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-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-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] [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] [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] [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'
[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-tabpanelfocusedCommentId=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-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] [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] [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-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] [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.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at
[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-tabpanelfocusedCommentId=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] [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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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] [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] [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] [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-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 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at
[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-tabpanelfocusedCommentId=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 domain Id 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-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 domain Id 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-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.NativeMethodAccessorImpl.invoke0(Native Method) at
[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 domain Id 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] [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-eb274d2f471capiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ command=queryAsyncJobResultresponse=jsonsignature=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] 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-eb274d2f471capiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ command=queryAsyncJobResultresponse=jsonsignature=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] 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-eb274d2f471capiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ command=queryAsyncJobResultresponse=jsonsignature=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] [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-tabpanelfocusedCommentId=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-eb274d2f471capiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ command=queryAsyncJobResultresponse=jsonsignature=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] [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-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-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-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] [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] [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] [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-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.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at
[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] [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-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-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] [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-tabpanelfocusedCommentId=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] [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] [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-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] [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] [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.servlet.http.HttpServlet.service(HttpServlet.java:717) at
[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-98f3e0a07bfdapiKey=mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtwdestzoneid=ba915df8-d4ef-4901-848b-e8d8257ba830command=copyTemplatesignature=kFETVPXF0CRW1R%2BSRw60s%2FWjG3U%3Dresponse=jsonid=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-5af9d2bacf6dapiKey=mo2uCIkOVxioCTzdq_-GDMEZX25XKno5ath3z01A7BuNz2cdqPnDdeN1inq1892z41C4xlU2-2mWvyfvWQSdtwcommand=queryAsyncJobResultresponse=jsonsignature=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',
'command':
[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] [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-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] [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] [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] [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)
[jira] [Created] (CLOUDSTACK-7026) mark the test_01_primary_storage_iscsi as test that requires hardware.
Bharat Kumar created CLOUDSTACK-7026: Summary: 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)
[jira] [Updated] (CLOUDSTACK-7026) test that requires hardware.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 updated CLOUDSTACK-7026: - Summary: test that requires hardware.mark the test_01_primary_storage_iscsi as test that requires hardware (was: mark the test_01_primary_storage_iscsi as test that requires hardware.) test that requires hardware.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)
[jira] [Updated] (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 updated CLOUDSTACK-7026: - Summary: mark the test_01_primary_storage_iscsi as test that requires hardware (was: test that requires hardware.mark the test_01_primary_storage_iscsi as test that requires hardware) 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)
[jira] [Created] (CLOUDSTACK-6933) registering an iso fails in KVM deployment.
Bharat Kumar created CLOUDSTACK-6933: Summary: registering an iso fails in KVM deployment. Key: CLOUDSTACK-6933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6933 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Environment: KVM advanced network Reporter: Bharat Kumar Fix For: 4.4.0 registing an iso fails with the connection refused error in KVM deployment. below are the iptable rules on the relevant SSVM in the env. Chain INPUT (policy DROP 28 packets, 1340 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:443 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:80 0 0 ACCEPT tcp -- eth1 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:3922 172 13277 ACCEPT all -- eth0 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 4122 469K ACCEPT all -- eth1 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 196 10976 ACCEPT all -- eth2 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth3 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- lo * 0.0.0.0/00.0.0.0/0 0 0 DROP icmp -- * * 0.0.0.0/00.0.0.0/0 icmptype 13 0 0 ACCEPT icmp -- * * 0.0.0.0/00.0.0.0/0 3 180 ACCEPT tcp -- eth0 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:3922 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 511 packets, 81586 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * eth10.0.0.0/0 172.16.88.0/24 state NEW tcp 2576 155K ACCEPT tcp -- * eth10.0.0.0/0 172.16.88.0/24 state NEW tcp 0 0 REJECT tcp -- * eth10.0.0.0/00.0.0.0/0 state NEW tcp dpt:80 reject-with icmp-port-unreachable 0 0 REJECT tcp -- * eth10.0.0.0/00.0.0.0/0 state NEW tcp dpt:443 reject-with icmp-port-unreachable Chain HTTP (0 references) pkts bytes target prot opt in out source destination root@s-54-QA:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.16.171.10.0.0.0 UG0 00 eth2 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0 172.16.88.0 0.0.0.0 255.255.255.0 U 0 00 eth1 172.16.88.0 0.0.0.0 255.255.255.0 U 0 00 eth3 172.16.171.00.0.0.0 255.255.255.0 U 0 00 eth2 As per the above config when a packet is sent to 172.16.88.x/24 subnet we are routing it via interface eth1. but we also have a reject rule in the OUTPUT chain for the packets leaving from eth1. as a result the packets get dropped. if we interchange the routes i.e. if the route related to eth3 is hit before hitting the eth1 route the register iso is successful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-6769) [Automation]: Test case failure in test_iso.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar reopened CLOUDSTACK-6769:
--
[Automation]: Test case failure in test_iso.py
--
Key: CLOUDSTACK-6769
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6769
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, XenServer
Affects Versions: 4.4.0
Reporter: Harikrishna Patnala
Assignee: Girish Shilamkar
Fix For: 4.4.0
There is test case failure in test_iso.py
1) integration.smoke.test_iso.TestCreateIso.test_01_create_iso
Error Message
Exception while downloading ISO 06f0617c-4605-4a8f-855b-085486a1fd4b: Error
In Downloading ISO: ISO Status - Network is unreachable
=== TestName: test_01_create_iso | Status : FAILED ===
- end captured stdout --
begin captured logging
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
STARTED : TC: test_01_create_iso :::
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Payload: {'apiKey':
u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
'command': 'listDomains', 'signature': 'Or2nHFPqukzhTba7v4PyKSS2Obc=',
'response': 'json'}
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Sending GET Cmd : listDomains===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6wcommand=listDomainsresponse=jsonsignature=Or2nHFPqukzhTba7v4PyKSS2Obc%3D
HTTP/1.1 200 159
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Response : [{path : u'ROOT', haschild : False, id :
u'45612b7c-e49c-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Payload: {'apiKey':
u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
'name': 'zone-xen', 'command': 'listZones', 'signature':
'77O72WZATq83Kw9J9yK0yKsjlHM=', 'response': 'json'}
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Sending GET Cmd : listZones===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?response=jsonapiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6wcommand=listZonesname=zone-xensignature=77O72WZATq83Kw9J9yK0yKsjlHM%3D
HTTP/1.1 200 446
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Response : [{localstorageenabled : False, name : u'zone-xen',
guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
u'921064dc-f25a-3393-94b7-7ba269fa1f82', dns2 : u'8.8.4.4', dns1 :
u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
u'Advanced', id : u'5c872b2f-53eb-46bd-8d7f-f9654f509b39', internaldns2 :
u'172.16.88.7'}]
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Payload: {'username': 'test-account-TestISO-test_01_create_iso-UI4FTT',
'domainid': u'45612b7c-e49c-11e3-a141-00163e189e44', 'firstname': 'test',
'lastname': 'test', 'response': 'json', 'apiKey':
u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
'command': 'createAccount', 'accounttype': 0, 'signature':
'q5ftoGqB/V1+Q+L3FGbYsOWsON0=', 'password': 'password', 'email':
'test-acco...@test.com'}
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Sending GET Cmd : createAccount===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?username=test-account-TestISO-test_01_create_iso-UI4FTTdomainid=45612b7c-e49c-11e3-a141-00163e189e44firstname=testlastname=testemail=test-account%40test.comapiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6wcommand=createAccountaccounttype=0signature=q5ftoGqB%2FV1%2BQ%2BL3FGbYsOWsON0%3Dpassword=passwordresponse=json
HTTP/1.1 200 1650
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT',
domainid : u'45612b7c-e49c-11e3-a141-00163e189e44', vpclimit : u'Unlimited',
iplimit :
[jira] [Commented] (CLOUDSTACK-6769) [Automation]: Test case failure in test_iso.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033855#comment-14033855
]
Bharat Kumar commented on CLOUDSTACK-6769:
--
Hi reopening this issue as the create_iso fails in KVM with a connection
refused error.
[Automation]: Test case failure in test_iso.py
--
Key: CLOUDSTACK-6769
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6769
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, XenServer
Affects Versions: 4.4.0
Reporter: Harikrishna Patnala
Assignee: Girish Shilamkar
Fix For: 4.4.0
There is test case failure in test_iso.py
1) integration.smoke.test_iso.TestCreateIso.test_01_create_iso
Error Message
Exception while downloading ISO 06f0617c-4605-4a8f-855b-085486a1fd4b: Error
In Downloading ISO: ISO Status - Network is unreachable
=== TestName: test_01_create_iso | Status : FAILED ===
- end captured stdout --
begin captured logging
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
STARTED : TC: test_01_create_iso :::
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Payload: {'apiKey':
u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
'command': 'listDomains', 'signature': 'Or2nHFPqukzhTba7v4PyKSS2Obc=',
'response': 'json'}
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Sending GET Cmd : listDomains===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6wcommand=listDomainsresponse=jsonsignature=Or2nHFPqukzhTba7v4PyKSS2Obc%3D
HTTP/1.1 200 159
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Response : [{path : u'ROOT', haschild : False, id :
u'45612b7c-e49c-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Payload: {'apiKey':
u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
'name': 'zone-xen', 'command': 'listZones', 'signature':
'77O72WZATq83Kw9J9yK0yKsjlHM=', 'response': 'json'}
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Sending GET Cmd : listZones===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?response=jsonapiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6wcommand=listZonesname=zone-xensignature=77O72WZATq83Kw9J9yK0yKsjlHM%3D
HTTP/1.1 200 446
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Response : [{localstorageenabled : False, name : u'zone-xen',
guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
u'921064dc-f25a-3393-94b7-7ba269fa1f82', dns2 : u'8.8.4.4', dns1 :
u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
u'Advanced', id : u'5c872b2f-53eb-46bd-8d7f-f9654f509b39', internaldns2 :
u'172.16.88.7'}]
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Payload: {'username': 'test-account-TestISO-test_01_create_iso-UI4FTT',
'domainid': u'45612b7c-e49c-11e3-a141-00163e189e44', 'firstname': 'test',
'lastname': 'test', 'response': 'json', 'apiKey':
u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
'command': 'createAccount', 'accounttype': 0, 'signature':
'q5ftoGqB/V1+Q+L3FGbYsOWsON0=', 'password': 'password', 'email':
'test-acco...@test.com'}
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Sending GET Cmd : createAccount===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?username=test-account-TestISO-test_01_create_iso-UI4FTTdomainid=45612b7c-e49c-11e3-a141-00163e189e44firstname=testlastname=testemail=test-account%40test.comapiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6wcommand=createAccountaccounttype=0signature=q5ftoGqB%2FV1%2BQ%2BL3FGbYsOWsON0%3Dpassword=passwordresponse=json
HTTP/1.1 200 1650
test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
Response :
[jira] [Created] (CLOUDSTACK-6874) automation test failures.
Bharat Kumar created CLOUDSTACK-6874: Summary: automation test failures. Key: CLOUDSTACK-6874 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6874 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 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6875) test_volumes is failing on simulator runs
Bharat Kumar created CLOUDSTACK-6875:
Summary: test_volumes is failing on simulator runs
Key: CLOUDSTACK-6875
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6875
Project: CloudStack
Issue Type: Sub-task
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Reporter: Bharat Kumar
Error Message
Job failed: {jobprocstatus : 0, created : u'2014-06-08T20:26:20-0700', cmd :
u'org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin',
userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 2, jobid :
u'b263a941-29b1-4ab8-9c00-7a0d2678b591', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u'Unexpected exception'},
accountid : u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
begin captured stdout -
=== TestName: test_09_delete_detached_volume | Status : EXCEPTION ===
- end captured stdout --
begin captured logging
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: STARTED : TC: test_09_delete_detached_volume :::
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Delete Volume ID: 24051890-92ad-4cee-8ca3-119d278b072a
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Payload: {'account': u'test-account-TestCreateVolume-N2SRV2',
'domainid': u'36a27fb8-ef83-11e3-a86b-00163e0af42c', 'name': 'Test Volume',
'zoneid': u'ef5040e4-6e78-433b-a21a-656a7ab31e80', 'apiKey':
u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
'command': 'createVolume', 'signature': 'O0mZxBTYte8bIWPhtBYKUycq8Yo=',
'diskofferingid': u'92b2888e-c624-4042-82b4-632bed2bb38d', 'response': 'json'}
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Sending GET Cmd : createVolume===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.23
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?account=test-account-TestCreateVolume-N2SRV2domainid=36a27fb8-ef83-11e3-a86b-00163e0af42cname=Test+Volumezoneid=ef5040e4-6e78-433b-a21a-656a7ab31e80apiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQcommand=createVolumesignature=O0mZxBTYte8bIWPhtBYKUycq8Yo%3Ddiskofferingid=92b2888e-c624-4042-82b4-632bed2bb38dresponse=json
HTTP/1.1 200 121
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: === Jobid: 2249fb73-7560-4d22-a7f9-dba0507b096e Started ===
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Payload: {'signature': '8di/lZIPnn9qCgFh0fHVVrH7/8U=', 'apiKey':
u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
'command': 'queryAsyncJobResult', 'response': 'json', 'jobid':
u'2249fb73-7560-4d22-a7f9-dba0507b096e'}
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.23
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?jobid=2249fb73-7560-4d22-a7f9-dba0507b096eapiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQcommand=queryAsyncJobResultresponse=jsonsignature=8di%2FlZIPnn9qCgFh0fHVVrH7%2F8U%3D
HTTP/1.1 200 430
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Response : {jobprocstatus : 0, created : u'2014-06-08T20:26:14-0700',
cmd : u'org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin',
userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 0, jobid :
u'2249fb73-7560-4d22-a7f9-dba0507b096e', jobresultcode : 0, jobinstanceid :
u'c936802c-42f3-4ff3-9eb2-dd003517a8ef', jobinstancetype : u'Volume', accountid
: u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: === JobId:2249fb73-7560-4d22-a7f9-dba0507b096e is Still Processing, Will
TimeOut in:3595
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Payload: {'signature': '8di/lZIPnn9qCgFh0fHVVrH7/8U=', 'apiKey':
u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
'command': 'queryAsyncJobResult', 'response': 'json', 'jobid':
u'2249fb73-7560-4d22-a7f9-dba0507b096e'}
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1):
