[jira] [Closed] (CLOUDSTACK-5540) ResourceUnavailableException when the commands fail on non-upgarded domain router.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori closed CLOUDSTACK-5540. - Resolution: Fixed Closing the issue as it is no more observed. ResourceUnavailableException when the commands fail on non-upgarded domain router. Key: CLOUDSTACK-5540 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5540 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.3.0 Environment: upgraded from ACS4.2 to CCP 4.3 Reporter: manasaveloori Assignee: Kishan Kavala Fix For: 4.3.0 Upgraded the ACS4.2 build to CCP 4.3. On the non upgraded setup performed the following commands. Applied PF,LB,Static nat,Enabled Remote access VPN. As expected behaviour the commands are failing on non upgraded VRs. But the exceptions are shown as .ResourceUnavailableException instead of Router requires Upgrade. Snippet form Ms log: 2013-12-18 07:17:34,139 DEBUG [c.c.n.IpAddressManagerImpl] (Job-Executor-14:ctx-10287a9f ctx-19958fbf) Resource is not available: VirtualRouter com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:3] is unreachable: Unable to apply ip association on router at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3735) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.associatePublicIP(VirtualNetworkApplianceManagerImpl.java:3526) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.associatePublicIP(VpcVirtualNetworkApplianceManagerImpl.java:505) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy240.associatePublicIP(Unknown Source) at com.cloud.network.element.VirtualRouterElement.applyIps(VirtualRouterElement.java:476) at com.cloud.network.IpAddressManagerImpl.applyIpAssociations(IpAddressManagerImpl.java:976) at com.cloud.network.IpAddressManagerImpl.applyRules(IpAddressManagerImpl.java:514) at com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:521) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy175.applyRules(Unknown Source) at com.cloud.network.rules.RulesManagerImpl.applyPortForwardingRules(RulesManagerImpl.java:871) at com.cloud.network.rules.RulesManagerImpl.revokePortForwardingRuleInternal(RulesManagerImpl.java:702) at com.cloud.network.rules.RulesManagerImpl.revokePortForwardingRule(RulesManagerImpl.java:688) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
[jira] [Closed] (CLOUDSTACK-5849) Failed to shutdown the network when corresponding External LB provider gets Disabled while still in use by the network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
manasaveloori closed CLOUDSTACK-5849.
-
Resolution: Fixed
CS-18845 Based on this issue.Closing as it is by design
Failed to shutdown the network when corresponding External LB provider gets
Disabled while still in use by the network
--
Key: CLOUDSTACK-5849
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5849
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller, Network Devices
Affects Versions: 4.3.0
Environment: upgraded from 3.0.6 patch E to 4.3
Reporter: manasaveloori
Assignee: Murali Reddy
Fix For: 4.3.0
Attachments: management-server.rar, management-server306.log.rar,
management-server4.3.rar, mysqldump306PatchE.dmp, mysqldump306PatchE.dmp,
mysqldump4.3.dmp, mysqldump4.3.dmp
Steps:
1. Deployed CS 3.0.6 Patch E with Xen 6.0.2 HV.
2. Created the service offering for netscaler device.
3. Added incompatible version of Netscaler. added NS10.1: Build 120.1316
to CS 3.0.6 build.
it was success.
4. Now created the network using the service offering created in step 2.
5. Observed that the network went into shut down state as the netscaler
failed to implement the network.
6. Removed the netscaler device from CS and disabled the service offering.
7. Now there were no VMs associated to that network.Tried to delete the
network.But it failed as the network was not in correct state.
Note: issue existed in 3.0.6 that network is not deleted if it is in shutdown
state.
2014-01-07 21:32:09,720 DEBUG [agent.manager.AgentManagerImpl]
(RouterMonitor-1:null) Details from executing class
com.cloud.agent.api.NetworkUsageCommand:
2014-01-07 21:32:09,720 DEBUG
[network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
Recieved and Sent bytes are both 0. Not updating user_statistics
2014-01-07 21:32:11,498 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-5:null) Ping from 8
2014-01-07 21:32:11,917 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-6:null) Ping from 5
2014-01-07 21:32:12,164 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-19:null) submit async job-75, job: AsyncJobVO {id:75, userId:
2, accountId: 2, sessionKey: null, instanceType: null, instanceId: null, cmd:
com.cloud.api.commands.DeleteNetworkCmd, cmdOriginator: null, cmdVersion: 0,
callbackType: 0, callbackAddress: null, status: 0, processStatus: 0,
resultCode: 0, result: null, initMsid: 6642334695485, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null}
2014-01-07 21:32:12,169 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-69:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
for job-75
2014-01-07 21:32:12,179 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-69:job-75) Sync job-75 execution on object network.216
2014-01-07 21:32:12,188 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-69:job-75) job com.cloud.api.commands.DeleteNetworkCmd for
job-75 was queued, processing the queue.
2014-01-07 21:32:12,197 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-69:job-75) Executing sync queue item: SyncQueueItemVO {id:17,
queueId: 17, contentType: AsyncJob, contentId: 75, lastProcessMsid:
6642334695485, lastprocessNumber: 1, lastProcessTime: Tue Jan 07 21:32:12 IST
2014, created: Tue Jan 07 21:32:12 IST 2014}
2014-01-07 21:32:12,199 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-69:job-75) Schedule queued job-75
2014-01-07 21:32:12,207 DEBUG [cloud.async.SyncQueueManagerImpl]
(Job-Executor-69:job-75) There is a pending process in sync queue(id: 17)
2014-01-07 21:32:12,210 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-70:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
for job-75
2014-01-07 21:32:12,233 DEBUG [cloud.network.NetworkManagerImpl]
(Job-Executor-70:job-75) Network is not implemented: Ntwk[216|Guest|17]
2014-01-07 21:32:12,233 DEBUG [db.Transaction.Transaction]
(Job-Executor-70:job-75) Rolling back the transaction: Time = 1 Name =
-AsyncJobManagerImpl$1.run:396-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
called by
[jira] [Commented] (CLOUDSTACK-6083) Missing cidrlist in 4.3 adv zone firewall
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900142#comment-13900142 ] ASF subversion and git services commented on CLOUDSTACK-6083: - Commit e8f93f28fc424c73156723d9b65b13c05dafc5a8 in branch refs/heads/4.3-forward from [~jayapal] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e8f93f2 ] CLOUDSTACK-6083 corrected firewall rule cidr load issue Missing cidrlist in 4.3 adv zone firewall - Key: CLOUDSTACK-6083 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6083 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Environment: CentOS 6.5 HVs and mgmt, adv zone (without sg) Reporter: Nux Assignee: Jayapal Reddy Priority: Critical It's the first time I'm testing firewall in 4.3 Advanced zone (without SG) so please let me know if I'm missing something obvious; I notice the cidrlist is missing from the rules, both in UI and in cloudmonkey. If I create the rule from cloudmoneky it also doesn't register a cidrlist, so it doesn't seem to be UI's fault. This is what I see in the logs http://fpaste.org/75819/39203643/ when I create a rule. Anyone else experiencing this? Do note: This is a (until now successfull) upgrade from 4.2.1. The cidrs make it into the firewall_rules_cidrs table. I also checked inside the VR and while iptables does have rules for the ports I mentioned, the CIDRs are missing, too. See http://img.nux.ro/3Kk-Selection_050.png mycloudmonkey list firewallrules id=835dfc08-beab-458a-9c30-6b0b2b11f201 count = 1 firewallrule: id = 835dfc08-beab-458a-9c30-6b0b2b11f201 cidrlist = endport = 65535 ipaddress = 172.16.72.212 ipaddressid = f481629a-deb6-4413-b253-e8e98d8a303a networkid = c615df7c-3ea3-4138-a83c-d848e20fe1f6 protocol = tcp startport = 1 state = Active tags: -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-778) user provided hostname to be specified in vCenter instead of CloudStack generated name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900144#comment-13900144 ] Wei Zhou commented on CLOUDSTACK-778: - Guys, Is this functionality only used for vmware? -Wei user provided hostname to be specified in vCenter instead of CloudStack generated name -- Key: CLOUDSTACK-778 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-778 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: haroon abdelrahman Assignee: Venkata Siva Vijayendra Bhamidipati Fix For: 4.2.0 Release Planning: Dev List discussion: unknown Functional Spec: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Allow+user+provided+hostname%2C+internal+VM+name+on+hypervisor+for+guest+VMs Feature Branch: unknown -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6083) Missing cidrlist in 4.3 adv zone firewall
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900160#comment-13900160 ] ASF subversion and git services commented on CLOUDSTACK-6083: - Commit 3136401d40d295ac9180ee0460a1512462064a73 in branch refs/heads/master from [~jayapal] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3136401 ] CLOUDSTACK-6083 corrected firewall rule cidr load issue Missing cidrlist in 4.3 adv zone firewall - Key: CLOUDSTACK-6083 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6083 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Environment: CentOS 6.5 HVs and mgmt, adv zone (without sg) Reporter: Nux Assignee: Jayapal Reddy Priority: Critical It's the first time I'm testing firewall in 4.3 Advanced zone (without SG) so please let me know if I'm missing something obvious; I notice the cidrlist is missing from the rules, both in UI and in cloudmonkey. If I create the rule from cloudmoneky it also doesn't register a cidrlist, so it doesn't seem to be UI's fault. This is what I see in the logs http://fpaste.org/75819/39203643/ when I create a rule. Anyone else experiencing this? Do note: This is a (until now successfull) upgrade from 4.2.1. The cidrs make it into the firewall_rules_cidrs table. I also checked inside the VR and while iptables does have rules for the ports I mentioned, the CIDRs are missing, too. See http://img.nux.ro/3Kk-Selection_050.png mycloudmonkey list firewallrules id=835dfc08-beab-458a-9c30-6b0b2b11f201 count = 1 firewallrule: id = 835dfc08-beab-458a-9c30-6b0b2b11f201 cidrlist = endport = 65535 ipaddress = 172.16.72.212 ipaddressid = f481629a-deb6-4413-b253-e8e98d8a303a networkid = c615df7c-3ea3-4138-a83c-d848e20fe1f6 protocol = tcp startport = 1 state = Active tags: -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6090) Virtual Router Service Failure Alerting
Harikrishna Patnala created CLOUDSTACK-6090: --- Summary: Virtual Router Service Failure Alerting Key: CLOUDSTACK-6090 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6090 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Virtual Router Affects Versions: 4.4.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.4.0 We already have monitoring services in Virtual Router in 4.3 and ensure the services running through the lifetime of VR. Upon failure alerts are getting generated in Virtual router. There is a need to send these alerts to management server to notify admin. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6083) Missing cidrlist in 4.3 adv zone firewall
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-6083. --- Resolution: Fixed Missing cidrlist in 4.3 adv zone firewall - Key: CLOUDSTACK-6083 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6083 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Environment: CentOS 6.5 HVs and mgmt, adv zone (without sg) Reporter: Nux Assignee: Jayapal Reddy Priority: Critical It's the first time I'm testing firewall in 4.3 Advanced zone (without SG) so please let me know if I'm missing something obvious; I notice the cidrlist is missing from the rules, both in UI and in cloudmonkey. If I create the rule from cloudmoneky it also doesn't register a cidrlist, so it doesn't seem to be UI's fault. This is what I see in the logs http://fpaste.org/75819/39203643/ when I create a rule. Anyone else experiencing this? Do note: This is a (until now successfull) upgrade from 4.2.1. The cidrs make it into the firewall_rules_cidrs table. I also checked inside the VR and while iptables does have rules for the ports I mentioned, the CIDRs are missing, too. See http://img.nux.ro/3Kk-Selection_050.png mycloudmonkey list firewallrules id=835dfc08-beab-458a-9c30-6b0b2b11f201 count = 1 firewallrule: id = 835dfc08-beab-458a-9c30-6b0b2b11f201 cidrlist = endport = 65535 ipaddress = 172.16.72.212 ipaddressid = f481629a-deb6-4413-b253-e8e98d8a303a networkid = c615df7c-3ea3-4138-a83c-d848e20fe1f6 protocol = tcp startport = 1 state = Active tags: -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6083) Missing cidrlist in 4.3 adv zone firewall
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900183#comment-13900183 ] Nux commented on CLOUDSTACK-6083: - Confirmed, works for me. Missing cidrlist in 4.3 adv zone firewall - Key: CLOUDSTACK-6083 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6083 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Environment: CentOS 6.5 HVs and mgmt, adv zone (without sg) Reporter: Nux Assignee: Jayapal Reddy Priority: Critical It's the first time I'm testing firewall in 4.3 Advanced zone (without SG) so please let me know if I'm missing something obvious; I notice the cidrlist is missing from the rules, both in UI and in cloudmonkey. If I create the rule from cloudmoneky it also doesn't register a cidrlist, so it doesn't seem to be UI's fault. This is what I see in the logs http://fpaste.org/75819/39203643/ when I create a rule. Anyone else experiencing this? Do note: This is a (until now successfull) upgrade from 4.2.1. The cidrs make it into the firewall_rules_cidrs table. I also checked inside the VR and while iptables does have rules for the ports I mentioned, the CIDRs are missing, too. See http://img.nux.ro/3Kk-Selection_050.png mycloudmonkey list firewallrules id=835dfc08-beab-458a-9c30-6b0b2b11f201 count = 1 firewallrule: id = 835dfc08-beab-458a-9c30-6b0b2b11f201 cidrlist = endport = 65535 ipaddress = 172.16.72.212 ipaddressid = f481629a-deb6-4413-b253-e8e98d8a303a networkid = c615df7c-3ea3-4138-a83c-d848e20fe1f6 protocol = tcp startport = 1 state = Active tags: -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-4840) Automation: multiple IPs per NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosk Kelkar reassigned CLOUDSTACK-4840: --- Assignee: Ashutosk Kelkar (was: Gaurav Aradhye) Automation: multiple IPs per NIC - Key: CLOUDSTACK-4840 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4840 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: Sudha Ponnaganti Assignee: Ashutosk Kelkar Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6091) [Automation]: test_vpc_routers.py fails with error AssertionError: Migration to host Target hostid failed. The router host isstill Source hostid
Dhananjay D Pathak created CLOUDSTACK-6091: -- Summary: [Automation]: test_vpc_routers.py fails with error AssertionError: Migration to host Target hostid failed. The router host isstill Source hostid Key: CLOUDSTACK-6091 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6091 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.2.0 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server release 6.4 (Santiago) Reporter: Dhananjay D Pathak Marvin Test: cloudstack/test/integration/component/test_vpc_routers.py fails with Error as described bellow (log files are attached): Test start/stop of router after addition of one guest network ... ok Test reboot of router after addition of one guest network ... ok Test migrate of router after addition of one guest network ... FAIL Test to change service offering of router after addition of one guest network ... ok Test destroy of router after addition of one guest network ... ok Test to stop and start router after creation of VPC ... ok Test to reboot the router after creating a VPC ... ok Test migration of router to another host after creating VPC ... FAIL Tests to change service offering of the Router after ... ok Test to destroy the router after creating a VPC ... ok == FAIL: Test migrate of router after addition of one guest network -- Traceback (most recent call last): File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_routers.py, line 1186, in test_03_migrate_router_after_addition_of_one_guest_network self.migrate_router(routers[0]) File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_routers.py, line 980, in migrate_router still %s % (host.id, router.hostid)) AssertionError: Migration to host f6c30c21-ccc8-45d7-97fe-6d9df5566670 failed. The router host isstill a3b4b53f-ea13-4e9a-b46d-a90b88b6f1fd -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6091) [Automation]: test_vpc_routers.py fails with error AssertionError: Migration to host Target hostid failed. The router host isstill Source hostid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhananjay D Pathak updated CLOUDSTACK-6091: --- Attachment: runinfo.txt results.txt failed_plus_exceptions.txt Log files for execution of test_vpc_routers.py. [Automation]: test_vpc_routers.py fails with error AssertionError: Migration to host Target hostid failed. The router host isstill Source hostid - Key: CLOUDSTACK-6091 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6091 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.2.0 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server release 6.4 (Santiago) Reporter: Dhananjay D Pathak Labels: test Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt Marvin Test: cloudstack/test/integration/component/test_vpc_routers.py fails with Error as described bellow (log files are attached): Test start/stop of router after addition of one guest network ... ok Test reboot of router after addition of one guest network ... ok Test migrate of router after addition of one guest network ... FAIL Test to change service offering of router after addition of one guest network ... ok Test destroy of router after addition of one guest network ... ok Test to stop and start router after creation of VPC ... ok Test to reboot the router after creating a VPC ... ok Test migration of router to another host after creating VPC ... FAIL Tests to change service offering of the Router after ... ok Test to destroy the router after creating a VPC ... ok == FAIL: Test migrate of router after addition of one guest network -- Traceback (most recent call last): File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_routers.py, line 1186, in test_03_migrate_router_after_addition_of_one_guest_network self.migrate_router(routers[0]) File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_routers.py, line 980, in migrate_router still %s % (host.id, router.hostid)) AssertionError: Migration to host f6c30c21-ccc8-45d7-97fe-6d9df5566670 failed. The router host isstill a3b4b53f-ea13-4e9a-b46d-a90b88b6f1fd -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (CLOUDSTACK-5815) [Hyper-v] Two SNAT rules for one isolated network if acquired ip is from different vlan
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N reopened CLOUDSTACK-5815:
---
Verified this bug on the latest build from 4.3 with commit
52f2af19c89b06826d5ee196eb3fc69f244177f9. I still see the issue and the
behavior is same as before.
Following is the IpAssocCommand for PF creation:
2014-02-13 06:10:51,890 DEBUG [c.c.a.t.Request] (Job-Executor-100:ctx-45781660
ctx-02373089) Seq 4-298790783: Executing: { Cmd , MgmtId: 6615759585382, via:
4(10.147.40.31), Ver: v1, Flags: 11,
[{com.cloud.agent.api.routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.147.48.5,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,broadcastUri:vlan://48,vlanGateway:10.147.48.1,vlanNetmask:255.255.255.0,vifMacAddress:06:a5:94:00:00:17,networkRate:200,trafficType:Public},{accountId:2,publicIp:10.147.48.10,sourceNat:false,add:true,oneToOneNat:false,firstIP:false,broadcastUri:vlan://48,vlanGateway:10.147.48.1,vlanNetmask:255.255.255.0,vifMacAddress:06:81:61:00:00:17,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:10.147.40.228,router.name:r-4-QA},wait:0}},{com.cloud.agent.api.routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.147.52.221,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,broadcastUri:vlan://52,vlanGateway:10.147.52.1,vlanNetmask:255.255.255.0,vifMacAddress:06:81:69:00:00:17,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:10.147.40.228,router.name:r-4-QA},wait:0}}]
}
root@r-4-QA:~# ip addr show eth2
4: eth2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 06:81:60:00:00:17 brd ff:ff:ff:ff:ff:ff
inet 10.147.48.5/24 brd 10.147.48.255 scope global eth2
inet 10.147.52.221/24 brd 10.147.52.255 scope global eth2
inet 10.147.48.10/24 brd 10.147.48.255 scope global secondary eth2
inet6 fe80::481:60ff:fe00:17/64 scope link
valid_lft forever preferred_lft forever
root@r-4-QA:~# iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 85 packets, 6590 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- eth2 * 0.0.0.0/010.147.48.5
tcp dpt:22 to:10.1.1.14:22
0 0 DNAT tcp -- eth0 * 0.0.0.0/010.147.48.5
tcp dpt:22 to:10.1.1.14:22
0 0 DNAT tcp -- eth2 * 0.0.0.0/0
10.147.48.10 tcp dpt:22 to:10.1.1.14:22
0 0 DNAT tcp -- eth0 * 0.0.0.0/0
10.147.48.10 tcp dpt:22 to:10.1.1.14:22
0 0 DNAT tcp -- eth2 * 0.0.0.0/0
10.147.52.221tcp dpt:22 to:10.1.1.14:22
0 0 DNAT tcp -- eth0 * 0.0.0.0/0
10.147.52.221tcp dpt:22 to:10.1.1.14:22
Chain INPUT (policy ACCEPT 22 packets, 1320 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 223 packets, 14928 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/010.147.48.5
tcp dpt:22 to:10.1.1.14:22
0 0 DNAT tcp -- * * 0.0.0.0/0
10.147.48.10 tcp dpt:22 to:10.1.1.14:22
0 0 DNAT tcp -- * * 0.0.0.0/0
10.147.52.221tcp dpt:22 to:10.1.1.14:22
Chain POSTROUTING (policy ACCEPT 223 packets, 14928 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * eth20.0.0.0/00.0.0.0/0
to:10.147.48.5
0 0 SNAT all -- * eth20.0.0.0/00.0.0.0/0
to:10.147.52.221
0 0 SNAT tcp -- * eth010.1.1.0/24 10.1.1.14
tcp dpt:22 to:10.1.1.1
[Hyper-v] Two SNAT rules for one isolated network if acquired ip is from
different vlan
---
Key: CLOUDSTACK-5815
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5815
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Network Controller
Affects Versions: Future
Environment: Latest build from 4.3 branch with
commit:6f309b8a87d3376950a60234d399c6e3749ad1c7
Reporter: Sanjeev N
Assignee: Rajesh Battala
Labels: hyper-V,, hyper-v, hyperv
Fix For: 4.4.0
[Hyper-v] Two SNAT rules for one isolated network if acquired ip is from
different vlan
Steps to Reproduce:
[jira] [Created] (CLOUDSTACK-6092) Storage OverProvisioning as a Per Primary Basis
Saksham Srivastava created CLOUDSTACK-6092: -- Summary: Storage OverProvisioning as a Per Primary Basis Key: CLOUDSTACK-6092 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6092 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Storage Controller Affects Versions: 4.4.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5815) [Hyper-v] Two SNAT rules for one isolated network if acquired ip is from different vlan
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N resolved CLOUDSTACK-5815.
---
Resolution: Fixed
[Hyper-v] Two SNAT rules for one isolated network if acquired ip is from
different vlan
---
Key: CLOUDSTACK-5815
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5815
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Network Controller
Affects Versions: Future
Environment: Latest build from 4.3 branch with
commit:6f309b8a87d3376950a60234d399c6e3749ad1c7
Reporter: Sanjeev N
Assignee: Rajesh Battala
Labels: hyper-V,, hyper-v, hyperv
Fix For: 4.4.0
[Hyper-v] Two SNAT rules for one isolated network if acquired ip is from
different vlan
Steps to Reproduce:
=
1.Bring up CS in advanced zone with hyper-v cluster
2.Create isolated guest network and deploy few vms in the network
3.Exhaust all the public IP addresses present in the zone (in user_ip_address
table set the allocated=now())
4.Add new public IP range in new vlan and new subnet
5.Acquire one ip address from the new ip range and configure PF and assign
one vm deployed at step2
Expected Result:
==
In isolated network there is only one SNAT ip address for the entire network.
So even the acquired IP address is from different vlan, new SNAT rule should
not be configured with the acquired ip address.
Actual Result:
Since the ip address acquired at step5 is from new vlan and is the ip address
from that vlan additional SNAT rule got configured on VR with the acquired ip
address.
Following is the output from iptables on VR:
root@r-4-VM:~# iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 279 packets, 28169 bytes)
pkts bytes target prot opt in out source
destination
0 0 DNAT tcp -- eth2 * 0.0.0.0/0
10.147.31.240tcp dpt:22 to:10.1.1.26:22
0 0 DNAT tcp -- eth0 * 0.0.0.0/0
10.147.31.240tcp dpt:22 to:10.1.1.26:22
Chain INPUT (policy ACCEPT 4 packets, 240 bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 4 packets, 304 bytes)
pkts bytes target prot opt in out source
destination
0 0 DNAT tcp -- * * 0.0.0.0/0
10.147.31.240tcp dpt:22 to:10.1.1.26:22
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 SNAT tcp -- * eth010.1.1.0/24 10.1.1.26
tcp dpt:22 to:10.1.1.1
4 304 SNAT all -- * eth20.0.0.0/00.0.0.0/0
to:10.147.48.5
0 0 SNAT all -- * eth20.0.0.0/00.0.0.0/0
to:10.147.31.240
ip address configuration on eth2 as follows:
root@r-4-VM:~# ip addr show eth2
4: eth2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 06:78:3c:00:00:17 brd ff:ff:ff:ff:ff:ff
inet 10.147.48.5/24 brd 10.147.48.255 scope global eth2
inet 10.147.31.240/24 brd 10.147.31.255 scope global eth2
inet6 fe80::478:3cff:fe00:17/64 scope link
valid_lft forever preferred_lft forever
Following is the IpAssocCmd got executed after configuring PF rule on the
acquired ip address:
2014-01-07 11:30:39,274 DEBUG [c.c.a.t.Request] (Job-Executor-31:ctx-26e587af
ctx-d423299a) Seq 4-2034961238: Sending { Cmd , MgmtId: 132129494109518,
via: 4(10.147.40.31), Ver: v1, Flags: 11,
[{com.cloud.agent.api.routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.147.48.5,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,broadcastUri:vlan://48,vlanGateway:10.147.48.1,vlanNetmask:255.255.255.0,vifMacAddress:06:88:76:00:00:17,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:10.147.40.230,router.name:r-4-VM},wait:0}},{com.cloud.agent.api.routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.147.31.240,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,broadcastUri:vlan://31,vlanGateway:10.147.31.1,vlanNetmask:255.255.255.0,vifMacAddress:06:78:3e:00:00:17,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:10.147.40.230,router.name:r-4-VM},wait:0}}]
}
2014-01-07 11:30:39,275 DEBUG [c.c.a.t.Request] (Job-Executor-31:ctx-26e587af
ctx-d423299a) Seq 4-2034961238: Executing: { Cmd
[jira] [Updated] (CLOUDSTACK-6092) Storage OverProvisioning as a Per Primary Basis
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava updated CLOUDSTACK-6092: --- Description: The current scenario is to set the global parameter storage.overprovisioning.factor that is inherently applicable for any qualified primary store to leverage over provision of the underlying storage. Cloud Deployments can have different combinations of primary storage either for different vendors or from the same vendor but different products Depending on the storage capability, CloudStack admins need the flexibility to determine what the over-provisioning factor should be for each primary storage. Storage OverProvisioning as a Per Primary Basis --- Key: CLOUDSTACK-6092 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6092 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Storage Controller Affects Versions: 4.4.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava Labels: Storage Fix For: 4.4.0 The current scenario is to set the global parameter storage.overprovisioning.factor that is inherently applicable for any qualified primary store to leverage over provision of the underlying storage. Cloud Deployments can have different combinations of primary storage either for different vendors or from the same vendor but different products Depending on the storage capability, CloudStack admins need the flexibility to determine what the over-provisioning factor should be for each primary storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6093) [Automation]: test_vpc_network_lbrules.py fail with error as cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext : u'Failed t
Dhananjay D Pathak created CLOUDSTACK-6093:
--
Summary: [Automation]: test_vpc_network_lbrules.py fail with error
as cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
530, errortext : u'Failed to create VPC'}
Key: CLOUDSTACK-6093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6093
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: marvin
Affects Versions: 4.2.0
Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server
release 6.4 (Santiago)
Reporter: Dhananjay D Pathak
Marvin Test cloudstack/test/integration/component/test_vpc_network_lbrules.py
fails with error as described bellow (log files are attached):
Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... ok
Test Create LB rules for 1 network which is part of a two/multiple virtual
networks of a ... ERROR
Test case no 222 : Create LB rules for a two/multiple virtual networks of a ...
ERROR
Test case no 222 : Create LB rules for a two/multiple virtual networks of a ...
ERROR
Test case no 214 : Delete few(not all) LB rules for a single virtual network of
a ... ERROR
Test Delete few(not all) LB rules for a single virtual network of ... ERROR
Test Delete all LB rules for a single virtual network of a ... ERROR
Test Delete all LB rules for a single virtual network of a ... ERROR
Test User should not be allowed to create a LB rule for a VM that belongs to a
different VPC. ... ERROR
Test User should not be allowed to create a LB rule for a VM that does not
belong to any VPC. ... ERROR
Test case no 217 and 236: User should not be allowed to create a LB rule for a
... ok
Test User should not be allowed to create a LB rule on an Ipaddress that Source
Nat enabled. ... ok
Test User should not be allowed to create a LB rule on an Ipaddress that
already has a PF rule. ... FAIL
Test User should not be allowed to create a LB rule on an Ipaddress that
already has a Static Nat rule. ... ok
Test release Ip address that has a LB rule assigned to it. ... ERROR
==
ERROR: Test Create LB rules for 1 network which is part of a two/multiple
virtual networks of a
--
Traceback (most recent call last):
File
/DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_lbrules.py,
line 246, in setUp
domainid=self.account.domainid
File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py,
line 3114, in create
return VPC(apiclient.createVPC(cmd).__dict__)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1988, in createVPC
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
line 280, in marvinRequest
response = self.poll(asyncJobId, response_type)
File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
line 86, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
530, errortext : u'Failed to create VPC'}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6093) [Automation]: test_vpc_network_lbrules.py fail with error as cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext : u'Failed t
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dhananjay D Pathak updated CLOUDSTACK-6093:
---
Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt
Log files for execution of test_vpc_network_lbrules.py.
[Automation]: test_vpc_network_lbrules.py fail with error as
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
530, errortext : u'Failed to create VPC'}
---
Key: CLOUDSTACK-6093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6093
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: marvin
Affects Versions: 4.2.0
Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server
release 6.4 (Santiago)
Reporter: Dhananjay D Pathak
Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt
Marvin Test cloudstack/test/integration/component/test_vpc_network_lbrules.py
fails with error as described bellow (log files are attached):
Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... ok
Test Create LB rules for 1 network which is part of a two/multiple virtual
networks of a ... ERROR
Test case no 222 : Create LB rules for a two/multiple virtual networks of a
... ERROR
Test case no 222 : Create LB rules for a two/multiple virtual networks of a
... ERROR
Test case no 214 : Delete few(not all) LB rules for a single virtual network
of a ... ERROR
Test Delete few(not all) LB rules for a single virtual network of ... ERROR
Test Delete all LB rules for a single virtual network of a ... ERROR
Test Delete all LB rules for a single virtual network of a ... ERROR
Test User should not be allowed to create a LB rule for a VM that belongs to
a different VPC. ... ERROR
Test User should not be allowed to create a LB rule for a VM that does not
belong to any VPC. ... ERROR
Test case no 217 and 236: User should not be allowed to create a LB rule for
a ... ok
Test User should not be allowed to create a LB rule on an Ipaddress that
Source Nat enabled. ... ok
Test User should not be allowed to create a LB rule on an Ipaddress that
already has a PF rule. ... FAIL
Test User should not be allowed to create a LB rule on an Ipaddress that
already has a Static Nat rule. ... ok
Test release Ip address that has a LB rule assigned to it. ... ERROR
==
ERROR: Test Create LB rules for 1 network which is part of a two/multiple
virtual networks of a
--
Traceback (most recent call last):
File
/DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_lbrules.py,
line 246, in setUp
domainid=self.account.domainid
File
/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line
3114, in create
return VPC(apiclient.createVPC(cmd).__dict__)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1988, in createVPC
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
280, in marvinRequest
response = self.poll(asyncJobId, response_type)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
86, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
530, errortext : u'Failed to create VPC'}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6094) Insufficient Error information when adding template with broken vhd file
Gerd Katzenbeisser created CLOUDSTACK-6094: -- Summary: Insufficient Error information when adding template with broken vhd file Key: CLOUDSTACK-6094 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6094 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.1 Reporter: Gerd Katzenbeisser I resized a VHD capacity using Microsofts diskutil instead of vhd-util. The resulting vhd file looks invalid to vhd-uti: RoboRex1.vhd appears invalid; dumping metadata ... failed to get batmap header However - when trying to add a template with such a file the upload completes but the template does not install and is not usable. After restarting the secondary storage VM the download starts again. After upload the result of vhd-util check should be reported as error if the check fails. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6095) [Automation] : test_vpc_network_pfrules.pyfails with error as AssertionError: Failed to SSH into VM
Dhananjay D Pathak created CLOUDSTACK-6095: -- Summary: [Automation] : test_vpc_network_pfrules.pyfails with error as AssertionError: Failed to SSH into VM Key: CLOUDSTACK-6095 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6095 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.2.0 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server release 6.4 (Santiago) Reporter: Dhananjay D Pathak Marvin Test test_vpc_network_pfrules.py fails with Error as described bellow (log files are attached): Test : Create VPC PF rules on acquired public ip when VpcVirtualRouter is stopped ... FAIL Test Create VPC PF rules on acquired public ip when VpcVirtualRouter is Running ... FAIL Test Create multiple VPC PF rules on acquired public ip in diff't networks when VpcVirtualRouter is stopped ... FAIL Test Create multiple VPC PF rules on acquired public ip in diff't networks when VpcVirtualRouter is running ... FAIL Test delete a PF rule in VPC when VpcVirtualRouter is Stopped ... FAIL Test delete a PF rule in VPC when VpcVirtualRouter is Running ... FAIL Test delete all PF rules in VPC when VpcVirtualRouter is Stopped ... FAIL Test delete all PF rules in VPC when VpcVirtualRouter is Running ... FAIL Test delete all PF rules in VPC across multiple networks when VpcVirtualRouter is Stopped ... FAIL Test delete all PF rules in VPC across multiple networks when VpcVirtualRouter is Running ... FAIL == FAIL: Test : Create VPC PF rules on acquired public ip when VpcVirtualRouter is stopped -- Traceback (most recent call last): File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_pfrules.py, line 508, in test_01_network_services_VPC_StopCreatePF self.check_ssh_into_vm(vm_1, public_ip_1, testnegative=False) File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_pfrules.py, line 328, in check_ssh_into_vm self.fail(Failed to SSH into VM - %s % (public_ip.ipaddress.ipaddress)) AssertionError: Failed to SSH into VM - 207.19.99.48 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6096) Using eject on Windows will prevent attaching ISO to the instance
Francois Gaudreault created CLOUDSTACK-6096: --- Summary: Using eject on Windows will prevent attaching ISO to the instance Key: CLOUDSTACK-6096 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6096 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server Affects Versions: 4.2.1 Reporter: Francois Gaudreault Seen on 4.2.1 with XS6.2 SP1 with Windows 2008 template. If you deploy a Windows template, and you attach an ISO to the instance, and then you click on Eject from Windows, you will be able to detach the ISO from CloudStack, but the SR on XenServer will remain. That will prevent a user to re-attach the same or any other ISO to this instance. The error we see when we try to reattach the ISO is misleading since it talks about the URL not being found instead of the real cause. 2014-02-12 20:13:44,060 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-454:null) Seq 1-1166937279: Executing request 2014-02-12 20:13:44,182 WARN [xen.resource.CitrixResourceBase] (DirectAgent-454:null) can not getVDIbyLocationandSR 223-2-d0e89fa1-fcaf-3180-ae86-5aeab5d7a8b1.iso 2014-02-12 20:13:44,183 WARN [xen.resource.XenServerStorageProcessor] (DirectAgent-454:null) Failed to attach iso: com.cloud.utils.exception.CloudRuntimeException: Could not find ISO with URL: To recover from this, I had to SSH to the XenServer Hypervisor, lazy unmount the stuck SR, and remove it. Then I was able to reattach the ISO again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6095) [Automation] : test_vpc_network_pfrules.pyfails with error as AssertionError: Failed to SSH into VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhananjay D Pathak updated CLOUDSTACK-6095: --- Attachment: runinfo.txt results.txt index.html failed_plus_exceptions.txt Log files for execution of test_vpc_network_pfrules.py are attached. [Automation] : test_vpc_network_pfrules.pyfails with error as AssertionError: Failed to SSH into VM Key: CLOUDSTACK-6095 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6095 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.2.0 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server release 6.4 (Santiago) Reporter: Dhananjay D Pathak Attachments: failed_plus_exceptions.txt, index.html, results.txt, runinfo.txt Marvin Test test_vpc_network_pfrules.py fails with Error as described bellow (log files are attached): Test : Create VPC PF rules on acquired public ip when VpcVirtualRouter is stopped ... FAIL Test Create VPC PF rules on acquired public ip when VpcVirtualRouter is Running ... FAIL Test Create multiple VPC PF rules on acquired public ip in diff't networks when VpcVirtualRouter is stopped ... FAIL Test Create multiple VPC PF rules on acquired public ip in diff't networks when VpcVirtualRouter is running ... FAIL Test delete a PF rule in VPC when VpcVirtualRouter is Stopped ... FAIL Test delete a PF rule in VPC when VpcVirtualRouter is Running ... FAIL Test delete all PF rules in VPC when VpcVirtualRouter is Stopped ... FAIL Test delete all PF rules in VPC when VpcVirtualRouter is Running ... FAIL Test delete all PF rules in VPC across multiple networks when VpcVirtualRouter is Stopped ... FAIL Test delete all PF rules in VPC across multiple networks when VpcVirtualRouter is Running ... FAIL == FAIL: Test : Create VPC PF rules on acquired public ip when VpcVirtualRouter is stopped -- Traceback (most recent call last): File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_pfrules.py, line 508, in test_01_network_services_VPC_StopCreatePF self.check_ssh_into_vm(vm_1, public_ip_1, testnegative=False) File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_pfrules.py, line 328, in check_ssh_into_vm self.fail(Failed to SSH into VM - %s % (public_ip.ipaddress.ipaddress)) AssertionError: Failed to SSH into VM - 207.19.99.48 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6097) [Automation] : test_volumes.pyfails with error as Failed to attach volume: TestDiskServ to VM:VM ID; Failed to attach volume for uuid: Volume uuid due to You at
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dhananjay D Pathak updated CLOUDSTACK-6097:
---
Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt
Log files for execution of test_volumes.py are attached.
[Automation] : test_volumes.pyfails with error as Failed to attach volume:
TestDiskServ to VM:VM ID; Failed to attach volume for uuid: Volume uuid
due to You attempted an operation on a VM that was not in an appropriate
power state at the time;
-
Key: CLOUDSTACK-6097
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6097
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: marvin
Affects Versions: 4.2.0
Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server
release 6.4 (Santiago)
Reporter: Dhananjay D Pathak
Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt
Marvin Test test_volumes.py fails with Error as described bellow (log files
are attached):
Test Volume attach/detach to VM (5 data volumes) ... ERROR
Test Attach volumes (max capacity) ... ERROR
Test attach volumes (more than max) to an instance ... ok
Test Volumes and ISO attach ... ERROR
Test custom disk sizes beyond range ... ok
Attach a created Volume to a Running VM ... ok
Detach a Volume attached to a VM ... ok
Delete a Volume unattached to an VM ... ok
Create a volume under a non-root domain as non-root-domain user ... ERROR
==
ERROR: Test Volume attach/detach to VM (5 data volumes)
--
Traceback (most recent call last):
File
/DataDisk/temp/cloudstack/test/integration/component/test_volumes.py, line
520, in test_01_volume_attach_detach
volume
File
/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line
543, in attach_volume
return apiclient.attachVolume(cmd)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1483, in attachVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
280, in marvinRequest
response = self.poll(asyncJobId, response_type)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
86, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
530, errortext : uFailed to attach volume: TestDiskServ to VM:
ecd07768-df22-468a-8023-7f922564e9f5; Failed to attach volume for uuid:
1621ee3f-650d-4b25-a125-13a83aae4912 due to You attempted an operation on a
VM that was not in an appropriate power state at the time; for example, you
attempted to start a VM that was already running. The parameters returned
are the VM's handle, and the expected and actual VM state at the time of the
call.}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6097) [Automation] : test_volumes.pyfails with error as Failed to attach volume: TestDiskServ to VM:VM ID; Failed to attach volume for uuid: Volume uuid due to You at
Dhananjay D Pathak created CLOUDSTACK-6097:
--
Summary: [Automation] : test_volumes.pyfails with error as Failed
to attach volume: TestDiskServ to VM:VM ID; Failed to attach volume for uuid:
Volume uuid due to You attempted an operation on a VM that was not in an
appropriate power state at the time;
Key: CLOUDSTACK-6097
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6097
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: marvin
Affects Versions: 4.2.0
Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server
release 6.4 (Santiago)
Reporter: Dhananjay D Pathak
Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt
Marvin Test test_volumes.py fails with Error as described bellow (log files are
attached):
Test Volume attach/detach to VM (5 data volumes) ... ERROR
Test Attach volumes (max capacity) ... ERROR
Test attach volumes (more than max) to an instance ... ok
Test Volumes and ISO attach ... ERROR
Test custom disk sizes beyond range ... ok
Attach a created Volume to a Running VM ... ok
Detach a Volume attached to a VM ... ok
Delete a Volume unattached to an VM ... ok
Create a volume under a non-root domain as non-root-domain user ... ERROR
==
ERROR: Test Volume attach/detach to VM (5 data volumes)
--
Traceback (most recent call last):
File /DataDisk/temp/cloudstack/test/integration/component/test_volumes.py,
line 520, in test_01_volume_attach_detach
volume
File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py,
line 543, in attach_volume
return apiclient.attachVolume(cmd)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1483, in attachVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
line 280, in marvinRequest
response = self.poll(asyncJobId, response_type)
File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
line 86, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
530, errortext : uFailed to attach volume: TestDiskServ to VM:
ecd07768-df22-468a-8023-7f922564e9f5; Failed to attach volume for uuid:
1621ee3f-650d-4b25-a125-13a83aae4912 due to You attempted an operation on a VM
that was not in an appropriate power state at the time; for example, you
attempted to start a VM that was already running. The parameters returned are
the VM's handle, and the expected and actual VM state at the time of the call.}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6098) [Automation] : test_tags.py fails with error as Exception during cleanup : Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext : u'Command failed due
Dhananjay D Pathak created CLOUDSTACK-6098:
--
Summary: [Automation] : test_tags.py fails with error as Exception
during cleanup : Execute cmd: asyncquery failed, due to: {errorcode : 530,
errortext : u'Command failed due to Internal Server Error'}
Key: CLOUDSTACK-6098
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6098
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: marvin
Affects Versions: 4.2.0
Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server
release 6.4 (Santiago)
Reporter: Dhananjay D Pathak
Test Create tag on LB rule and remove the LB rule ... FAIL
ERROR
Test Create tag on nat rule and remove the nat rule ... FAIL
ERROR
Test Create tag on firewall rule and remove the firewall rule ... ok
Test Create tag on vpn and remove the vpn ... SKIP: VPN resource tags are
unsupported in 4.0
Test creation, listing and deletion tags on UserVM ... ok
Test creation, listing and deletion tag on templates ... ok
Test creation, listing and deletion tags on ISO ... ok
Test creation, listing and deletion tagson volume ... ok
Test creation, listing and deletion tag son snapshot ... ok
Testcreation, listing and deletion tags on guest network ... ok
Test migration of a tagged vm and delete the tag ... ERROR
Test to verify that tags are not case sensitive ... ERROR
Test multiple tags and with special characters on same machine ... ERROR
Test creation, listing and deletion tags on projects ... ok
Test Query the tags from other account ... ok
Test Query the tags from admin account ... ok
Test listAPI with invalid tags parameter ... ERROR
Test deletion and addition of same tag on a resource. ... ERROR
Test creation of same tag on multiple resources ... ERROR
Test creation of tag on stopped vm. ... ERROR
Test creation of tag on stopped vm. ... ERROR
==
ERROR: Test Create tag on LB rule and remove the LB rule
--
Traceback (most recent call last):
File /DataDisk/temp/cloudstack/test/integration/component/test_tags.py,
line 264, in tearDown
raise Exception(Warning: Exception during cleanup : %s % e)
Exception: Warning: Exception during cleanup : Execute cmd: asyncquery failed,
due to: {errorcode : 530, errortext : u'Command failed due to Internal Server
Error'}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6098) [Automation] : test_tags.py fails with error as Exception during cleanup : Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext : u'Command failed due
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dhananjay D Pathak updated CLOUDSTACK-6098:
---
Description:
Marvin Test test_tags.py fails with Error as described bellow (log files are
attached):
Test Create tag on LB rule and remove the LB rule ... FAIL
ERROR
Test Create tag on nat rule and remove the nat rule ... FAIL
ERROR
Test Create tag on firewall rule and remove the firewall rule ... ok
Test Create tag on vpn and remove the vpn ... SKIP: VPN resource tags are
unsupported in 4.0
Test creation, listing and deletion tags on UserVM ... ok
Test creation, listing and deletion tag on templates ... ok
Test creation, listing and deletion tags on ISO ... ok
Test creation, listing and deletion tagson volume ... ok
Test creation, listing and deletion tag son snapshot ... ok
Testcreation, listing and deletion tags on guest network ... ok
Test migration of a tagged vm and delete the tag ... ERROR
Test to verify that tags are not case sensitive ... ERROR
Test multiple tags and with special characters on same machine ... ERROR
Test creation, listing and deletion tags on projects ... ok
Test Query the tags from other account ... ok
Test Query the tags from admin account ... ok
Test listAPI with invalid tags parameter ... ERROR
Test deletion and addition of same tag on a resource. ... ERROR
Test creation of same tag on multiple resources ... ERROR
Test creation of tag on stopped vm. ... ERROR
Test creation of tag on stopped vm. ... ERROR
==
ERROR: Test Create tag on LB rule and remove the LB rule
--
Traceback (most recent call last):
File /DataDisk/temp/cloudstack/test/integration/component/test_tags.py,
line 264, in tearDown
raise Exception(Warning: Exception during cleanup : %s % e)
Exception: Warning: Exception during cleanup : Execute cmd: asyncquery failed,
due to: {errorcode : 530, errortext : u'Command failed due to Internal Server
Error'}
=
ERROR: Test to verify that tags are not case sensitive
--
Traceback (most recent call last):
File /DataDisk/temp/cloudstack/test/integration/component/test_tags.py,
line 1548, in test_13_tag_case_insensitive
tags={'region': 'India'}
File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py,
line 3019, in create
return Tag(apiclient.createTags(cmd).__dict__)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 2103, in createTags
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
line 280, in marvinRequest
response = self.poll(asyncJobId, response_type)
File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
line 86, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
530, errortext : u'Entity already exists: '}
was:
Test Create tag on LB rule and remove the LB rule ... FAIL
ERROR
Test Create tag on nat rule and remove the nat rule ... FAIL
ERROR
Test Create tag on firewall rule and remove the firewall rule ... ok
Test Create tag on vpn and remove the vpn ... SKIP: VPN resource tags are
unsupported in 4.0
Test creation, listing and deletion tags on UserVM ... ok
Test creation, listing and deletion tag on templates ... ok
Test creation, listing and deletion tags on ISO ... ok
Test creation, listing and deletion tagson volume ... ok
Test creation, listing and deletion tag son snapshot ... ok
Testcreation, listing and deletion tags on guest network ... ok
Test migration of a tagged vm and delete the tag ... ERROR
Test to verify that tags are not case sensitive ... ERROR
Test multiple tags and with special characters on same machine ... ERROR
Test creation, listing and deletion tags on projects ... ok
Test Query the tags from other account ... ok
Test Query the tags from admin account ... ok
Test listAPI with invalid tags parameter ... ERROR
Test deletion and addition of same tag on a resource. ... ERROR
Test creation of same tag on multiple resources ... ERROR
Test creation of tag on stopped vm. ... ERROR
Test creation of tag on stopped vm. ... ERROR
==
ERROR: Test Create tag on LB rule and remove the LB rule
--
Traceback (most recent call last):
File /DataDisk/temp/cloudstack/test/integration/component/test_tags.py,
line 264, in tearDown
raise Exception(Warning: Exception during cleanup : %s % e)
Exception: Warning:
[jira] [Created] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPoin
Bharat Kumar created CLOUDSTACK-6099: Summary: live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPointerException Key: CLOUDSTACK-6099 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Bharat Kumar Assignee: Bharat Kumar Steps to reproduce === 1-Prepare CS setup with xen 6.2 ,two host in a cluster 2-create a custom service offering 3-deploy a vm with custom service offering 4-try to migrate vm Expected = vm should get migrate successfully Actual == Migrate vm is failing with NPE observation === migrate vm is working fine for vms deployed with regular compute offering Log === 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize : 115238502400, askingSize : 0, allocated disable threshold: 0.85 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator returning 1 suitable storage pools 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to check for allocation: [Host[-4-Routing]] 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation after prioritization: [Host[-4-Routing]] 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing api command: findHostsForMigration java.lang.NullPointerException at com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) at com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) at com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy210.listHostsForMigrationOfVM(Unknown Source) at org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at
[jira] [Updated] (CLOUDSTACK-6098) [Automation] : test_tags.py fails with error as Exception during cleanup : Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext : u'Command failed due
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dhananjay D Pathak updated CLOUDSTACK-6098:
---
Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt
Log files for execution of test_tags.py are attached.
[Automation] : test_tags.py fails with error as Exception during cleanup :
Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
u'Command failed due to Internal Server Error'}
Key: CLOUDSTACK-6098
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6098
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: marvin
Affects Versions: 4.2.0
Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server
release 6.4 (Santiago)
Reporter: Dhananjay D Pathak
Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt
Marvin Test test_tags.py fails with Error as described bellow (log files are
attached):
Test Create tag on LB rule and remove the LB rule ... FAIL
ERROR
Test Create tag on nat rule and remove the nat rule ... FAIL
ERROR
Test Create tag on firewall rule and remove the firewall rule ... ok
Test Create tag on vpn and remove the vpn ... SKIP: VPN resource tags are
unsupported in 4.0
Test creation, listing and deletion tags on UserVM ... ok
Test creation, listing and deletion tag on templates ... ok
Test creation, listing and deletion tags on ISO ... ok
Test creation, listing and deletion tagson volume ... ok
Test creation, listing and deletion tag son snapshot ... ok
Testcreation, listing and deletion tags on guest network ... ok
Test migration of a tagged vm and delete the tag ... ERROR
Test to verify that tags are not case sensitive ... ERROR
Test multiple tags and with special characters on same machine ... ERROR
Test creation, listing and deletion tags on projects ... ok
Test Query the tags from other account ... ok
Test Query the tags from admin account ... ok
Test listAPI with invalid tags parameter ... ERROR
Test deletion and addition of same tag on a resource. ... ERROR
Test creation of same tag on multiple resources ... ERROR
Test creation of tag on stopped vm. ... ERROR
Test creation of tag on stopped vm. ... ERROR
==
ERROR: Test Create tag on LB rule and remove the LB rule
--
Traceback (most recent call last):
File /DataDisk/temp/cloudstack/test/integration/component/test_tags.py,
line 264, in tearDown
raise Exception(Warning: Exception during cleanup : %s % e)
Exception: Warning: Exception during cleanup : Execute cmd: asyncquery
failed, due to: {errorcode : 530, errortext : u'Command failed due to
Internal Server Error'}
=
ERROR: Test to verify that tags are not case sensitive
--
Traceback (most recent call last):
File /DataDisk/temp/cloudstack/test/integration/component/test_tags.py,
line 1548, in test_13_tag_case_insensitive
tags={'region': 'India'}
File
/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line
3019, in create
return Tag(apiclient.createTags(cmd).__dict__)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 2103, in createTags
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
280, in marvinRequest
response = self.poll(asyncJobId, response_type)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
86, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
530, errortext : u'Entity already exists: '}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Issue Comment Deleted] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-6099: - Comment: was deleted (was: pushed the fix in the internal 4.3 http://git-ccp.citrix.com/cgit/internal-cloudstack.git/commit/?h=4.3id=f7a6749c151f330cb7f13bd6fc8671341cd9e9e5) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPointerException - Key: CLOUDSTACK-6099 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Reporter: Bharat Kumar Assignee: Bharat Kumar Steps to reproduce === 1-Prepare CS setup with xen 6.2 ,two host in a cluster 2-create a custom service offering 3-deploy a vm with custom service offering 4-try to migrate vm Expected = vm should get migrate successfully Actual == Migrate vm is failing with NPE observation === migrate vm is working fine for vms deployed with regular compute offering Log === 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize : 115238502400, askingSize : 0, allocated disable threshold: 0.85 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator returning 1 suitable storage pools 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to check for allocation: [Host[-4-Routing]] 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation after prioritization: [Host[-4-Routing]] 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing api command: findHostsForMigration java.lang.NullPointerException at com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) at com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) at com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy210.listHostsForMigrationOfVM(Unknown Source) at org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at
[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900376#comment-13900376 ] Bharat Kumar commented on CLOUDSTACK-6099: -- pushed the fix in the internal 4.3 http://git-ccp.citrix.com/cgit/internal-cloudstack.git/commit/?h=4.3id=f7a6749c151f330cb7f13bd6fc8671341cd9e9e5 live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPointerException - Key: CLOUDSTACK-6099 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Reporter: Bharat Kumar Assignee: Bharat Kumar Steps to reproduce === 1-Prepare CS setup with xen 6.2 ,two host in a cluster 2-create a custom service offering 3-deploy a vm with custom service offering 4-try to migrate vm Expected = vm should get migrate successfully Actual == Migrate vm is failing with NPE observation === migrate vm is working fine for vms deployed with regular compute offering Log === 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize : 115238502400, askingSize : 0, allocated disable threshold: 0.85 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator returning 1 suitable storage pools 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to check for allocation: [Host[-4-Routing]] 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation after prioritization: [Host[-4-Routing]] 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing api command: findHostsForMigration java.lang.NullPointerException at com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) at com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) at com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy210.listHostsForMigrationOfVM(Unknown Source) at org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at
[jira] [Resolved] (CLOUDSTACK-5680) Contrail:MS:API: Contrail DHCP fails with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar resolved CLOUDSTACK-5680. Resolution: Fixed Fix Version/s: 4.2.1 Will be fixed when CLOUDSTACK-5681. gets addressed. Manually edit DB as workaround. Contrail:MS:API: Contrail DHCP fails with exception --- Key: CLOUDSTACK-5680 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5680 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Contrail, Management Server Affects Versions: 4.2.0 Environment: Contrail Reporter: Parth Jagirdar Fix For: 4.2.1 Instance creation succeeds but IP doesn't get assigned. 2013-12-27 17:00:53,915 INFO [contrail.api.ApiConnector] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Response Status: HTTP/1.1 503 Service Unavailable 2013-12-27 17:00:53,915 ERROR [contrail.api.ApiConnector] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) create api request failed: Service Unavailable 2013-12-27 17:00:53,915 ERROR [contrail.api.ApiConnector] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Failure message: Virtual-Network(default-domain:default-project:contrail) has no defined subnet(s) 2013-12-27 17:00:53,916 WARN [contrail.management.ContrailGuru] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) virtual-machine update com.cloud.exception.InternalErrorException: Unable to create instance-ip i-2-3036-VM-0 at net.juniper.contrail.model.InstanceIpModel.update(InstanceIpModel.java:99) at net.juniper.contrail.model.VMInterfaceModel.update(VMInterfaceModel.java:227) at net.juniper.contrail.model.VirtualMachineModel.update(VirtualMachineModel.java:327) at net.juniper.contrail.management.ContrailGuru.reserve(ContrailGuru.java:228) at com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:2157) at com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:2127) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:886) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) 2013-12-27 17:00:53,920 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Changing active number of nics for network id=215 on 1 2013-12-27 17:00:53,930 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Asking ContrailElementImpl_EnhancerByCloudStack_749d004 to prepare for Nic[12138-3036-c0945234-c3a2-451b-ae04-f465478eee1e-null] 2013-12-27 17:00:53,930 DEBUG [contrail.management.ContrailElement] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) NetworkElement prepare: contrail, traffic type: Guest 2013-12-27 17:00:53,930 DEBUG [contrail.management.ContrailElement] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) ignore network contrail 2013-12-27 17:00:53,936 DEBUG [cloud.network.NetworkModelImpl] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Service SecurityGroup is not supported in the network id=215 2013-12-27 17:00:53,937 DEBUG
[jira] [Closed] (CLOUDSTACK-5680) Contrail:MS:API: Contrail DHCP fails with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-5680. -- Contrail:MS:API: Contrail DHCP fails with exception --- Key: CLOUDSTACK-5680 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5680 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Contrail, Management Server Affects Versions: 4.2.0 Environment: Contrail Reporter: Parth Jagirdar Fix For: 4.2.1 Instance creation succeeds but IP doesn't get assigned. 2013-12-27 17:00:53,915 INFO [contrail.api.ApiConnector] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Response Status: HTTP/1.1 503 Service Unavailable 2013-12-27 17:00:53,915 ERROR [contrail.api.ApiConnector] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) create api request failed: Service Unavailable 2013-12-27 17:00:53,915 ERROR [contrail.api.ApiConnector] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Failure message: Virtual-Network(default-domain:default-project:contrail) has no defined subnet(s) 2013-12-27 17:00:53,916 WARN [contrail.management.ContrailGuru] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) virtual-machine update com.cloud.exception.InternalErrorException: Unable to create instance-ip i-2-3036-VM-0 at net.juniper.contrail.model.InstanceIpModel.update(InstanceIpModel.java:99) at net.juniper.contrail.model.VMInterfaceModel.update(VMInterfaceModel.java:227) at net.juniper.contrail.model.VirtualMachineModel.update(VirtualMachineModel.java:327) at net.juniper.contrail.management.ContrailGuru.reserve(ContrailGuru.java:228) at com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:2157) at com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:2127) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:886) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) 2013-12-27 17:00:53,920 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Changing active number of nics for network id=215 on 1 2013-12-27 17:00:53,930 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Asking ContrailElementImpl_EnhancerByCloudStack_749d004 to prepare for Nic[12138-3036-c0945234-c3a2-451b-ae04-f465478eee1e-null] 2013-12-27 17:00:53,930 DEBUG [contrail.management.ContrailElement] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) NetworkElement prepare: contrail, traffic type: Guest 2013-12-27 17:00:53,930 DEBUG [contrail.management.ContrailElement] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) ignore network contrail 2013-12-27 17:00:53,936 DEBUG [cloud.network.NetworkModelImpl] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Service SecurityGroup is not supported in the network id=215 2013-12-27 17:00:53,937 DEBUG [contrail.management.ContrailGuru] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) update NicProfile 12138 on contrail 2013-12-27
[jira] [Resolved] (CLOUDSTACK-5777) Contrail:MS: Rebooting Xen host results in disconnected SR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar resolved CLOUDSTACK-5777. Resolution: Fixed Fix Version/s: 4.3.0 Not seen in 4.3 Contrail:MS: Rebooting Xen host results in disconnected SR -- Key: CLOUDSTACK-5777 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5777 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail, XenServer Affects Versions: 4.2.0 Environment: Contrail, Xen 6.1 Reporter: Parth Jagirdar Priority: Blocker Fix For: 4.3.0 Reboot a host and SR results in disconnected state. This was also observed after installing Contrail RPM's on Xen host. Admin can manually repair SR from Xen-center. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5682) Contrail:MS: Sync virtual Machines fails with exception.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900584#comment-13900584
]
Parth Jagirdar commented on CLOUDSTACK-5682:
Observed in 4.3 as well
Contrail:MS: Sync virtual Machines fails with exception.
Key: CLOUDSTACK-5682
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5682
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, Management Server
Affects Versions: 4.2.0
Environment: Contrail
Reporter: Parth Jagirdar
Priority: Critical
2013-12-30 11:14:50,888 WARN [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync virtual-machines
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
net.juniper.contrail.management.DBSyncGeneric.equal(DBSyncGeneric.java:136)
at
net.juniper.contrail.management.DBSyncGeneric.syncCollections(DBSyncGeneric.java:237)
at
net.juniper.contrail.management.DBSyncGeneric.syncGeneric(DBSyncGeneric.java:280)
at
net.juniper.contrail.management.ServerDBSyncImpl.syncVirtualMachine(ServerDBSyncImpl.java:649)
at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
net.juniper.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:95)
at
net.juniper.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:123)
at
net.juniper.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:456)
at
net.juniper.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:473)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: java.lang.NullPointerException
at
net.juniper.contrail.management.ServerDBSyncImpl.buildNicResources(ServerDBSyncImpl.java:766)
at
net.juniper.contrail.management.ServerDBSyncImpl.equalVirtualMachine(ServerDBSyncImpl.java:789)
at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
... 15 more
2013-12-30 11:14:50,889 INFO [contrail.management.ServerDBSync]
(DBSyncTimer:null) out of sync detected: VirtualMachine
2013-12-30 11:14:50,889 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check finish: VirtualMachine
2013-12-30 11:14:50,889 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check start: ServiceInstance
2013-12-30 11:14:50,889 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Request: GET, /service-instances
2013-12-30 11:14:50,892 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2013-12-30 11:14:50,892 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check finish: ServiceInstance
2013-12-30 11:14:50,892 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check start: FloatingIp
2013-12-30 11:14:50,903 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Request: POST, /fqname-to-id, {type:fl
oating-ip-pool,fq_name:[default-domain,default-project,__default_Public__,PublicIpPool]}
2013-12-30 11:14:50,906 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 404 Not Found
2013-12-30 11:14:50,906 DEBUG [contrail.management.DBSyncGeneric]
(DBSyncTimer:null) Generic db sync : FloatingIp
2013-12-30 11:14:50,906 DEBUG [contrail.management.DBSyncGeneric]
(DBSyncTimer:null) Sync state checking statsFloatingIp
: create: 0, delete: 0, equal: 0, diff:0
2013-12-30 11:14:50,906 DEBUG [contrail.management.DBSyncGeneric]
(DBSyncTimer:null) DB and VNC objects are in sync : Flo
atingIp
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5777) Contrail:MS: Rebooting Xen host results in disconnected SR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-5777. -- Contrail:MS: Rebooting Xen host results in disconnected SR -- Key: CLOUDSTACK-5777 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5777 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail, XenServer Affects Versions: 4.2.0 Environment: Contrail, Xen 6.1 Reporter: Parth Jagirdar Priority: Blocker Fix For: 4.3.0 Reboot a host and SR results in disconnected state. This was also observed after installing Contrail RPM's on Xen host. Admin can manually repair SR from Xen-center. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5775) Contrail:MS: Stop VM fails with exception; and expunges it from the host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar resolved CLOUDSTACK-5775. Resolution: Fixed Fixed in 4.3 Contrail:MS: Stop VM fails with exception; and expunges it from the host Key: CLOUDSTACK-5775 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5775 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Contrail, Management Server Affects Versions: 4.2.0 Environment: Contrail Reporter: Parth Jagirdar Priority: Blocker Stop VM fails with exception, On ACS UI VM remains stuck in stopping state. On host VM does gets stopped. and eventually expunged. 2014-01-03 14:57:27,579 DEBUG [contrail.management.EventUtils$EventInterceptor] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) interceptException 2014-01-03 14:57:27,579 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StopVMCmd java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.finalizeStop(UserVmManagerImpl.java:3271) at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1253) at com.cloud.vm.VirtualMachineManagerImpl.stop(VirtualMachineManagerImpl.java:1039) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.stopvirtualmachine(VMEntityManagerImpl.java:251) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.stop(VirtualMachineEntityImpl.java:214) at com.cloud.vm.UserVmManagerImpl.stopVirtualMachine(UserVmManagerImpl.java:3228) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.StopVMCmd.execute(StopVMCmd.java:117) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) 2014-01-03 14:57:27,581 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) Complete async job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: null 2014-01-03 14:57:30,131 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null) ===START=== 10.215.2.19 -- GET command=queryAsyncJobResultjobId=e893cbca-59e9-4ee1-bce3-cc918fb829f1response=jsonsessionkey=lhySlIIDUvWHZ5yKeVK55FnVmbc%3D_=1388789861991 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5775) Contrail:MS: Stop VM fails with exception; and expunges it from the host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar resolved CLOUDSTACK-5775. Resolution: Fixed fixed in 4.3 Contrail:MS: Stop VM fails with exception; and expunges it from the host Key: CLOUDSTACK-5775 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5775 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Contrail, Management Server Affects Versions: 4.2.0 Environment: Contrail Reporter: Parth Jagirdar Priority: Blocker Stop VM fails with exception, On ACS UI VM remains stuck in stopping state. On host VM does gets stopped. and eventually expunged. 2014-01-03 14:57:27,579 DEBUG [contrail.management.EventUtils$EventInterceptor] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) interceptException 2014-01-03 14:57:27,579 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StopVMCmd java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.finalizeStop(UserVmManagerImpl.java:3271) at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1253) at com.cloud.vm.VirtualMachineManagerImpl.stop(VirtualMachineManagerImpl.java:1039) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.stopvirtualmachine(VMEntityManagerImpl.java:251) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.stop(VirtualMachineEntityImpl.java:214) at com.cloud.vm.UserVmManagerImpl.stopVirtualMachine(UserVmManagerImpl.java:3228) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.StopVMCmd.execute(StopVMCmd.java:117) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) 2014-01-03 14:57:27,581 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) Complete async job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: null 2014-01-03 14:57:30,131 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null) ===START=== 10.215.2.19 -- GET command=queryAsyncJobResultjobId=e893cbca-59e9-4ee1-bce3-cc918fb829f1response=jsonsessionkey=lhySlIIDUvWHZ5yKeVK55FnVmbc%3D_=1388789861991 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5775) Contrail:MS: Stop VM fails with exception; and expunges it from the host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-5775. -- Contrail:MS: Stop VM fails with exception; and expunges it from the host Key: CLOUDSTACK-5775 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5775 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Contrail, Management Server Affects Versions: 4.2.0 Environment: Contrail Reporter: Parth Jagirdar Priority: Blocker Stop VM fails with exception, On ACS UI VM remains stuck in stopping state. On host VM does gets stopped. and eventually expunged. 2014-01-03 14:57:27,579 DEBUG [contrail.management.EventUtils$EventInterceptor] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) interceptException 2014-01-03 14:57:27,579 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StopVMCmd java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.finalizeStop(UserVmManagerImpl.java:3271) at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1253) at com.cloud.vm.VirtualMachineManagerImpl.stop(VirtualMachineManagerImpl.java:1039) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.stopvirtualmachine(VMEntityManagerImpl.java:251) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.stop(VirtualMachineEntityImpl.java:214) at com.cloud.vm.UserVmManagerImpl.stopVirtualMachine(UserVmManagerImpl.java:3228) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.StopVMCmd.execute(StopVMCmd.java:117) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) 2014-01-03 14:57:27,581 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) Complete async job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: null 2014-01-03 14:57:30,131 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null) ===START=== 10.215.2.19 -- GET command=queryAsyncJobResultjobId=e893cbca-59e9-4ee1-bce3-cc918fb829f1response=jsonsessionkey=lhySlIIDUvWHZ5yKeVK55FnVmbc%3D_=1388789861991 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (CLOUDSTACK-5775) Contrail:MS: Stop VM fails with exception; and expunges it from the host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar reopened CLOUDSTACK-5775: Contrail:MS: Stop VM fails with exception; and expunges it from the host Key: CLOUDSTACK-5775 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5775 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Contrail, Management Server Affects Versions: 4.2.0 Environment: Contrail Reporter: Parth Jagirdar Priority: Blocker Stop VM fails with exception, On ACS UI VM remains stuck in stopping state. On host VM does gets stopped. and eventually expunged. 2014-01-03 14:57:27,579 DEBUG [contrail.management.EventUtils$EventInterceptor] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) interceptException 2014-01-03 14:57:27,579 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StopVMCmd java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.finalizeStop(UserVmManagerImpl.java:3271) at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1253) at com.cloud.vm.VirtualMachineManagerImpl.stop(VirtualMachineManagerImpl.java:1039) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.stopvirtualmachine(VMEntityManagerImpl.java:251) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.stop(VirtualMachineEntityImpl.java:214) at com.cloud.vm.UserVmManagerImpl.stopVirtualMachine(UserVmManagerImpl.java:3228) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.StopVMCmd.execute(StopVMCmd.java:117) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) 2014-01-03 14:57:27,581 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-34:job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ]) Complete async job-43 = [ e893cbca-59e9-4ee1-bce3-cc918fb829f1 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: null 2014-01-03 14:57:30,131 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null) ===START=== 10.215.2.19 -- GET command=queryAsyncJobResultjobId=e893cbca-59e9-4ee1-bce3-cc918fb829f1response=jsonsessionkey=lhySlIIDUvWHZ5yKeVK55FnVmbc%3D_=1388789861991 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5776) Contrail:MS: Reboot host remains in UP state on ACS UI.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar resolved CLOUDSTACK-5776. Resolution: Fixed Not observed in 4.3 Contrail:MS: Reboot host remains in UP state on ACS UI. --- Key: CLOUDSTACK-5776 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5776 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail, XenServer Affects Versions: 4.2.0 Environment: Contrail. Reporter: Parth Jagirdar Host remains in UP state on UI. Although User VMs and Systems VM are marked in stopped state. Host info should be synced with ACS appropriately. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5776) Contrail:MS: Reboot host remains in UP state on ACS UI.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-5776. -- Contrail:MS: Reboot host remains in UP state on ACS UI. --- Key: CLOUDSTACK-5776 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5776 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail, XenServer Affects Versions: 4.2.0 Environment: Contrail. Reporter: Parth Jagirdar Host remains in UP state on UI. Although User VMs and Systems VM are marked in stopped state. Host info should be synced with ACS appropriately. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5967) Virtual router in OVS network fails to start with error from XenServer: VM_REQUIRES_NETWORK
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900641#comment-13900641
]
Paul Angus commented on CLOUDSTACK-5967:
Hi,
Using 4.3 RC4 I can now create an instance on an OVS but if I try to migrate
the instance to another VM it fails with the VM_REQUIRES_NETWORK error.
Attempting to manually using XenCenter says Cannot see required Network
although OVSTunel517 appears to be on both servers.
m.cloud.utils.exception.CloudRuntimeException: Unable to migrate VM(i-2-7-VM)
from host(05b443f9-8f69-4855-a6e0-8018afe5a551) due to Task failed! Task
record: uuid: c4682573-5c30-ae62-6163-32cda5ae75f5
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Feb 13 17:25:39 GMT 2014
finished: Thu Feb 13 17:25:39 GMT 2014
status: failure
residentOn: com.xensource.xenapi.Host@ad885ef9
progress: 1.0
type: none/
result:
errorInfo: [VM_REQUIRES_NETWORK,
OpaqueRef:754c9612-d1be-1c26-7096-bc71b423c652,
OpaqueRef:20d04b69-b3f7-3590-25da-85d547d3327c]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Regards,
Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
paul.an...@shapeblue.com
Virtual router in OVS network fails to start with error from XenServer:
VM_REQUIRES_NETWORK
---
Key: CLOUDSTACK-5967
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5967
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: CloudStack 4.3 with XenServer 6.2
GRE tunnel based advanced network
Reporter: Paul Angus
Assignee: Murali Reddy
Priority: Blocker
Fix For: 4.3.0
Virtual Router start fails with error VM_REQUIRES_NETWORK when using GRE
tunnel encapsulation.
Tunnel is created on XenServer (OVSTunnel194)
virtual router appears briefly then dissappears and insufficient capacity
error is returned by cloudstack
2014-01-28 16:17:09,829 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-12:ctx-3a256248 ctx-58300764) Creating monitoring services on
VM[DomainRouter|r-12-VM] start...
2014-01-28 16:17:09,842 DEBUG [c.c.a.t.Request] (Job-Executor-12:ctx-3a256248
ctx-58300764) Seq 2-232063002: Sending { Cmd , MgmtId: 345049362040, via:
2(localhost.localdomain), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StartCommand:{vm:{id:12,name:r-12-VM,bootloader:PyGrub,type:DomainRouter,cpus:1,minSpeed:125,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:x86_64,os:Debian
GNU/Linux 7(32-bit),bootArgs: template=domP name=r-12-VM
eth2ip=192.168.1.53 eth2mask=255.255.255.0 gateway=192.168.1.254
eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs2cloud.internal
dhcprange=10.1.1.1 eth1ip=169.254.0.255 eth1mask=255.255.0.0 type=router
disable_rp_filter=true
[jira] [Commented] (CLOUDSTACK-5967) Virtual router in OVS network fails to start with error from XenServer: VM_REQUIRES_NETWORK
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900642#comment-13900642
]
Paul Angus commented on CLOUDSTACK-5967:
Hi,
Using 4.3 RC4 I can now create an instance on an OVS but if I try to migrate
the instance to another VM it fails with the VM_REQUIRES_NETWORK error.
Attempting to manually using XenCenter says Cannot see required Network
although OVSTunel517 appears to be on both servers.
m.cloud.utils.exception.CloudRuntimeException: Unable to migrate VM(i-2-7-VM)
from host(05b443f9-8f69-4855-a6e0-8018afe5a551) due to Task failed! Task
record: uuid: c4682573-5c30-ae62-6163-32cda5ae75f5
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Feb 13 17:25:39 GMT 2014
finished: Thu Feb 13 17:25:39 GMT 2014
status: failure
residentOn: com.xensource.xenapi.Host@ad885ef9
progress: 1.0
type: none/
result:
errorInfo: [VM_REQUIRES_NETWORK,
OpaqueRef:754c9612-d1be-1c26-7096-bc71b423c652,
OpaqueRef:20d04b69-b3f7-3590-25da-85d547d3327c]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Regards,
Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
paul.an...@shapeblue.com
Virtual router in OVS network fails to start with error from XenServer:
VM_REQUIRES_NETWORK
---
Key: CLOUDSTACK-5967
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5967
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: CloudStack 4.3 with XenServer 6.2
GRE tunnel based advanced network
Reporter: Paul Angus
Assignee: Murali Reddy
Priority: Blocker
Fix For: 4.3.0
Virtual Router start fails with error VM_REQUIRES_NETWORK when using GRE
tunnel encapsulation.
Tunnel is created on XenServer (OVSTunnel194)
virtual router appears briefly then dissappears and insufficient capacity
error is returned by cloudstack
2014-01-28 16:17:09,829 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-12:ctx-3a256248 ctx-58300764) Creating monitoring services on
VM[DomainRouter|r-12-VM] start...
2014-01-28 16:17:09,842 DEBUG [c.c.a.t.Request] (Job-Executor-12:ctx-3a256248
ctx-58300764) Seq 2-232063002: Sending { Cmd , MgmtId: 345049362040, via:
2(localhost.localdomain), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StartCommand:{vm:{id:12,name:r-12-VM,bootloader:PyGrub,type:DomainRouter,cpus:1,minSpeed:125,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:x86_64,os:Debian
GNU/Linux 7(32-bit),bootArgs: template=domP name=r-12-VM
eth2ip=192.168.1.53 eth2mask=255.255.255.0 gateway=192.168.1.254
eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs2cloud.internal
dhcprange=10.1.1.1 eth1ip=169.254.0.255 eth1mask=255.255.0.0 type=router
disable_rp_filter=true
[jira] [Created] (CLOUDSTACK-6100) second private gateway on same nicira based network gets sourcenat even when not specified
Daan Hoogland created CLOUDSTACK-6100: - Summary: second private gateway on same nicira based network gets sourcenat even when not specified Key: CLOUDSTACK-6100 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6100 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Daan Hoogland Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6100) second private gateway on same nicira based network gets sourcenat even when not specified
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland resolved CLOUDSTACK-6100. --- Resolution: Fixed fix submitted second private gateway on same nicira based network gets sourcenat even when not specified -- Key: CLOUDSTACK-6100 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6100 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Daan Hoogland Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelven Yang resolved CLOUDSTACK-6065. - Resolution: Fixed No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 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.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Assignee: Kelven Yang Priority: Critical Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900820#comment-13900820 ] ASF subversion and git services commented on CLOUDSTACK-6065: - Commit 1283919f02e2c4d2652ca18693b6cf2906b2263d in branch refs/heads/4.3-forward from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1283919 ] CLOUDSTACK-6065: Fix NPE problem caused by the lack of context setup in threads from agent manager thread pool No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 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.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Assignee: Kelven Yang Priority: Critical Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6101) Contrail:MS: Disable NAT on acquired IP results in exception
Parth Jagirdar created CLOUDSTACK-6101:
--
Summary: 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
Fix For: 4.3.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 Status: HTTP/1.1 400
Bad Request
2014-02-13 13:53:08,505 ERROR [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) create api request failed: Bad
Request
2014-02-13 13:53:08,508 ERROR [n.j.c.a.ApiConnector]
(Job-Executor-77:ctx-6e8167ac ctx-152aebc9) Failure message:
!DOCTYPE HTML PUBLIC
[jira] [Commented] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900941#comment-13900941 ] ASF subversion and git services commented on CLOUDSTACK-6065: - Commit adf4dd59270917b1607940d7064748bd438cbbcc in branch refs/heads/4.3 from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=adf4dd5 ] CLOUDSTACK-6065: Fix NPE problem caused by the lack of context setup in threads from agent manager thread pool (cherry picked from commit 1283919f02e2c4d2652ca18693b6cf2906b2263d) Signed-off-by: Animesh Chaturvedi anim...@apache.org No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 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.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Assignee: Kelven Yang Priority: Critical Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6089) resource tags show up in multiples
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900938#comment-13900938 ] ASF subversion and git services commented on CLOUDSTACK-6089: - Commit 1c640448df26ac97330705ee0af04fe024ec3150 in branch refs/heads/4.3 from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1c64044 ] CLOUDSTACK-6089: Implement equals() method for ResourceTagResponse so that the java Set can properly determine if a ResourceTagResponse is unique. This ensures we don't get duplicate resource tags showing up any time a UserVmResponse is crafted (which can be quite often due to the way the responses are crafted). (cherry picked from commit 06ae23710ddc3784939bcd499b7437c13495bb88) Signed-off-by: Animesh Chaturvedi anim...@apache.org resource tags show up in multiples -- Key: CLOUDSTACK-6089 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6089 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, Future, 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: Future, 4.3.0 Due to the way user_vm_view returns multiple rows when, for instance, a vm has multiple volumes, we're getting duplicate resource tags attached in all user vm responses. The NicResponse works around this by implementing an equals() method so that the Set containing Nics can enforce uniqueness, doing the same for resource tags. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6083) Missing cidrlist in 4.3 adv zone firewall
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900940#comment-13900940 ] ASF subversion and git services commented on CLOUDSTACK-6083: - Commit 88463cd10b3dae6af3168177355fd0ba92f87ecc in branch refs/heads/4.3 from [~jayapal] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=88463cd ] CLOUDSTACK-6083 corrected firewall rule cidr load issue (cherry picked from commit e8f93f28fc424c73156723d9b65b13c05dafc5a8) Signed-off-by: Animesh Chaturvedi anim...@apache.org Missing cidrlist in 4.3 adv zone firewall - Key: CLOUDSTACK-6083 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6083 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Environment: CentOS 6.5 HVs and mgmt, adv zone (without sg) Reporter: Nux Assignee: Jayapal Reddy Priority: Critical It's the first time I'm testing firewall in 4.3 Advanced zone (without SG) so please let me know if I'm missing something obvious; I notice the cidrlist is missing from the rules, both in UI and in cloudmonkey. If I create the rule from cloudmoneky it also doesn't register a cidrlist, so it doesn't seem to be UI's fault. This is what I see in the logs http://fpaste.org/75819/39203643/ when I create a rule. Anyone else experiencing this? Do note: This is a (until now successfull) upgrade from 4.2.1. The cidrs make it into the firewall_rules_cidrs table. I also checked inside the VR and while iptables does have rules for the ports I mentioned, the CIDRs are missing, too. See http://img.nux.ro/3Kk-Selection_050.png mycloudmonkey list firewallrules id=835dfc08-beab-458a-9c30-6b0b2b11f201 count = 1 firewallrule: id = 835dfc08-beab-458a-9c30-6b0b2b11f201 cidrlist = endport = 65535 ipaddress = 172.16.72.212 ipaddressid = f481629a-deb6-4413-b253-e8e98d8a303a networkid = c615df7c-3ea3-4138-a83c-d848e20fe1f6 protocol = tcp startport = 1 state = Active tags: -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6089) resource tags show up in multiples
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900939#comment-13900939 ] ASF subversion and git services commented on CLOUDSTACK-6089: - Commit 0ff152258eb62db09ba5cad2698a2e9d370fdd7c in branch refs/heads/4.3 from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0ff1522 ] CLOUDSTACK-6089: Use resource tag's key to determine match in equals() method for ResourceTagResponse (cherry picked from commit ed73e3e1b30c7c49c5dbfe8f2cac3d3dac85090e) Signed-off-by: Animesh Chaturvedi anim...@apache.org resource tags show up in multiples -- Key: CLOUDSTACK-6089 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6089 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, Future, 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: Future, 4.3.0 Due to the way user_vm_view returns multiple rows when, for instance, a vm has multiple volumes, we're getting duplicate resource tags attached in all user vm responses. The NicResponse works around this by implementing an equals() method so that the Set containing Nics can enforce uniqueness, doing the same for resource tags. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6102) Need of a field at Instance details volume details page, which should say, to which VM snapshot or volume snapshot we are pointing to.
rashid created CLOUDSTACK-6102: -- Summary: Need of a field at Instance details volume details page, which should say, to which VM snapshot or volume snapshot we are pointing to. Key: CLOUDSTACK-6102 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6102 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Snapshot, Volumes Reporter: rashid Priority: Minor Fix For: 4.4.0 As user revert to certain vm snapshot or volume snapshot, user should be able to see at VM details or volume details page, to which snapshot they have been reverted to successfully. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901120#comment-13901120 ] ASF subversion and git services commented on CLOUDSTACK-5674: - Commit c0d8b9e334021f398cbb0dfb5c2aca86b7717bea in branch refs/heads/marvin from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0d8b9e ] CLOUDSTACK-5674: getZoneForTests should return None if zone is NA in test_data.py [Automation]: Enhancements to accommodate multiple regression runs on a single CS server Key: CLOUDSTACK-5674 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5674 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, we will not be able to run multiple regression runs on a given CS server either sequentially\parallelly reason being few hard codings done at various places. 2. So, the idea is to run complete regression\automation test suites at one stretch on a given setup post deployDC. We deploy multiple zones with different hypervisor type in each zone. 3. Tests should cut down time and run across multiple zones with different hypervisor type in each zone, post deployment 3. The fixes and new changes should incorporate to take care to run suites parallelly if we wanted or sequentially for various test suites like vmware,xen,kvm etc on single CS machine without disturbing\redeploying and installing the new CS instance. Phase1: We will make framework\marvin changes. Phase2: Incorporate test module changes for these. Adding this ticket to track these changes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6103) vms with isos attached don't migrate
Marcus Sorensen created CLOUDSTACK-6103: --- Summary: vms with isos attached don't migrate Key: CLOUDSTACK-6103 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6103 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0, Future, 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0, 4.4.0 VMs with isos attached don't seem to provide the iso information with PrepareForMigrationCommand. This seems to be hypervisor-agnostic, though not all hypervisors may require it to be passed in preparation. Commit incoming... -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6095) [Automation] : test_vpc_network_pfrules.pyfails with error as AssertionError: Failed to SSH into VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhananjay D Pathak updated CLOUDSTACK-6095: --- Attachment: runinfo.txt results.txt failed_plus_exceptions.txt Similar issue is observed for other test test_vpc_offerings too, so updating here. Log files for execution of test_vpc_offerings.py are attached. [Automation] : test_vpc_network_pfrules.pyfails with error as AssertionError: Failed to SSH into VM Key: CLOUDSTACK-6095 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6095 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.2.0 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server release 6.4 (Santiago) Reporter: Dhananjay D Pathak Attachments: failed_plus_exceptions.txt, failed_plus_exceptions.txt, index.html, results.txt, results.txt, runinfo.txt, runinfo.txt Marvin Test test_vpc_network_pfrules.py fails with Error as described bellow (log files are attached): Test : Create VPC PF rules on acquired public ip when VpcVirtualRouter is stopped ... FAIL Test Create VPC PF rules on acquired public ip when VpcVirtualRouter is Running ... FAIL Test Create multiple VPC PF rules on acquired public ip in diff't networks when VpcVirtualRouter is stopped ... FAIL Test Create multiple VPC PF rules on acquired public ip in diff't networks when VpcVirtualRouter is running ... FAIL Test delete a PF rule in VPC when VpcVirtualRouter is Stopped ... FAIL Test delete a PF rule in VPC when VpcVirtualRouter is Running ... FAIL Test delete all PF rules in VPC when VpcVirtualRouter is Stopped ... FAIL Test delete all PF rules in VPC when VpcVirtualRouter is Running ... FAIL Test delete all PF rules in VPC across multiple networks when VpcVirtualRouter is Stopped ... FAIL Test delete all PF rules in VPC across multiple networks when VpcVirtualRouter is Running ... FAIL == FAIL: Test : Create VPC PF rules on acquired public ip when VpcVirtualRouter is stopped -- Traceback (most recent call last): File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_pfrules.py, line 508, in test_01_network_services_VPC_StopCreatePF self.check_ssh_into_vm(vm_1, public_ip_1, testnegative=False) File /DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_pfrules.py, line 328, in check_ssh_into_vm self.fail(Failed to SSH into VM - %s % (public_ip.ipaddress.ipaddress)) AssertionError: Failed to SSH into VM - 207.19.99.48 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6104) PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
Sateesh Chodapuneedi created CLOUDSTACK-6104: Summary: PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment Key: CLOUDSTACK-6104 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6104 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller, VMware Affects Versions: 4.4.0 Environment: CloudStack deployed over VMware ESXi hypervisor with Nexus 1000v as distributed virtual switch. Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.4.0 Currently PVLAN support is available in CloudStack deployment over VMware ESXi hypervisor for VMware dvSwitch only. This needs to be extended to Cisco Nexus 1000v as well. Code changes are required on resource front to ensure PVLAN setup/configuration done over Nexus 1000v switch in the same way as currently being done over VMware dvSwitch. FS - https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs+-+Functional+Specification+for+VMWare+integration+with+CloudStack Background of support of PVLAN in CloudStack :- https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+for+isolation+within+a+VLAN -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6103) vms with isos attached don't migrate
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901184#comment-13901184 ] ASF subversion and git services commented on CLOUDSTACK-6103: - Commit df77c4310a5020f4fc8df8309ada60d5e76ef893 in branch refs/heads/master from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=df77c43 ] CLOUDSTACK-6103: Pass VM iso information along with PrepareForMigrationCommand, so that destination hypervisor can mount pool. This further exposed an issue for KVM where iso was not getting cleaned up upon successful migration, fixed as well. vms with isos attached don't migrate Key: CLOUDSTACK-6103 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6103 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0, Future, 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0, 4.4.0 VMs with isos attached don't seem to provide the iso information with PrepareForMigrationCommand. This seems to be hypervisor-agnostic, though not all hypervisors may require it to be passed in preparation. Commit incoming... -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6103) vms with isos attached don't migrate
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901190#comment-13901190 ] ASF subversion and git services commented on CLOUDSTACK-6103: - Commit 76e019f717ca27f5124aebc9db3c5d807bb72868 in branch refs/heads/4.3-forward from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=76e019f ] CLOUDSTACK-6103: Pass VM iso information along with PrepareForMigrationCommand, so that destination hypervisor can mount pool. This further exposed an issue for KVM where iso was not getting cleaned up upon successful migration, fixed as well. vms with isos attached don't migrate Key: CLOUDSTACK-6103 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6103 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0, Future, 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0, 4.4.0 VMs with isos attached don't seem to provide the iso information with PrepareForMigrationCommand. This seems to be hypervisor-agnostic, though not all hypervisors may require it to be passed in preparation. Commit incoming... -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901191#comment-13901191 ] ASF subversion and git services commented on CLOUDSTACK-5674: - Commit f0eb184d8a5bf3412190468641fa3d887cfe7bb1 in branch refs/heads/marvin from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f0eb184 ] CLOUDSTACK-5674: Fix get_domain and remove dependency on ostype in get_template [Automation]: Enhancements to accommodate multiple regression runs on a single CS server Key: CLOUDSTACK-5674 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5674 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, we will not be able to run multiple regression runs on a given CS server either sequentially\parallelly reason being few hard codings done at various places. 2. So, the idea is to run complete regression\automation test suites at one stretch on a given setup post deployDC. We deploy multiple zones with different hypervisor type in each zone. 3. Tests should cut down time and run across multiple zones with different hypervisor type in each zone, post deployment 3. The fixes and new changes should incorporate to take care to run suites parallelly if we wanted or sequentially for various test suites like vmware,xen,kvm etc on single CS machine without disturbing\redeploying and installing the new CS instance. Phase1: We will make framework\marvin changes. Phase2: Incorporate test module changes for these. Adding this ticket to track these changes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6103) vms with isos attached don't migrate
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901194#comment-13901194 ] ASF subversion and git services commented on CLOUDSTACK-6103: - Commit bb01aad377e97b65dd31e4c4ba60d8a1297b25d9 in branch refs/heads/4.2 from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bb01aad ] CLOUDSTACK-6103: Pass VM iso information along with PrepareForMigrationCommand, so that destination hypervisor can mount pool. This further exposed an issue for KVM where iso was not getting cleaned up upon successful migration, fixed as well. vms with isos attached don't migrate Key: CLOUDSTACK-6103 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6103 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0, Future, 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0, 4.4.0 VMs with isos attached don't seem to provide the iso information with PrepareForMigrationCommand. This seems to be hypervisor-agnostic, though not all hypervisors may require it to be passed in preparation. Commit incoming... -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-6103) vms with isos attached don't migrate
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen closed CLOUDSTACK-6103. --- Resolution: Fixed Tested start/stop with iso, then migrate with iso, and without. vms with isos attached don't migrate Key: CLOUDSTACK-6103 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6103 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0, Future, 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0, 4.4.0 VMs with isos attached don't seem to provide the iso information with PrepareForMigrationCommand. This seems to be hypervisor-agnostic, though not all hypervisors may require it to be passed in preparation. Commit incoming... -- This message was sent by Atlassian JIRA (v6.1.5#6160)
