[jira] [Updated] (CLOUDSTACK-7496) [Automation][HyperV] Unable to ssh into the System VMs after Reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7496: --- Assignee: Sowmya Krishnan (was: Rajesh Battala) [Automation][HyperV] Unable to ssh into the System VMs after Reboot --- Key: CLOUDSTACK-7496 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7496 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Sowmya Krishnan Priority: Critical Fix For: 4.5.0 Attachments: runinfo.zip I attached the Automation client log information to this bug report. It shows that the System VMs could not be accessed via ssh after reboot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7373) Incorrect Japanese keyboard mapping with CentOS CLI guestOS on VMware host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151409#comment-14151409
]
ASF subversion and git services commented on CLOUDSTACK-7373:
-
Commit bdf7d6530593db33636b2fecf18bb2cf4c61d21f in cloudstack's branch
refs/heads/master from [~sanjay.tripathi]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bdf7d65 ]
CLOUDSTACK-7373: Incorrect Japanese keyboard mapping with CentOS CLI and
windows guestOS on VMware.
Incorrect Japanese keyboard mapping with CentOS CLI guestOS on VMware host
--
Key: CLOUDSTACK-7373
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7373
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: VNC Proxy
Affects Versions: 4.4.0
Environment: Latest master branch(4.5)
VMware ESXI 5.1
CentOS 6.3 CLI
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
Fix For: 4.5.0
VM - Cent OS 6.5 x64 ( Both GUI and CLI)
Keyboard - JP
The Keys that are mapped incorrectly are:
||Sl. No||Actual Key Typed||Key mapped to|
|1 | _| - |
|2 | ^ | = |
|3 | @ | [ |
|4 | [| ] |
|5 | :| ’ |
|6 | ]| \ |
|7 | \| No input taken |
| | | |
|| |||Shift Keys||Shift Keys|
|9 | ” | @ |
|10 | | ^|
|11 | ’ | |
|12 | ( | *|
|13 | ) |( |
|14 | = |) |
|15 | ~ | _ |
|16 | ` |+ |
|17 | { } | [ |
|18 | + | ] |
|19 | * |:|
|20 | } | ”|
|21 | _ | No input taken |
Additional Information:
#vi /etc/sysconfig/i18n
Language set as : LANG=ja_JP.utf8
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7545) [VMware] DiskIOLimitation from ComputeOffering and DiskOffering doesn't apply to VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151456#comment-14151456 ] Axel Delahaye commented on CLOUDSTACK-7545: --- Are you interested in an implementation for VmWare ? [VMware] DiskIOLimitation from ComputeOffering and DiskOffering doesn't apply to VM --- Key: CLOUDSTACK-7545 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7545 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0 Environment: Vmware Vcenter 5.5 Reporter: Axel Delahaye Priority: Critical Labels: iops, vmware When I set up an iops limit to the ComputeOffering or the DiskOffering. After start a VM and looking in the vCenter web client, all disks of the VM are set to Unlimited IOPS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7615) [Automation] Firewall rules fails with ResourceUnavailableException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151506#comment-14151506
]
Jayapal Reddy commented on CLOUDSTACK-7615:
---
Hi Rayees/Animesh,
The exception is handled properly in the code.
In the logs what you see is the thrown exception is printed as a warning
message.
Do you want NOT to print the exception in log message ?
Assigning it you, if it is ok then reassign to me.
Thanks,
Jayapal
[Automation] Firewall rules fails with ResourceUnavailableException
---
Key: CLOUDSTACK-7615
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7615
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: Rayees Namathponnan
Assignee: Jayapal Reddy
Fix For: 4.5.0
Attachments: management-server.log.1
This Exception should be handled properly, seen this issue during automation
run, VR not available to apply, that need to be tracked
Here i am creating this ticket to imrove logggin
1, Ver: v1, Flags: 0,
[{com.cloud.agent.api.Answer:{result:false,details:,wait:0}}] }
2014-09-23 17:05:27,007 DEBUG [c.c.a.t.Request]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Seq
1-7258113749460975844: Received: { Ans: , MgmtI
d: 72809463712085, via: 1, Ver: v1, Flags: 0, { Answer } }
2014-09-23 17:05:27,007 WARN [c.c.n.f.FirewallManagerImpl]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Failed to apply
firewall rules due to
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Unable to apply firewall rules on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4050)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyFirewallRules(VirtualNetworkApplianceManagerImpl.java:3862)
at sun.reflect.GeneratedMethodAccessor323.invoke(Unknown Source)
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 $Proxy190.applyFirewallRules(Unknown Source)
at
com.cloud.network.element.VirtualRouterElement.applyFWRules(VirtualRouterElement.java:260)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:577)
at
com.cloud.network.IpAddressManagerImpl.applyRules(IpAddressManagerImpl.java:504)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:532)
at
com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(FirewallManagerImpl.java:658)
at
com.cloud.network.firewall.FirewallManagerImpl.applyIngressFirewallRules(FirewallManagerImpl.java:630)
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 $Proxy195.applyIngressFirewallRules(Unknown Source)
at
[jira] [Updated] (CLOUDSTACK-7615) [Automation] Firewall rules fails with ResourceUnavailableException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy updated CLOUDSTACK-7615:
--
Assignee: Rayees Namathponnan (was: Jayapal Reddy)
[Automation] Firewall rules fails with ResourceUnavailableException
---
Key: CLOUDSTACK-7615
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7615
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: Rayees Namathponnan
Assignee: Rayees Namathponnan
Fix For: 4.5.0
Attachments: management-server.log.1
This Exception should be handled properly, seen this issue during automation
run, VR not available to apply, that need to be tracked
Here i am creating this ticket to imrove logggin
1, Ver: v1, Flags: 0,
[{com.cloud.agent.api.Answer:{result:false,details:,wait:0}}] }
2014-09-23 17:05:27,007 DEBUG [c.c.a.t.Request]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Seq
1-7258113749460975844: Received: { Ans: , MgmtI
d: 72809463712085, via: 1, Ver: v1, Flags: 0, { Answer } }
2014-09-23 17:05:27,007 WARN [c.c.n.f.FirewallManagerImpl]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Failed to apply
firewall rules due to
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Unable to apply firewall rules on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4050)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyFirewallRules(VirtualNetworkApplianceManagerImpl.java:3862)
at sun.reflect.GeneratedMethodAccessor323.invoke(Unknown Source)
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 $Proxy190.applyFirewallRules(Unknown Source)
at
com.cloud.network.element.VirtualRouterElement.applyFWRules(VirtualRouterElement.java:260)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:577)
at
com.cloud.network.IpAddressManagerImpl.applyRules(IpAddressManagerImpl.java:504)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:532)
at
com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(FirewallManagerImpl.java:658)
at
com.cloud.network.firewall.FirewallManagerImpl.applyIngressFirewallRules(FirewallManagerImpl.java:630)
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 $Proxy195.applyIngressFirewallRules(Unknown Source)
at
org.apache.cloudstack.api.command.user.firewall.CreatePortForwardingRuleCmd.execute(CreatePortForwardingRuleCmd.java:213)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
[jira] [Created] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0.1 with Xenserver HV.
manasaveloori created CLOUDSTACK-7642: - Summary: [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0.1 with Xenserver HV. Key: CLOUDSTACK-7642 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7642 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.5.0 Environment: upgrade from 4.3.0.1 to 4.5 using Xen server 6.2 Reporter: manasaveloori Priority: Blocker Fix For: 4.5.0 1. Deployed 4.3.0.1 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0.1 build. 2. Registered the 4.5 template as systemvm-xenserver-4.5 3. Upgraded to 4.5 and started the MS. Observation: Observed the following exception in MS logs .Hosts went into disconnected stated. 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host 1(Rack1Pod1Host29) 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to find class com.cloud.hypervisor.xen.resource.XenServer620Resource java.lang.ClassNotFoundException: com.cloud.hypervisor.xen.resource.XenServer620Resource at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) at com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) at com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) at com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) at com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) at com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) at com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235) at org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) 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.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) 2014-09-29 13:45:26,852 WARN [c.c.a.m.AgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = Rack1Pod1Host29] Attaching the dumps and logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7643) [Automation] EIP/ELB ssvm test cases failing while verifyig gateway
Rayees Namathponnan created CLOUDSTACK-7643: --- Summary: [Automation] EIP/ELB ssvm test cases failing while verifyig gateway Key: CLOUDSTACK-7643 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7643 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Rayees Namathponnan Priority: Critical Fix For: 4.5.0 SSVM test cases failing in EIP/ ELB runs Below test cases failing integration.smoke.test_ssvm.TestSSVMs.test_01_list_sec_storage_vm integration.smoke.test_ssvm.TestSSVMs.test_02_list_cpvm_vm integration.smoke.test_ssvm.TestSSVMs.test_06_stop_cpvm integration.smoke.test_ssvm.TestSSVMs.test_05_stop_ssvm These test cases failing while checking gateway, in EIP/ELB setup gate will be netscaler IP, we need to update this test case for EIP/ELB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7643) [Automation] EIP/ELB ssvm test cases failing while verifyig gateway
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7643: Assignee: Gaurav Aradhye [Automation] EIP/ELB ssvm test cases failing while verifyig gateway --- Key: CLOUDSTACK-7643 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7643 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Rayees Namathponnan Assignee: Gaurav Aradhye Priority: Critical Fix For: 4.5.0 SSVM test cases failing in EIP/ ELB runs Below test cases failing integration.smoke.test_ssvm.TestSSVMs.test_01_list_sec_storage_vm integration.smoke.test_ssvm.TestSSVMs.test_02_list_cpvm_vm integration.smoke.test_ssvm.TestSSVMs.test_06_stop_cpvm integration.smoke.test_ssvm.TestSSVMs.test_05_stop_ssvm These test cases failing while checking gateway, in EIP/ELB setup gate will be netscaler IP, we need to update this test case for EIP/ELB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7644) test_persistent_networks.py - SSH failure in case of LB rules due to port mismatch
Gaurav Aradhye created CLOUDSTACK-7644: -- Summary: test_persistent_networks.py - SSH failure in case of LB rules due to port mismatch Key: CLOUDSTACK-7644 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7644 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Environment: Observed in KVM Regression runs Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 Test case which try SSH to VM after creating LB rule fail during SSH. The SSH method tries to connect via SSH to default port 22, but LB rule is created for public port . Hence in this case, port number should be explicitly passed while trying SSH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7645) Many instances of ???label.*???
Stephen Turner created CLOUDSTACK-7645: -- Summary: Many instances of ???label.*??? Key: CLOUDSTACK-7645 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Stephen Turner Assignee: Mihaela Stoica Fix For: 4.5.0 We have many instances of \?\?\?label.*\?\?\? in the UI, including strings I know were correct recently. (For example, I saw it on the certificate upload UI, which was recently rewritten). I think something is wrong with the mechanism rather than individual translations, so rather than creating a bug for each one, I have bundled them together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7607) [UI]Incorrect name ( ???label.user.vm???) with cloudstack dash board General Alerts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Turner resolved CLOUDSTACK-7607. Resolution: Duplicate I have created a ticket to bundle up all similar issues. Resolving these as Duplicates, because that was the closest resolution I could find. [UI]Incorrect name ( ???label.user.vm???) with cloudstack dash board General Alerts -- Key: CLOUDSTACK-7607 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7607 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Steps: 1. Configure Adv zone using XS 6.5 2. Deployed VM . It failed to deploy due to insufficient resources. 3. This generated an Alert for user VM deploy failure Observation : [UI]Incorrect name ( ???label.user.vm???) with cloudstack dash board General Alerts Attached screen shot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7608) [UI]Incorrect name (View ???label.portable.ip???) with Region Details page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Turner resolved CLOUDSTACK-7608. Resolution: Duplicate I have created a ticket to bundle up all similar issues. Resolving these as Duplicates, because that was the closest resolution I could find. [UI]Incorrect name (View ???label.portable.ip???) with Region Details page Key: CLOUDSTACK-7608 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7608 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Attachments: incorrectregionUI.png Steps: 1. Configure Adv zone using XS 6.5 2. Access Region = Details page Observation: [UI]Incorrect name (View ???label.portable.ip???) with Region Details page Attached screen shot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7606) [UI]Incorrect Field value (???label.vm.id??? state.detached) with uploaded volume details page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Turner resolved CLOUDSTACK-7606. Resolution: Duplicate I have created a ticket to bundle up all similar issues. Resolving these as Duplicates, because that was the closest resolution I could find. [UI]Incorrect Field value (???label.vm.id??? state.detached) with uploaded volume details page --- Key: CLOUDSTACK-7606 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7606 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Fix For: 4.5.0 Attachments: incorrectdashboardUI.png, incorrectuploadvolumeid.png Steps: 1. Configure Adv zone using XS 6.5 2. Uploaded a new vhd volume using upload volume option 3. Access this volume details page Observation: [UI]Incorrect Field value (???label.vm.id??? state.detached) with uploaded volume details page Attached the screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7596) [UI] Text box for dns entry displaying ??? in label
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Turner resolved CLOUDSTACK-7596. Resolution: Duplicate I have created a ticket to bundle up all similar issues. Resolving these as Duplicates, because that was the closest resolution I could find. [UI] Text box for dns entry displaying ??? in label Key: CLOUDSTACK-7596 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7596 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Minor Fix For: 4.5.0 Attachments: UI Bug 63.jpg Cloudstack 4.5 on Rhel 6.3 During zone creation wizard the text field for entering IPV4 DNS is showing ??? in the label. Please see attached image. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7597) [UI]Incorrect Field value (???label.vgpu???) with VM details page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Turner resolved CLOUDSTACK-7597. Resolution: Duplicate I have created a ticket to bundle up all similar issues. Resolving these as Duplicates, because that was the closest resolution I could find. [UI]Incorrect Field value (???label.vgpu???) with VM details page -- Key: CLOUDSTACK-7597 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7597 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Fix For: 4.5.0 Attachments: incorrectlable.png Steps: 1. Install and configure adv zone(XenServer 6.5). 2. Deploy VM instance 3. Try to view VM details screen Observation: [UI]Incorrect Field value (???label.vgpu???) with VM details page (Attached screen) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7615) [Automation] Firewall rules fails with ResourceUnavailableException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-7615:
Assignee: Jayapal Reddy (was: Rayees Namathponnan)
[Automation] Firewall rules fails with ResourceUnavailableException
---
Key: CLOUDSTACK-7615
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7615
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: Rayees Namathponnan
Assignee: Jayapal Reddy
Fix For: 4.5.0
Attachments: management-server.log.1
This Exception should be handled properly, seen this issue during automation
run, VR not available to apply, that need to be tracked
Here i am creating this ticket to imrove logggin
1, Ver: v1, Flags: 0,
[{com.cloud.agent.api.Answer:{result:false,details:,wait:0}}] }
2014-09-23 17:05:27,007 DEBUG [c.c.a.t.Request]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Seq
1-7258113749460975844: Received: { Ans: , MgmtI
d: 72809463712085, via: 1, Ver: v1, Flags: 0, { Answer } }
2014-09-23 17:05:27,007 WARN [c.c.n.f.FirewallManagerImpl]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Failed to apply
firewall rules due to
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Unable to apply firewall rules on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4050)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyFirewallRules(VirtualNetworkApplianceManagerImpl.java:3862)
at sun.reflect.GeneratedMethodAccessor323.invoke(Unknown Source)
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 $Proxy190.applyFirewallRules(Unknown Source)
at
com.cloud.network.element.VirtualRouterElement.applyFWRules(VirtualRouterElement.java:260)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:577)
at
com.cloud.network.IpAddressManagerImpl.applyRules(IpAddressManagerImpl.java:504)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:532)
at
com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(FirewallManagerImpl.java:658)
at
com.cloud.network.firewall.FirewallManagerImpl.applyIngressFirewallRules(FirewallManagerImpl.java:630)
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 $Proxy195.applyIngressFirewallRules(Unknown Source)
at
org.apache.cloudstack.api.command.user.firewall.CreatePortForwardingRuleCmd.execute(CreatePortForwardingRuleCmd.java:213)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
[jira] [Created] (CLOUDSTACK-7646) test_nuage_vsp.py - Fix indentation issues and list out of index, mark test case as invalid, should be moved to BVT
Gaurav Aradhye created CLOUDSTACK-7646: -- Summary: test_nuage_vsp.py - Fix indentation issues and list out of index, mark test case as invalid, should be moved to BVT Key: CLOUDSTACK-7646 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7646 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Environment: Observed on KVM Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 This test has many indentation issues and list index issues. Also even after fixing the issues the test case does not pass which indicates it has not run before adding to regression test cases. It should be marked as Invalid. After author fixes the remaining issues, this test suite should be moved to Smoke (BVT) as it has only one test case which is clearly a BVT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7635) CS 4.3.1 GUI Import certificate fails in Firefox 32.0.2.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151610#comment-14151610 ] France commented on CLOUDSTACK-7635: I would not like to do it in production environment again if not absolutely necessary. I can however try to add it to your test environment, if you give me access. We can even do it together using RDP, VNC, teamviewer or something. Contact me to my private mail. CS 4.3.1 GUI Import certificate fails in Firefox 32.0.2. Key: CLOUDSTACK-7635 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7635 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.1 Environment: CentOS 6.5 Reporter: France Assignee: Stephen Turner CS 4.3 GUI Import certificate fails in Firefox 32.0.2 on OSX with error message: Failed to update SSL Certificate. There is nothing in management or catalina log, regarding when this happens. However it works normally with latest Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7615) [Automation] Firewall rules fails with ResourceUnavailableException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151611#comment-14151611
]
ASF subversion and git services commented on CLOUDSTACK-7615:
-
Commit 1d01ee3a60259b2113d14c2890306d7f2e56fbff in cloudstack's branch
refs/heads/master from Jayapal
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1d01ee3 ]
CLOUDSTACK-7615: Update log msg to print error msg rather than exception
[Automation] Firewall rules fails with ResourceUnavailableException
---
Key: CLOUDSTACK-7615
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7615
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: Rayees Namathponnan
Assignee: Jayapal Reddy
Fix For: 4.5.0
Attachments: management-server.log.1
This Exception should be handled properly, seen this issue during automation
run, VR not available to apply, that need to be tracked
Here i am creating this ticket to imrove logggin
1, Ver: v1, Flags: 0,
[{com.cloud.agent.api.Answer:{result:false,details:,wait:0}}] }
2014-09-23 17:05:27,007 DEBUG [c.c.a.t.Request]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Seq
1-7258113749460975844: Received: { Ans: , MgmtI
d: 72809463712085, via: 1, Ver: v1, Flags: 0, { Answer } }
2014-09-23 17:05:27,007 WARN [c.c.n.f.FirewallManagerImpl]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Failed to apply
firewall rules due to
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Unable to apply firewall rules on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4050)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyFirewallRules(VirtualNetworkApplianceManagerImpl.java:3862)
at sun.reflect.GeneratedMethodAccessor323.invoke(Unknown Source)
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 $Proxy190.applyFirewallRules(Unknown Source)
at
com.cloud.network.element.VirtualRouterElement.applyFWRules(VirtualRouterElement.java:260)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:577)
at
com.cloud.network.IpAddressManagerImpl.applyRules(IpAddressManagerImpl.java:504)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:532)
at
com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(FirewallManagerImpl.java:658)
at
com.cloud.network.firewall.FirewallManagerImpl.applyIngressFirewallRules(FirewallManagerImpl.java:630)
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 $Proxy195.applyIngressFirewallRules(Unknown Source)
at
[jira] [Resolved] (CLOUDSTACK-7615) [Automation] Firewall rules fails with ResourceUnavailableException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy resolved CLOUDSTACK-7615.
---
Resolution: Fixed
[Automation] Firewall rules fails with ResourceUnavailableException
---
Key: CLOUDSTACK-7615
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7615
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: Rayees Namathponnan
Assignee: Jayapal Reddy
Fix For: 4.5.0
Attachments: management-server.log.1
This Exception should be handled properly, seen this issue during automation
run, VR not available to apply, that need to be tracked
Here i am creating this ticket to imrove logggin
1, Ver: v1, Flags: 0,
[{com.cloud.agent.api.Answer:{result:false,details:,wait:0}}] }
2014-09-23 17:05:27,007 DEBUG [c.c.a.t.Request]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Seq
1-7258113749460975844: Received: { Ans: , MgmtI
d: 72809463712085, via: 1, Ver: v1, Flags: 0, { Answer } }
2014-09-23 17:05:27,007 WARN [c.c.n.f.FirewallManagerImpl]
(API-Job-Executor-107:ctx-76d385d5 job-214 ctx-f4bf84ec) Failed to apply
firewall rules due to
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Unable to apply firewall rules on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4050)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyFirewallRules(VirtualNetworkApplianceManagerImpl.java:3862)
at sun.reflect.GeneratedMethodAccessor323.invoke(Unknown Source)
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 $Proxy190.applyFirewallRules(Unknown Source)
at
com.cloud.network.element.VirtualRouterElement.applyFWRules(VirtualRouterElement.java:260)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:577)
at
com.cloud.network.IpAddressManagerImpl.applyRules(IpAddressManagerImpl.java:504)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:532)
at
com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(FirewallManagerImpl.java:658)
at
com.cloud.network.firewall.FirewallManagerImpl.applyIngressFirewallRules(FirewallManagerImpl.java:630)
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 $Proxy195.applyIngressFirewallRules(Unknown Source)
at
org.apache.cloudstack.api.command.user.firewall.CreatePortForwardingRuleCmd.execute(CreatePortForwardingRuleCmd.java:213)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
[jira] [Commented] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0.1 with Xenserver HV.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151708#comment-14151708 ] Rohit Yadav commented on CLOUDSTACK-7642: - CloudStack never had any 4.3.0.1 release, is this related to CCP then we won't be able to help. Also, what is the idea around using 4.5 systemvm template first and then upgrading to 4.5.0? [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0.1 with Xenserver HV. Key: CLOUDSTACK-7642 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7642 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.5.0 Environment: upgrade from 4.3.0.1 to 4.5 using Xen server 6.2 Reporter: manasaveloori Priority: Blocker Fix For: 4.5.0 Attachments: management-server.rar, mysqldump4.5.rar, mysqldumpBeforeUp.rar 1. Deployed 4.3.0.1 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0.1 build. 2. Registered the 4.5 template as systemvm-xenserver-4.5 3. Upgraded to 4.5 and started the MS. Observation: Observed the following exception in MS logs .Hosts went into disconnected stated. 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host 1(Rack1Pod1Host29) 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to find class com.cloud.hypervisor.xen.resource.XenServer620Resource java.lang.ClassNotFoundException: com.cloud.hypervisor.xen.resource.XenServer620Resource at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) at com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) at com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) at com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) at com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) at com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) at com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235) at org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) 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.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) 2014-09-29 13:45:26,852 WARN [c.c.a.m.AgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = Rack1Pod1Host29] Attaching the dumps and logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7635) CS 4.3.1 GUI Import certificate fails in Firefox 32.0.2.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151899#comment-14151899 ] Stephen Turner commented on CLOUDSTACK-7635: Thanks for the offer but I'm not sure there's much gain in doing it in my test environment, because it's working there. I really need a repro in an environment where it's not working. CS 4.3.1 GUI Import certificate fails in Firefox 32.0.2. Key: CLOUDSTACK-7635 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7635 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.1 Environment: CentOS 6.5 Reporter: France Assignee: Stephen Turner CS 4.3 GUI Import certificate fails in Firefox 32.0.2 on OSX with error message: Failed to update SSL Certificate. There is nothing in management or catalina log, regarding when this happens. However it works normally with latest Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7647) Public checkbox in Add compute offering tab is unchecked by default
Brian Federle created CLOUDSTACK-7647: - Summary: Public checkbox in Add compute offering tab is unchecked by default Key: CLOUDSTACK-7647 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7647 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Brian Federle In Service Offerings - Add compute offering, by default in Chrome the Public checkbox is unchecked, the option of choosing the domain only appears after 2 consecutive checks in the Public checkbox. In Firefox the Public checkbox has proper behavior. The issue must be fixed for Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7647) Public checkbox in Add compute offering tab is unchecked by default
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle reassigned CLOUDSTACK-7647: - Assignee: Brian Federle Public checkbox in Add compute offering tab is unchecked by default --- Key: CLOUDSTACK-7647 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7647 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Brian Federle Assignee: Brian Federle In Service Offerings - Add compute offering, by default in Chrome the Public checkbox is unchecked, the option of choosing the domain only appears after 2 consecutive checks in the Public checkbox. In Firefox the Public checkbox has proper behavior. The issue must be fixed for Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7647) Public checkbox in Add compute offering tab is unchecked by default
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14152171#comment-14152171 ] ASF subversion and git services commented on CLOUDSTACK-7647: - Commit ef4b5d41b7dd9ba16afd04c7716bada4a4721f79 in cloudstack's branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ef4b5d4 ] CLOUDSTACK-7647: Fix 'isReverse' checkboxes which are checked by default Public checkbox in Add compute offering tab is unchecked by default --- Key: CLOUDSTACK-7647 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7647 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Brian Federle Assignee: Brian Federle In Service Offerings - Add compute offering, by default in Chrome the Public checkbox is unchecked, the option of choosing the domain only appears after 2 consecutive checks in the Public checkbox. In Firefox the Public checkbox has proper behavior. The issue must be fixed for Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7647) Public checkbox in Add compute offering tab is unchecked by default
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-7647. --- Resolution: Fixed Public checkbox in Add compute offering tab is unchecked by default --- Key: CLOUDSTACK-7647 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7647 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Brian Federle Assignee: Brian Federle In Service Offerings - Add compute offering, by default in Chrome the Public checkbox is unchecked, the option of choosing the domain only appears after 2 consecutive checks in the Public checkbox. In Firefox the Public checkbox has proper behavior. The issue must be fixed for Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6430) [SDN] CS asks for vlan range even we create physical network with GRE isolation and uses those ranges as GRE keys in creating tunnels
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy updated CLOUDSTACK-6430:
-
Assignee: (was: Murali Reddy)
[SDN] CS asks for vlan range even we create physical network with GRE
isolation and uses those ranges as GRE keys in creating tunnels
-
Key: CLOUDSTACK-6430
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6430
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.4.0
Environment: Latest build from 4.4 with commit
80d82106dcc701e9569dde16161b24ff3abfa67f
Reporter: Sanjeev N
Priority: Critical
Fix For: Future
Attachments: management-server.log.2014-04-15.gz
[SDN] CS asks for vlan range even-though we create physical network with GRE
isolation and uses those ranges as GRE keys in creating tunnels
Steps to reproduce:
1.Install CS with latest build from 4.4
2.During zone creation choose GRE as the isolation method and proceed further
3.Zone creation wizard asks to specify vlan range so give some range there
4.Proceed to complete zone creation
5.Create an isolated network with stretched-l2 service.
6.Deploy guest vms in the network and make sure that vms in that network are
spanned across the hosts in the cluster
Observations:
===
When the vms are created on more than one host in the cluster CS programs GRE
ports on the ovsswitch on all the hypervisors on which the vms are running
and it uses the one of the vlan from the vlan range given during zone
creation.
Expected Result:
==
1.When physical network is created based on GRE isolation CS should not ask
for the vlan range
2.GRE key should be picked up randomly so that user does not have to provide
any range even for the GRE keys.
In my setup I had provided vlan range as 981-1000 and the following are the
GRE tunnels info from the hypervisor:
Bridge xapi3
fail_mode: standalone
Port t983-1-5
Interface t983-1-5
type: gre
options: {key=983, remote_ip=10.147.40.31}
Port vif5.0
Interface vif5.0
Port t983-1-4
Interface t983-1-4
type: gre
options: {key=983, remote_ip=10.147.40.14}
Port xapi3
Interface xapi3
type: internal
ovs_version: 1.4.6
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6762) [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not added in bridge flow table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6762: - Fix Version/s: (was: 4.4.0) Future [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not added in bridge flow table --- Key: CLOUDSTACK-6762 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6762 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit d130530bd3e1cd6d8249d5045e00e4e4e2201521 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Labels: ovs Fix For: Future Attachments: management-server.rar [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not added in bridge flow table Steps to reproduce: 1.Bring up CS in advanced zone with two hosts in xen cluster 2.Add physical network with isolation type GRE 3.Create an isolated network offering with connectivity service and OVS asc the provider 4.Create a user account and deploy one vm with above network offering and make sure that vm comes on host1 and VR comes on host2 5.Verify the flow table on the ovs bridge created for this network Result: == flow table rules to drop multicast and broacast traffic on tunnel ports are not added on the host where VR is running but the same rules are added on the host where vm is running VR is running on the following host: [root@Rack1Pod1Host14 ~]# ovs-ofctl dump-flows xapi3 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=988.459s, table=0, n_packets=5, n_bytes=810, priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2 cookie=0x0, duration=988.469s, table=0, n_packets=0, n_bytes=0, priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL cookie=0x0, duration=1011.44s, table=0, n_packets=20, n_bytes=2354, priority=0 actions=NORMAL cookie=0x0, duration=988.45s, table=0, n_packets=0, n_bytes=0, priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2 cookie=0x0, duration=988.479s, table=0, n_packets=0, n_bytes=0, priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL [root@Rack1Pod1Host14 ~]# VM is running on the following host: [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi3 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=456.937s, table=0, n_packets=0, n_bytes=0, priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2 cookie=0x0, duration=456.951s, table=0, n_packets=0, n_bytes=0, priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL cookie=0x0, duration=551.614s, table=0, n_packets=0, n_bytes=0, priority=1000,ip,in_port=1,nw_dst=224.0.0.0/24 actions=drop cookie=0x0, duration=551.932s, table=0, n_packets=15, n_bytes=1836, priority=0 actions=NORMAL cookie=0x0, duration=456.926s, table=0, n_packets=0, n_bytes=0, priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2 cookie=0x0, duration=551.624s, table=0, n_packets=0, n_bytes=0, priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=drop cookie=0x0, duration=456.962s, table=0, n_packets=9, n_bytes=2178, priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL On both the hosts port 1 is tunnel port and port 2 is vif. Following is the log snippet for xapi3 from host where VR is running: 2014-05-26 08:06:14DEBUG [root] About to manually create the bridge:xapi3 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', '--may-exist', 'add-br', 'xapi3', '--', 'set', 'bridge', 'xapi3', 'other_config:gre_key=OVSTunnel983'] 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi3', 'external_ids:xs-network-uuid=9d7ff1a3-342a-b206-ca09-7fbe8bcabfd0'] 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi3', 'stp_enable=true'] 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 'bridge', 'xapi3', 'other_config:gre_key'] 2014-05-26 08:06:14DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi3', '--minimal'] 2014-05-26 08:06:14DEBUG [root] Setup_ovs_bridge completed with result:SUCCESS:xapi3 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--timeout=30', 'wait-until', 'bridge', 'xapi3', '--', 'get', 'bridge', 'xapi3', 'name'] 2014-05-26 08:06:14DEBUG [root] bridge xapi3 for creating tunnel - VERIFIED 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'add-port',
[jira] [Updated] (CLOUDSTACK-6762) [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not added in bridge flow table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6762: - Assignee: (was: Murali Reddy) [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not added in bridge flow table --- Key: CLOUDSTACK-6762 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6762 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit d130530bd3e1cd6d8249d5045e00e4e4e2201521 Reporter: Sanjeev N Priority: Critical Labels: ovs Fix For: Future Attachments: management-server.rar [OVS]Flow rules to drop Broadcast/Multicast traffic on tunnel ports are not added in bridge flow table Steps to reproduce: 1.Bring up CS in advanced zone with two hosts in xen cluster 2.Add physical network with isolation type GRE 3.Create an isolated network offering with connectivity service and OVS asc the provider 4.Create a user account and deploy one vm with above network offering and make sure that vm comes on host1 and VR comes on host2 5.Verify the flow table on the ovs bridge created for this network Result: == flow table rules to drop multicast and broacast traffic on tunnel ports are not added on the host where VR is running but the same rules are added on the host where vm is running VR is running on the following host: [root@Rack1Pod1Host14 ~]# ovs-ofctl dump-flows xapi3 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=988.459s, table=0, n_packets=5, n_bytes=810, priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2 cookie=0x0, duration=988.469s, table=0, n_packets=0, n_bytes=0, priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL cookie=0x0, duration=1011.44s, table=0, n_packets=20, n_bytes=2354, priority=0 actions=NORMAL cookie=0x0, duration=988.45s, table=0, n_packets=0, n_bytes=0, priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2 cookie=0x0, duration=988.479s, table=0, n_packets=0, n_bytes=0, priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL [root@Rack1Pod1Host14 ~]# VM is running on the following host: [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi3 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=456.937s, table=0, n_packets=0, n_bytes=0, priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2 cookie=0x0, duration=456.951s, table=0, n_packets=0, n_bytes=0, priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL cookie=0x0, duration=551.614s, table=0, n_packets=0, n_bytes=0, priority=1000,ip,in_port=1,nw_dst=224.0.0.0/24 actions=drop cookie=0x0, duration=551.932s, table=0, n_packets=15, n_bytes=1836, priority=0 actions=NORMAL cookie=0x0, duration=456.926s, table=0, n_packets=0, n_bytes=0, priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2 cookie=0x0, duration=551.624s, table=0, n_packets=0, n_bytes=0, priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=drop cookie=0x0, duration=456.962s, table=0, n_packets=9, n_bytes=2178, priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL On both the hosts port 1 is tunnel port and port 2 is vif. Following is the log snippet for xapi3 from host where VR is running: 2014-05-26 08:06:14DEBUG [root] About to manually create the bridge:xapi3 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', '--may-exist', 'add-br', 'xapi3', '--', 'set', 'bridge', 'xapi3', 'other_config:gre_key=OVSTunnel983'] 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi3', 'external_ids:xs-network-uuid=9d7ff1a3-342a-b206-ca09-7fbe8bcabfd0'] 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi3', 'stp_enable=true'] 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 'bridge', 'xapi3', 'other_config:gre_key'] 2014-05-26 08:06:14DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi3', '--minimal'] 2014-05-26 08:06:14DEBUG [root] Setup_ovs_bridge completed with result:SUCCESS:xapi3 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--timeout=30', 'wait-until', 'bridge', 'xapi3', '--', 'get', 'bridge', 'xapi3', 'name'] 2014-05-26 08:06:14DEBUG [root] bridge xapi3 for creating tunnel - VERIFIED 2014-05-26 08:06:14DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'add-port', 'xapi3', 't983-4-1', '--', 'set', 'interface', 't983-4-1',
[jira] [Updated] (CLOUDSTACK-6796) [OVS]Failure in network update does not change network offering to original offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6796: - Assignee: (was: Murali Reddy) [OVS]Failure in network update does not change network offering to original offering Key: CLOUDSTACK-6796 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6796 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit d130530bd3e1cd6d8249d5045e00e4e4e2201521 Reporter: Sanjeev N Priority: Critical Labels: ovs Fix For: Future Attachments: management-server.rar [OVS]Failure in network update does not change network offering to original offering hence starting vms would fail in the network Steps to Reproduce: === 1.Bring up CS in advanced zone with xen cluster 2.Create physical network with GRE isolation 3.Create network with default offering DefaultIsolatedNetworkOfferingWithSourceNatService 4.Deploy few vms in the above netwrok 5.Create another network offering with virtual networking service and OVS as the connectivity service provider 6.Stop all the vms in the network 7.Update network with new offering created at step5 Results: == Network update will fail from vlan isolation to connectivity service due to bug CS-6795. However the network offering id for the network is changing to new network offering. It is not setting back to default isolated network offering. mysql select * from ntwk_offering_service_map where network_offering_id=15; ++-++---+-+ | id | network_offering_id | service| provider | created | ++-++---+-+ | 60 | 15 | Connectivity | Ovs | 2014-05-26 12:51:34 | | 55 | 15 | Dhcp | VirtualRouter | 2014-05-26 12:51:34 | | 54 | 15 | Dns| VirtualRouter | 2014-05-26 12:51:34 | | 61 | 15 | Firewall | VirtualRouter | 2014-05-26 12:51:34 | | 58 | 15 | Lb | VirtualRouter | 2014-05-26 12:51:34 | | 57 | 15 | PortForwarding | VirtualRouter | 2014-05-26 12:51:34 | | 56 | 15 | SourceNat | VirtualRouter | 2014-05-26 12:51:34 | | 59 | 15 | StaticNat | VirtualRouter | 2014-05-26 12:51:34 | | 53 | 15 | UserData | VirtualRouter | 2014-05-26 12:51:34 | ++-++---+-+ 9 rows in set (0.00 sec) Following is the network created with default isolated network offering but after network update failure the offering still shows the new offering: mysql select * from networks where id=211\G; *** 1. row *** id: 211 name: vlan1 uuid: f803e17f-b59b-4229-9e70-5bb4fcfc2570 display_text: vlan1 traffic_type: Guest broadcast_domain_type: Vlan broadcast_uri: vlan://986 gateway: 10.1.1.1 cidr: 10.1.1.0/24 mode: Dhcp network_offering_id: 15 physical_network_id: 200 data_center_id: 1 guru_name: ExternalGuestNetworkGuru state: Shutdown related: 211 domain_id: 1 account_id: 2 dns1: NULL dns2: NULL guru_data: NULL set_fields: 0 acl_type: Account network_domain: cs2cloud.internal reservation_id: c2b3cb64-adfd-4722-9aed-8d2d7710e32f guest_type: Isolated restart_required: 0 created: 2014-05-28 11:09:16 removed: NULL specify_ip_ranges: 0 vpc_id: NULL ip6_gateway: NULL ip6_cidr: NULL network_cidr: NULL display_network: 1 network_acl_id: NULL streched_l2: 0 1 row in set (0.00 sec) ERROR: No query specified Impact of this: === Since the network offering is with connectivity service , CS is failed to implement the network and vm start is failing. 2014-05-28 07:52:28,188 DEBUG [c.c.n.e.OvsElement] (Work-Job-Executor-47:ctx-3e2b5a9e job-122/job-123 ctx-ccbcca96) Checking if OvsElement can handle service SourceNat on network vlan1 2014-05-28 07:52:28,189 DEBUG
[jira] [Updated] (CLOUDSTACK-6796) [OVS]Failure in network update does not change network offering to original offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6796: - Fix Version/s: (was: 4.4.0) Future [OVS]Failure in network update does not change network offering to original offering Key: CLOUDSTACK-6796 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6796 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit d130530bd3e1cd6d8249d5045e00e4e4e2201521 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Labels: ovs Fix For: Future Attachments: management-server.rar [OVS]Failure in network update does not change network offering to original offering hence starting vms would fail in the network Steps to Reproduce: === 1.Bring up CS in advanced zone with xen cluster 2.Create physical network with GRE isolation 3.Create network with default offering DefaultIsolatedNetworkOfferingWithSourceNatService 4.Deploy few vms in the above netwrok 5.Create another network offering with virtual networking service and OVS as the connectivity service provider 6.Stop all the vms in the network 7.Update network with new offering created at step5 Results: == Network update will fail from vlan isolation to connectivity service due to bug CS-6795. However the network offering id for the network is changing to new network offering. It is not setting back to default isolated network offering. mysql select * from ntwk_offering_service_map where network_offering_id=15; ++-++---+-+ | id | network_offering_id | service| provider | created | ++-++---+-+ | 60 | 15 | Connectivity | Ovs | 2014-05-26 12:51:34 | | 55 | 15 | Dhcp | VirtualRouter | 2014-05-26 12:51:34 | | 54 | 15 | Dns| VirtualRouter | 2014-05-26 12:51:34 | | 61 | 15 | Firewall | VirtualRouter | 2014-05-26 12:51:34 | | 58 | 15 | Lb | VirtualRouter | 2014-05-26 12:51:34 | | 57 | 15 | PortForwarding | VirtualRouter | 2014-05-26 12:51:34 | | 56 | 15 | SourceNat | VirtualRouter | 2014-05-26 12:51:34 | | 59 | 15 | StaticNat | VirtualRouter | 2014-05-26 12:51:34 | | 53 | 15 | UserData | VirtualRouter | 2014-05-26 12:51:34 | ++-++---+-+ 9 rows in set (0.00 sec) Following is the network created with default isolated network offering but after network update failure the offering still shows the new offering: mysql select * from networks where id=211\G; *** 1. row *** id: 211 name: vlan1 uuid: f803e17f-b59b-4229-9e70-5bb4fcfc2570 display_text: vlan1 traffic_type: Guest broadcast_domain_type: Vlan broadcast_uri: vlan://986 gateway: 10.1.1.1 cidr: 10.1.1.0/24 mode: Dhcp network_offering_id: 15 physical_network_id: 200 data_center_id: 1 guru_name: ExternalGuestNetworkGuru state: Shutdown related: 211 domain_id: 1 account_id: 2 dns1: NULL dns2: NULL guru_data: NULL set_fields: 0 acl_type: Account network_domain: cs2cloud.internal reservation_id: c2b3cb64-adfd-4722-9aed-8d2d7710e32f guest_type: Isolated restart_required: 0 created: 2014-05-28 11:09:16 removed: NULL specify_ip_ranges: 0 vpc_id: NULL ip6_gateway: NULL ip6_cidr: NULL network_cidr: NULL display_network: 1 network_acl_id: NULL streched_l2: 0 1 row in set (0.00 sec) ERROR: No query specified Impact of this: === Since the network offering is with connectivity service , CS is failed to implement the network and vm start is failing. 2014-05-28 07:52:28,188 DEBUG [c.c.n.e.OvsElement] (Work-Job-Executor-47:ctx-3e2b5a9e job-122/job-123 ctx-ccbcca96) Checking if OvsElement can handle service
[jira] [Updated] (CLOUDSTACK-6828) [OVS] Tunnel ports are not getting deleted even failure in vm deployment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6828: - Fix Version/s: (was: 4.4.0) Future [OVS] Tunnel ports are not getting deleted even failure in vm deployment Key: CLOUDSTACK-6828 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6828 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Labels: ovs Fix For: Future Attachments: management-server.rar, ovstunnel-host13.log, ovstunnel-host14.log [OVS] Tunnel ports are not getting deleted even failure in vm deployment Steps to Reproduce: 1.Bringup CS in advanced zone with Xen cluster 2.Create physical network with GRE isolation 3.Create network offering with virtual networking and ovs as the connectivity service provider. 4.Deploy vm with above offering and simulate vm failure (In my case I was trying with multiple physical networks scenario and because of some configuration issues network implement failed so failure in vm deployment) Result: = During vm deployment ovs bridge and tunnel ports were created between the two hosts. But after the failure there was no clean up of the ovs-bridge and the tunnel ports. Observations: == xapi7 and xapi6 were the bridges created for the network. Following is the log snippet from ovstunnel log from both the hosts: [root@Rack1Pod1Host14 ~]# ovs-vsctl list-ports xapi7 t10016-4-1 [root@Rack1Pod1Host14 ~]# grep xapi7 /var/log/cloud/ovstunnel.log 2014-06-03 05:38:46DEBUG [root] About to manually create the bridge:xapi7 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', '--may-exist', 'add-br', 'xapi7', '--', 'set', 'bridge', 'xapi7', 'other_config:gre_key=OVSTunnel10016'] 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi7', 'external_ids:xs-network-uuid=127de5bb-a423-2774-98b6-ce1827d261d7'] 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi7', 'stp_enable=true'] 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 'bridge', 'xapi7', 'other_config:gre_key'] 2014-06-03 05:38:46DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi7', '--minimal'] 2014-06-03 05:38:46DEBUG [root] Setup_ovs_bridge completed with result:SUCCESS:xapi7 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--timeout=30', 'wait-until', 'bridge', 'xapi7', '--', 'get', 'bridge', 'xapi7', 'name'] 2014-06-03 05:38:50DEBUG [root] bridge xapi7 for creating tunnel - VERIFIED 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'add-port', 'xapi7', 't10016-4-1', '--', 'set', 'interface', 't10016-4-1', 'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.13'] 2014-06-03 05:38:50DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi7', '--minimal'] 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 'add-flow', 'xapi7', 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,actions=drop'] 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 'add-flow', 'xapi7', 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,ip,nw_dst=224.0.0.0/24,actions=drop'] [root@Rack1Pod1Host13 ~]# ovs-vsctl list-ports xapi6 t10016-1-4 [root@Rack1Pod1Host13 ~]# grep xapi6 /var/log/cloud/ovstunnel.log 2014-06-03 05:38:56DEBUG [root] About to manually create the bridge:xapi6 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', '--may-exist', 'add-br', 'xapi6', '--', 'set', 'bridge', 'xapi6', 'other_config:gre_key=OVSTunnel10016'] 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi6', 'external_ids:xs-network-uuid=ae6fe450-3399-7dad-b972-aa45755c2803'] 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi6', 'stp_enable=true'] 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 'bridge', 'xapi6', 'other_config:gre_key'] 2014-06-03 05:38:56DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi6', '--minimal'] 2014-06-03 05:38:56DEBUG [root] Setup_ovs_bridge completed with result:SUCCESS:xapi6 2014-06-03
[jira] [Updated] (CLOUDSTACK-6828) [OVS] Tunnel ports are not getting deleted even failure in vm deployment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6828: - Assignee: (was: Murali Reddy) [OVS] Tunnel ports are not getting deleted even failure in vm deployment Key: CLOUDSTACK-6828 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6828 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Priority: Critical Labels: ovs Fix For: Future Attachments: management-server.rar, ovstunnel-host13.log, ovstunnel-host14.log [OVS] Tunnel ports are not getting deleted even failure in vm deployment Steps to Reproduce: 1.Bringup CS in advanced zone with Xen cluster 2.Create physical network with GRE isolation 3.Create network offering with virtual networking and ovs as the connectivity service provider. 4.Deploy vm with above offering and simulate vm failure (In my case I was trying with multiple physical networks scenario and because of some configuration issues network implement failed so failure in vm deployment) Result: = During vm deployment ovs bridge and tunnel ports were created between the two hosts. But after the failure there was no clean up of the ovs-bridge and the tunnel ports. Observations: == xapi7 and xapi6 were the bridges created for the network. Following is the log snippet from ovstunnel log from both the hosts: [root@Rack1Pod1Host14 ~]# ovs-vsctl list-ports xapi7 t10016-4-1 [root@Rack1Pod1Host14 ~]# grep xapi7 /var/log/cloud/ovstunnel.log 2014-06-03 05:38:46DEBUG [root] About to manually create the bridge:xapi7 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', '--may-exist', 'add-br', 'xapi7', '--', 'set', 'bridge', 'xapi7', 'other_config:gre_key=OVSTunnel10016'] 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi7', 'external_ids:xs-network-uuid=127de5bb-a423-2774-98b6-ce1827d261d7'] 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi7', 'stp_enable=true'] 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 'bridge', 'xapi7', 'other_config:gre_key'] 2014-06-03 05:38:46DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi7', '--minimal'] 2014-06-03 05:38:46DEBUG [root] Setup_ovs_bridge completed with result:SUCCESS:xapi7 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--timeout=30', 'wait-until', 'bridge', 'xapi7', '--', 'get', 'bridge', 'xapi7', 'name'] 2014-06-03 05:38:50DEBUG [root] bridge xapi7 for creating tunnel - VERIFIED 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'add-port', 'xapi7', 't10016-4-1', '--', 'set', 'interface', 't10016-4-1', 'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.13'] 2014-06-03 05:38:50DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi7', '--minimal'] 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 'add-flow', 'xapi7', 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,actions=drop'] 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 'add-flow', 'xapi7', 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,ip,nw_dst=224.0.0.0/24,actions=drop'] [root@Rack1Pod1Host13 ~]# ovs-vsctl list-ports xapi6 t10016-1-4 [root@Rack1Pod1Host13 ~]# grep xapi6 /var/log/cloud/ovstunnel.log 2014-06-03 05:38:56DEBUG [root] About to manually create the bridge:xapi6 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', '--may-exist', 'add-br', 'xapi6', '--', 'set', 'bridge', 'xapi6', 'other_config:gre_key=OVSTunnel10016'] 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi6', 'external_ids:xs-network-uuid=ae6fe450-3399-7dad-b972-aa45755c2803'] 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 'Bridge', 'xapi6', 'stp_enable=true'] 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 'bridge', 'xapi6', 'other_config:gre_key'] 2014-06-03 05:38:56DEBUG [root] Executing:['/opt/xensource/bin/xe', 'network-list', 'bridge=xapi6', '--minimal'] 2014-06-03 05:38:56DEBUG [root] Setup_ovs_bridge completed with result:SUCCESS:xapi6 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl',
[jira] [Updated] (CLOUDSTACK-6841) [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6841: - Fix Version/s: (was: 4.4.0) Future [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks Key: CLOUDSTACK-6841 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6841 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Labels: ovs Fix For: Future Attachments: cloud-44.dmp, management-server.rar, ovstunnel-host13.log, ovstunnel-host14.log [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks Steps to reproduce: == 1.Bring up CS in advanced zone with xen cluster with min of two hosts and two nics on both the hosts 2.Create two physical networks with GRE isolation during zone creation: in physical network1 add guest,publicmanagement traffic types with tag tag1 in physical network2 add only guest traffic with tag tag2 3.create two network offerings NO1NO2 with virtual networking and ovs as the connectivity service provider and user taggings tag1 tag2 in NO1 NO2 respectively 4.Create isolated networks nw1 nw2 using NO1 NO2 5.Deploy vms in both the netwoks and make sure that both the networks are spread across both the hosts in the cluster 6.Verify tunnel ports remote_ips on both the hosts On xenservers used NIC0 for physical network1(by using traffic labels) and NIC1 for physical network2 NIC0NIC1 both have routable IP addresses. Result: = Remote_ips for all the tunnel ports created in the above networks are set to NIC1 ip addresses. But tunnel ports in network created on physical network1 should have NIC0 ip address as remote_ip and NIC1 ip address for the tunnel ports in other network. mysql select * from ovs_tunnel_interface; ++--+---+---+-++ | id | ip | netmask | mac | host_id | label | ++--+---+---+-++ | 1 | 0| 0 | 0 | 0 | lock | | 2 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab | 1 | management | | 3 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d | 2 | management | | 4 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab | 1 | gre | | 5 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d | 2 | gre | ++--+---+---+-++ 5 rows in set (0.00 sec) Here management label is on NIC0 and gre is on NIC1 and 10.147.42.1310.147.42.14 are assigned to NIC1 on the hosts. But in the above table we are using same ip address against bot the labels. So tunnel ports for both the networks are created with same remote_ip address. Host details are as follows: mysql select id,name,private_ip_address,public_ip_address,data_center_id,cluster_id from host where id in (1,2); ++-++---+++ | id | name| private_ip_address | public_ip_address | data_center_id | cluster_id | ++-++---+++ | 1 | Rack1Pod1Host13 | 10.147.40.13 | 10.147.40.13 | 1 | 1 | | 2 | Rack1Pod1Host14 | 10.147.40.14 | 10.147.40.14 | 1 | 1 | ++-++---+++ 2 rows in set (0.00 sec) 10.147.40.13 10.147.40.14 ip addresses are management addresses assigned to NIC0 on both the hosts. Tunnel ports details on the hosts are: system@xapi16: lookups: hit:11752 missed:3227 lost:0 flows: 4 port 0: xapi16 (internal) port 1: t4018-2-1 (gre: key=4018, remote_ip=10.147.42.13) port 2: vif26.0 system@xapi15: lookups: hit:4359 missed:167 lost:0 flows: 0 port 0: xapi15 (internal) port 1: t992-2-1 (gre: key=992, remote_ip=10.147.42.13) port 2: vif25.0 Attaching MS log file, cloud DB and ovstunnel log files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6841) [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6841: - Assignee: (was: Murali Reddy) [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks Key: CLOUDSTACK-6841 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6841 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Priority: Critical Labels: ovs Fix For: Future Attachments: cloud-44.dmp, management-server.rar, ovstunnel-host13.log, ovstunnel-host14.log [OVS] Remote_ips for tunnel ports are not configured properly in case of multipel physical networks Steps to reproduce: == 1.Bring up CS in advanced zone with xen cluster with min of two hosts and two nics on both the hosts 2.Create two physical networks with GRE isolation during zone creation: in physical network1 add guest,publicmanagement traffic types with tag tag1 in physical network2 add only guest traffic with tag tag2 3.create two network offerings NO1NO2 with virtual networking and ovs as the connectivity service provider and user taggings tag1 tag2 in NO1 NO2 respectively 4.Create isolated networks nw1 nw2 using NO1 NO2 5.Deploy vms in both the netwoks and make sure that both the networks are spread across both the hosts in the cluster 6.Verify tunnel ports remote_ips on both the hosts On xenservers used NIC0 for physical network1(by using traffic labels) and NIC1 for physical network2 NIC0NIC1 both have routable IP addresses. Result: = Remote_ips for all the tunnel ports created in the above networks are set to NIC1 ip addresses. But tunnel ports in network created on physical network1 should have NIC0 ip address as remote_ip and NIC1 ip address for the tunnel ports in other network. mysql select * from ovs_tunnel_interface; ++--+---+---+-++ | id | ip | netmask | mac | host_id | label | ++--+---+---+-++ | 1 | 0| 0 | 0 | 0 | lock | | 2 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab | 1 | management | | 3 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d | 2 | management | | 4 | 10.147.42.13 | 255.255.255.0 | 78:2b:cb:74:c4:ab | 1 | gre | | 5 | 10.147.42.14 | 255.255.255.0 | d4:ae:52:7a:a5:9d | 2 | gre | ++--+---+---+-++ 5 rows in set (0.00 sec) Here management label is on NIC0 and gre is on NIC1 and 10.147.42.1310.147.42.14 are assigned to NIC1 on the hosts. But in the above table we are using same ip address against bot the labels. So tunnel ports for both the networks are created with same remote_ip address. Host details are as follows: mysql select id,name,private_ip_address,public_ip_address,data_center_id,cluster_id from host where id in (1,2); ++-++---+++ | id | name| private_ip_address | public_ip_address | data_center_id | cluster_id | ++-++---+++ | 1 | Rack1Pod1Host13 | 10.147.40.13 | 10.147.40.13 | 1 | 1 | | 2 | Rack1Pod1Host14 | 10.147.40.14 | 10.147.40.14 | 1 | 1 | ++-++---+++ 2 rows in set (0.00 sec) 10.147.40.13 10.147.40.14 ip addresses are management addresses assigned to NIC0 on both the hosts. Tunnel ports details on the hosts are: system@xapi16: lookups: hit:11752 missed:3227 lost:0 flows: 4 port 0: xapi16 (internal) port 1: t4018-2-1 (gre: key=4018, remote_ip=10.147.42.13) port 2: vif26.0 system@xapi15: lookups: hit:4359 missed:167 lost:0 flows: 0 port 0: xapi15 (internal) port 1: t992-2-1 (gre: key=992, remote_ip=10.147.42.13) port 2: vif25.0 Attaching MS log file, cloud DB and ovstunnel log files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-2418) [GSLB] NPE while removing the GSLB enabled Netscaler device
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy updated CLOUDSTACK-2418:
-
Fix Version/s: (was: 4.4.0)
Future
[GSLB] NPE while removing the GSLB enabled Netscaler device
---
Key: CLOUDSTACK-2418
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2418
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0
Environment: commit # 09af15035b9febe6f55e73a1389f950ab042564f
Reporter: venkata swamybabu budumuru
Assignee: Murali Reddy
Fix For: Future
Attachments: logs.tgz, logs.tgz
Steps to reproduce :
1. Have CloudStack with at least one advanced zone having at least one
physical network
2. add a Netscaler to the above physical network and enable it for GSLB
3. delete the above Netscaler
Observations:
(i) Delete happens successfully but in the logs it shows NPE
Here is the snippet from the mgmt server log
2013-05-09 13:33:45,798 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-10:null) Sending Disconnect to listener:
com.cloud.consoleproxy.ConsoleProxyListener
2013-05-09 13:33:45,799 DEBUG [cloud.host.Status] (AgentTaskPool-10:null)
Transition:[Resource state = Maintenance, Agent event = Remove, Host id = 20,
name = 200-NetscalerVPXLoadBalancer-10.147.44.5]
2013-05-09 13:33:45,803 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-145:job-289) Complete async job-289, jobStatus: 1, resultCode:
0, result: org.apache.cloudstack.api.response.SuccessResponse@6c6f4fe8
2013-05-09 13:33:45,805 ERROR [agent.manager.AgentManagerImpl]
(AgentTaskPool-10:null) Exception caught while handling disconnect:
java.lang.NullPointerException
at com.cloud.host.dao.HostDaoImpl.updateState(HostDaoImpl.java:786)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at com.cloud.host.dao.HostDaoImpl.updateState(HostDaoImpl.java:67)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:111)
at
com.cloud.agent.manager.AgentManagerImpl.agentStatusTransitTo(AgentManagerImpl.java:1432)
at
com.cloud.agent.manager.AgentManagerImpl.disconnectAgent(AgentManagerImpl.java:1451)
at
com.cloud.agent.manager.AgentManagerImpl.handleDisconnectWithoutInvestigation(AgentManagerImpl.java:882)
at
com.cloud.agent.manager.ClusteredAgentManagerImpl.handleDisconnect(ClusteredAgentManagerImpl.java:291)
at
com.cloud.agent.manager.ClusteredAgentManagerImpl.handleDisconnectWithoutInvestigation(ClusteredAgentManagerImpl.java:280)
at
com.cloud.agent.manager.AgentManagerImpl$DisconnectTask.run(AgentManagerImpl.java:983)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
2013-05-09 13:33:45,813 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-145:job-289) Done executing
com.cloud.api.commands.DeleteNetscalerLoadBalancerCmd for job-289
2013-05-09 13:33:48,772 DEBUG [cloud.api.ApiServlet]
(1394157230@qtp-1391263288-168:null) ===START=== 10.252.241.169 -- GET
command=queryAsyncJobResultjobId=ee8f7cb4-81b5-482c-a86c-7fd0fc7a494aresponse=jsonsessionkey=pugR8azkFvoNOD%2FvU%2B0iwMN%2FMYc%3D_=1368101085616
2013-05-09 13:33:48,791 DEBUG [cloud.async.AsyncJobManagerImpl]
(1394157230@qtp-1391263288-168:null) Async job-289 completed
2013-05-09 13:33:48,799 DEBUG [cloud.api.ApiServlet]
(1394157230@qtp-1391263288-168:null) ===END=== 10.252.241.169 -- GET
command=queryAsyncJobResultjobId=ee8f7cb4-81b5-482c-a86c-7fd0fc7a494aresponse=jsonsessionkey=pugR8azkFvoNOD%2FvU%2B0iwMN%2FMYc%3D_=1368101085616
2013-05-09 13:33:49,520 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-104:null) Seq 5-814088194: Executing request
2013-05-09 13:33:49,530 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-104:null) Seq 5-814088194: Response Received:
2013-05-09 13:33:49,531 DEBUG [agent.transport.Request]
(DirectAgent-104:null) Seq 5-814088194: Processing: { Ans: , MgmtId:
7280707764394, via: 5,
[jira] [Updated] (CLOUDSTACK-2418) [GSLB] NPE while removing the GSLB enabled Netscaler device
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy updated CLOUDSTACK-2418:
-
Assignee: (was: Murali Reddy)
[GSLB] NPE while removing the GSLB enabled Netscaler device
---
Key: CLOUDSTACK-2418
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2418
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0
Environment: commit # 09af15035b9febe6f55e73a1389f950ab042564f
Reporter: venkata swamybabu budumuru
Fix For: Future
Attachments: logs.tgz, logs.tgz
Steps to reproduce :
1. Have CloudStack with at least one advanced zone having at least one
physical network
2. add a Netscaler to the above physical network and enable it for GSLB
3. delete the above Netscaler
Observations:
(i) Delete happens successfully but in the logs it shows NPE
Here is the snippet from the mgmt server log
2013-05-09 13:33:45,798 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-10:null) Sending Disconnect to listener:
com.cloud.consoleproxy.ConsoleProxyListener
2013-05-09 13:33:45,799 DEBUG [cloud.host.Status] (AgentTaskPool-10:null)
Transition:[Resource state = Maintenance, Agent event = Remove, Host id = 20,
name = 200-NetscalerVPXLoadBalancer-10.147.44.5]
2013-05-09 13:33:45,803 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-145:job-289) Complete async job-289, jobStatus: 1, resultCode:
0, result: org.apache.cloudstack.api.response.SuccessResponse@6c6f4fe8
2013-05-09 13:33:45,805 ERROR [agent.manager.AgentManagerImpl]
(AgentTaskPool-10:null) Exception caught while handling disconnect:
java.lang.NullPointerException
at com.cloud.host.dao.HostDaoImpl.updateState(HostDaoImpl.java:786)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at com.cloud.host.dao.HostDaoImpl.updateState(HostDaoImpl.java:67)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:111)
at
com.cloud.agent.manager.AgentManagerImpl.agentStatusTransitTo(AgentManagerImpl.java:1432)
at
com.cloud.agent.manager.AgentManagerImpl.disconnectAgent(AgentManagerImpl.java:1451)
at
com.cloud.agent.manager.AgentManagerImpl.handleDisconnectWithoutInvestigation(AgentManagerImpl.java:882)
at
com.cloud.agent.manager.ClusteredAgentManagerImpl.handleDisconnect(ClusteredAgentManagerImpl.java:291)
at
com.cloud.agent.manager.ClusteredAgentManagerImpl.handleDisconnectWithoutInvestigation(ClusteredAgentManagerImpl.java:280)
at
com.cloud.agent.manager.AgentManagerImpl$DisconnectTask.run(AgentManagerImpl.java:983)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
2013-05-09 13:33:45,813 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-145:job-289) Done executing
com.cloud.api.commands.DeleteNetscalerLoadBalancerCmd for job-289
2013-05-09 13:33:48,772 DEBUG [cloud.api.ApiServlet]
(1394157230@qtp-1391263288-168:null) ===START=== 10.252.241.169 -- GET
command=queryAsyncJobResultjobId=ee8f7cb4-81b5-482c-a86c-7fd0fc7a494aresponse=jsonsessionkey=pugR8azkFvoNOD%2FvU%2B0iwMN%2FMYc%3D_=1368101085616
2013-05-09 13:33:48,791 DEBUG [cloud.async.AsyncJobManagerImpl]
(1394157230@qtp-1391263288-168:null) Async job-289 completed
2013-05-09 13:33:48,799 DEBUG [cloud.api.ApiServlet]
(1394157230@qtp-1391263288-168:null) ===END=== 10.252.241.169 -- GET
command=queryAsyncJobResultjobId=ee8f7cb4-81b5-482c-a86c-7fd0fc7a494aresponse=jsonsessionkey=pugR8azkFvoNOD%2FvU%2B0iwMN%2FMYc%3D_=1368101085616
2013-05-09 13:33:49,520 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-104:null) Seq 5-814088194: Executing request
2013-05-09 13:33:49,530 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-104:null) Seq 5-814088194: Response Received:
2013-05-09 13:33:49,531 DEBUG [agent.transport.Request]
(DirectAgent-104:null) Seq 5-814088194: Processing: { Ans: , MgmtId:
7280707764394, via: 5, Ver: v1, Flags: 10,
[jira] [Updated] (CLOUDSTACK-3973) [GSLB] [LOGS Message] Improving logs messages for GSLB rule configuration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-3973: - Fix Version/s: (was: 4.4.0) Future [GSLB] [LOGS Message] Improving logs messages for GSLB rule configuration - Key: CLOUDSTACK-3973 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3973 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit # 6275d697e340be5b520f37b15d72343fa47c00a9 Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Fix For: Future Attachments: logs.tgz Steps to reproduce: 1. Have latest cloudstack with at least 2 advanced zones where each zone is configure with GSLB provider. 2. Create LB rule in each zone using VR (LB rule 1 in zone1 and LB rule 2 in zone2) 3. As a non-ROOT domain user, create a GSLB rule and map LBrule1. Observations: (i) This will create GSLB site, vserver, service in zone1 netscaler 4. now map LBRule2 to the above GSLB rule. (ii) This will create GSLB site2 on netscaler devices in both the zones. During this process, this will end up in configuring site1, vserver, service in Zone1 NS device again and throws log message like below. This is little confusing and gives an impression that something went wrong. it would be good to change these message to be little more informative. 2013-07-31 14:28:23,869 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-93:null) Seq 9-712310787: Executing request 2013-07-31 14:28:23,973 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Failed to add GSLB virtual server: cloud-gslb-vserver-GSLB1.xyztelco.com due to Resource already exists 2013-07-31 14:28:24,085 WARN [network.resource.NetscalerResource] (DirectAgent-93:null) Retrying GlobalLoadBalancerConfigCommand. Number of retries remaining: 1 2013-07-31 14:28:24,158 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully added GSLB virtual server: cloud-gslb-vserver-GSLB1.xyztelco.com 2013-07-31 14:28:24,258 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully updated GSLB site: cloudsite1 2013-07-31 14:28:24,356 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully created service: cloud-gslb-service-cloudsite1-10.147.44.64-22 at site: cloudsite1 2013-07-31 14:28:24,474 WARN [network.resource.NetscalerResource] (DirectAgent-93:null) Failed to bind monitor to GSLB service due to The monitor is already bound to the service 2013-07-31 14:28:24,562 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully created GSLB site: cloudsite2 2013-07-31 14:28:24,692 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully created service: cloud-gslb-service-cloudsite2-10.147.54.63-22 at site: cloudsite2 2013-07-31 14:28:24,730 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully created service: cloud-gslb-service-cloudsite2-10.147.54.63-22 and virtual server: cloud-gslb-vserver-GSLB1.xyztelco.com binding -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3973) [GSLB] [LOGS Message] Improving logs messages for GSLB rule configuration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-3973: - Assignee: (was: Murali Reddy) [GSLB] [LOGS Message] Improving logs messages for GSLB rule configuration - Key: CLOUDSTACK-3973 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3973 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit # 6275d697e340be5b520f37b15d72343fa47c00a9 Reporter: venkata swamybabu budumuru Fix For: Future Attachments: logs.tgz Steps to reproduce: 1. Have latest cloudstack with at least 2 advanced zones where each zone is configure with GSLB provider. 2. Create LB rule in each zone using VR (LB rule 1 in zone1 and LB rule 2 in zone2) 3. As a non-ROOT domain user, create a GSLB rule and map LBrule1. Observations: (i) This will create GSLB site, vserver, service in zone1 netscaler 4. now map LBRule2 to the above GSLB rule. (ii) This will create GSLB site2 on netscaler devices in both the zones. During this process, this will end up in configuring site1, vserver, service in Zone1 NS device again and throws log message like below. This is little confusing and gives an impression that something went wrong. it would be good to change these message to be little more informative. 2013-07-31 14:28:23,869 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-93:null) Seq 9-712310787: Executing request 2013-07-31 14:28:23,973 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Failed to add GSLB virtual server: cloud-gslb-vserver-GSLB1.xyztelco.com due to Resource already exists 2013-07-31 14:28:24,085 WARN [network.resource.NetscalerResource] (DirectAgent-93:null) Retrying GlobalLoadBalancerConfigCommand. Number of retries remaining: 1 2013-07-31 14:28:24,158 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully added GSLB virtual server: cloud-gslb-vserver-GSLB1.xyztelco.com 2013-07-31 14:28:24,258 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully updated GSLB site: cloudsite1 2013-07-31 14:28:24,356 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully created service: cloud-gslb-service-cloudsite1-10.147.44.64-22 at site: cloudsite1 2013-07-31 14:28:24,474 WARN [network.resource.NetscalerResource] (DirectAgent-93:null) Failed to bind monitor to GSLB service due to The monitor is already bound to the service 2013-07-31 14:28:24,562 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully created GSLB site: cloudsite2 2013-07-31 14:28:24,692 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully created service: cloud-gslb-service-cloudsite2-10.147.54.63-22 at site: cloudsite2 2013-07-31 14:28:24,730 DEBUG [network.resource.NetscalerResource] (DirectAgent-93:null) Successfully created service: cloud-gslb-service-cloudsite2-10.147.54.63-22 and virtual server: cloud-gslb-vserver-GSLB1.xyztelco.com binding -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-2993) [PortableIPRange] remove some of the unused columns if they are not required from portable_ip_address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-2993: - Assignee: (was: Murali Reddy) [PortableIPRange] remove some of the unused columns if they are not required from portable_ip_address - Key: CLOUDSTACK-2993 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2993 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit # 971c40d98e07ab6cddb8e6db5095c1acea935815 Reporter: venkata swamybabu budumuru Priority: Minor Fix For: Future Attachments: logs.tgz Steps to reproduce: 1. Have the latest CS setup with at least 1 advanced zone 2. add a portable ip range 3. check the db for portable_ip_address table. Observations : (i) Found that the following fields in the table are not used any of my tests. (ii) If they are not used then please remove them. Here are the fields: data_center_id | physical_network_id | network_id | vpc_id Attaching all the required logs along with db dump to the bug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6719) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6719: - Assignee: (was: Murali Reddy) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC Key: CLOUDSTACK-6719 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6719 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.4.0 Reporter: sadhu suresh Fix For: 4.5.0 problem:OVS:VPC:UI: Add new tier wizard allowing to add non OVS enabled network to VPC created with OVS+distributed VPC VR Steps to Reprodude: 1.Bring up CS in advanced zon 2.create a vpc offering with OVS and along with other all supported services 3. create a VPC with above network offering 4.try to create non ovs network(i.e network created default isolated vpc offering) on ovs based VPC. actual result: allowing to add non OVS enabled network to OVS enabled VPC expected result: it should not allow to add non OVS enabled network to OVS enabled VPC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7171) not getting console of user vm via virsh on kvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-7171. -- Resolution: Cannot Reproduce console is working fine now. not getting console of user vm via virsh on kvm --- Key: CLOUDSTACK-7171 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7171 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Environment: KMV host on centos6.2 advance zone Reporter: shweta agarwal Assignee: Murali Reddy Priority: Minor Fix For: 4.5.0 Attachments: MSlog.tar.gz, kvmhostlog.tar.gz Repro steps: Create a KVM(centos6.2) advance zone setup . Once everything is uop created a user vm with default centos 5.5 template On KVM host try to access console of this user vm via vrish Bug : Nothing happens I even tried registering ubuntu template and created a ubuntu VM still not able to access console via virsh for ubuntu VM as well But able to access console via virsh for system vms , CPVM, SSVM, router vm Attaching MS logs and kvm logs for the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6719) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6719: - Fix Version/s: (was: 4.4.0) 4.5.0 OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC Key: CLOUDSTACK-6719 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6719 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.4.0 Reporter: sadhu suresh Assignee: Murali Reddy Fix For: 4.5.0 problem:OVS:VPC:UI: Add new tier wizard allowing to add non OVS enabled network to VPC created with OVS+distributed VPC VR Steps to Reprodude: 1.Bring up CS in advanced zon 2.create a vpc offering with OVS and along with other all supported services 3. create a VPC with above network offering 4.try to create non ovs network(i.e network created default isolated vpc offering) on ovs based VPC. actual result: allowing to add non OVS enabled network to OVS enabled VPC expected result: it should not allow to add non OVS enabled network to OVS enabled VPC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6705) [SDN] VNI range is not allowing more than 2147483647 as a maximum vnet range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6705: - Fix Version/s: (was: 4.4.0) 4.5.0 [SDN] VNI range is not allowing more than 2147483647 as a maximum vnet range Key: CLOUDSTACK-6705 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6705 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 branch with commit e6961fd21bb6d793302c234d0f409f66dc498072 Reporter: Sanjeev N Assignee: Murali Reddy Fix For: 4.5.0 [SDN] VNI range is not allowing more than 2147483647 as a maximum vnet range 1.Bring up CS in advanced zone 2.Create physical network with GRE isolation 3.In guest network creation give vnet/vni range as 1-4294967295 Result: == Failed to add above vnet range. 2014-05-19 10:37:40,383 WARN [c.c.n.NetworkServiceImpl] (API-Job-Executor-27:job-31 ctx-ff496cfb) Unable to parse vnet range: java.lang.NumberFormatException: For input string: 4294967100 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:495) at java.lang.Integer.parseInt(Integer.java:527) at com.cloud.network.NetworkServiceImpl.validateVlanRange(NetworkServiceImpl.java:2749) at com.cloud.network.NetworkServiceImpl.addOrRemoveVnets(NetworkServiceImpl.java:2640) at com.cloud.network.NetworkServiceImpl.updatePhysicalNetwork(NetworkServiceImpl.java:2622) 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.$Proxy154.updatePhysicalNetwork(Unknown Source) at org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd.execute(UpdatePhysicalNetworkCmd.java:99) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:119) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496) 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:453) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) 2014-05-19 10:37:40,394 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-27:job-31) Unexpected exception while executing
[jira] [Resolved] (CLOUDSTACK-6426) Event Bus no longer receives events for AsyncJobs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy resolved CLOUDSTACK-6426.
--
Resolution: Cannot Reproduce
Async job events are getting published on the event bus in latest master (4.5).
Event Bus no longer receives events for AsyncJobs
-
Key: CLOUDSTACK-6426
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6426
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
Reporter: David Grizzanti
Assignee: Murali Reddy
It appears that as of 4.3, the async job manager no longer publishes messages
to the event bus for async jobs. Prior to 4.3, messages for
starting/completing AsyncJob were published to the Event Bus.
Example:
Event {:source=management-server, :type=AsyncJobEvent,
:action=submit, :resource_type=None, :resource_id=*}
{instanceType=None, jobId=e52fe236-9109-49f2-96e9-02cc1bebf3f8,
processStatus=0, commandEventType=NIC.CREATE, resultCode=0,
command=org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd,
account=b32dc958-b904-11e3-b3f0-080027079e3d,
user=b32e02b0-b904-11e3-b3f0-080027079e3d}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6705) [SDN] VNI range is not allowing more than 2147483647 as a maximum vnet range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6705: - Assignee: (was: Murali Reddy) [SDN] VNI range is not allowing more than 2147483647 as a maximum vnet range Key: CLOUDSTACK-6705 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6705 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 branch with commit e6961fd21bb6d793302c234d0f409f66dc498072 Reporter: Sanjeev N Fix For: Future [SDN] VNI range is not allowing more than 2147483647 as a maximum vnet range 1.Bring up CS in advanced zone 2.Create physical network with GRE isolation 3.In guest network creation give vnet/vni range as 1-4294967295 Result: == Failed to add above vnet range. 2014-05-19 10:37:40,383 WARN [c.c.n.NetworkServiceImpl] (API-Job-Executor-27:job-31 ctx-ff496cfb) Unable to parse vnet range: java.lang.NumberFormatException: For input string: 4294967100 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:495) at java.lang.Integer.parseInt(Integer.java:527) at com.cloud.network.NetworkServiceImpl.validateVlanRange(NetworkServiceImpl.java:2749) at com.cloud.network.NetworkServiceImpl.addOrRemoveVnets(NetworkServiceImpl.java:2640) at com.cloud.network.NetworkServiceImpl.updatePhysicalNetwork(NetworkServiceImpl.java:2622) 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.$Proxy154.updatePhysicalNetwork(Unknown Source) at org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd.execute(UpdatePhysicalNetworkCmd.java:99) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:119) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496) 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:453) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) 2014-05-19 10:37:40,394 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-27:job-31) Unexpected exception while executing org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd
[jira] [Updated] (CLOUDSTACK-6705) [SDN] VNI range is not allowing more than 2147483647 as a maximum vnet range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-6705: - Fix Version/s: (was: 4.5.0) Future [SDN] VNI range is not allowing more than 2147483647 as a maximum vnet range Key: CLOUDSTACK-6705 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6705 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 branch with commit e6961fd21bb6d793302c234d0f409f66dc498072 Reporter: Sanjeev N Fix For: Future [SDN] VNI range is not allowing more than 2147483647 as a maximum vnet range 1.Bring up CS in advanced zone 2.Create physical network with GRE isolation 3.In guest network creation give vnet/vni range as 1-4294967295 Result: == Failed to add above vnet range. 2014-05-19 10:37:40,383 WARN [c.c.n.NetworkServiceImpl] (API-Job-Executor-27:job-31 ctx-ff496cfb) Unable to parse vnet range: java.lang.NumberFormatException: For input string: 4294967100 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:495) at java.lang.Integer.parseInt(Integer.java:527) at com.cloud.network.NetworkServiceImpl.validateVlanRange(NetworkServiceImpl.java:2749) at com.cloud.network.NetworkServiceImpl.addOrRemoveVnets(NetworkServiceImpl.java:2640) at com.cloud.network.NetworkServiceImpl.updatePhysicalNetwork(NetworkServiceImpl.java:2622) 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.$Proxy154.updatePhysicalNetwork(Unknown Source) at org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd.execute(UpdatePhysicalNetworkCmd.java:99) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:119) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496) 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:453) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) 2014-05-19 10:37:40,394 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-27:job-31) Unexpected exception while executing
[jira] [Updated] (CLOUDSTACK-6420) Network implement: use network stateMachine instead of explicitly setting the state on network object
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy updated CLOUDSTACK-6420:
-
Assignee: (was: Murali Reddy)
Network implement: use network stateMachine instead of explicitly setting the
state on network object
-
Key: CLOUDSTACK-6420
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6420
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.4.0
Reporter: Alena Prokharchyk
Fix For: Future
In NetworkOrchestrator, implementNetwork code, some places use state machine
when update the network's state, some just update the network directly. Have
to eliminate the latest, and use state machine everywhere.
if (isSharedNetworkWithServices(network)) {
network.setState(Network.State.Implementing);
} else {
stateTransitTo(network, Event.ImplementNetwork);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6827) Can't enable VR service provider in case of multiple physical networks
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy updated CLOUDSTACK-6827:
-
Assignee: (was: Murali Reddy)
Can't enable VR service provider in case of multiple physical networks
--
Key: CLOUDSTACK-6827
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6827
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server, Network Controller
Affects Versions: 4.4.0
Environment: Latest build from 4.4 with commit
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Priority: Critical
Fix For: 4.4.0
Attachments: management-server.rar
Can't enable VR service provider in case of multiple physical networks
Steps to reproduce:
==
1.Bring up CS in advanced zone with xen cluster
2.Once the system is up disable the zone and add another physical network and
add only guest traffic into it.
3.Go to network service providers in the physical network
4.All the providers are disabled by default. Try to enable Virtual Router
http://10.147.59.119:8096/client/api?command=updateNetworkServiceProviderid=beb30cda-7e3a-44e9-b179-c1c6fd605b47state=Enabled
Result:
=
Enabling VR service provider failed and observed following exception:
2014-06-03 06:13:54,846 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(ApiServer-8:ctx-8602d969 ctx-e30c2238) submit async job-82, details:
AsyncJobVO {id:82, userId: 1, accountId: 1, instanceType:
PhysicalNetworkServiceProvider, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
cmdInfo:
{id:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxDetails:{\PhysicalNetworkServiceProvider\:\beb30cda-7e3a-44e9-b179-c1c6fd605b47\,\com.cloud.network.PhysicalNetworkServiceProvider\:6},cmdEventType:SERVICE.PROVIDER.UPDATE,ctxUserId:1,state:Enabled,httpmethod:GET,uuid:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxAccountId:1,ctxStartEventId:218},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-03 06:13:54,853 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-45:ctx-4f22f44a job-82) Add job-82 into job monitoring
2014-06-03 06:13:54,853 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-45:ctx-4f22f44a job-82) Executing AsyncJobVO {id:82,
userId: 1, accountId: 1, instanceType: PhysicalNetworkServiceProvider,
instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
cmdInfo:
{id:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxDetails:{\PhysicalNetworkServiceProvider\:\beb30cda-7e3a-44e9-b179-c1c6fd605b47\,\com.cloud.network.PhysicalNetworkServiceProvider\:6},cmdEventType:SERVICE.PROVIDER.UPDATE,ctxUserId:1,state:Enabled,httpmethod:GET,uuid:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxAccountId:1,ctxStartEventId:218},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-03 06:13:54,860 WARN [c.c.a.d.ParamGenericValidationWorker]
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) Received unknown
parameters for command updateNetworkServiceProvider. Unknown parameters :
ctxdetails
2014-06-03 06:13:54,871 DEBUG [c.c.n.NetworkServiceImpl]
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) trying to update the
state of the service provider id=6 on physical network: 201 to state: Enabled
2014-06-03 06:13:54,878 DEBUG [c.c.s.StatsCollector]
(StatsCollector-2:ctx-e6a2a82e) HostStatsCollector is running...
2014-06-03 06:13:54,885 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-45:ctx-4f22f44a job-82) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd
com.cloud.utils.exception.CloudRuntimeException: Provider is not ready,
cannot Enable the provider, please configure the provider first
at
com.cloud.network.NetworkServiceImpl.updateNetworkServiceProvider(NetworkServiceImpl.java:3425)
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
[jira] [Updated] (CLOUDSTACK-2293) [BasicZone-XenServer] DeletePhysicalNetworkCmd is not deleting the external devices
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-2293: - Fix Version/s: (was: 4.4.0) Future [BasicZone-XenServer] DeletePhysicalNetworkCmd is not deleting the external devices --- Key: CLOUDSTACK-2293 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2293 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit 0e2ffe72aa641f4551cae63fbc36454c5934342f Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Fix For: Future Attachments: logs.tgz Steps to reproduce : 1. Have at least one basic zone created with Xen Cluster using EIP/ELB Offering with NetScaler mysql select * from network_offerings where id=15\G *** 1. row *** id: 15 name: EIPOffering uuid: 6207d909-c780-4661-8a61-7e397aad7b77 unique_name: EIPOffering display_text: EIPOffering nw_rate: NULL mc_rate: 10 traffic_type: Guest tags: NULL system_only: 0 specify_vlan: 1 service_offering_id: NULL conserve_mode: 0 created: 2013-04-24 17:23:07 removed: NULL default: 0 availability: Optional dedicated_lb_service: 0 shared_source_nat_service: 0 sort_key: 0 redundant_router_service: 0 state: Enabled guest_type: Shared elastic_ip_service: 1 eip_associate_public_ip: 0 elastic_lb_service: 1 specify_ip_ranges: 1 inline: 0 is_persistent: 0 2. Deleted all the physical network that exists in the basic zone but, it didn't cleanup the NetScaler info associated with Physical network.Can see the netscaler info in the cloud.host_details table. 3. Due to the above reason, deleteZone is failing saying there are servers running in this zone. 2013-04-30 10:30:50,205 DEBUG [cloud.api.ApiServlet] (1098099294@qtp-293858992-68:null) ===START=== 10.252.248.175 -- GET command=deleteZoneid=f0d20b77-3aec-4a0d-a154-9f1324c31956response=jsonsessionkey=CnR%2Bbnhyla1mzycOIXluse0E5o4%3D_=1367312502554 2013-04-30 10:30:50,277 ERROR [cloud.api.ApiServer] (1098099294@qtp-293858992-68:null) unhandled exception executing api command: deleteZone com.cloud.utils.exception.CloudRuntimeException: The zone is not deletable because there are servers running in this zone at com.cloud.configuration.ConfigurationManagerImpl.checkIfZoneIsDeletable(ConfigurationManagerImpl.java:1128) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.configuration.ConfigurationManagerImpl.deleteZone(ConfigurationManagerImpl.java:1262) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.admin.zone.DeleteZoneCmd.execute(DeleteZoneCmd.java:73) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:512) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:362) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
[jira] [Updated] (CLOUDSTACK-4016) [PortableIP] [VPC] listPublicIpAddresses lists the portable IP that was already transferred to a different ISOLATED network.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy updated CLOUDSTACK-4016:
-
Fix Version/s: (was: 4.4.0)
Future
[PortableIP] [VPC] listPublicIpAddresses lists the portable IP that was
already transferred to a different ISOLATED network.
Key: CLOUDSTACK-4016
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4016
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.2.0
Environment: commit id # 9cd4e089a5798f422961940efbf8ae33ed906b87
Reporter: venkata swamybabu budumuru
Assignee: Murali Reddy
Fix For: Future
Attachments: logs.tgz
Steps to reproduce:
1. Have latest CloudStack with at least 1 advanced zone
2. Have at least 1 ISOLATED NETWORK and one VPC Tier. Each with at least 1 VM
deployed.
3. Acquired portable IP and associate to VPC Tier
4. Enable staticNAT on the above portable IP that maps to the ISOLATED
NETWORK and to the VM deployed in isolated network.
5. Go to Network- VPC (Tier1) - list public ip address
Observations:
(i) The above fired the following AP with VPC id and it showed the above
portable IP which was transferred to ISOLATED Network.
_ 1375374504585
command listPublicIpAddresses
listAll true
page 1
pagesize 20
response json
sessionkeyh6Mx8XmDIxmLHaEr3fH7026LeBY=
vpcid a9b586fa-1ea2-4ba5-ac83-4c4dec7d30d5
{ listpublicipaddressesresponse : { count:3 ,publicipaddress : [
{id:dde1818b-1125-465c-b9f3-2ea07bd28d6e,ipaddress:10.147.48.102,allocated:2013-08-01T21:37:13+0530,zoneid:73435150-0b47-4753-8d1f-7b27e125f02c,zonename:zone1,issourcenat:false,account:dom1Acc1,domainid:0b000776-40b4-41e0-b27f-2f5d3be2b021,domain:dom1,forvirtualnetwork:true,isstaticnat:true,issystem:false,virtualmachineid:ee706467-909c-4f62-a0c4-9b087ae89a89,vmipaddress:10.0.0.155,virtualmachinename:VM1VPC1Zone1,virtualmachinedisplayname:VM1VPC1Zone1,associatednetworkid:535d7756-1ba8-4691-ad8e-b2e70e3836b9,associatednetworkname:Network1,networkid:6620535c-62f8-4c94-a270-83dcbc563540,state:Allocated,physicalnetworkid:ca52283b-9dbc-4499-b4bc-ddeed8254e03,vpcid:a9b586fa-1ea2-4ba5-ac83-4c4dec7d30d5,tags:[],isportable:true},
{id:2e0447dc-1d48-474c-bced-60210436916f,ipaddress:10.147.48.100,allocated:2013-08-01T21:32:22+0530,zoneid:73435150-0b47-4753-8d1f-7b27e125f02c,zonename:zone1,issourcenat:false,account:dom1Acc1,domainid:0b000776-40b4-41e0-b27f-2f5d3be2b021,domain:dom1,forvirtualnetwork:true,isstaticnat:true,issystem:false,virtualmachineid:4cc88676-55ad-4d75-b2b5-027389213704,vmipaddress:10.1.1.223,virtualmachinename:VM1Zone1,virtualmachinedisplayname:VM1Zone1,associatednetworkid:e4c03081-1abc-4ef4-9dcd-77f72ced9846,associatednetworkname:IsolatedNet1,networkid:6620535c-62f8-4c94-a270-83dcbc563540,state:Allocated,physicalnetworkid:ca52283b-9dbc-4499-b4bc-ddeed8254e03,vpcid:a9b586fa-1ea2-4ba5-ac83-4c4dec7d30d5,tags:[],isportable:true},
{id:d2090e7b-2322-41d6-b123-d4cb5e57a3dd,ipaddress:10.147.44.64,allocated:2013-08-01T20:50:22+0530,zoneid:73435150-0b47-4753-8d1f-7b27e125f02c,zonename:zone1,issourcenat:true,account:dom1Acc1,domainid:0b000776-40b4-41e0-b27f-2f5d3be2b021,domain:dom1,forvirtualnetwork:true,isstaticnat:false,issystem:false,networkid:6620535c-62f8-4c94-a270-83dcbc563540,state:Allocated,physicalnetworkid:ca52283b-9dbc-4499-b4bc-ddeed8254e03,vpcid:a9b586fa-1ea2-4ba5-ac83-4c4dec7d30d5,tags:[],isportable:false}
] } }
(ii) Found the cloud.user_ip_address table for the above portable IP still
showing the VPC id. Here is the snippet.
mysql select * from user_ip_address where id=24\G
*** 1. row ***
id: 24
uuid: 2e0447dc-1d48-474c-bced-60210436916f
account_id: 3
domain_id: 2
public_ip_address: 10.147.48.100
data_center_id: 1
source_nat: 0
allocated: 2013-08-01 16:02:22
vlan_db_id: 12
one_to_one_nat: 1
vm_id: 5
state: Allocated
mac_address: 0
source_network_id: 200
network_id: 208
physical_network_id: 200
is_system: 0
vpc_id: 2
dnat_vmip: 10.1.1.223
is_portable: 1
1 row in set (0.00 sec)
Attaching all the required logs along with db dump to the bug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-4016) [PortableIP] [VPC] listPublicIpAddresses lists the portable IP that was already transferred to a different ISOLATED network.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy updated CLOUDSTACK-4016:
-
Assignee: (was: Murali Reddy)
[PortableIP] [VPC] listPublicIpAddresses lists the portable IP that was
already transferred to a different ISOLATED network.
Key: CLOUDSTACK-4016
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4016
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.2.0
Environment: commit id # 9cd4e089a5798f422961940efbf8ae33ed906b87
Reporter: venkata swamybabu budumuru
Fix For: Future
Attachments: logs.tgz
Steps to reproduce:
1. Have latest CloudStack with at least 1 advanced zone
2. Have at least 1 ISOLATED NETWORK and one VPC Tier. Each with at least 1 VM
deployed.
3. Acquired portable IP and associate to VPC Tier
4. Enable staticNAT on the above portable IP that maps to the ISOLATED
NETWORK and to the VM deployed in isolated network.
5. Go to Network- VPC (Tier1) - list public ip address
Observations:
(i) The above fired the following AP with VPC id and it showed the above
portable IP which was transferred to ISOLATED Network.
_ 1375374504585
command listPublicIpAddresses
listAll true
page 1
pagesize 20
response json
sessionkeyh6Mx8XmDIxmLHaEr3fH7026LeBY=
vpcid a9b586fa-1ea2-4ba5-ac83-4c4dec7d30d5
{ listpublicipaddressesresponse : { count:3 ,publicipaddress : [
{id:dde1818b-1125-465c-b9f3-2ea07bd28d6e,ipaddress:10.147.48.102,allocated:2013-08-01T21:37:13+0530,zoneid:73435150-0b47-4753-8d1f-7b27e125f02c,zonename:zone1,issourcenat:false,account:dom1Acc1,domainid:0b000776-40b4-41e0-b27f-2f5d3be2b021,domain:dom1,forvirtualnetwork:true,isstaticnat:true,issystem:false,virtualmachineid:ee706467-909c-4f62-a0c4-9b087ae89a89,vmipaddress:10.0.0.155,virtualmachinename:VM1VPC1Zone1,virtualmachinedisplayname:VM1VPC1Zone1,associatednetworkid:535d7756-1ba8-4691-ad8e-b2e70e3836b9,associatednetworkname:Network1,networkid:6620535c-62f8-4c94-a270-83dcbc563540,state:Allocated,physicalnetworkid:ca52283b-9dbc-4499-b4bc-ddeed8254e03,vpcid:a9b586fa-1ea2-4ba5-ac83-4c4dec7d30d5,tags:[],isportable:true},
{id:2e0447dc-1d48-474c-bced-60210436916f,ipaddress:10.147.48.100,allocated:2013-08-01T21:32:22+0530,zoneid:73435150-0b47-4753-8d1f-7b27e125f02c,zonename:zone1,issourcenat:false,account:dom1Acc1,domainid:0b000776-40b4-41e0-b27f-2f5d3be2b021,domain:dom1,forvirtualnetwork:true,isstaticnat:true,issystem:false,virtualmachineid:4cc88676-55ad-4d75-b2b5-027389213704,vmipaddress:10.1.1.223,virtualmachinename:VM1Zone1,virtualmachinedisplayname:VM1Zone1,associatednetworkid:e4c03081-1abc-4ef4-9dcd-77f72ced9846,associatednetworkname:IsolatedNet1,networkid:6620535c-62f8-4c94-a270-83dcbc563540,state:Allocated,physicalnetworkid:ca52283b-9dbc-4499-b4bc-ddeed8254e03,vpcid:a9b586fa-1ea2-4ba5-ac83-4c4dec7d30d5,tags:[],isportable:true},
{id:d2090e7b-2322-41d6-b123-d4cb5e57a3dd,ipaddress:10.147.44.64,allocated:2013-08-01T20:50:22+0530,zoneid:73435150-0b47-4753-8d1f-7b27e125f02c,zonename:zone1,issourcenat:true,account:dom1Acc1,domainid:0b000776-40b4-41e0-b27f-2f5d3be2b021,domain:dom1,forvirtualnetwork:true,isstaticnat:false,issystem:false,networkid:6620535c-62f8-4c94-a270-83dcbc563540,state:Allocated,physicalnetworkid:ca52283b-9dbc-4499-b4bc-ddeed8254e03,vpcid:a9b586fa-1ea2-4ba5-ac83-4c4dec7d30d5,tags:[],isportable:false}
] } }
(ii) Found the cloud.user_ip_address table for the above portable IP still
showing the VPC id. Here is the snippet.
mysql select * from user_ip_address where id=24\G
*** 1. row ***
id: 24
uuid: 2e0447dc-1d48-474c-bced-60210436916f
account_id: 3
domain_id: 2
public_ip_address: 10.147.48.100
data_center_id: 1
source_nat: 0
allocated: 2013-08-01 16:02:22
vlan_db_id: 12
one_to_one_nat: 1
vm_id: 5
state: Allocated
mac_address: 0
source_network_id: 200
network_id: 208
physical_network_id: 200
is_system: 0
vpc_id: 2
dnat_vmip: 10.1.1.223
is_portable: 1
1 row in set (0.00 sec)
Attaching all the required logs along with db dump to the bug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-2293) [BasicZone-XenServer] DeletePhysicalNetworkCmd is not deleting the external devices
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-2293: - Assignee: (was: Murali Reddy) [BasicZone-XenServer] DeletePhysicalNetworkCmd is not deleting the external devices --- Key: CLOUDSTACK-2293 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2293 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit 0e2ffe72aa641f4551cae63fbc36454c5934342f Reporter: venkata swamybabu budumuru Fix For: Future Attachments: logs.tgz Steps to reproduce : 1. Have at least one basic zone created with Xen Cluster using EIP/ELB Offering with NetScaler mysql select * from network_offerings where id=15\G *** 1. row *** id: 15 name: EIPOffering uuid: 6207d909-c780-4661-8a61-7e397aad7b77 unique_name: EIPOffering display_text: EIPOffering nw_rate: NULL mc_rate: 10 traffic_type: Guest tags: NULL system_only: 0 specify_vlan: 1 service_offering_id: NULL conserve_mode: 0 created: 2013-04-24 17:23:07 removed: NULL default: 0 availability: Optional dedicated_lb_service: 0 shared_source_nat_service: 0 sort_key: 0 redundant_router_service: 0 state: Enabled guest_type: Shared elastic_ip_service: 1 eip_associate_public_ip: 0 elastic_lb_service: 1 specify_ip_ranges: 1 inline: 0 is_persistent: 0 2. Deleted all the physical network that exists in the basic zone but, it didn't cleanup the NetScaler info associated with Physical network.Can see the netscaler info in the cloud.host_details table. 3. Due to the above reason, deleteZone is failing saying there are servers running in this zone. 2013-04-30 10:30:50,205 DEBUG [cloud.api.ApiServlet] (1098099294@qtp-293858992-68:null) ===START=== 10.252.248.175 -- GET command=deleteZoneid=f0d20b77-3aec-4a0d-a154-9f1324c31956response=jsonsessionkey=CnR%2Bbnhyla1mzycOIXluse0E5o4%3D_=1367312502554 2013-04-30 10:30:50,277 ERROR [cloud.api.ApiServer] (1098099294@qtp-293858992-68:null) unhandled exception executing api command: deleteZone com.cloud.utils.exception.CloudRuntimeException: The zone is not deletable because there are servers running in this zone at com.cloud.configuration.ConfigurationManagerImpl.checkIfZoneIsDeletable(ConfigurationManagerImpl.java:1128) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.configuration.ConfigurationManagerImpl.deleteZone(ConfigurationManagerImpl.java:1262) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.admin.zone.DeleteZoneCmd.execute(DeleteZoneCmd.java:73) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:512) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:362) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326)
[jira] [Updated] (CLOUDSTACK-3813) Service.provider.create event doesnt mention about the Service Provider in the event's description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-3813: - Fix Version/s: (was: 4.4.0) Future Service.provider.create event doesnt mention about the Service Provider in the event's description Key: CLOUDSTACK-3813 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3813 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: Chandan Purushothama Assignee: Murali Reddy Fix For: Future mysql select id,type,state,description,user_id,account_id,domain_id,created,level,start_id,parameters,archived from event where type like SERVICE.PROVIDER.CREATE; ++-+-+---+-++---+-+---+--++--+ | id | type| state | description | user_id | account_id | domain_id | created | level | start_id | parameters | archived | ++-+-+---+-++---+-+---+--++--+ | 8 | SERVICE.PROVIDER.CREATE | Created | Successfully created entity for Creating Physical Network ServiceProvider | 2 | 1 | 1 | 2013-07-24 20:48:39 | INFO |0 | NULL |0 | | 9 | SERVICE.PROVIDER.CREATE | Created | Successfully created entity for Creating Physical Network ServiceProvider | 2 | 1 | 1 | 2013-07-24 20:48:39 | INFO |0 | NULL |0 | | 10 | SERVICE.PROVIDER.CREATE | Created | Successfully created entity for Creating Physical Network ServiceProvider | 2 | 1 | 1 | 2013-07-24 20:48:39 | INFO |0 | NULL |0 | | 11 | SERVICE.PROVIDER.CREATE | Created | Successfully created entity for Creating Physical Network ServiceProvider | 2 | 1 | 1 | 2013-07-24 20:48:39 | INFO |0 | NULL |0 | ++-+-+---+-++---+-+---+--++--+ 4 rows in set (0.04 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-2345) [GSLB] deleting GSLB rules is not cleaning server info from GSLB device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-2345: - Fix Version/s: (was: 4.4.0) Future [GSLB] deleting GSLB rules is not cleaning server info from GSLB device --- Key: CLOUDSTACK-2345 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2345 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit # 09af15035b9febe6f55e73a1389f950ab042564f Reporter: venkata swamybabu budumuru Assignee: Murali Reddy Priority: Minor Fix For: Future Attachments: logs.tgz Steps to reproduce: 1. create CloudStack setup with at least 2 zones 2. create a GSLBRule with at least 2 LB rules 3. Delete all the above created rules and issue show server on GSLB device Observations :- (i) Found that server list is not cleaned up on the Netscaler devices Here is the snippet from Netscaler: show server 1) Name: 10.147.44.21 State:ENABLED IPAddress:10.147.44.21 2) Name: 10.147.54.14 State:ENABLED IPAddress:10.147.54.14 3) Name: Cloud-Server--10.147.44.61 State:ENABLED IPAddress:10.147.44.61 4) Name: Cloud-Server--10.147.54.161 State:ENABLED IPAddress: 10.147.54.161 Done Attaching all the required logs to the bug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3813) Service.provider.create event doesnt mention about the Service Provider in the event's description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-3813: - Assignee: (was: Murali Reddy) Service.provider.create event doesnt mention about the Service Provider in the event's description Key: CLOUDSTACK-3813 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3813 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: Chandan Purushothama Fix For: Future mysql select id,type,state,description,user_id,account_id,domain_id,created,level,start_id,parameters,archived from event where type like SERVICE.PROVIDER.CREATE; ++-+-+---+-++---+-+---+--++--+ | id | type| state | description | user_id | account_id | domain_id | created | level | start_id | parameters | archived | ++-+-+---+-++---+-+---+--++--+ | 8 | SERVICE.PROVIDER.CREATE | Created | Successfully created entity for Creating Physical Network ServiceProvider | 2 | 1 | 1 | 2013-07-24 20:48:39 | INFO |0 | NULL |0 | | 9 | SERVICE.PROVIDER.CREATE | Created | Successfully created entity for Creating Physical Network ServiceProvider | 2 | 1 | 1 | 2013-07-24 20:48:39 | INFO |0 | NULL |0 | | 10 | SERVICE.PROVIDER.CREATE | Created | Successfully created entity for Creating Physical Network ServiceProvider | 2 | 1 | 1 | 2013-07-24 20:48:39 | INFO |0 | NULL |0 | | 11 | SERVICE.PROVIDER.CREATE | Created | Successfully created entity for Creating Physical Network ServiceProvider | 2 | 1 | 1 | 2013-07-24 20:48:39 | INFO |0 | NULL |0 | ++-+-+---+-++---+-+---+--++--+ 4 rows in set (0.04 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-2345) [GSLB] deleting GSLB rules is not cleaning server info from GSLB device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-2345: - Assignee: (was: Murali Reddy) [GSLB] deleting GSLB rules is not cleaning server info from GSLB device --- Key: CLOUDSTACK-2345 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2345 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit # 09af15035b9febe6f55e73a1389f950ab042564f Reporter: venkata swamybabu budumuru Priority: Minor Fix For: Future Attachments: logs.tgz Steps to reproduce: 1. create CloudStack setup with at least 2 zones 2. create a GSLBRule with at least 2 LB rules 3. Delete all the above created rules and issue show server on GSLB device Observations :- (i) Found that server list is not cleaned up on the Netscaler devices Here is the snippet from Netscaler: show server 1) Name: 10.147.44.21 State:ENABLED IPAddress:10.147.44.21 2) Name: 10.147.54.14 State:ENABLED IPAddress:10.147.54.14 3) Name: Cloud-Server--10.147.44.61 State:ENABLED IPAddress:10.147.44.61 4) Name: Cloud-Server--10.147.54.161 State:ENABLED IPAddress: 10.147.54.161 Done Attaching all the required logs to the bug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6827) Can't enable VR service provider in case of multiple physical networks
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-6827:
---
Assignee: Sheng Yang
Can't enable VR service provider in case of multiple physical networks
--
Key: CLOUDSTACK-6827
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6827
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server, Network Controller
Affects Versions: 4.4.0
Environment: Latest build from 4.4 with commit
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Sheng Yang
Priority: Critical
Fix For: 4.4.0
Attachments: management-server.rar
Can't enable VR service provider in case of multiple physical networks
Steps to reproduce:
==
1.Bring up CS in advanced zone with xen cluster
2.Once the system is up disable the zone and add another physical network and
add only guest traffic into it.
3.Go to network service providers in the physical network
4.All the providers are disabled by default. Try to enable Virtual Router
http://10.147.59.119:8096/client/api?command=updateNetworkServiceProviderid=beb30cda-7e3a-44e9-b179-c1c6fd605b47state=Enabled
Result:
=
Enabling VR service provider failed and observed following exception:
2014-06-03 06:13:54,846 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(ApiServer-8:ctx-8602d969 ctx-e30c2238) submit async job-82, details:
AsyncJobVO {id:82, userId: 1, accountId: 1, instanceType:
PhysicalNetworkServiceProvider, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
cmdInfo:
{id:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxDetails:{\PhysicalNetworkServiceProvider\:\beb30cda-7e3a-44e9-b179-c1c6fd605b47\,\com.cloud.network.PhysicalNetworkServiceProvider\:6},cmdEventType:SERVICE.PROVIDER.UPDATE,ctxUserId:1,state:Enabled,httpmethod:GET,uuid:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxAccountId:1,ctxStartEventId:218},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-03 06:13:54,853 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-45:ctx-4f22f44a job-82) Add job-82 into job monitoring
2014-06-03 06:13:54,853 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-45:ctx-4f22f44a job-82) Executing AsyncJobVO {id:82,
userId: 1, accountId: 1, instanceType: PhysicalNetworkServiceProvider,
instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
cmdInfo:
{id:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxDetails:{\PhysicalNetworkServiceProvider\:\beb30cda-7e3a-44e9-b179-c1c6fd605b47\,\com.cloud.network.PhysicalNetworkServiceProvider\:6},cmdEventType:SERVICE.PROVIDER.UPDATE,ctxUserId:1,state:Enabled,httpmethod:GET,uuid:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxAccountId:1,ctxStartEventId:218},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-03 06:13:54,860 WARN [c.c.a.d.ParamGenericValidationWorker]
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) Received unknown
parameters for command updateNetworkServiceProvider. Unknown parameters :
ctxdetails
2014-06-03 06:13:54,871 DEBUG [c.c.n.NetworkServiceImpl]
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) trying to update the
state of the service provider id=6 on physical network: 201 to state: Enabled
2014-06-03 06:13:54,878 DEBUG [c.c.s.StatsCollector]
(StatsCollector-2:ctx-e6a2a82e) HostStatsCollector is running...
2014-06-03 06:13:54,885 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-45:ctx-4f22f44a job-82) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd
com.cloud.utils.exception.CloudRuntimeException: Provider is not ready,
cannot Enable the provider, please configure the provider first
at
com.cloud.network.NetworkServiceImpl.updateNetworkServiceProvider(NetworkServiceImpl.java:3425)
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
[jira] [Updated] (CLOUDSTACK-7310) XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7310: --- Assignee: Devdeep Singh XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer - Key: CLOUDSTACK-7310 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes, XenServer Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Devdeep Singh Priority: Critical Fix For: 4.5.0 XenServer does not allowing shrinking of disks currently. Please add code on Cloudstack to prevent such an operation (similar to VMWare case). Failing to prevent such an operation on XenServer leads to https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0.1 with Xenserver HV.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-7642: - Description: 1. Deployed 4.3.0 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0 build. 2. Registered the 4.5 template as systemvm-xenserver-4.5 3. Upgraded to 4.5 and started the MS. Observation: Observed the following exception in MS logs .Hosts went into disconnected stated. 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host 1(Rack1Pod1Host29) 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to find class com.cloud.hypervisor.xen.resource.XenServer620Resource java.lang.ClassNotFoundException: com.cloud.hypervisor.xen.resource.XenServer620Resource at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) at com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) at com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) at com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) at com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) at com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) at com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235) at org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) 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.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) 2014-09-29 13:45:26,852 WARN [c.c.a.m.AgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = Rack1Pod1Host29] Attaching the dumps and logs. was: 1. Deployed 4.3.0.1 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0.1 build. 2. Registered the 4.5 template as systemvm-xenserver-4.5 3. Upgraded to 4.5 and started the MS. Observation: Observed the following exception in MS logs .Hosts went into disconnected stated. 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host 1(Rack1Pod1Host29) 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to find class com.cloud.hypervisor.xen.resource.XenServer620Resource java.lang.ClassNotFoundException: com.cloud.hypervisor.xen.resource.XenServer620Resource at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) at com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) at com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) at com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) at com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) at com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) at
[jira] [Updated] (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 ] Animesh Chaturvedi updated CLOUDSTACK-7501: --- Assignee: Kishan Kavala 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: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: Ms.tar.gz Repro steps: 1. Create a LXC advance zone setup with one LXC cluster 2. When system vms are up .add one more KVM cluster 3. Put LXC host to maintenance Bug: System VM is not coming up on KVM cluster Expected result: System VMs should come up on KVM cluster Ms log shows : Cluster: 2 has HyperVisorType that does not match the VM, skipping this cluster which should not be the case in case of SSVM and CPVM attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7556) [API]Non live Migration of root and data disk from cluster wide primary to zone wide and vice versa is not failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7556: --- Assignee: edison su [API]Non live Migration of root and data disk from cluster wide primary to zone wide and vice versa is not failing -- Key: CLOUDSTACK-7556 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7556 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Environment: 1zone,1pod,2 clusters with ESXi5.1 HV each Reporter: manasaveloori Assignee: edison su Priority: Critical Fix For: 4.5.0 1. Cluster C1 has primary PS1 and C2 -primary PS2.Also added one zone wide PS PSZW. 2. Deployed a VM with data disk under cluster1. 3. Stopped the VM. 4. Fired the API for migrating the root/data disk from PS1 to PSZW. Migration of root/data from cluster wide to zone wide and vice versa should fail as there is a scope change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7590:
---
Assignee: Prachi Damle
Deletion of Account is not deleting the account from the database
-
Key: CLOUDSTACK-7590
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7590
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: Chandan Purushothama
Assignee: Prachi Damle
Priority: Critical
Fix For: 4.5.0
Deletion of account marks the account as removed in the database but doesnt
remove the record from the database as shown below:
mysql select * from account where removed is not null \G
*** 1. row ***
id: 7
account_name: CSRegularVPNClientUser
uuid: 96e06a77-fa96-4e38-b380-023d406d445e
type: 0
domain_id: 1
state: enabled
removed: 2014-09-20 00:33:41
cleanup_needed: 0
network_domain: NULL
default_zone_id: NULL
default: 0
1 row in set (0.00 sec)
mysql
*If anyone wants to recreate the account with the same name. It fails with
the below exception:*
{noformat}
2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user:
CSRegularVPNClientUser, accountId: 6 timezone:null
2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the
transaction: Time = 16 Name = catalina-exec-11; called by
-TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) unhandled exception
executing api command: [Ljava.lang.String;@5b4cfa82
javax.persistence.EntityExistsException: Entity already exists:
at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
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
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
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 $Proxy67.persist(Unknown Source)
at
com.cloud.user.AccountManagerImpl.createUser(AccountManagerImpl.java:1962)
at
com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1039)
at
com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1027)
at
com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
at
com.cloud.user.AccountManagerImpl.createUserAccount(AccountManagerImpl.java:1027)
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
[jira] [Updated] (CLOUDSTACK-6101) Contrail:MS: Disable NAT on acquired IP results in exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-6101:
---
Assignee: Sachchidanand Vaidya
Contrail:MS: Disable NAT on acquired IP results in exception
Key: CLOUDSTACK-6101
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6101
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, Management Server
Affects Versions: 4.3.0
Environment: Contrail
Reporter: Parth Jagirdar
Assignee: Sachchidanand Vaidya
Fix For: 4.4.0
Disable NAT, rule gets removed but exception is thrown.
2014-02-13 13:53:08,389 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Revoking all Firewallrules as a
part of disabling static nat for public IP id=3
2014-02-13 13:53:08,400 DEBUG [c.c.n.f.FirewallManagerImpl]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Releasing 0 firewall rules for ip
id=3
2014-02-13 13:53:08,401 DEBUG [c.c.n.f.FirewallManagerImpl]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) There are no firewall rules to
apply
2014-02-13 13:53:08,402 DEBUG [c.c.n.f.FirewallManagerImpl]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Successfully released firewall
rules for ip id=3 and # of rules now = 0
2014-02-13 13:53:08,408 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Releasing 0 port forwarding rules
for ip id=3
2014-02-13 13:53:08,410 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Releasing 0 static nat rules for
ip id=3
2014-02-13 13:53:08,411 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) There are no port forwarding
rules to apply for ip id=3
2014-02-13 13:53:08,412 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) There are no static nat rules to
apply for ip id=3
2014-02-13 13:53:08,423 INFO [o.a.c.e.o.NetworkOrchestrator]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Let ContrailElement handle
StaticNat in network 206
2014-02-13 13:53:08,441 INFO [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Request: GET,
/virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2
2014-02-13 13:53:08,451 INFO [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Response Status: HTTP/1.1 200
OK
2014-02-13 13:53:08,455 INFO [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Request: PUT,
/virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2,
{virtual-network:{virtual_network_properties:{extend_to_external_routers:false,network_id:4},route_target_list:{route_target:[target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002]},network_ipam_refs:[{to:[default-domain,default-project,default-network-ipam],attr:{ipam_subnets:[{subnet:{ip_prefix:10.223.138.64,ip_prefix_len:26},default_gateway:10.223.138.65}]},href:null,uuid:null}],floating_ip_pools:[{to:[default-domain,default-project,__default_Public__,PublicIpPool],attr:null,href:http://10.223.58.3:8082/floating-ip-pool/8cf92e6e-b81a-44d6-9f6d-1472aaec7264,uuid:8cf92e6e-b81a-44d6-9f6d-1472aaec7264}],routing_instances:[{to:[default-domain,default-project,__default_Public__,__default_Public__],attr:null,href:http://10.223.58.3:8082/routing-instance/74769566-dfce-4b6d-bbb5-db772bccb2f9,uuid:74769566-dfce-4b6d-bbb5-db772bccb2f9}],name:__default_Public__,uuid:e6c067bc-bc63-4613-a7af-84d0182ff6d2,fq_name:[default-domain,default-project,__default_Public__],parent_type:project,parent_uuid:fafebf0e-5d9c-4c99-928d-25ab65bd7ebc}}
2014-02-13 13:53:08,492 INFO [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Response Status: HTTP/1.1 200
OK
2014-02-13 13:53:08,492 INFO [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Request: GET,
/virtual-machine-interface/07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19
2014-02-13 13:53:08,496 INFO [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Response Status: HTTP/1.1 404
Not Found
2014-02-13 13:53:08,496 INFO [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Request: POST,
/virtual-machine-interfaces,
{virtual-machine-interface:{virtual_machine_interface_mac_addresses:{mac_address:[06:e4:2a:00:00:35]},virtual_network_refs:[{to:[default-domain,default-project,__default_Public__],attr:null,href:null,uuid:null}],name:s-11-VM-2,uuid:07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19,fq_name:[s-11-VM,s-11-VM-2],parent_type:virtual-machine}}
2014-02-13 13:53:08,505 INFO [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Response
[jira] [Updated] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-7642: - Summary: [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV. (was: [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0.1 with Xenserver HV.) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV. -- Key: CLOUDSTACK-7642 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7642 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.5.0 Environment: upgrade from 4.3.0.1 to 4.5 using Xen server 6.2 Reporter: manasaveloori Priority: Blocker Fix For: 4.5.0 Attachments: management-server.rar, mysqldump4.5.rar, mysqldumpBeforeUp.rar 1. Deployed 4.3.0 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0 build. 2. Registered the 4.5 template as systemvm-xenserver-4.5 3. Upgraded to 4.5 and started the MS. Observation: Observed the following exception in MS logs .Hosts went into disconnected stated. 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host 1(Rack1Pod1Host29) 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to find class com.cloud.hypervisor.xen.resource.XenServer620Resource java.lang.ClassNotFoundException: com.cloud.hypervisor.xen.resource.XenServer620Resource at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) at com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) at com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) at com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) at com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) at com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) at com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235) at org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) 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.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) 2014-09-29 13:45:26,852 WARN [c.c.a.m.AgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = Rack1Pod1Host29] Attaching the dumps and logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-7642: - Environment: upgrade from 4.3.0 to 4.5 using Xen server 6.2 (was: upgrade from 4.3.0.1 to 4.5 using Xen server 6.2 ) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV. -- Key: CLOUDSTACK-7642 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7642 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.5.0 Environment: upgrade from 4.3.0 to 4.5 using Xen server 6.2 Reporter: manasaveloori Priority: Blocker Fix For: 4.5.0 Attachments: management-server.rar, mysqldump4.5.rar, mysqldumpBeforeUp.rar 1. Deployed 4.3.0 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0 build. 2. Registered the 4.5 template as systemvm-xenserver-4.5 3. Upgraded to 4.5 and started the MS. Observation: Observed the following exception in MS logs .Hosts went into disconnected stated. 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host 1(Rack1Pod1Host29) 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to find class com.cloud.hypervisor.xen.resource.XenServer620Resource java.lang.ClassNotFoundException: com.cloud.hypervisor.xen.resource.XenServer620Resource at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) at com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) at com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) at com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) at com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) at com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) at com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235) at org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) 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.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) 2014-09-29 13:45:26,852 WARN [c.c.a.m.AgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = Rack1Pod1Host29] Attaching the dumps and logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7642: --- Assignee: Devdeep Singh [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV. -- Key: CLOUDSTACK-7642 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7642 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.5.0 Environment: upgrade from 4.3.0 to 4.5 using Xen server 6.2 Reporter: manasaveloori Assignee: Devdeep Singh Priority: Blocker Fix For: 4.5.0 Attachments: management-server.rar, mysqldump4.5.rar, mysqldumpBeforeUp.rar 1. Deployed 4.3.0 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0 build. 2. Registered the 4.5 template as systemvm-xenserver-4.5 3. Upgraded to 4.5 and started the MS. Observation: Observed the following exception in MS logs .Hosts went into disconnected stated. 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host 1(Rack1Pod1Host29) 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to find class com.cloud.hypervisor.xen.resource.XenServer620Resource java.lang.ClassNotFoundException: com.cloud.hypervisor.xen.resource.XenServer620Resource at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) at com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) at com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) at com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) at com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) at com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) at com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235) at org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) 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.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) 2014-09-29 13:45:26,852 WARN [c.c.a.m.AgentManagerImpl] (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 1, name = Rack1Pod1Host29] Attaching the dumps and logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7421) [Automation] Exceptions in orchestrate* methods from virtualMachineManagerImpl are shown in log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7421:
---
Assignee: Koushik Das
[Automation] Exceptions in orchestrate* methods from
virtualMachineManagerImpl are shown in log
---
Key: CLOUDSTACK-7421
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7421
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: Koushik Das
Fix For: 4.5.0
Steps to reproduce
1 ) Deploy VM
2) Add one more nic
3) remove default nic the VM
Result
Below exception thrown in log, it should be handled with proper messgae
cloud.vm.VmWorkRemoveNicFromVm for VM 30, job origin: 248
2014-08-23 09:50:33,665 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-61:ctx-5c747fe0 job-248/job-249) Unable to complete
AsyncJobVO {id:249, userId: 2, accountId: 2, instanceType: null, instanceId:
null, cmd: com.cloud.vm.VmWorkRemoveNicFromVm, cmdInfo:
rO0ABXNyACJjb20uY2xvdWQudm0uVm1Xb3JrUmVtb3ZlTmljRnJvbVZtxM1Xh9nBu10CAAFMAAVuaWNJZHQAEExqYXZhL2xhbmcvTG9uZzt4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAB50ABlWaXJ0dWFsTWFjaGluZU1hbmFnZXJJbXBsc3IADmphdmEubGFuZy5Mb25nO4vkkMyPI98CAAFKAAV2YWx1ZXhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cABI,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 90928106758026, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Sat Aug 23 09:50:32 PDT 2014}, job origin:248
com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from
VM[User|i-18-30-TestVM] in Ntwk[222|Guest|17], nic is default.
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:2963)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:4690)
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.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
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)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7267) [LXC] message should be more meaningful in case of failure of template creation from root volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7267: --- Assignee: Kishan Kavala [LXC] message should be more meaningful in case of failure of template creation from root volume Key: CLOUDSTACK-7267 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7267 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: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: 1. Create a LXC VM 2. Stop VM 3. Create a template from root data disk 4. Template creation will fail with the message:Failed to create templateroot disk file /mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/d377b54e-d337-4e9c-9adb-5ed1ccc3b84a doesn't exist Bug: message shoulld be meaningful for failure .. may be not supported in LXC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7317) wrong message when trying to upgrade a running VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7317:
---
Assignee: Kishan Kavala
wrong message when trying to upgrade a running VM
-
Key: CLOUDSTACK-7317
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7317
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: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Repro steps:
1. Create a VM with small service offerings ( i did it on LXC hypervisor)
2. While VM is running change service offering
Bug:
We get message This operation not permitted for this hypervisor of the vm
Expected Result :
Message should be related to VM should be stopped while changing service
offerings
MS log shows :
2014-08-12 05:26:21,708 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-36:ctx-b9835d0e job-439) Executing AsyncJobVO {id:439,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin, cmdInfo:
{id:033042b7-0973-4e00-b4b8-d9f3af49c3ac,response:json,sessionkey:HEgqZRWcriIz5k+MxuauDaQK6Wc\u003d,serviceofferingid:b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c,ctxDetails:{\com.cloud.vm.VirtualMachine\:\033042b7-0973-4e00-b4b8-d9f3af49c3ac\,\com.cloud.offering.ServiceOffering\:\b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c\},cmdEventType:VM.UPGRADE,ctxUserId:2,httpmethod:GET,_:1407835578042,uuid:033042b7-0973-4e00-b4b8-d9f3af49c3ac,ctxAccountId:2,ctxStartEventId:278},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-08-12 05:26:21,709 DEBUG [c.c.a.ApiServlet]
(catalina-exec-11:ctx-ee357ccc ctx-490ac18f) ===END=== 10.146.0.131 -- GET
command=scaleVirtualMachineresponse=jsonsessionkey=HEgqZRWcriIz5k%2BMxuauDaQK6Wc%3Did=033042b7-0973-4e00-b4b8-d9f3af49c3acserviceofferingid=b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c_=1407835578042
2014-08-12 05:26:21,880 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-36:ctx-b9835d0e job-439) Unexpected exception while
executing 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: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 $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
[jira] [Updated] (CLOUDSTACK-7094) Update PV-tools in all the VMs in case of xenserver upgrade to avoid PV-tools error in VMs with VGPU support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7094: --- Assignee: Sanjay Tripathi Update PV-tools in all the VMs in case of xenserver upgrade to avoid PV-tools error in VMs with VGPU support Key: CLOUDSTACK-7094 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7094 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.4.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.5.0 If VM(say windows 7) with PV tools installed is running on XS host 6.0 or on previous versions and user wants to upgrade it to XS 620SP1. Steps to follow: a. Upgrade XenServer to 620SP1 b. Update the PV tools in all the VMs. c. Change service offering to have VGPU support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3658) [DB Upgrade] - Deprecate several old object storage tables and columns as a part of 41-42 db upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-3658: --- Priority: Major (was: Critical) [DB Upgrade] - Deprecate several old object storage tables and columns as a part of 41-42 db upgrade Key: CLOUDSTACK-3658 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3658 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Storage Controller Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.5.0 Attachments: cloud-after-upgrade.dmp We should deprecate the following db tables and table columes as a part of 41-42 db upgrade due to recent object storage refactoring: -Upload -s3 -swift -template_host_ref -template_s3_ref -template_swift_ref -volume_host_ref -columes (s3_id, swift_id, sechost_id) from snapshots table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6838) Add test cases for download url expiration functionality
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-6838: --- Issue Type: Test (was: Bug) Add test cases for download url expiration functionality Key: CLOUDSTACK-6838 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6838 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.5.0 Download urls for template/volume should expire after configurable time. We should add test cases for download url expiration functionality if it doesnt already exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6838) Add test cases for download url expiration functionality
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-6838: --- Assignee: (was: Nitin Mehta) Add test cases for download url expiration functionality Key: CLOUDSTACK-6838 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6838 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Nitin Mehta Fix For: 4.5.0 Download urls for template/volume should expire after configurable time. We should add test cases for download url expiration functionality if it doesnt already exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-6945: Priority: Critical (was: Minor) Null pointer exception when starting a VM that had its template deleted --- Key: CLOUDSTACK-6945 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945 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 Environment: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud Platform packages installed and properly configured. Reporter: Rafael Weingartner Priority: Critical Fix For: 4.5.0, 4.4.1 It seems that you have a bug in CS 4.3.0(and probably previous versions?) when starting a machine that was created from a template that has been deleted. There will happen a null pointer exception in com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart: “858 -if (volTemplateId != null volTemplateId.longValue() != template.getId())” The object, “template” is going to be null, because in: “811 - VirtualMachineTemplate template = _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());” The findById, will add a where clause, looking for template that have the column removed that is null, therefore It will return a null object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-6827) Can't enable VR service provider in case of multiple physical networks
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang reassigned CLOUDSTACK-6827:
--
Assignee: Animesh Chaturvedi (was: Sheng Yang)
Can't enable VR service provider in case of multiple physical networks
--
Key: CLOUDSTACK-6827
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6827
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server, Network Controller
Affects Versions: 4.4.0
Environment: Latest build from 4.4 with commit
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Animesh Chaturvedi
Priority: Critical
Fix For: 4.4.0
Attachments: management-server.rar
Can't enable VR service provider in case of multiple physical networks
Steps to reproduce:
==
1.Bring up CS in advanced zone with xen cluster
2.Once the system is up disable the zone and add another physical network and
add only guest traffic into it.
3.Go to network service providers in the physical network
4.All the providers are disabled by default. Try to enable Virtual Router
http://10.147.59.119:8096/client/api?command=updateNetworkServiceProviderid=beb30cda-7e3a-44e9-b179-c1c6fd605b47state=Enabled
Result:
=
Enabling VR service provider failed and observed following exception:
2014-06-03 06:13:54,846 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(ApiServer-8:ctx-8602d969 ctx-e30c2238) submit async job-82, details:
AsyncJobVO {id:82, userId: 1, accountId: 1, instanceType:
PhysicalNetworkServiceProvider, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
cmdInfo:
{id:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxDetails:{\PhysicalNetworkServiceProvider\:\beb30cda-7e3a-44e9-b179-c1c6fd605b47\,\com.cloud.network.PhysicalNetworkServiceProvider\:6},cmdEventType:SERVICE.PROVIDER.UPDATE,ctxUserId:1,state:Enabled,httpmethod:GET,uuid:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxAccountId:1,ctxStartEventId:218},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-03 06:13:54,853 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-45:ctx-4f22f44a job-82) Add job-82 into job monitoring
2014-06-03 06:13:54,853 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-45:ctx-4f22f44a job-82) Executing AsyncJobVO {id:82,
userId: 1, accountId: 1, instanceType: PhysicalNetworkServiceProvider,
instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
cmdInfo:
{id:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxDetails:{\PhysicalNetworkServiceProvider\:\beb30cda-7e3a-44e9-b179-c1c6fd605b47\,\com.cloud.network.PhysicalNetworkServiceProvider\:6},cmdEventType:SERVICE.PROVIDER.UPDATE,ctxUserId:1,state:Enabled,httpmethod:GET,uuid:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxAccountId:1,ctxStartEventId:218},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-03 06:13:54,860 WARN [c.c.a.d.ParamGenericValidationWorker]
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) Received unknown
parameters for command updateNetworkServiceProvider. Unknown parameters :
ctxdetails
2014-06-03 06:13:54,871 DEBUG [c.c.n.NetworkServiceImpl]
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) trying to update the
state of the service provider id=6 on physical network: 201 to state: Enabled
2014-06-03 06:13:54,878 DEBUG [c.c.s.StatsCollector]
(StatsCollector-2:ctx-e6a2a82e) HostStatsCollector is running...
2014-06-03 06:13:54,885 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-45:ctx-4f22f44a job-82) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd
com.cloud.utils.exception.CloudRuntimeException: Provider is not ready,
cannot Enable the provider, please configure the provider first
at
com.cloud.network.NetworkServiceImpl.updateNetworkServiceProvider(NetworkServiceImpl.java:3425)
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)
[jira] [Resolved] (CLOUDSTACK-5474) EventBus: RabbitMQ provider expects password to be stored in plain text.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-5474. -- Resolution: Won't Fix there is no need for code fix. We could have password encrypted, and we can specify encrypted password in the spring file that is used for the event bus. Details of how to specify are provided in doc bug CLOUDSTACK-5879 EventBus: RabbitMQ provider expects password to be stored in plain text. Key: CLOUDSTACK-5474 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5474 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.0, 4.2.0, 4.3.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 EventBus: RabbitMQ provider expects password to be stored in plain text. This is security concern. This bug is to support encrypted password in the RabbitMQ config file. Will update the bug with the details of the encryption algorithm after investigation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6827) Can't enable VR service provider in case of multiple physical networks
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-6827:
---
Assignee: Murali Reddy (was: Animesh Chaturvedi)
Can't enable VR service provider in case of multiple physical networks
--
Key: CLOUDSTACK-6827
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6827
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server, Network Controller
Affects Versions: 4.4.0
Environment: Latest build from 4.4 with commit
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
Fix For: 4.4.0
Attachments: management-server.rar
Can't enable VR service provider in case of multiple physical networks
Steps to reproduce:
==
1.Bring up CS in advanced zone with xen cluster
2.Once the system is up disable the zone and add another physical network and
add only guest traffic into it.
3.Go to network service providers in the physical network
4.All the providers are disabled by default. Try to enable Virtual Router
http://10.147.59.119:8096/client/api?command=updateNetworkServiceProviderid=beb30cda-7e3a-44e9-b179-c1c6fd605b47state=Enabled
Result:
=
Enabling VR service provider failed and observed following exception:
2014-06-03 06:13:54,846 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(ApiServer-8:ctx-8602d969 ctx-e30c2238) submit async job-82, details:
AsyncJobVO {id:82, userId: 1, accountId: 1, instanceType:
PhysicalNetworkServiceProvider, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
cmdInfo:
{id:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxDetails:{\PhysicalNetworkServiceProvider\:\beb30cda-7e3a-44e9-b179-c1c6fd605b47\,\com.cloud.network.PhysicalNetworkServiceProvider\:6},cmdEventType:SERVICE.PROVIDER.UPDATE,ctxUserId:1,state:Enabled,httpmethod:GET,uuid:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxAccountId:1,ctxStartEventId:218},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-03 06:13:54,853 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-45:ctx-4f22f44a job-82) Add job-82 into job monitoring
2014-06-03 06:13:54,853 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-45:ctx-4f22f44a job-82) Executing AsyncJobVO {id:82,
userId: 1, accountId: 1, instanceType: PhysicalNetworkServiceProvider,
instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd,
cmdInfo:
{id:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxDetails:{\PhysicalNetworkServiceProvider\:\beb30cda-7e3a-44e9-b179-c1c6fd605b47\,\com.cloud.network.PhysicalNetworkServiceProvider\:6},cmdEventType:SERVICE.PROVIDER.UPDATE,ctxUserId:1,state:Enabled,httpmethod:GET,uuid:beb30cda-7e3a-44e9-b179-c1c6fd605b47,ctxAccountId:1,ctxStartEventId:218},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7332683579487, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-03 06:13:54,860 WARN [c.c.a.d.ParamGenericValidationWorker]
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) Received unknown
parameters for command updateNetworkServiceProvider. Unknown parameters :
ctxdetails
2014-06-03 06:13:54,871 DEBUG [c.c.n.NetworkServiceImpl]
(API-Job-Executor-45:ctx-4f22f44a job-82 ctx-f118a929) trying to update the
state of the service provider id=6 on physical network: 201 to state: Enabled
2014-06-03 06:13:54,878 DEBUG [c.c.s.StatsCollector]
(StatsCollector-2:ctx-e6a2a82e) HostStatsCollector is running...
2014-06-03 06:13:54,885 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-45:ctx-4f22f44a job-82) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.network.UpdateNetworkServiceProviderCmd
com.cloud.utils.exception.CloudRuntimeException: Provider is not ready,
cannot Enable the provider, please configure the provider first
at
com.cloud.network.NetworkServiceImpl.updateNetworkServiceProvider(NetworkServiceImpl.java:3425)
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)
