[jira] [Created] (CLOUDSTACK-7935) keep colons in the request to ACS
Remi Bergsma created CLOUDSTACK-7935: Summary: keep colons in the request to ACS Key: CLOUDSTACK-7935 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7935 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Cloudmonkey Reporter: Remi Bergsma Priority: Minor We run into an interesting issue with CloudMonkey today. Before 5.3 this worked, now it doesn't any more. Creating a private gateway on our SDN platform (lswitch instead of vlan id): (mccp_admin) > create privategateway vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4 vlan=lswitch:d3b79b6a-eb65-47f6-982f-e78f18f8b7b1 gateway=10.71.25.3 ipaddress=10.71.25.12 netmask=255.255.255.192 Returns: Error Error: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. In the CloudStack logs: s=10.71.25.12&netmask=255.255.255.192&networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4&response=json&signatureversion=3&vlan=lswitch%253Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1&vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e&signature=TuyC3d900X%2B88P6zJwz4NcN1RxY%3D 2014-11-17 14:32:26,178 DEBUG [c.c.n.v.VpcManagerImpl] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) Creating Private gateway for VPC [VPC [483-SBP_VPC_MDMS] 2014-11-17 14:32:26,185 ERROR [c.c.a.ApiServer] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) unhandled exception executing api command: createPrivateGateway com.cloud.utils.exception.CloudRuntimeException: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. It seems CloudMonkey replaces the ":" with "%3A" resulting in an invalid request. See this pull request for a solution that works: https://github.com/apache/cloudstack-cloudmonkey/pull/1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7935) keep colons in the request to ACS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-7935. > keep colons in the request to ACS > - > > Key: CLOUDSTACK-7935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Cloudmonkey >Reporter: Remi Bergsma >Priority: Minor > > We run into an interesting issue with CloudMonkey today. Before 5.3 this > worked, now it doesn't any more. > Creating a private gateway on our SDN platform (lswitch instead of vlan id): > (mccp_admin) > create privategateway > vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e > networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4 > vlan=lswitch:d3b79b6a-eb65-47f6-982f-e78f18f8b7b1 gateway=10.71.25.3 > ipaddress=10.71.25.12 netmask=255.255.255.192 > Returns: > Error Error: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an > unknown BroadcastDomainType. > In the CloudStack logs: > s=10.71.25.12&netmask=255.255.255.192&networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4&response=json&signatureversion=3&vlan=lswitch%253Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1&vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e&signature=TuyC3d900X%2B88P6zJwz4NcN1RxY%3D > 2014-11-17 14:32:26,178 DEBUG [c.c.n.v.VpcManagerImpl] > (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) Creating Private > gateway for VPC [VPC [483-SBP_VPC_MDMS] > 2014-11-17 14:32:26,185 ERROR [c.c.a.ApiServer] > (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) unhandled exception > executing api command: createPrivateGateway > com.cloud.utils.exception.CloudRuntimeException: string > 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown > BroadcastDomainType. > It seems CloudMonkey replaces the ":" with "%3A" resulting in an invalid > request. > See this pull request for a solution that works: > https://github.com/apache/cloudstack-cloudmonkey/pull/1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7935) keep colons in the request to ACS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-7935. -- Resolution: Fixed Fixed by: https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git;a=commitdiff;h=18feb8074e47042470185dc74744dc075e43a7b6 > keep colons in the request to ACS > - > > Key: CLOUDSTACK-7935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Cloudmonkey >Reporter: Remi Bergsma >Priority: Minor > > We run into an interesting issue with CloudMonkey today. Before 5.3 this > worked, now it doesn't any more. > Creating a private gateway on our SDN platform (lswitch instead of vlan id): > (mccp_admin) > create privategateway > vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e > networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4 > vlan=lswitch:d3b79b6a-eb65-47f6-982f-e78f18f8b7b1 gateway=10.71.25.3 > ipaddress=10.71.25.12 netmask=255.255.255.192 > Returns: > Error Error: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an > unknown BroadcastDomainType. > In the CloudStack logs: > s=10.71.25.12&netmask=255.255.255.192&networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4&response=json&signatureversion=3&vlan=lswitch%253Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1&vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e&signature=TuyC3d900X%2B88P6zJwz4NcN1RxY%3D > 2014-11-17 14:32:26,178 DEBUG [c.c.n.v.VpcManagerImpl] > (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) Creating Private > gateway for VPC [VPC [483-SBP_VPC_MDMS] > 2014-11-17 14:32:26,185 ERROR [c.c.a.ApiServer] > (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) unhandled exception > executing api command: createPrivateGateway > com.cloud.utils.exception.CloudRuntimeException: string > 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown > BroadcastDomainType. > It seems CloudMonkey replaces the ":" with "%3A" resulting in an invalid > request. > See this pull request for a solution that works: > https://github.com/apache/cloudstack-cloudmonkey/pull/1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7414) SSVM 4.4.0-6 fails to connect to NFS v3 and v4.1 shares
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329201#comment-14329201 ] Remi Bergsma commented on CLOUDSTACK-7414: -- Disable NFSv4 on Windows, it will then work with NFSv3 just fine. > SSVM 4.4.0-6 fails to connect to NFS v3 and v4.1 shares > --- > > Key: CLOUDSTACK-7414 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7414 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.4.0 > Environment: CloudStack v4.4 with SystemTemplate 4.4.0-6 > Deafult SSVM over Debian > Windows Storage Server 2012 with NFS running ver 3 or 4.1 > VMWare 5.5 >Reporter: Gaur Sunder >Priority: Critical > Labels: NFSv3, NFSv4.1, secondary_storage, ssvm > Original Estimate: 24h > Remaining Estimate: 24h > > Secondary Storage is provided on Windows Storage Server 2012. NFS Service is > installed and working. Note that WSS 2012 supports NFS v3 and v4.1 but not v4 > (for whatever reason they may have) > Able to add Secondary Storage using CS UI. > SSVM starts but fails to load the Secondary Storage. Checked with > ssvm-check.sh saying Error: "NFS is not currently mounted" and "NFS Server is > 0.0.0.0" > Manually mounting NFS location with "mount -t nfs -o vers=3" or "mount -t nfs > -o minorversion=1" successfully loads the storage location. > Tried setting /etc/nfsmount.conf with Defaultvers=3 or Defaultvers=4.1 but > appears SSVM ignores nfsmount.conf file. > Can add manual entry in /etc/fstab but not sure if that is going to work in > SSVM as while mounting it creates a uuid location dynamically. > There is no way to supply mount options to SSVM and SSVM is not automatically > degrading to v3 if v4 is not successful. > There should be a way to either pass mount options to SSVM or some > script/setting that can be edited/provided to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8300) Add index on archived field in cloud.event table
Remi Bergsma created CLOUDSTACK-8300: Summary: Add index on archived field in cloud.event table Key: CLOUDSTACK-8300 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8300 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.2 Reporter: Remi Bergsma Priority: Minor When there are many events in the cloud.event table, the UI throws an SQL exception and the management server spikes at 100% CPU for minutes. That causes other API calls to fail with 430 errors. Studying the error below, it seems an index on the 'archived' field is missing (since it is used in the WHERE clause). We have 1.4M events in the table: select count(*) from event; 1497838 Solution: Please add the index to the archived field and consider doing the same for the state field. Work around: Delete events manually delete from event where state = "Completed"; Since state also does not have an index, this takes some time. Error logged: 2015-03-04 14:19:28,429 ERROR [c.c.a.ApiServer] (TP-Processor50:ctx-3116c380 ctx-c861804c) unhandled exception executing api command: [Ljava.lang.String;@b96205f com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@17f33b92: SELECT event_view.id, event_view.uuid, event_view.type, event_view.state, event_view.description, event_view.created, event_view.user_id, event_view.user_name, event_view.l evel, event_view.start_id, event_view.start_uuid, event_view.parameters, event_view.account_id, event_view.account_uuid, event_view.account_name, event_view.account_type, event_view.domain_id, event_view.domain_uuid, event_view.domain_name, event_view.domain_path, event_view.project_id , event_view.project_uuid, event_view.project_name, event_view.archived, event_view.display FROM event_view WHERE event_view.account_type != 5 AND event_view.archived = 0 ORDER BY event_view.created DESC LIMIT 0, 20 at com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:425) at com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361) at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345) at com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296) at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy268.searchAndCount(Unknown Source) at com.cloud.api.query.QueryManagerImpl.searchForEventsInternal(QueryManagerImpl.java:583) at com.cloud.api.query.QueryManagerImpl.searchForEvents(QueryManagerImpl.java:472) at org.apache.cloudstack.api.command.user.event.ListEventsCmd.execute(ListEventsCmd.java:112) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:682) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:511) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) 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:115) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77) 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.S
[jira] [Created] (CLOUDSTACK-8316) VolumeOrchestrator checks StorageHAMigrationEnabled setting where it should not
Remi Bergsma created CLOUDSTACK-8316:
Summary: VolumeOrchestrator checks StorageHAMigrationEnabled
setting where it should not
Key: CLOUDSTACK-8316
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8316
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Volumes
Affects Versions: 4.4.2
Reporter: Remi Bergsma
Scenario:
enable.ha.storage.migration = false
Attach a volume to a disk that is on another storage pool than the vm you are
attaching to.
Error: Cannot migrate volumes. Volume Migration is disabled
Cause:
file:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
if (StorageHAMigrationEnabled.value()) {
It checks the HA setting, but this is not an HA event!
Proposed solution:
Option A: add setting: enable.storage.migration and check that instead
Option B: remove the check altogether as it does not provide much value
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8316) VolumeOrchestrator checks StorageHAMigrationEnabled setting where it should not
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356941#comment-14356941
]
Remi Bergsma commented on CLOUDSTACK-8316:
--
Seems this has already been fixed in master.
https://github.com/apache/cloudstack/blob/master/engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
> VolumeOrchestrator checks StorageHAMigrationEnabled setting where it should
> not
> ---
>
> Key: CLOUDSTACK-8316
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8316
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.4.2
>Reporter: Remi Bergsma
>
> Scenario:
> enable.ha.storage.migration = false
> Attach a volume to a disk that is on another storage pool than the vm you are
> attaching to.
> Error: Cannot migrate volumes. Volume Migration is disabled
> Cause:
> file:
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>
> if (StorageHAMigrationEnabled.value()) {
>
> It checks the HA setting, but this is not an HA event!
> Proposed solution:
> Option A: add setting: enable.storage.migration and check that instead
> Option B: remove the check altogether as it does not provide much value
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4690) KVM Router - to many ethernet devices created
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493564#comment-14493564 ] Remi Bergsma commented on CLOUDSTACK-4690: -- Did you guys find a solution/cause for this yet? > KVM Router - to many ethernet devices created > - > > Key: CLOUDSTACK-4690 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4690 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.1.1 > Environment: Centos 6.4 >Reporter: Paul Edwards >Priority: Critical > Attachments: 20141001-agent.log, 20141001-management-server.log, > management-server.log, router.log > > > We have setup cloudstack with advanced networking. We have a network created > 172.16.24.0/23, called news preprod. This has a number of vms created under > it. When we initially set this up, we noticed that the router we created with > 4 ethernet interfaces. This was unexpected, but didn't seem to be effecting > the running of the router, so we didn't worry about it. The interfaces were: > eth0 172.16.24.14, eth1 169.254.1.91, and both eth2 and eth2 were given the > external ip (xxx.xxx.245.59). We investigated why we were getting 2 > externals, but couldn't figure it out. We also configured the router to have > a redundant, with keepalived. They were working fine. > Now I needed to add another external ip to the network. Did that, and > restarted the network. I now have 8 (eight) eth interfaces. The new external > ip is NOT one of them. Heres the ifconfig output: > root@r-235-VM:~# ifconfig > eth0 Link encap:Ethernet HWaddr 02:00:68:e1:00:1a > inet addr:172.16.24.14 Bcast:172.16.25.255 Mask:255.255.254.0 > inet6 addr: fe80::68ff:fee1:1a/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:5485 errors:0 dropped:0 overruns:0 frame:0 > TX packets:21101 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:325618 (317.9 KiB) TX bytes:1581746 (1.5 MiB) > eth1 Link encap:Ethernet HWaddr 0e:00:a9:fe:01:5b > inet addr:169.254.1.91 Bcast:169.254.255.255 Mask:255.255.0.0 > inet6 addr: fe80::c00:a9ff:fefe:15b/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:22118 errors:0 dropped:0 overruns:0 frame:0 > TX packets:21148 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3942785 (3.7 MiB) TX bytes:4287970 (4.0 MiB) > eth2 Link encap:Ethernet HWaddr 06:16:06:00:01:03 > inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0 > inet6 addr: fe80::416:6ff:fe00:103/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:17331 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3930 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:1063053 (1.0 MiB) TX bytes:234546 (229.0 KiB) > eth3 Link encap:Ethernet HWaddr 06:d7:ec:00:01:03 > inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0 > inet6 addr: fe80::4d7:ecff:fe00:103/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:13603 errors:0 dropped:0 overruns:0 frame:0 > TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:792907 (774.3 KiB) TX bytes:704 (704.0 B) > eth4 Link encap:Ethernet HWaddr 06:8b:5a:00:01:03 > inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0 > inet6 addr: fe80::48b:5aff:fe00:103/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:13319 errors:0 dropped:0 overruns:0 frame:0 > TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:779753 (761.4 KiB) TX bytes:704 (704.0 B) > eth5 Link encap:Ethernet HWaddr 06:7e:68:00:01:03 > inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0 > inet6 addr: fe80::47e:68ff:fe00:103/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:13080 errors:0 dropped:0 overruns:0 frame:0 > TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:762111 (744.2 KiB) TX bytes:704 (704.0 B) > eth6 Link encap:Ethernet HWaddr 06:7e:68:00:01:03 > inet addr:xxx.xxx.245.59 Bcas
[jira] [Closed] (CLOUDSTACK-6543) Advanced search on instances has domain list unsorted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-6543. > Advanced search on instances has domain list unsorted > - > > Key: CLOUDSTACK-6543 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6543 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Remi Bergsma >Priority: Minor > Fix For: 4.6.0 > > > UI: > go to instances > select little arrow to enter advanced search > the domains in this list are unsorted (listed in the order they were added). > Especially when there are a large number of them, this way of working takes a > lot of time to select the right one. > Please sort this list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6543) Advanced search on instances has domain list unsorted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-6543. -- Resolution: Fixed Fix Version/s: 4.6.0 > Advanced search on instances has domain list unsorted > - > > Key: CLOUDSTACK-6543 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6543 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Remi Bergsma >Priority: Minor > Fix For: 4.6.0 > > > UI: > go to instances > select little arrow to enter advanced search > the domains in this list are unsorted (listed in the order they were added). > Especially when there are a large number of them, this way of working takes a > lot of time to select the right one. > Please sort this list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-6665) DHCP does not release ip addresses properly on VPC routers (edithosts.sh)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997453#comment-13997453
]
Remi Bergsma edited comment on CLOUDSTACK-6665 at 5/14/14 10:35 AM:
Review 21431 has been created to address this issue.
https://reviews.apache.org/r/21431/
was (Author: remibergsma):
Review 21431 has been created to address this issue.
> DHCP does not release ip addresses properly on VPC routers (edithosts.sh)
> -
>
> Key: CLOUDSTACK-6665
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6665
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
>Affects Versions: 4.3.0, 4.4.0
>Reporter: Remi Bergsma
>Priority: Critical
>
> DHCP does not release ip addresses properly on VPC routers (edithosts.sh)
> How to reproduce:
> - create vpc network with small prefix
> - create as many vm’s until all ip address space is consumed
> - delete one vm
> - now create a vm again: there should be an ip address freed
> - it does not work though. Error on router:
> /var/log/dnsmasq.log:May 13 12:53:16 dnsmasq-dhcp[32100]: DHCPDISCOVER(eth3)
> 02:00:00:0d:00:b6 no address available
> How to reproduce #2:
> - create a vm with static ip
> - destroy it
> - create vm with same static ip: this ip should be free again
> This does not work either:
> /var/log/dnsmasq.log:May 13 13:59:41 dnsmasq-dhcp[32100]: DHCPDISCOVER(eth3)
> 02:00:69:06:00:c1 no address available
> Cause:
> edithosts.sh is supposed to clean up addresses.
> edithosts.sh line 101:
> dhcp_release eth0 $ipv4 $(grep "$ipv4 " $DHCP_LEASES | awk '{print $2}') >
> /dev/null 2>&1
> But it doesn’t work, because eth0 is the link local address on VPC routers.
> We should make the interface variable on VPC routers.
> It does work fine on redundant routers, for example. Because eth0 is the
> actual guest network.
> CloudStack reports to the user: Insufficient capacity.
> Manual work-around:
> Run on the router:
> dhcp_release eth3 02:00:69:06:00:c1 10.75.16.8
> Replace eth3 with the correct interface.
> It logs:
> /var/log/messages-20140419:May 13 13:38:29 r-4197-VM cloud: edithosts:
> released 10.75.16.8
> It now works!
> This an annoying bug for users that use static ip’s in their networks. Also
> users that deploy a lot of test vm’s in the same network are impacted. Let’s
> fix it :-)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-6666) UI search for vm's in port forward rules field does not work
Remi Bergsma created CLOUDSTACK-: Summary: UI search for vm's in port forward rules field does not work Key: CLOUDSTACK- URL: https://issues.apache.org/jira/browse/CLOUDSTACK- Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0, 4.4.0 Reporter: Remi Bergsma Priority: Minor How to reproduce: Click: - network - vpc from drop down - select a vpc network - configure - router :: public ip addresses - click ip address - configuration tab - port forwarding :: view all - add vm the search above this screen does not work this because the ‘keyword’ parameter is not parsed to the listVirtualMachines call. API call made: account some name command listVirtualMachines domainid69d000c7-a8f8-0009-0a8a-949172fe2bda listAll true page1 pageSize20 responsejson sessionkey bla Please add filter so the search will work. Especially with large amounts of vm's this is annoying. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6665) DHCP does not release ip addresses properly on VPC routers (edithosts.sh)
Remi Bergsma created CLOUDSTACK-6665:
Summary: DHCP does not release ip addresses properly on VPC
routers (edithosts.sh)
Key: CLOUDSTACK-6665
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6665
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: SystemVM
Affects Versions: 4.3.0, 4.4.0
Reporter: Remi Bergsma
Priority: Critical
DHCP does not release ip addresses properly on VPC routers (edithosts.sh)
How to reproduce:
- create vpc network with small prefix
- create as many vm’s until all ip address space is consumed
- delete one vm
- now create a vm again: there should be an ip address freed
- it does not work though. Error on router:
/var/log/dnsmasq.log:May 13 12:53:16 dnsmasq-dhcp[32100]: DHCPDISCOVER(eth3)
02:00:00:0d:00:b6 no address available
How to reproduce #2:
- create a vm with static ip
- destroy it
- create vm with same static ip: this ip should be free again
This does not work either:
/var/log/dnsmasq.log:May 13 13:59:41 dnsmasq-dhcp[32100]: DHCPDISCOVER(eth3)
02:00:69:06:00:c1 no address available
Cause:
edithosts.sh is supposed to clean up addresses.
edithosts.sh line 101:
dhcp_release eth0 $ipv4 $(grep "$ipv4 " $DHCP_LEASES | awk '{print $2}') >
/dev/null 2>&1
But it doesn’t work, because eth0 is the link local address on VPC routers. We
should make the interface variable on VPC routers.
It does work fine on redundant routers, for example. Because eth0 is the actual
guest network.
CloudStack reports to the user: Insufficient capacity.
Manual work-around:
Run on the router:
dhcp_release eth3 02:00:69:06:00:c1 10.75.16.8
Replace eth3 with the correct interface.
It logs:
/var/log/messages-20140419:May 13 13:38:29 r-4197-VM cloud: edithosts: released
10.75.16.8
It now works!
This an annoying bug for users that use static ip’s in their networks. Also
users that deploy a lot of test vm’s in the same network are impacted. Let’s
fix it :-)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6665) DHCP does not release ip addresses properly on VPC routers (edithosts.sh)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma updated CLOUDSTACK-6665:
-
Review 21431 has been created to address this issue.
> DHCP does not release ip addresses properly on VPC routers (edithosts.sh)
> -
>
> Key: CLOUDSTACK-6665
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6665
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
>Affects Versions: 4.3.0, 4.4.0
>Reporter: Remi Bergsma
>Priority: Critical
>
> DHCP does not release ip addresses properly on VPC routers (edithosts.sh)
> How to reproduce:
> - create vpc network with small prefix
> - create as many vm’s until all ip address space is consumed
> - delete one vm
> - now create a vm again: there should be an ip address freed
> - it does not work though. Error on router:
> /var/log/dnsmasq.log:May 13 12:53:16 dnsmasq-dhcp[32100]: DHCPDISCOVER(eth3)
> 02:00:00:0d:00:b6 no address available
> How to reproduce #2:
> - create a vm with static ip
> - destroy it
> - create vm with same static ip: this ip should be free again
> This does not work either:
> /var/log/dnsmasq.log:May 13 13:59:41 dnsmasq-dhcp[32100]: DHCPDISCOVER(eth3)
> 02:00:69:06:00:c1 no address available
> Cause:
> edithosts.sh is supposed to clean up addresses.
> edithosts.sh line 101:
> dhcp_release eth0 $ipv4 $(grep "$ipv4 " $DHCP_LEASES | awk '{print $2}') >
> /dev/null 2>&1
> But it doesn’t work, because eth0 is the link local address on VPC routers.
> We should make the interface variable on VPC routers.
> It does work fine on redundant routers, for example. Because eth0 is the
> actual guest network.
> CloudStack reports to the user: Insufficient capacity.
> Manual work-around:
> Run on the router:
> dhcp_release eth3 02:00:69:06:00:c1 10.75.16.8
> Replace eth3 with the correct interface.
> It logs:
> /var/log/messages-20140419:May 13 13:38:29 r-4197-VM cloud: edithosts:
> released 10.75.16.8
> It now works!
> This an annoying bug for users that use static ip’s in their networks. Also
> users that deploy a lot of test vm’s in the same network are impacted. Let’s
> fix it :-)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
Remi Bergsma created CLOUDSTACK-7184: Summary: HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down Key: CLOUDSTACK-7184 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, XenServer Affects Versions: 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors Reporter: Remi Bergsma Priority: Blocker Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did discover this and marked the host as down, and immediately started HA. Just 18 seconds later the hypervisor returned and we ended up with 5 vm's that were running on two hypervisors at the same time. This, of course, resulted in file system corruption and the loss of the vm's. One side of the story is why XenServer allowed this to happen (will not bother you with this one). The CloudStack side of the story: HA should only start after at least xen.heartbeat.interval seconds. If the host is down long enough, the Xen heartbeat script will fence the hypervisor and prevent corruption. If it is not down long enough, nothing should happen. Logs (short): 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) . 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on the VMs . 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 505, name = mccpvmXX] cs marks host down: 2014-07-25 05:03:31,920 cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6067) UI does not list routers matched by search string
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911426#comment-13911426 ] Remi Bergsma commented on CLOUDSTACK-6067: -- This happens also on the 'Infrastructure' overview page where it displays the number of routers for the project. It does the same two api calls and does a count. This results in all projects having their own router(s) counted + all project routers. > UI does not list routers matched by search string > - > > Key: CLOUDSTACK-6067 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6067 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.1 >Reporter: Rutger te Nijenhuis >Priority: Trivial > > While searching for virtual routers on a specific keyword, the gui returns > the matched search and all project routers. Keyword isn't applied to second > api call listing the project routers: > api?command=listRouters&listAll=true&page=1&pagesize=20&keyword=r-1313&response=json&sessionkey=qjeqwijeo12@*($(!*kjsij&_=1392044881273 > /client > api?command=listRouters&listAll=true&page=1&pagesize=20&projectid=-1&response=json&sessionkey=qjeqwijeo12@*($(!*kjsij&_=1392044881446 > /client -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4666) VM created under projects don't show up in admin instances, or under hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911431#comment-13911431 ] Remi Bergsma commented on CLOUDSTACK-4666: -- Alena, Danny, The UI does list the project routers (by making 2 api calls as you said) but for instances/virtual machines this is not the case. It would make sense to have the same behavior. As an admin I would like to see what is still running on a given host, for example when I want to decommission a cluster. Could you please add the 2nd API call (projectid=-1) so that all instances are showed to the admin? Thanks! Remi > VM created under projects don't show up in admin instances, or under hosts > -- > > Key: CLOUDSTACK-4666 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4666 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.1.0 > Environment: CentOS release 6.4 (Final) >Reporter: danny webb > Attachments: hosts_view_instances.png, instances_tab.png, > only_in_project_view.png > > > If you create a VM via the API that is assigned to a project it the VM isn't > viewable anywhere except in the project view. Even for the admin user. > Places you can't see them in the UI: > Admin -> Instances > Admin -> Infrastructure -> Hosts -> Hostname -> View Instances > User -> Instances > this is problematic because you have no way of gauging the overall > utilisation of hosts without being able to see all hosts assigned to them. > It seems to me that assigning a VM to a project shouldn't remove it from the > overall instances list. You should be able as a user be able to have the > overall view of instances regardless of project in the instances view as long > as you are a member of that project. If you need to get granular with what > VMs are assigned to what projects you can do that via the project view. And > the admin should definitely be able to see all instances in the instances > page without having to delve into the project view and trying to find the > host. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4606) HA does not kick on Routing VM hanging on kernel panic.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911485#comment-13911485
]
Remi Bergsma commented on CLOUDSTACK-4606:
--
Wouldn't it be easiest to have the virtual router reboot itself in case of a
kernel panic after, say, 10 seconds?
/etc/sysctl.conf:
kernel.panic = 10
The backup node will then take over. Or if it's non-HA, it will work again
after the reboot.
> HA does not kick on Routing VM hanging on kernel panic.
> ---
>
> Key: CLOUDSTACK-4606
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4606
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.1.1
>Reporter: Roeland Kuipers
>
> If a routing VM hangs on kernel panic. It will never be recovered by the HA
> process of Cloudstack.
> In this case the Virtual Router cannot be accessed anymore over link-local
> and/or management address and cannot be managed anymore.
> We think HA should reboot a router when this occurs.
> See also CLOUDSTACK-4607 and CLOUDSTACK-4605
> Errors observed while hanging:
> 013-09-04 18:57:42,108 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-446:null) callHostPlugin failed for cmd: routerProxy with args
> args: vpc_netusage.sh 169.254.3.166 -l 95.142.107.111 -g, due to Failed to
> create input stream: Read timed out
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for
> cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed out
> 2013-09-04 18:57:42,109 DEBUG [agent.transport.Request]
> (DirectAgent-446:null) Seq 105-1580215291: Processing: { Ans: , MgmtId:
> 345052370017, via: 105, Ver: v1, Flags: 10,
> [{"NetworkUsageAnswer":{"result":false,"details":"Exception:
> com.cloud.utils.exception.CloudRuntimeException\nMessage: callHostPlugin
> failed for cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed
> out\nStack: com.cloud.utils.exception.CloudRuntimeException: callHostPlugin
> failed for cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed
> out\n\tat
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:3745)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServer56Resource.VPCNetworkUsage(XenServer56Resource.java:186)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServer56Resource.execute(XenServer56Resource.java:211)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:71)\n\tat
>
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:191)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)\n\tat
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:138)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)\n\tat
> java.lang.Thread.run(Thread.java:662)\n","wait":0}}] }
> Message: callHostPlugin failed for cmd: routerProxy with args args:
> vpc_netusage.sh 169.254.3.166 -l 95.142.107.111 -g, due to Failed to create
> input stream: Read timed out
> Stack: com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed
> for cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed out
> Message: callHostPlugin failed for cmd: routerProxy with args args:
> vpc_netusage.sh 169.254.3.166 -l 95.142.107.111 -g, due to Failed to create
> input stream: Read timed out
> Stack: com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed
> for cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed out
> 2013-09-04 19:08:20,909 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-367:null) callHostPlugin failed for cmd: routerProxy with args
> args: vpc_netusage.sh 169.254.3.166 -l 95.142.107.111 -g, due to Failed to
> create input stream: Read timed out
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for
> cmd: r
[jira] [Created] (CLOUDSTACK-6212) 'vm_instance' table has no AUTO_INCREMENT on 'id' field
Remi Bergsma created CLOUDSTACK-6212: Summary: 'vm_instance' table has no AUTO_INCREMENT on 'id' field Key: CLOUDSTACK-6212 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6212 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.1, 4.3.0 Reporter: Remi Bergsma We had an production issue today where two instances got the same id / instance name. This happened in a multi-master setup, with proper 'auto_increment_increment' and 'auto_increment_offset' variables set in MySQL. I related the problem to the 'vm_instance' table as it seems the primary key, 'id', does not have an AUTO_INCREMENT set. Hence, two API calls around the same time on each of the management servers returned the same instance id with all kind of trouble as a result. Could the AUTO_INCREMENT be added, or is there a reason it is missing? Below is the CREATE statement of the table, which is CloudStack 4.2.1: CREATE TABLE `vm_instance` ( `id` bigint(20) unsigned NOT NULL, `name` varchar(255) NOT NULL, `instance_name` varchar(255) NOT NULL COMMENT 'name of the vm instance running on the hosts', `state` varchar(32) NOT NULL, `vm_template_id` bigint(20) unsigned DEFAULT NULL, `guest_os_id` bigint(20) unsigned NOT NULL, `private_mac_address` varchar(17) DEFAULT NULL, `private_ip_address` char(40) DEFAULT NULL, `pod_id` bigint(20) unsigned DEFAULT NULL, `data_center_id` bigint(20) unsigned NOT NULL COMMENT 'Data Center the instance belongs to', `host_id` bigint(20) unsigned DEFAULT NULL, `last_host_id` bigint(20) unsigned DEFAULT NULL COMMENT 'tentative host for first run or last host that it has been running on', `proxy_id` bigint(20) unsigned DEFAULT NULL COMMENT 'console proxy allocated in previous session', `proxy_assign_time` datetime DEFAULT NULL COMMENT 'time when console proxy was assigned', `vnc_password` varchar(255) NOT NULL COMMENT 'vnc password', `ha_enabled` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'Should HA be enabled for this VM', `limit_cpu_use` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT 'Limit the cpu usage to service offering', `update_count` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT 'date state was updated', `update_time` datetime DEFAULT NULL COMMENT 'date the destroy was requested', `created` datetime NOT NULL COMMENT 'date created', `removed` datetime DEFAULT NULL COMMENT 'date removed if not null', `type` varchar(32) NOT NULL COMMENT 'type of vm it is', `vm_type` varchar(32) NOT NULL COMMENT 'vm type', `account_id` bigint(20) unsigned NOT NULL COMMENT 'user id of owner', `domain_id` bigint(20) unsigned NOT NULL, `service_offering_id` bigint(20) unsigned NOT NULL COMMENT 'service offering id', `reservation_id` char(40) DEFAULT NULL COMMENT 'reservation id', `hypervisor_type` char(32) DEFAULT NULL COMMENT 'hypervisor type', `uuid` varchar(40) DEFAULT NULL, `disk_offering_id` bigint(20) unsigned DEFAULT NULL, `cpu` int(10) unsigned DEFAULT NULL, `ram` bigint(20) unsigned DEFAULT NULL, `owner` varchar(255) DEFAULT NULL, `speed` int(10) unsigned DEFAULT NULL, `host_name` varchar(255) DEFAULT NULL, `display_name` varchar(255) DEFAULT NULL, `desired_state` varchar(32) DEFAULT NULL, `dynamically_scalable` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT 'true if VM contains XS/VMWare tools inorder to support dynamic scaling of VM cpu/memory', `display_vm` tinyint(1) NOT NULL DEFAULT '1' COMMENT 'Should vm instance be displayed to the end user', PRIMARY KEY (`id`), UNIQUE KEY `id` (`id`), UNIQUE KEY `uc_vm_instance_uuid` (`uuid`), KEY `i_vm_instance__removed` (`removed`), KEY `i_vm_instance__type` (`type`), KEY `i_vm_instance__pod_id` (`pod_id`), KEY `i_vm_instance__update_time` (`update_time`), KEY `i_vm_instance__update_count` (`update_count`), KEY `i_vm_instance__state` (`state`), KEY `i_vm_instance__data_center_id` (`data_center_id`), KEY `fk_vm_instance__host_id` (`host_id`), KEY `i_vm_instance__template_id` (`vm_template_id`), KEY `fk_vm_instance__account_id` (`account_id`), KEY `fk_vm_instance__service_offering_id` (`service_offering_id`), KEY `fk_vm_instance__last_host_id` (`last_host_id`), CONSTRAINT `fk_vm_instance__account_id` FOREIGN KEY (`account_id`) REFERENCES `account` (`id`), CONSTRAINT `fk_vm_instance__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`), CONSTRAINT `fk_vm_instance__last_host_id` FOREIGN KEY (`last_host_id`) REFERENCES `host` (`id`), CONSTRAINT `fk_vm_instance__service_offering_id` FOREIGN KEY (`service_offering_id`) REFERENCES `service_offering` (`id`), CONSTRAINT `fk_vm_instance__template_id` FOREIGN KEY (`vm_template_id`) REFERENCES `vm_template` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 I did not see any relevant c
[jira] [Created] (CLOUDSTACK-6293) Custom SSL certificate for console proxy does not work after upgrade 4.2.1 -> 4.3
Remi Bergsma created CLOUDSTACK-6293:
Summary: Custom SSL certificate for console proxy does not work
after upgrade 4.2.1 -> 4.3
Key: CLOUDSTACK-6293
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6293
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Upgrade
Affects Versions: 4.3.0
Reporter: Remi Bergsma
We use a custom SSL certificate that had been installed before the upgrade.
After upgrading from 4.2.1 to 4.3 the console proxy did not work due to a wrong
SSL url being generated:
https://1-2-3-4.*.ssl.example.com instead of https://1-2-3-4.ssl.example.com
We fixed this by altering these settings to remove "*."
secstorage.ssl.cert.domain
consoleproxy.url.domain
These settings were altered during the upgrade, and they actually break it.
2014-03-27 14:46:45,429 DEBUG [utils.db.ScriptRunner] (main:null) UPDATE
`cloud`.`configuration` SET value = CONCAT("*.",(SELECT `temptable`.`value`
FROM (SELECT * FROM `cloud`.`configuration` WHERE
`name`="consoleproxy.url.domain") AS `temptable` WHERE
`temptable`.`name`="consoleproxy.url.domain")) WHERE
`name`="consoleproxy.url.domain"
2014-03-27 14:46:45,441 DEBUG [utils.db.ScriptRunner] (main:null) UPDATE
`cloud`.`configuration` SET `value` = CONCAT("*.",(SELECT `temptable`.`value`
FROM (SELECT * FROM `cloud`.`configuration` WHERE
`name`="secstorage.ssl.cert.domain") AS `temptable` WHERE
`temptable`.`name`="secstorage.ssl.cert.domain")) WHERE
`name`="secstorage.ssl.cert.domain"
The SQL can be found in this file:
/usr/share/cloudstack-management/setup/db/schema-421to430.sql
Please fix this!
Thanks,
Remi
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-6538) Migrating a volume causes snapshot schedule to disappear
Remi Bergsma created CLOUDSTACK-6538: Summary: Migrating a volume causes snapshot schedule to disappear Key: CLOUDSTACK-6538 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6538 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Remi Bergsma When a volume is migrated to another primary storage, the snapshot schedule that exists before migration, is no longer active after migration. Steps to reproduce: - create a volume - create a snapshot policy - note it creates an entry in cloud.snapshot_policy table - migrate volume to another primary storage - note the entry in cloud.snapshot_policy has been deleted Cause: Migrating a volume leads to a volume with a new id and uuid. Since the snapshot schedule is linked to a volume based on id, this is lost after migration. Please: - do not delete entries in cloud.snapshot_policy but mark as ‘deleted’ instead (like done on other tables) - recreate the snapshot schedule for a volume that was migrated, using its new id. Or update the table with the new id. This is a serious bug, because the user does not expect the snapshot schedule to disappear. Hence, when a snapshot is needed after migration you have a problem that cannot be fixed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6540) API: add listOrphanedSnapshots() call
Remi Bergsma created CLOUDSTACK-6540: Summary: API: add listOrphanedSnapshots() call Key: CLOUDSTACK-6540 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6540 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.3.0 Reporter: Remi Bergsma When a volume is migrated to another primary storage, its snapshots disappear from the UI as they are linked to the now expunged volume. The snapshot itself is not marked as deleted in the database, so it stays there. A listall=true displays them all, but there is no way to tell if the snapshot is still linked to a volume that is still active. When I know the name of the volume, I can use a keyword search like this: > list snapshots listall=true filter=name,created,volumeid keyword=ROOT-18202 count = 3 snapshot: ++--+--+ |name| created | volumeid | ++--+--+ | centos01_ROOT-18202_20140430110253 | 2014-04-30T13:02:53+0200 | 2b606f51-6b56-46b5-b85e-6a3e02babf23 | | centos01_ROOT-18202_20140429101022 | 2014-04-29T12:10:22+0200 | 3788e908-eb75-4063-8116-ec9812d3fb95 | | centos01_ROOT-18202_20140429095746 | 2014-04-29T11:57:46+0200 | 166f7545-33e2-423a-b900-3f3cea64a868 | ++--+--+ But there is no way to list all the orphaned ones. To garden those, please add an api call that lists all snapshots that are linked to expunged volumes. One can use its output to delete the snapshots. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6541) The UI allows snapshot schedules that the API does not accept
Remi Bergsma created CLOUDSTACK-6541: Summary: The UI allows snapshot schedules that the API does not accept Key: CLOUDSTACK-6541 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6541 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Remi Bergsma Priority: Minor Monthly snapshot schedules for volumes can only be done on day 1-28 of month. The UI allows to select 29,30,31 and when you save it, the following error is displayed: Invalid schedule: 00:1:31 for interval type: monthly Please remove days 29,30,31 from select box. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6539) When migrating a volume, warn that snapshots will be lost
Remi Bergsma created CLOUDSTACK-6539: Summary: When migrating a volume, warn that snapshots will be lost Key: CLOUDSTACK-6539 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6539 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Remi Bergsma Snapshots that are created on a volume, are not available anymore after the volume is migrated to another primary storage. This is something the user does not expect, so let’s warn for it in the UI. Alert: Migrating this volume will delete its snapshots. Sure? If NO, do nothing. If YES, proceed like we do now. Cause: Snapshots are linked to a volume id, which changes after migration. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6543) Advanced search on instances has domain list unsorted
Remi Bergsma created CLOUDSTACK-6543: Summary: Advanced search on instances has domain list unsorted Key: CLOUDSTACK-6543 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6543 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Remi Bergsma Priority: Minor UI: go to instances select little arrow to enter advanced search the domains in this list are unsorted (listed in the order they were added). Especially when there are a large number of them, this way of working takes a lot of time to select the right one. Please sort this list. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6542) Interval type not consistent in create/list snapshot schedules
Remi Bergsma created CLOUDSTACK-6542: Summary: Interval type not consistent in create/list snapshot schedules Key: CLOUDSTACK-6542 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6542 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Remi Bergsma Priority: Minor When you create a snapshot schedule, the ‘intervaltype’ has to be entered like ‘DAILY, HOURLY’ etc. create snapshotpolicy volumeid=2b606f51-6b56-46b5-b85e-6a3e02babf23 schedule=23:1 intervaltype=DAILY timezone=Europe/Amsterdam maxsnaps=1 When you list the snapshot schedule, the ‘intervaltype’ is an integer, 0=HOURLY, 1=DAILY etc. > list snapshotpolicies volumeid=2b606f51-6b56-46b5-b85e-6a3e02babf23 count = 1 snapshotpolicy: +--+--+--+--+--+--+ | maxsnaps | intervaltype | schedule | volumeid | timezone | id | +--+--+--+--+--+--+ |1 | 1 | 23:1 | 2b606f51-6b56-46b5-b85e-6a3e02babf23 | Europe/Amsterdam | 9b736a09-4549-4638-a88d-f8ae9cc87c51 | +--+--+--+--+--+--+ Could this be made more consistent, maybe allow both formats in both calls? When you want to list a schedule, and use this data to create a new one this ‘translating’ is a bit weird. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6541) The UI allows snapshot schedules that the API does not accept
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-6541: - Component/s: UI > The UI allows snapshot schedules that the API does not accept > - > > Key: CLOUDSTACK-6541 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6541 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Remi Bergsma >Priority: Minor > > Monthly snapshot schedules for volumes can only be done on day 1-28 of month. > The UI allows to select 29,30,31 and when you save it, the following error is > displayed: > Invalid schedule: 00:1:31 for interval type: monthly > Please remove days 29,30,31 from select box. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6542) Interval type not consistent in create/list snapshot schedules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-6542: - Description: When you create a snapshot schedule, the ‘intervaltype’ has to be entered like ‘DAILY, HOURLY’ etc. create snapshotpolicy volumeid=2b606f51-6b56-46b5-b85e-6a3e02babf23 schedule=23:1 intervaltype=DAILY timezone=Europe/Amsterdam maxsnaps=1 When you list the snapshot schedule, the ‘intervaltype’ is an integer, 0=HOURLY, 1=DAILY etc. > list snapshotpolicies volumeid=2b606f51-6b56-46b5-b85e-6a3e02babf23 count = 1 snapshotpolicy: | maxsnaps | intervaltype | schedule | volumeid | timezone | id | |1 | 1 | 23:1 | 2b606f51-6b56-46b5-b85e-6a3e02babf23 | Europe/Amsterdam | 9b736a09-4549-4638-a88d-f8ae9cc87c51 | Could this be made more consistent, maybe allow both formats in both calls? When you want to list a schedule, and use this data to create a new one this ‘translating’ is a bit weird. was: When you create a snapshot schedule, the ‘intervaltype’ has to be entered like ‘DAILY, HOURLY’ etc. create snapshotpolicy volumeid=2b606f51-6b56-46b5-b85e-6a3e02babf23 schedule=23:1 intervaltype=DAILY timezone=Europe/Amsterdam maxsnaps=1 When you list the snapshot schedule, the ‘intervaltype’ is an integer, 0=HOURLY, 1=DAILY etc. > list snapshotpolicies volumeid=2b606f51-6b56-46b5-b85e-6a3e02babf23 count = 1 snapshotpolicy: +--+--+--+--+--+--+ | maxsnaps | intervaltype | schedule | volumeid | timezone | id | +--+--+--+--+--+--+ |1 | 1 | 23:1 | 2b606f51-6b56-46b5-b85e-6a3e02babf23 | Europe/Amsterdam | 9b736a09-4549-4638-a88d-f8ae9cc87c51 | +--+--+--+--+--+--+ Could this be made more consistent, maybe allow both formats in both calls? When you want to list a schedule, and use this data to create a new one this ‘translating’ is a bit weird. > Interval type not consistent in create/list snapshot schedules > -- > > Key: CLOUDSTACK-6542 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6542 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Remi Bergsma >Priority: Minor > > When you create a snapshot schedule, the ‘intervaltype’ has to be entered > like ‘DAILY, HOURLY’ etc. > create snapshotpolicy volumeid=2b606f51-6b56-46b5-b85e-6a3e02babf23 > schedule=23:1 intervaltype=DAILY timezone=Europe/Amsterdam maxsnaps=1 > When you list the snapshot schedule, the ‘intervaltype’ is an integer, > 0=HOURLY, 1=DAILY etc. > > list snapshotpolicies volumeid=2b606f51-6b56-46b5-b85e-6a3e02babf23 > count = 1 > snapshotpolicy: > | maxsnaps | intervaltype | schedule | volumeid | > timezone | id | > |1 | 1 | 23:1 | 2b606f51-6b56-46b5-b85e-6a3e02babf23 | > Europe/Amsterdam | 9b736a09-4549-4638-a88d-f8ae9cc87c51 | > > Could this be made more consistent, maybe allow both formats in both calls? > When you want to list a schedule, and use this data to create a new one this > ‘translating’ is a bit weird. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6540) API: add listOrphanedSnapshots() call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-6540: - Description: When a volume is migrated to another primary storage, its snapshots disappear from the UI as they are linked to the now expunged volume. The snapshot itself is not marked as deleted in the database, so it stays there. A listall=true displays them all, but there is no way to tell if the snapshot is still linked to a volume that is still active. When I know the name of the volume, I can use a keyword search like this: > list snapshots listall=true filter=name,created,volumeid keyword=ROOT-18202 count = 3 snapshot: |name| created | volumeid | | centos01_ROOT-18202_20140430110253 | 2014-04-30T13:02:53+0200 | 2b606f51-6b56-46b5-b85e-6a3e02babf23 | | centos01_ROOT-18202_20140429101022 | 2014-04-29T12:10:22+0200 | 3788e908-eb75-4063-8116-ec9812d3fb95 | | centos01_ROOT-18202_20140429095746 | 2014-04-29T11:57:46+0200 | 166f7545-33e2-423a-b900-3f3cea64a868 | But there is no way to list all the orphaned ones. To garden those, please add an api call that lists all snapshots that are linked to expunged volumes. One can use its output to delete the snapshots. was: When a volume is migrated to another primary storage, its snapshots disappear from the UI as they are linked to the now expunged volume. The snapshot itself is not marked as deleted in the database, so it stays there. A listall=true displays them all, but there is no way to tell if the snapshot is still linked to a volume that is still active. When I know the name of the volume, I can use a keyword search like this: > list snapshots listall=true filter=name,created,volumeid keyword=ROOT-18202 count = 3 snapshot: |name| created | volumeid | | centos01_ROOT-18202_20140430110253 | 2014-04-30T13:02:53+0200 | 2b606f51-6b56-46b5-b85e-6a3e02babf23 | | centos01_ROOT-18202_20140429101022 | 2014-04-29T12:10:22+0200 | 3788e908-eb75-4063-8116-ec9812d3fb95 | | centos01_ROOT-18202_20140429095746 | 2014-04-29T11:57:46+0200 | 166f7545-33e2-423a-b900-3f3cea64a868 | But there is no way to list all the orphaned ones. To garden those, please add an api call that lists all snapshots that are linked to expunged volumes. One can use its output to delete the snapshots. > API: add listOrphanedSnapshots() call > - > > Key: CLOUDSTACK-6540 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6540 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0 >Reporter: Remi Bergsma > > When a volume is migrated to another primary storage, its snapshots disappear > from the UI as they are linked to the now expunged volume. The snapshot > itself is not marked as deleted in the database, so it stays there. > A listall=true displays them all, but there is no way to tell if the snapshot > is still linked to a volume that is still active. > When I know the name of the volume, I can use a keyword search like this: > > list snapshots listall=true filter=name,created,volumeid keyword=ROOT-18202 > count = 3 > snapshot: > |name| created | > volumeid | > | centos01_ROOT-18202_20140430110253 | 2014-04-30T13:02:53+0200 | > 2b606f51-6b56-46b5-b85e-6a3e02babf23 | > | centos01_ROOT-18202_20140429101022 | 2014-04-29T12:10:22+0200 | > 3788e908-eb75-4063-8116-ec9812d3fb95 | > | centos01_ROOT-18202_20140429095746 | 2014-04-29T11:57:46+0200 | > 166f7545-33e2-423a-b900-3f3cea64a868 | > But there is no way to list all the orphaned ones. To garden those, please > add an api call that lists all snapshots that are linked to expunged volumes. > One can use its output to delete the snapshots. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6540) API: add listOrphanedSnapshots() call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-6540: - Description: When a volume is migrated to another primary storage, its snapshots disappear from the UI as they are linked to the now expunged volume. The snapshot itself is not marked as deleted in the database, so it stays there. A listall=true displays them all, but there is no way to tell if the snapshot is still linked to a volume that is still active. When I know the name of the volume, I can use a keyword search like this: > list snapshots listall=true filter=name,created,volumeid keyword=ROOT-18202 count = 3 snapshot: |name| created | volumeid | | centos01_ROOT-18202_20140430110253 | 2014-04-30T13:02:53+0200 | 2b606f51-6b56-46b5-b85e-6a3e02babf23 | | centos01_ROOT-18202_20140429101022 | 2014-04-29T12:10:22+0200 | 3788e908-eb75-4063-8116-ec9812d3fb95 | | centos01_ROOT-18202_20140429095746 | 2014-04-29T11:57:46+0200 | 166f7545-33e2-423a-b900-3f3cea64a868 | But there is no way to list all the orphaned ones. To garden those, please add an api call that lists all snapshots that are linked to expunged volumes. One can use its output to delete the snapshots. was: When a volume is migrated to another primary storage, its snapshots disappear from the UI as they are linked to the now expunged volume. The snapshot itself is not marked as deleted in the database, so it stays there. A listall=true displays them all, but there is no way to tell if the snapshot is still linked to a volume that is still active. When I know the name of the volume, I can use a keyword search like this: > list snapshots listall=true filter=name,created,volumeid keyword=ROOT-18202 count = 3 snapshot: ++--+--+ |name| created | volumeid | ++--+--+ | centos01_ROOT-18202_20140430110253 | 2014-04-30T13:02:53+0200 | 2b606f51-6b56-46b5-b85e-6a3e02babf23 | | centos01_ROOT-18202_20140429101022 | 2014-04-29T12:10:22+0200 | 3788e908-eb75-4063-8116-ec9812d3fb95 | | centos01_ROOT-18202_20140429095746 | 2014-04-29T11:57:46+0200 | 166f7545-33e2-423a-b900-3f3cea64a868 | ++--+--+ But there is no way to list all the orphaned ones. To garden those, please add an api call that lists all snapshots that are linked to expunged volumes. One can use its output to delete the snapshots. > API: add listOrphanedSnapshots() call > - > > Key: CLOUDSTACK-6540 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6540 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0 >Reporter: Remi Bergsma > > When a volume is migrated to another primary storage, its snapshots disappear > from the UI as they are linked to the now expunged volume. The snapshot > itself is not marked as deleted in the database, so it stays there. > A listall=true displays them all, but there is no way to tell if the snapshot > is still linked to a volume that is still active. > When I know the name of the volume, I can use a keyword search like this: > > list snapshots listall=true filter=name,created,volumeid keyword=ROOT-18202 > count = 3 > snapshot: > |name| created | > volumeid | > | centos01_ROOT-18202_20140430110253 | 2014-04-30T13:02:53+0200 | > 2b606f51-6b56-46b5-b85e-6a3e02babf23 | > | centos01_ROOT-18202_20140429101022 | 2014-04-29T12:10:22+0200 | > 3788e908-eb75-4063-8116-ec9812d3fb95 | > | centos01_ROOT-18202_20140429095746 | 2014-04-29T11:57:46+0200 | > 166f7545-33e2-423a-b900-3f3cea64a868 | > But there is no way to list all the orphaned ones. To garden those, please > add an api call that lists all snapshots that are linked to expunged volumes. > One can use its output to delete the snapshots. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128253#comment-14128253 ] Remi Bergsma commented on CLOUDSTACK-7184: -- +1! > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)
Remi Bergsma created CLOUDSTACK-7527: Summary: XenServer heartbeat-script: make it reboot faster (when fencing) Key: CLOUDSTACK-7527 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: XenServer Affects Versions: 4.3.0, 4.4.0 Reporter: Remi Bergsma Priority: Minor xenheartbeat.sh: I've seen the 'reboot' command hang, even though it has the force option specified (last line of the script). Wouldn't it be better to invoke it like this: echo b > /proc/sysrq-trigger Tested it, starts boot sequence immediately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128266#comment-14128266 ] Remi Bergsma edited comment on CLOUDSTACK-7184 at 9/10/14 9:34 AM: --- @[~dahn] Now that you're working on this script, please also look at CLOUDSTACK-7527 (https://issues.apache.org/jira/browse/CLOUDSTACK-7527). Thx! was (Author: remibergsma): [~dahn] Now that you're working on this script, please also look at CLOUDSTACK-7527 (https://issues.apache.org/jira/browse/CLOUDSTACK-7527). Thx! > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128266#comment-14128266 ] Remi Bergsma commented on CLOUDSTACK-7184: -- [~dahn] Now that you're working on this script, please also look at CLOUDSTACK-7527 (https://issues.apache.org/jira/browse/CLOUDSTACK-7527). Thx! > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8878) No route to host on VPC router after stop/start/reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909158#comment-14909158 ] Remi Bergsma commented on CLOUDSTACK-8878: -- This will be addressed here: https://github.com/apache/cloudstack/pull/887 > No route to host on VPC router after stop/start/reboot > -- > > Key: CLOUDSTACK-8878 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8878 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > > The VPC router was broken after the fix applied for PR #765 resulting in 2 > exceptions in the test_vpc_routers.py: > === TestName: test_01_start_stop_router_after_addition_of_one_guest_network | > Status : EXCEPTION === > === TestName: test_02_reboot_router_after_addition_of_one_guest_network | > Status : EXCEPTION === > It has also been reproduced manually: > 1. Create a VPC > 2. Add tiers/VMs/Public IPs/PF rules > 3. Stop the router > 4. Start the router > Router won't start due to "no route to host error" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8791) VR Migrate fails with Error : invalid argument: virDomainDefFormatInternal: unsupported flags (0x8)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma closed CLOUDSTACK-8791.
> VR Migrate fails with Error : invalid argument: virDomainDefFormatInternal:
> unsupported flags (0x8)
> ---
>
> Key: CLOUDSTACK-8791
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8791
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
> Environment: KVM Hypervisor
>Reporter: Deepthi Machiraju
>Assignee: Remi Bergsma
>Priority: Critical
> Attachments: management-server.zip, mysqlcloud.dmp
>
>
> - Deploy a network , with RVR offering id and ensure both master and back up
> are UP and Running
> - Migrate 'Master' to the available suitable Host.
> Expected result :
> Migrate should be successful.
> Observation :
> Migrate is failing with the below exception :
> .utils.exception.CloudRuntimeException: invalid argument:
> virDomainDefFormatInternal: unsupported flags (0x8)
> 2015-08-31 12:12:54,074 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-114:ctx-32f05da2 job-187/job-188) Done with run of VM work
> job: com.cloud.vm.VmWorkMigrate for VM 39, job origin: 187
> 2015-08-31 12:12:54,074 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-114:ctx-32f05da2 job-187/job-188) Unable to complete
> AsyncJobVO {id:188, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkMigrate, cmdInfo:
> rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAJ3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAnNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXEAfgAJcQB-AAlwcQB-AAk,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 55769813040052, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Mon Aug 31 12:12:53 UTC 2015}, job origin:187
> com.cloud.utils.exception.CloudRuntimeException: invalid argument:
> virDomainDefFormatInternal: unsupported flags (0x8)
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1979)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1876)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4598)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4730)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2015-08-31 12:12:54,077 DEBUG [o.a.c.f.j.i.AsyncJ
[jira] [Resolved] (CLOUDSTACK-8791) VR Migrate fails with Error : invalid argument: virDomainDefFormatInternal: unsupported flags (0x8)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma resolved CLOUDSTACK-8791.
--
Resolution: Won't Fix
Assignee: Remi Bergsma
No response so closing. Use recent RHEL / CentOS version as this is a known
issue in RHEL / CentOS 6.3.
> VR Migrate fails with Error : invalid argument: virDomainDefFormatInternal:
> unsupported flags (0x8)
> ---
>
> Key: CLOUDSTACK-8791
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8791
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
> Environment: KVM Hypervisor
>Reporter: Deepthi Machiraju
>Assignee: Remi Bergsma
>Priority: Critical
> Attachments: management-server.zip, mysqlcloud.dmp
>
>
> - Deploy a network , with RVR offering id and ensure both master and back up
> are UP and Running
> - Migrate 'Master' to the available suitable Host.
> Expected result :
> Migrate should be successful.
> Observation :
> Migrate is failing with the below exception :
> .utils.exception.CloudRuntimeException: invalid argument:
> virDomainDefFormatInternal: unsupported flags (0x8)
> 2015-08-31 12:12:54,074 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-114:ctx-32f05da2 job-187/job-188) Done with run of VM work
> job: com.cloud.vm.VmWorkMigrate for VM 39, job origin: 187
> 2015-08-31 12:12:54,074 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-114:ctx-32f05da2 job-187/job-188) Unable to complete
> AsyncJobVO {id:188, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkMigrate, cmdInfo:
> rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAJ3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAnNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXEAfgAJcQB-AAlwcQB-AAk,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 55769813040052, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Mon Aug 31 12:12:53 UTC 2015}, job origin:187
> com.cloud.utils.exception.CloudRuntimeException: invalid argument:
> virDomainDefFormatInternal: unsupported flags (0x8)
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1979)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1876)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4598)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4730)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurr
[jira] [Commented] (CLOUDSTACK-8804) configure routes only in case of public networks when using vpc network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909165#comment-14909165 ] Remi Bergsma commented on CLOUDSTACK-8804: -- Probably fixed by https://github.com/apache/cloudstack/pull/887 please test once merged. > configure routes only in case of public networks when using vpc network. > > > Key: CLOUDSTACK-8804 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8804 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > In CsAddress.py the process() method adds routes to all the network types > which are not of type control, This should be fixed to add routes only in > case of public networks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8808) Successfully registered VHD template is downloaded again due to missing virtualsize property in template.properties
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909390#comment-14909390
]
Remi Bergsma commented on CLOUDSTACK-8808:
--
[~rajanik] Thanks, will see if I can find such a template. It'd be best to
reject it at register time indeed.
> Successfully registered VHD template is downloaded again due to missing
> virtualsize property in template.properties
> ---
>
> Key: CLOUDSTACK-8808
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8808
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.4.4, 4.6.0
> Environment: Seen on NFS as sec storage
>Reporter: Remi Bergsma
>Assignee: Rajani Karuturi
>Priority: Blocker
>
> We noticed all of our templates are downloaded again as soon as we restart
> SSVM, its Cloud service or the management server it connects to.
> A scan done by the SSVM (listvmtmplt.sh) returns the template, but it is
> rejected later (Post download installation was not completed) because (Format
> is invalid) due to missing virtualSize property in template.properties.
> The initial registration did succeed however. I'd either want the
> registration to fail, or it to succeed. Not first succeed (and spin VMs
> without a problem) then fail unexpectedly later.
> This is the script processing the download:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
> 759 private List listTemplates(String rootdir) {
>
> 760 List result = new ArrayList();
>
> 761
>
> 762 Script script = new Script(listTmpltScr, s_logger);
>
> 763 script.add("-r", rootdir);
> For example this becomes:
> ==> /usr/local/cloud/systemvm/scripts/storage/secondary/listvmtmplt.sh -r
> /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0
> In this log file, it processes the output:
> less /var/log/cloud/cloud.out
> 2015-09-04 08:39:54,622 WARN [storage.template.DownloadManagerImpl]
> (agentRequest-Handler-1:null) Post download installation was not completed
> for /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0/template/tmpl/2/1607
> This error message is generated here:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
>
> 780 List publicTmplts = listTemplates(templateDir);
>
> 781 for (String tmplt : publicTmplts) {
>
> 782 String path = tmplt.substring(0,
> tmplt.lastIndexOf(File.separator));
> 783 TemplateLocation loc = new TemplateLocation(_storage, path);
>
> 784 try {
>
> 785 if (!loc.load()) {
>
> 786 s_logger.warn("Post download installation was not
> completed for " + path);
> 787 // loc.purge();
>
> 788 _storage.cleanup(path, templateDir);
>
> 789 continue;
>
> 790 }
>
> 791 } catch (IOException e) {
>
> 792 s_logger.warn("Unable to load template location " +
> path, e);
> 793 continue;
>
> 794 }
> In the logs this message is also seen:
> MCCP-ADMIN-1|s-32436-VM CLOUDSTACK: 10:09:17,333 WARN TemplateLocation:196 -
> Format is invalid
> It is generated here:
> .//core/src/com/cloud/storage/template/TemplateLocation.java
> 192public boolean addFormat(FormatInfo newInfo) {
>
> 193 deleteFormat(newInfo.format);
>
> 194
>
> 195 if (!checkFormatValidity(newInfo)) {
>
> 196 s_logger.warn("Format is invalid ");
>
> 197 return false;
>
> 198 }
[jira] [Commented] (CLOUDSTACK-8915) Cannot SSH into VMs deployed Redundant VPC routers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909702#comment-14909702 ] Remi Bergsma commented on CLOUDSTACK-8915: -- Discussed and agreed it is a blocker. > Cannot SSH into VMs deployed Redundant VPC routers > -- > > Key: CLOUDSTACK-8915 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8915 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > > The Marvin test under componenet/test_vpc_redundant.py no longer passes. I > also tried to test it manually, but unfortunately the feature is now broken. > * Create a Redundant VPC > * Add a tier > * Add a new VM to the tier > * Add an ACL, open port 22 and associate the ACL with the tier > * Acquire a pub IP > * Add a PF rule to port 22 towards the VM > * Try to SSH to the VM through the Pub IP > It fails with "No route to host" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8843) Guest VMs are not getting IPs as the DHCP port is not opened in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8843. -- Resolution: Fixed Fixed by PR #887 et all > Guest VMs are not getting IPs as the DHCP port is not opened in VR > -- > > Key: CLOUDSTACK-8843 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8843 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 >Reporter: manasaveloori >Assignee: Jayapal Reddy >Priority: Blocker > Fix For: 4.6.0 > > > 1. Deployed CS with latest build. > 2. Deployed a guest VM. > 3. VM is not assigned any ip address. > Observation: > In VR 67 port is not opened > root@r-9-VM:~# iptables-save > # Generated by iptables-save v1.4.14 on Mon Sep 14 09:02:39 2015 > *filter > :INPUT DROP [10:3400] > :FORWARD DROP [0:0] > :OUTPUT ACCEPT [117:15233] > :FW_OUTBOUND - [0:0] > :NETWORK_STATS - [0:0] > -A INPUT -j NETWORK_STATS > -A INPUT -d 224.0.0.18/32 -j ACCEPT > -A INPUT -d 225.0.0.50/32 -j ACCEPT > -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -p icmp -j ACCEPT > -A INPUT -i lo -j ACCEPT > -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED > -j ACCEPT > -A FORWARD -j NETWORK_STATS > -A OUTPUT -j NETWORK_STATS > -A FW_OUTBOUND -m state --state RELATED,ESTABLISHED -j ACCEPT > -A NETWORK_STATS -i eth0 -o eth2 > -A NETWORK_STATS -i eth2 -o eth0 > -A NETWORK_STATS ! -i eth0 -o eth2 -p tcp > -A NETWORK_STATS -i eth2 ! -o eth0 -p tcp > COMMIT > # Completed on Mon Sep 14 09:02:39 2015 > # Generated by iptables-save v1.4.14 on Mon Sep 14 09:02:39 2015 > *nat > :PREROUTING ACCEPT [83:8482] > :INPUT ACCEPT [25:1716] > :OUTPUT ACCEPT [5:380] > :POSTROUTING ACCEPT [0:0] > -A POSTROUTING -o eth2 -j SNAT --to-source 10.147.47.7 > COMMIT > # Completed on Mon Sep 14 09:02:39 2015 > # Generated by iptables-save v1.4.14 on Mon Sep 14 09:02:39 2015 > *mangle > :PREROUTING ACCEPT [391:44422] > :INPUT ACCEPT [367:42880] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [342:47621] > :POSTROUTING ACCEPT [342:47621] > :FIREWALL_10.147.47.7 - [0:0] > :VPN_10.147.47.7 - [0:0] > -A PREROUTING -d 10.147.47.7/32 -j FIREWALL_10.147.47.7 > -A PREROUTING -d 10.147.47.7/32 -j VPN_10.147.47.7 > -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark > --nfmask 0x --ctmask 0x > -A PREROUTING -i eth2 -m state --state NEW -j CONNMARK --set-xmark > 0x2/0x > -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill > -A FIREWALL_10.147.47.7 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FIREWALL_10.147.47.7 -j DROP > -A VPN_10.147.47.7 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A VPN_10.147.47.7 -j RETURN > COMMIT > # Completed on Mon Sep 14 09:02:39 2015 > root@r-9-VM:~# -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8843) Guest VMs are not getting IPs as the DHCP port is not opened in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-8843. > Guest VMs are not getting IPs as the DHCP port is not opened in VR > -- > > Key: CLOUDSTACK-8843 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8843 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 >Reporter: manasaveloori >Assignee: Jayapal Reddy >Priority: Blocker > Fix For: 4.6.0 > > > 1. Deployed CS with latest build. > 2. Deployed a guest VM. > 3. VM is not assigned any ip address. > Observation: > In VR 67 port is not opened > root@r-9-VM:~# iptables-save > # Generated by iptables-save v1.4.14 on Mon Sep 14 09:02:39 2015 > *filter > :INPUT DROP [10:3400] > :FORWARD DROP [0:0] > :OUTPUT ACCEPT [117:15233] > :FW_OUTBOUND - [0:0] > :NETWORK_STATS - [0:0] > -A INPUT -j NETWORK_STATS > -A INPUT -d 224.0.0.18/32 -j ACCEPT > -A INPUT -d 225.0.0.50/32 -j ACCEPT > -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -p icmp -j ACCEPT > -A INPUT -i lo -j ACCEPT > -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED > -j ACCEPT > -A FORWARD -j NETWORK_STATS > -A OUTPUT -j NETWORK_STATS > -A FW_OUTBOUND -m state --state RELATED,ESTABLISHED -j ACCEPT > -A NETWORK_STATS -i eth0 -o eth2 > -A NETWORK_STATS -i eth2 -o eth0 > -A NETWORK_STATS ! -i eth0 -o eth2 -p tcp > -A NETWORK_STATS -i eth2 ! -o eth0 -p tcp > COMMIT > # Completed on Mon Sep 14 09:02:39 2015 > # Generated by iptables-save v1.4.14 on Mon Sep 14 09:02:39 2015 > *nat > :PREROUTING ACCEPT [83:8482] > :INPUT ACCEPT [25:1716] > :OUTPUT ACCEPT [5:380] > :POSTROUTING ACCEPT [0:0] > -A POSTROUTING -o eth2 -j SNAT --to-source 10.147.47.7 > COMMIT > # Completed on Mon Sep 14 09:02:39 2015 > # Generated by iptables-save v1.4.14 on Mon Sep 14 09:02:39 2015 > *mangle > :PREROUTING ACCEPT [391:44422] > :INPUT ACCEPT [367:42880] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [342:47621] > :POSTROUTING ACCEPT [342:47621] > :FIREWALL_10.147.47.7 - [0:0] > :VPN_10.147.47.7 - [0:0] > -A PREROUTING -d 10.147.47.7/32 -j FIREWALL_10.147.47.7 > -A PREROUTING -d 10.147.47.7/32 -j VPN_10.147.47.7 > -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark > --nfmask 0x --ctmask 0x > -A PREROUTING -i eth2 -m state --state NEW -j CONNMARK --set-xmark > 0x2/0x > -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill > -A FIREWALL_10.147.47.7 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FIREWALL_10.147.47.7 -j DROP > -A VPN_10.147.47.7 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A VPN_10.147.47.7 -j RETURN > COMMIT > # Completed on Mon Sep 14 09:02:39 2015 > root@r-9-VM:~# -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8878) No route to host on VPC router after stop/start/reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8878. -- Resolution: Fixed Fixed by PR #887 et all > No route to host on VPC router after stop/start/reboot > -- > > Key: CLOUDSTACK-8878 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8878 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > > The VPC router was broken after the fix applied for PR #765 resulting in 2 > exceptions in the test_vpc_routers.py: > === TestName: test_01_start_stop_router_after_addition_of_one_guest_network | > Status : EXCEPTION === > === TestName: test_02_reboot_router_after_addition_of_one_guest_network | > Status : EXCEPTION === > It has also been reproduced manually: > 1. Create a VPC > 2. Add tiers/VMs/Public IPs/PF rules > 3. Stop the router > 4. Start the router > Router won't start due to "no route to host error" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8878) No route to host on VPC router after stop/start/reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-8878. > No route to host on VPC router after stop/start/reboot > -- > > Key: CLOUDSTACK-8878 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8878 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > > The VPC router was broken after the fix applied for PR #765 resulting in 2 > exceptions in the test_vpc_routers.py: > === TestName: test_01_start_stop_router_after_addition_of_one_guest_network | > Status : EXCEPTION === > === TestName: test_02_reboot_router_after_addition_of_one_guest_network | > Status : EXCEPTION === > It has also been reproduced manually: > 1. Create a VPC > 2. Add tiers/VMs/Public IPs/PF rules > 3. Stop the router > 4. Start the router > Router won't start due to "no route to host error" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8881) [Blocker] PF , static nat , LB , egress rules not working in case of isolated networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8881. -- Resolution: Fixed Fixed by PR #887 et all > [Blocker] PF , static nat , LB , egress rules not working in case of isolated > networks > -- > > Key: CLOUDSTACK-8881 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8881 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > BVTs are failing as - > integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat > integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat > integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb > integration.smoke.test_network.TestPortForwarding.test_01_port_fwd_on_src_nat > integration.smoke.test_network.TestPortForwarding.test_02_port_fwd_on_non_src_nat > integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_1_static_nat_rule > integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_2_nat_rule > integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_3_Load_Balancer_Rule > integration.smoke.test_network.TestRebootRouter.test_reboot_router > Repro steps: > 1.Create a advance zone setup > 2. Create a VM in isolated network > 3. add PF rules, LB rules, Static nat rules ,firewall rules , Egress rules to > the network > ( i added the rules for port 22 and on different public ips by acquiring ips ) > Bug: > none of the rules works > Routers iptables shows following entries > Chain INPUT (policy DROP 1330 packets, 79806 bytes) > pkts bytes target prot opt in out source dest ination > 1616 116814 NETWORK_STATS all – * * 0.0.0.0/0 0. 0.0.0/0 > 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18 > 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50 > 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED > 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0 > 4 730 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0 > 255 34874 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state > NEW,ESTABLISHED > 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18 > 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50 > 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED > 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0 > 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0 > 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state > NEW,ESTABLISHED > 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18 > 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50 > 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED > 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0 > 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0 > 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state > NEW,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8905) [Blocker] Egress rules are not configured in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8905. -- Resolution: Fixed Fixed by PR #887 et all > [Blocker] Egress rules are not configured in VR > --- > > Key: CLOUDSTACK-8905 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8905 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Assignee: Jayapal Reddy >Priority: Blocker > Fix For: 4.6.0 > > > 1. Deployed CS Advanced zone. > 2. Created an isolated network. > 3. Navigate to Egress rule: > Observing a pop up message: > "Configure the rules to allow Traffic" > Inside VR : > root@r-9-VM:~# iptables-save > 1.Generated by iptables-save v1.4.14 on Wed Sep 23 10:46:46 2015 > *filter > :INPUT DROP [0:0] > :FORWARD DROP [0:0] > :OUTPUT ACCEPT [65:7867] > :FW_OUTBOUND - [0:0] > :NETWORK_STATS - [0:0] > -A INPUT -j NETWORK_STATS > -A INPUT -d 224.0.0.18/32 -j ACCEPT > -A INPUT -d 225.0.0.50/32 -j ACCEPT > -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -p icmp -j ACCEPT > -A INPUT -i lo -j ACCEPT > -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED > -j ACCEPT > -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED > -j ACCEPT > -A INPUT -d 224.0.0.18/32 -j ACCEPT > -A INPUT -d 225.0.0.50/32 -j ACCEPT > -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -p icmp -j ACCEPT > -A INPUT -i lo -j ACCEPT > -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT > -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT > -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT > -A INPUT -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT > -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT > -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED > -j ACCEPT > -A FORWARD -j NETWORK_STATS > -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FORWARD -i eth0 -o eth0 -m state --state NEW -j ACCEPT > -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FORWARD -i eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND > -A OUTPUT -j NETWORK_STATS > -A FW_OUTBOUND -m state --state RELATED,ESTABLISHED -j ACCEPT > -A NETWORK_STATS -i eth0 -o eth2 > -A NETWORK_STATS -i eth2 -o eth0 > -A NETWORK_STATS ! -i eth0 -o eth2 -p tcp > -A NETWORK_STATS -i eth2 ! -o eth0 -p tcp > COMMIT > 2.Completed on Wed Sep 23 10:46:46 2015 > 3.Generated by iptables-save v1.4.14 on Wed Sep 23 10:46:46 2015 > *nat > :PREROUTING ACCEPT [21:1428] > :INPUT ACCEPT [21:1428] > :OUTPUT ACCEPT [2:152] > :POSTROUTING ACCEPT [0:0] > -A POSTROUTING -o eth2 -j SNAT --to-source 10.147.47.9 > COMMIT > 4.Completed on Wed Sep 23 10:46:46 2015 > 5.Generated by iptables-save v1.4.14 on Wed Sep 23 10:46:46 2015 > *mangle > :PREROUTING ACCEPT [331:33456] > :INPUT ACCEPT [352:35052] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [331:44643] > :POSTROUTING ACCEPT [331:44643] > :FIREWALL_10.147.47.9 - [0:0] > :VPN_10.147.47.9 - [0:0] > -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK > --restore-mark --nfmask 0x --ctmask 0x > -A PREROUTING -d 10.147.47.9/32 -j FIREWALL_10.147.47.9 > -A PREROUTING -d 10.147.47.9/32 -j VPN_10.147.47.9 > -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK > --restore-mark --nfmask 0x --ctmask 0x > -A PREROUTING -i eth2 -m state --state NEW -j CONNMARK --set-xmark > 0x2/0x > -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark > 0x0/0x > -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill > -A FIREWALL_10.147.47.9 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FIREWALL_10.147.47.9 -j DROP > -A VPN_10.147.47.9 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A VPN_10.147.47.9 -j RETURN > COMMIT > 6.Completed on Wed Sep 23 10:46:46 2015 > root@r-9-VM:~# -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8881) [Blocker] PF , static nat , LB , egress rules not working in case of isolated networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-8881. > [Blocker] PF , static nat , LB , egress rules not working in case of isolated > networks > -- > > Key: CLOUDSTACK-8881 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8881 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > BVTs are failing as - > integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat > integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat > integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb > integration.smoke.test_network.TestPortForwarding.test_01_port_fwd_on_src_nat > integration.smoke.test_network.TestPortForwarding.test_02_port_fwd_on_non_src_nat > integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_1_static_nat_rule > integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_2_nat_rule > integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_3_Load_Balancer_Rule > integration.smoke.test_network.TestRebootRouter.test_reboot_router > Repro steps: > 1.Create a advance zone setup > 2. Create a VM in isolated network > 3. add PF rules, LB rules, Static nat rules ,firewall rules , Egress rules to > the network > ( i added the rules for port 22 and on different public ips by acquiring ips ) > Bug: > none of the rules works > Routers iptables shows following entries > Chain INPUT (policy DROP 1330 packets, 79806 bytes) > pkts bytes target prot opt in out source dest ination > 1616 116814 NETWORK_STATS all – * * 0.0.0.0/0 0. 0.0.0/0 > 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18 > 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50 > 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED > 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0 > 4 730 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0 > 255 34874 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state > NEW,ESTABLISHED > 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18 > 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50 > 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED > 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0 > 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0 > 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state > NEW,ESTABLISHED > 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18 > 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50 > 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED > 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0 > 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0 > 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state > NEW,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8905) [Blocker] Egress rules are not configured in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-8905. > [Blocker] Egress rules are not configured in VR > --- > > Key: CLOUDSTACK-8905 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8905 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Assignee: Jayapal Reddy >Priority: Blocker > Fix For: 4.6.0 > > > 1. Deployed CS Advanced zone. > 2. Created an isolated network. > 3. Navigate to Egress rule: > Observing a pop up message: > "Configure the rules to allow Traffic" > Inside VR : > root@r-9-VM:~# iptables-save > 1.Generated by iptables-save v1.4.14 on Wed Sep 23 10:46:46 2015 > *filter > :INPUT DROP [0:0] > :FORWARD DROP [0:0] > :OUTPUT ACCEPT [65:7867] > :FW_OUTBOUND - [0:0] > :NETWORK_STATS - [0:0] > -A INPUT -j NETWORK_STATS > -A INPUT -d 224.0.0.18/32 -j ACCEPT > -A INPUT -d 225.0.0.50/32 -j ACCEPT > -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -p icmp -j ACCEPT > -A INPUT -i lo -j ACCEPT > -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED > -j ACCEPT > -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED > -j ACCEPT > -A INPUT -d 224.0.0.18/32 -j ACCEPT > -A INPUT -d 225.0.0.50/32 -j ACCEPT > -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -p icmp -j ACCEPT > -A INPUT -i lo -j ACCEPT > -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT > -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT > -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT > -A INPUT -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT > -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT > -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED > -j ACCEPT > -A FORWARD -j NETWORK_STATS > -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FORWARD -i eth0 -o eth0 -m state --state NEW -j ACCEPT > -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FORWARD -i eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND > -A OUTPUT -j NETWORK_STATS > -A FW_OUTBOUND -m state --state RELATED,ESTABLISHED -j ACCEPT > -A NETWORK_STATS -i eth0 -o eth2 > -A NETWORK_STATS -i eth2 -o eth0 > -A NETWORK_STATS ! -i eth0 -o eth2 -p tcp > -A NETWORK_STATS -i eth2 ! -o eth0 -p tcp > COMMIT > 2.Completed on Wed Sep 23 10:46:46 2015 > 3.Generated by iptables-save v1.4.14 on Wed Sep 23 10:46:46 2015 > *nat > :PREROUTING ACCEPT [21:1428] > :INPUT ACCEPT [21:1428] > :OUTPUT ACCEPT [2:152] > :POSTROUTING ACCEPT [0:0] > -A POSTROUTING -o eth2 -j SNAT --to-source 10.147.47.9 > COMMIT > 4.Completed on Wed Sep 23 10:46:46 2015 > 5.Generated by iptables-save v1.4.14 on Wed Sep 23 10:46:46 2015 > *mangle > :PREROUTING ACCEPT [331:33456] > :INPUT ACCEPT [352:35052] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [331:44643] > :POSTROUTING ACCEPT [331:44643] > :FIREWALL_10.147.47.9 - [0:0] > :VPN_10.147.47.9 - [0:0] > -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK > --restore-mark --nfmask 0x --ctmask 0x > -A PREROUTING -d 10.147.47.9/32 -j FIREWALL_10.147.47.9 > -A PREROUTING -d 10.147.47.9/32 -j VPN_10.147.47.9 > -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK > --restore-mark --nfmask 0x --ctmask 0x > -A PREROUTING -i eth2 -m state --state NEW -j CONNMARK --set-xmark > 0x2/0x > -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark > 0x0/0x > -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill > -A FIREWALL_10.147.47.9 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FIREWALL_10.147.47.9 -j DROP > -A VPN_10.147.47.9 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A VPN_10.147.47.9 -j RETURN > COMMIT > 6.Completed on Wed Sep 23 10:46:46 2015 > root@r-9-VM:~# -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8804) configure routes only in case of public networks when using vpc network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8804. -- Resolution: Fixed Fixed by PR #887 et all > configure routes only in case of public networks when using vpc network. > > > Key: CLOUDSTACK-8804 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8804 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > In CsAddress.py the process() method adds routes to all the network types > which are not of type control, This should be fixed to add routes only in > case of public networks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8804) configure routes only in case of public networks when using vpc network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-8804. > configure routes only in case of public networks when using vpc network. > > > Key: CLOUDSTACK-8804 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8804 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > In CsAddress.py the process() method adds routes to all the network types > which are not of type control, This should be fixed to add routes only in > case of public networks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8914) cannot delete pod, NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909783#comment-14909783 ] Remi Bergsma commented on CLOUDSTACK-8914: -- May need backporting to 4.5. Has been fixed in 4.6. > cannot delete pod, NPE > -- > > Key: CLOUDSTACK-8914 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8914 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.2 > Environment: Simple test setup with one zone, one pod, one cluster, > one host >Reporter: Noel D. Kendall >Priority: Critical > Labels: patch > > Tried a cloudmonkey script to clean up an environment, deleting host, > cluster, pod and zone in order to recreate. > Failed through cloudmonkey. > Tried manually deleting pod, same error, same debug stack. NPE. > Log snippet below: > 2015-09-26 11:36:42,153 DEBUG [c.c.a.ApiServlet] > (catalina-exec-23:ctx-a265f355) ===START=== 172.16.1.14 -- GET > command=deletePod&id=a0be72da-4681-42dc-8d3a-324879d778b0&response=json&_=1443281802111 > 2015-09-26 11:36:42,216 DEBUG [c.c.u.d.T.Transaction] > (catalina-exec-23:ctx-a265f355 ctx-7a0bf087) Rolling back the transaction: > Time = 52 Name = catalina-exec-23; called by > -TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-Transaction.execute:49-Transaction.execute:54-ConfigurationManagerImpl.deletePod:1023-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:57-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:606-AopUtils.invokeJoinpointUsingReflection:317-ReflectiveMethodInvocation.invokeJoinpoint:183 > 2015-09-26 11:36:42,291 ERROR [c.c.a.ApiServer] > (catalina-exec-23:ctx-a265f355 ctx-7a0bf087) unhandled exception executing > api command: [Ljava.lang.String;@4a47022e > java.lang.NullPointerException > at > com.cloud.dc.dao.VlanDaoImpl.listVlansForPodByType(VlanDaoImpl.java:161) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy98.listVlansForPodByType(Unknown Source) > at > com.cloud.network.NetworkModelImpl.listPodVlans(NetworkModelImpl.java:796) > at > com.cloud.configuration.ConfigurationManagerImpl$1.doInTransactionWithoutResult(ConfigurationManagerImpl.java:1043) > at > com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) > at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at com.cloud.utils.db.Transaction.execute(Transaction.java:54) > at > com.cloud.configuration.ConfigurationManagerImpl.deletePod(ConfigurationManagerImpl.java:1023) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java
[jira] [Commented] (CLOUDSTACK-8697) Assign VPC Internal LB rule to a VM fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909785#comment-14909785
]
Remi Bergsma commented on CLOUDSTACK-8697:
--
[~pavanb] Can you please test with latest master and see if it is still broken?
Thanks!
> Assign VPC Internal LB rule to a VM fails
> -
>
> Key: CLOUDSTACK-8697
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8697
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Attachments: MSLog.rar
>
>
> Assigning an internal LB rule to a VM inside VPC network fails. Seems to be a
> configuration issue.
>
> 2015-07-31 21:13:49,059 ERROR [c.c.u.s.SshHelper]
> (DirectAgent-345:ctx-2bdddfcc) SSH execution of command
> /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.171
> load_balancer.json has an error status code in return. result output:
> 2015-07-31 21:13:49,062 DEBUG [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-345:ctx-2bdddfcc) Processing ScriptConfigItem, executing
> update_config.py load_balancer.json took 6656ms
> 2015-07-31 21:13:49,062 WARN [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-345:ctx-2bdddfcc) Expected 1 answers while executing
> LoadBalancerConfigCommand but received 2
> 2015-07-31 21:13:49,062 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Response Received:
> 2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request]
> (DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Processing: { Ans:
> , MgmtId: 6702933999656, via: 7, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.routing.GroupAnswer":{"results":["null - failed:
> ","null - failed: "],"result":false,"wait":0}}] }
> 2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) Seq
> 7-4435764157983228083: Received: { Ans: , MgmtId: 6702933999656, via: 7,
> Ver: v1, Flags: 0, { GroupAnswer } }
> 2015-07-31 21:13:49,133 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl]
> (API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) LB Rollback rule id: 6
> while attaching VM: [29]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8697) Assign VPC Internal LB rule to a VM fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933198#comment-14933198
]
Remi Bergsma commented on CLOUDSTACK-8697:
--
[~wilder.rodrigues] I asked [~pavanb] to check it again. We'll look into it
soon.
> Assign VPC Internal LB rule to a VM fails
> -
>
> Key: CLOUDSTACK-8697
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8697
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Attachments: MS Log.rar, MSLog.rar
>
>
> Assigning an internal LB rule to a VM inside VPC network fails. Seems to be a
> configuration issue.
>
> 2015-07-31 21:13:49,059 ERROR [c.c.u.s.SshHelper]
> (DirectAgent-345:ctx-2bdddfcc) SSH execution of command
> /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.171
> load_balancer.json has an error status code in return. result output:
> 2015-07-31 21:13:49,062 DEBUG [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-345:ctx-2bdddfcc) Processing ScriptConfigItem, executing
> update_config.py load_balancer.json took 6656ms
> 2015-07-31 21:13:49,062 WARN [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-345:ctx-2bdddfcc) Expected 1 answers while executing
> LoadBalancerConfigCommand but received 2
> 2015-07-31 21:13:49,062 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Response Received:
> 2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request]
> (DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Processing: { Ans:
> , MgmtId: 6702933999656, via: 7, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.routing.GroupAnswer":{"results":["null - failed:
> ","null - failed: "],"result":false,"wait":0}}] }
> 2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) Seq
> 7-4435764157983228083: Received: { Ans: , MgmtId: 6702933999656, via: 7,
> Ver: v1, Flags: 0, { GroupAnswer } }
> 2015-07-31 21:13:49,133 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl]
> (API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) LB Rollback rule id: 6
> while attaching VM: [29]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8920) KVM agent cannot communicate with server on port 8250
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-8920: - Priority: Major (was: Blocker) > KVM agent cannot communicate with server on port 8250 > - > > Key: CLOUDSTACK-8920 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8920 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.2 > Environment: CentOS 6.7, OpenJDK 1.7.0 >Reporter: Noel D. Kendall > > Attempting to add a KVM host, the management server is able to reach the > target host via SSH and successfully changes agent.properties, and restarts > the agent process. All that works fine. Zone, Pod and Cluster are configured > successfully. > Problem is occurring on the agent when attempting to contact the management > server on port 8250. Getting an ERROR logged, unable to initialize the > threads, with an IOException -1 connection closed with -1 on reading size. > This sounds suspiciously like an SSL client is attempting to connect to a > non-SSL server. For the life of me, I cannot see how this is configured or > misconfigured. > I have created SSL certificates for the proxies, and successfully uploaded > these, following the documentation. Not sure this is related in any way or > not. > Have turned on full debugging log output in log4j, not seeing any elaboration > on the underlying cause of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8920) KVM agent cannot communicate with server on port 8250
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935103#comment-14935103 ] Remi Bergsma commented on CLOUDSTACK-8920: -- This works fine in my environment. Are you able to telnet to the management server over port 8250? Set the pro to critical, as this is not a blocker for release. > KVM agent cannot communicate with server on port 8250 > - > > Key: CLOUDSTACK-8920 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8920 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.2 > Environment: CentOS 6.7, OpenJDK 1.7.0 >Reporter: Noel D. Kendall > > Attempting to add a KVM host, the management server is able to reach the > target host via SSH and successfully changes agent.properties, and restarts > the agent process. All that works fine. Zone, Pod and Cluster are configured > successfully. > Problem is occurring on the agent when attempting to contact the management > server on port 8250. Getting an ERROR logged, unable to initialize the > threads, with an IOException -1 connection closed with -1 on reading size. > This sounds suspiciously like an SSL client is attempting to connect to a > non-SSL server. For the life of me, I cannot see how this is configured or > misconfigured. > I have created SSL certificates for the proxies, and successfully uploaded > these, following the documentation. Not sure this is related in any way or > not. > Have turned on full debugging log output in log4j, not seeing any elaboration > on the underlying cause of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8923) Create storage network IP range failed, Unknown parameters : zoneid
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935236#comment-14935236
]
Remi Bergsma commented on CLOUDSTACK-8923:
--
Hi [~nuxro] ! I am unable to reproduce but of course there still could be a
problem. Can you let me know what info you supply in the wizard? Then I'm going
to do exactly the same to see if we can find the issue.
Every PR I test I build from scratch and deploy a new CloudStack environment.
That works fine.
Let's find the difference!
The error is thrown here:
api/src/org/apache/cloudstack/api/command/admin/network/CreateStorageNetworkIpRangeCmd.java
@Override
115 public void execute() throws ResourceUnavailableException,
InsufficientCapacityException, ServerApiException, ConcurrentOperationException,
116 ResourceAllocationException {
117 try {
118 StorageNetworkIpRange result =
_storageNetworkService.createIpRange(this);
119 StorageNetworkIpRangeResponse response =
_responseGenerator.createStorageNetworkIpRangeResponse(result);
120 response.setResponseName(getCommandName());
121 this.setResponseObject(response);
122 } catch (Exception e) {
123 s_logger.warn("Create storage network IP range failed", e);
124 throw new ServerApiException(ApiErrorCode.INTERNAL_ERROR,
e.getMessage());
125 }
126 }
127
> Create storage network IP range failed, Unknown parameters : zoneid
> ---
>
> Key: CLOUDSTACK-8923
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8923
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs and MGMT
>Reporter: Nux
>Priority: Blocker
>
> I am installing ACS from today's master (3ded3e9
> http://tmp.nux.ro/acs460snap/ ).
> Adding an initial zone via the web UI wizard fails at the secondary storage
> setup stage:
> 2015-09-29 14:07:40,319 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Add job-27 into job monitoring
> 2015-09-29 14:07:40,322 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-314bbaae ctx-2db63923) ===END=== 85.13.192.198 -- GET
> command=createStorageNetworkIpRange&response=json&gateway=192.168.200.67&netmask=255.255.255.0&vlan=123&startip=192.168.200.200&endip=192.168.200.222&zoneid=2f0efdcf-adf6-4373-858e-87de6af4cc08&podid=eb7814d2-9a22-4ca4-93af-4a6b8abac67c&_=1443532060283
> 2015-09-29 14:07:40,327 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Executing AsyncJobVO {id:27,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd,
> cmdInfo: {"response":"json","ctxDetails":"{\"interface
> com.cloud.dc.Pod\":\"eb7814d2-9a22-4ca4-93af-4a6b8abac67c\"}","cmdEventType":"STORAGE.IP.RANGE.CREATE","ctxUserId":"2","gateway":"192.168.200.67","podid":"eb7814d2-9a22-4ca4-93af-4a6b8abac67c","zoneid":"2f0efdcf-adf6-4373-858e-87de6af4cc08","startip":"192.168.200.200","vlan":"123","httpmethod":"GET","_":"1443532060283","ctxAccountId":"2","ctxStartEventId":"68","netmask":"255.255.255.0","endip":"192.168.200.222"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-09-29 14:07:40,330 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Received unknown
> parameters for command createStorageNetworkIpRange. Unknown parameters :
> zoneid
> 2015-09-29 14:07:40,391 WARN [o.a.c.a.c.a.n.CreateStorageNetworkIpRangeCmd]
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Create storage network
> IP range failed
> com.cloud.utils.exception.CloudRuntimeException: Unable to commit or close
> the connection.
> at
> com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:730)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
> at
> c
[jira] [Commented] (CLOUDSTACK-8923) Create storage network IP range failed, Unknown parameters : zoneid
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936658#comment-14936658
]
Remi Bergsma commented on CLOUDSTACK-8923:
--
Thanks [~nuxro] will look into it soon. Can you also post the CloudMonkey
command please?
> Create storage network IP range failed, Unknown parameters : zoneid
> ---
>
> Key: CLOUDSTACK-8923
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8923
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs and MGMT
>Reporter: Nux
>Priority: Blocker
>
> I am installing ACS from today's master (3ded3e9
> http://tmp.nux.ro/acs460snap/ ).
> Adding an initial zone via the web UI wizard fails at the secondary storage
> setup stage:
> 2015-09-29 14:07:40,319 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Add job-27 into job monitoring
> 2015-09-29 14:07:40,322 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-314bbaae ctx-2db63923) ===END=== 85.13.192.198 -- GET
> command=createStorageNetworkIpRange&response=json&gateway=192.168.200.67&netmask=255.255.255.0&vlan=123&startip=192.168.200.200&endip=192.168.200.222&zoneid=2f0efdcf-adf6-4373-858e-87de6af4cc08&podid=eb7814d2-9a22-4ca4-93af-4a6b8abac67c&_=1443532060283
> 2015-09-29 14:07:40,327 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Executing AsyncJobVO {id:27,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd,
> cmdInfo: {"response":"json","ctxDetails":"{\"interface
> com.cloud.dc.Pod\":\"eb7814d2-9a22-4ca4-93af-4a6b8abac67c\"}","cmdEventType":"STORAGE.IP.RANGE.CREATE","ctxUserId":"2","gateway":"192.168.200.67","podid":"eb7814d2-9a22-4ca4-93af-4a6b8abac67c","zoneid":"2f0efdcf-adf6-4373-858e-87de6af4cc08","startip":"192.168.200.200","vlan":"123","httpmethod":"GET","_":"1443532060283","ctxAccountId":"2","ctxStartEventId":"68","netmask":"255.255.255.0","endip":"192.168.200.222"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-09-29 14:07:40,330 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Received unknown
> parameters for command createStorageNetworkIpRange. Unknown parameters :
> zoneid
> 2015-09-29 14:07:40,391 WARN [o.a.c.a.c.a.n.CreateStorageNetworkIpRangeCmd]
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Create storage network
> IP range failed
> com.cloud.utils.exception.CloudRuntimeException: Unable to commit or close
> the connection.
> at
> com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:730)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
> at
> com.cloud.network.StorageNetworkManagerImpl.createIpRange(StorageNetworkManagerImpl.java:229)
> at
> org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd.execute(CreateStorageNetworkIpRangeCmd.java:118)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
> at
> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.sql.SQLException: Connection is closed.
> at
> org.apache.commons.dbcp.Po
[jira] [Commented] (CLOUDSTACK-8923) Create storage network IP range failed, Unknown parameters : zoneid
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936942#comment-14936942
]
Remi Bergsma commented on CLOUDSTACK-8923:
--
[~nuxro] Thanks for the feedback, I was now able to reproduce the issue. With
or without the vlan specified.
WARN [o.a.c.a.c.a.n.CreateStorageNetworkIpRangeCmd]
(API-Job-Executor-41:ctx-6548cd93 job-719 ctx-8edc48f6) Create storage network
IP range failed
com.cloud.utils.exception.CloudRuntimeException: Unable to commit or close the
connection.
at
com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:730)
at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
at
com.cloud.network.StorageNetworkManagerImpl.createIpRange(StorageNetworkManagerImpl.java:229)
at
org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd.execute(CreateStorageNetworkIpRangeCmd.java:118)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
at
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.sql.SQLException: Connection is closed.
at
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.checkOpen(PoolingDataSource.java:185)
at
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:210)
at
com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:722)
... 17 more
ERROR [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-41:ctx-6548cd93
job-719) Unexpected exception
com.cloud.utils.exception.CloudRuntimeException: DB Exception on: null
It looks like a SQL problem
...
Caused by: java.sql.SQLException: Connection is closed.
...
[~rajanik] Can you have a look please?
> Create storage network IP range failed, Unknown parameters : zoneid
> ---
>
> Key: CLOUDSTACK-8923
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8923
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs and MGMT
>Reporter: Nux
>Priority: Blocker
>
> I am installing ACS from today's master (3ded3e9
> http://tmp.nux.ro/acs460snap/ ).
> Adding an initial zone via the web UI wizard fails at the secondary storage
> setup stage:
> 2015-09-29 14:07:40,319 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Add job-27 into job monitoring
> 2015-09-29 14:07:40,322 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-314bbaae ctx-2db63923) ===END=== 85.13.192.198 -- GET
> command=createStorageNetworkIpRange&response=json&gateway=192.168.200.67&netmask=255.255.255.0&vlan=123&startip=192.168.200.200&endip=192.168.200.222&zoneid=2f0efdcf-adf6-4373-858e-87de6af4cc08&podid=eb7814d2-9a22-4ca4-93af-4a6b8abac67c&_=1443532060283
> 2015-09-29 14:07:40,327 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Executing AsyncJobVO {id:27,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd,
> cmdInfo: {"response":"json","ctxDetails":"{\"interface
> com.cloud.dc.Pod\":\"eb7814d2-9a22-4ca4-93af-4a6b8abac67c\"}","cmdEventType":"STORAGE.IP.RANGE.CREATE","ctxUserId":"2","gateway":"192.168.200.67","podid":"eb7814d2-9a22-4ca4-93af-4a6b8abac67c","zoneid":"2f0efdcf-adf6-4373-858e-87de6af4cc08","startip":"192.168.200.200","vlan":
[jira] [Commented] (CLOUDSTACK-8924) [Blocker] test duplicated in test_scale_vm.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940805#comment-14940805
]
Remi Bergsma commented on CLOUDSTACK-8924:
--
[~rajapu] PR 900 is merged, can we resolve this? If not, please specify what
needs to be done. Thanks!
> [Blocker] test duplicated in test_scale_vm.py
> -
>
> Key: CLOUDSTACK-8924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8924
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
> Fix For: 4.6.0
>
>
> This is a blocker because BVTs for XS and Simulator are failing.
> Simulator zone - it is failing because
> This is a genuine failure - because the setup didn't have Dynamic Scaling
> enabled as part of global settings. Once it is enabled the tests ran fine.
> XS basic/Advzone - it is failing because
> the methods
> test_01_scale_vm(self):
> test_02_scale_vm_without_hypervisor_specifics(self):
> are essentially same with the exception of tags -
> first one - test_01_scale_vm - had a "required_hardware=true"
> second - test_02_scale_vm_without_hypervisor_specific had a
> "required_hardware=false"
> essentially we can get this test run on both Simulator and XenServer by
> modifying the "required_hardware=false".
> and test_02_scale_vm_without_hypervisor_specifc - can be deleted.
> The reason for failure on the XS is due to the following - "Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering"
> Following are the logs:
> Test scale virtual machine ... === TestName: test_01_scale_vm | Status :
> SUCCESS ===
> ok
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm) ... === TestName:
> test_02_scale_vm_without_hypervisor_specifics | Status : EXCEPTION ===
> ERROR
> ==
> ERROR: test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm)
> --
> Traceback (most recent call last):
> File "/root/cloudstack/test/integration/smoke/test_scale_vm.py", line 234,
> in test_02_scale_vm_without_hypervisor_specifics
> self.apiclient.scaleVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 797, in scaleVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created :
> u'2015-09-30T01:16:45+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin', userid :
> u'd46c0476-670a-11e5-8245-96e5a2a4ae9a', jobstatus : 2, jobid :
> u'ad32dee5-da3c-42c3-bdc3-35928b47697f', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering
> (BigInstance)'}, accountid : u'd46bf47c-670a-11e5-8245-96e5a2a4ae9a'}
> >> begin captured stdout << -
> === TestName: test_02_scale_vm_without_hypervisor_specifics | Status :
> EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: STARTED :
> TC: test_02_scale_vm_without_hypervisor_specifics :::
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Payload:
> {'isdynamicallyscalable': 'true', 'apiKey':
> u'FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w',
> 'response': 'json', 'command': 'updateVirtualMachine', 'signature':
> '4dANF6uDGtaOk6jIDb901ES+Oq8=', 'id': u'38c1ced0-693f-4e31-b976-9f4161ac57bb'}
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Sending GET Cmd
> : updateVirtualMachine===
> urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.220.135.73
> urllib3.connectionpool: DEBUG: "GET
> /client/api?isdynamicallyscalable=true&apiKey=FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w&response=json&command=updateVirtualMachine&signature=4dANF6uDGtaOk6jIDb901ES%2BOq8%3D&id=38c1ced0-693f-4e31-b976-9f4161ac57bb
> HTTP/1.1" 200 1703
> test_02_scale_vm_without_hyp
[jira] [Closed] (CLOUDSTACK-8924) [Blocker] test duplicated in test_scale_vm.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma closed CLOUDSTACK-8924.
> [Blocker] test duplicated in test_scale_vm.py
> -
>
> Key: CLOUDSTACK-8924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8924
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
> Fix For: 4.6.0
>
>
> This is a blocker because BVTs for XS and Simulator are failing.
> Simulator zone - it is failing because
> This is a genuine failure - because the setup didn't have Dynamic Scaling
> enabled as part of global settings. Once it is enabled the tests ran fine.
> XS basic/Advzone - it is failing because
> the methods
> test_01_scale_vm(self):
> test_02_scale_vm_without_hypervisor_specifics(self):
> are essentially same with the exception of tags -
> first one - test_01_scale_vm - had a "required_hardware=true"
> second - test_02_scale_vm_without_hypervisor_specific had a
> "required_hardware=false"
> essentially we can get this test run on both Simulator and XenServer by
> modifying the "required_hardware=false".
> and test_02_scale_vm_without_hypervisor_specifc - can be deleted.
> The reason for failure on the XS is due to the following - "Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering"
> Following are the logs:
> Test scale virtual machine ... === TestName: test_01_scale_vm | Status :
> SUCCESS ===
> ok
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm) ... === TestName:
> test_02_scale_vm_without_hypervisor_specifics | Status : EXCEPTION ===
> ERROR
> ==
> ERROR: test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm)
> --
> Traceback (most recent call last):
> File "/root/cloudstack/test/integration/smoke/test_scale_vm.py", line 234,
> in test_02_scale_vm_without_hypervisor_specifics
> self.apiclient.scaleVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 797, in scaleVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created :
> u'2015-09-30T01:16:45+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin', userid :
> u'd46c0476-670a-11e5-8245-96e5a2a4ae9a', jobstatus : 2, jobid :
> u'ad32dee5-da3c-42c3-bdc3-35928b47697f', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering
> (BigInstance)'}, accountid : u'd46bf47c-670a-11e5-8245-96e5a2a4ae9a'}
> >> begin captured stdout << -
> === TestName: test_02_scale_vm_without_hypervisor_specifics | Status :
> EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: STARTED :
> TC: test_02_scale_vm_without_hypervisor_specifics :::
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Payload:
> {'isdynamicallyscalable': 'true', 'apiKey':
> u'FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w',
> 'response': 'json', 'command': 'updateVirtualMachine', 'signature':
> '4dANF6uDGtaOk6jIDb901ES+Oq8=', 'id': u'38c1ced0-693f-4e31-b976-9f4161ac57bb'}
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Sending GET Cmd
> : updateVirtualMachine===
> urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.220.135.73
> urllib3.connectionpool: DEBUG: "GET
> /client/api?isdynamicallyscalable=true&apiKey=FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w&response=json&command=updateVirtualMachine&signature=4dANF6uDGtaOk6jIDb901ES%2BOq8%3D&id=38c1ced0-693f-4e31-b976-9f4161ac57bb
> HTTP/1.1" 200 1703
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Response : {domain :
> u'ROOT', domainid : u'a6d8fc3a-670a-11e5-8245-96e5a2a4ae9a', haen
[jira] [Resolved] (CLOUDSTACK-8924) [Blocker] test duplicated in test_scale_vm.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma resolved CLOUDSTACK-8924.
--
Resolution: Fixed
> [Blocker] test duplicated in test_scale_vm.py
> -
>
> Key: CLOUDSTACK-8924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8924
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
> Fix For: 4.6.0
>
>
> This is a blocker because BVTs for XS and Simulator are failing.
> Simulator zone - it is failing because
> This is a genuine failure - because the setup didn't have Dynamic Scaling
> enabled as part of global settings. Once it is enabled the tests ran fine.
> XS basic/Advzone - it is failing because
> the methods
> test_01_scale_vm(self):
> test_02_scale_vm_without_hypervisor_specifics(self):
> are essentially same with the exception of tags -
> first one - test_01_scale_vm - had a "required_hardware=true"
> second - test_02_scale_vm_without_hypervisor_specific had a
> "required_hardware=false"
> essentially we can get this test run on both Simulator and XenServer by
> modifying the "required_hardware=false".
> and test_02_scale_vm_without_hypervisor_specifc - can be deleted.
> The reason for failure on the XS is due to the following - "Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering"
> Following are the logs:
> Test scale virtual machine ... === TestName: test_01_scale_vm | Status :
> SUCCESS ===
> ok
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm) ... === TestName:
> test_02_scale_vm_without_hypervisor_specifics | Status : EXCEPTION ===
> ERROR
> ==
> ERROR: test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm)
> --
> Traceback (most recent call last):
> File "/root/cloudstack/test/integration/smoke/test_scale_vm.py", line 234,
> in test_02_scale_vm_without_hypervisor_specifics
> self.apiclient.scaleVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 797, in scaleVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created :
> u'2015-09-30T01:16:45+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin', userid :
> u'd46c0476-670a-11e5-8245-96e5a2a4ae9a', jobstatus : 2, jobid :
> u'ad32dee5-da3c-42c3-bdc3-35928b47697f', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering
> (BigInstance)'}, accountid : u'd46bf47c-670a-11e5-8245-96e5a2a4ae9a'}
> >> begin captured stdout << -
> === TestName: test_02_scale_vm_without_hypervisor_specifics | Status :
> EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: STARTED :
> TC: test_02_scale_vm_without_hypervisor_specifics :::
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Payload:
> {'isdynamicallyscalable': 'true', 'apiKey':
> u'FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w',
> 'response': 'json', 'command': 'updateVirtualMachine', 'signature':
> '4dANF6uDGtaOk6jIDb901ES+Oq8=', 'id': u'38c1ced0-693f-4e31-b976-9f4161ac57bb'}
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Sending GET Cmd
> : updateVirtualMachine===
> urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.220.135.73
> urllib3.connectionpool: DEBUG: "GET
> /client/api?isdynamicallyscalable=true&apiKey=FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w&response=json&command=updateVirtualMachine&signature=4dANF6uDGtaOk6jIDb901ES%2BOq8%3D&id=38c1ced0-693f-4e31-b976-9f4161ac57bb
> HTTP/1.1" 200 1703
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Response : {domain :
> u'ROOT', domainid : u'a6d8fc3a-670a-11e
[jira] [Closed] (CLOUDSTACK-8808) Successfully registered VHD template is downloaded again due to missing virtualsize property in template.properties
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma closed CLOUDSTACK-8808.
> Successfully registered VHD template is downloaded again due to missing
> virtualsize property in template.properties
> ---
>
> Key: CLOUDSTACK-8808
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8808
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.4.4, 4.6.0
> Environment: Seen on NFS as sec storage
>Reporter: Remi Bergsma
>Assignee: Rajani Karuturi
>Priority: Blocker
>
> We noticed all of our templates are downloaded again as soon as we restart
> SSVM, its Cloud service or the management server it connects to.
> A scan done by the SSVM (listvmtmplt.sh) returns the template, but it is
> rejected later (Post download installation was not completed) because (Format
> is invalid) due to missing virtualSize property in template.properties.
> The initial registration did succeed however. I'd either want the
> registration to fail, or it to succeed. Not first succeed (and spin VMs
> without a problem) then fail unexpectedly later.
> This is the script processing the download:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
> 759 private List listTemplates(String rootdir) {
>
> 760 List result = new ArrayList();
>
> 761
>
> 762 Script script = new Script(listTmpltScr, s_logger);
>
> 763 script.add("-r", rootdir);
> For example this becomes:
> ==> /usr/local/cloud/systemvm/scripts/storage/secondary/listvmtmplt.sh -r
> /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0
> In this log file, it processes the output:
> less /var/log/cloud/cloud.out
> 2015-09-04 08:39:54,622 WARN [storage.template.DownloadManagerImpl]
> (agentRequest-Handler-1:null) Post download installation was not completed
> for /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0/template/tmpl/2/1607
> This error message is generated here:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
>
> 780 List publicTmplts = listTemplates(templateDir);
>
> 781 for (String tmplt : publicTmplts) {
>
> 782 String path = tmplt.substring(0,
> tmplt.lastIndexOf(File.separator));
> 783 TemplateLocation loc = new TemplateLocation(_storage, path);
>
> 784 try {
>
> 785 if (!loc.load()) {
>
> 786 s_logger.warn("Post download installation was not
> completed for " + path);
> 787 // loc.purge();
>
> 788 _storage.cleanup(path, templateDir);
>
> 789 continue;
>
> 790 }
>
> 791 } catch (IOException e) {
>
> 792 s_logger.warn("Unable to load template location " +
> path, e);
> 793 continue;
>
> 794 }
> In the logs this message is also seen:
> MCCP-ADMIN-1|s-32436-VM CLOUDSTACK: 10:09:17,333 WARN TemplateLocation:196 -
> Format is invalid
> It is generated here:
> .//core/src/com/cloud/storage/template/TemplateLocation.java
> 192public boolean addFormat(FormatInfo newInfo) {
>
> 193 deleteFormat(newInfo.format);
>
> 194
>
> 195 if (!checkFormatValidity(newInfo)) {
>
> 196 s_logger.warn("Format is invalid ");
>
> 197 return false;
>
> 198 }
>
> 199
>
> 200 _props.setProperty("virtualsize",
> Long.t
[jira] [Resolved] (CLOUDSTACK-8808) Successfully registered VHD template is downloaded again due to missing virtualsize property in template.properties
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma resolved CLOUDSTACK-8808.
--
Resolution: Fixed
> Successfully registered VHD template is downloaded again due to missing
> virtualsize property in template.properties
> ---
>
> Key: CLOUDSTACK-8808
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8808
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.4.4, 4.6.0
> Environment: Seen on NFS as sec storage
>Reporter: Remi Bergsma
>Assignee: Rajani Karuturi
>Priority: Blocker
>
> We noticed all of our templates are downloaded again as soon as we restart
> SSVM, its Cloud service or the management server it connects to.
> A scan done by the SSVM (listvmtmplt.sh) returns the template, but it is
> rejected later (Post download installation was not completed) because (Format
> is invalid) due to missing virtualSize property in template.properties.
> The initial registration did succeed however. I'd either want the
> registration to fail, or it to succeed. Not first succeed (and spin VMs
> without a problem) then fail unexpectedly later.
> This is the script processing the download:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
> 759 private List listTemplates(String rootdir) {
>
> 760 List result = new ArrayList();
>
> 761
>
> 762 Script script = new Script(listTmpltScr, s_logger);
>
> 763 script.add("-r", rootdir);
> For example this becomes:
> ==> /usr/local/cloud/systemvm/scripts/storage/secondary/listvmtmplt.sh -r
> /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0
> In this log file, it processes the output:
> less /var/log/cloud/cloud.out
> 2015-09-04 08:39:54,622 WARN [storage.template.DownloadManagerImpl]
> (agentRequest-Handler-1:null) Post download installation was not completed
> for /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0/template/tmpl/2/1607
> This error message is generated here:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
>
> 780 List publicTmplts = listTemplates(templateDir);
>
> 781 for (String tmplt : publicTmplts) {
>
> 782 String path = tmplt.substring(0,
> tmplt.lastIndexOf(File.separator));
> 783 TemplateLocation loc = new TemplateLocation(_storage, path);
>
> 784 try {
>
> 785 if (!loc.load()) {
>
> 786 s_logger.warn("Post download installation was not
> completed for " + path);
> 787 // loc.purge();
>
> 788 _storage.cleanup(path, templateDir);
>
> 789 continue;
>
> 790 }
>
> 791 } catch (IOException e) {
>
> 792 s_logger.warn("Unable to load template location " +
> path, e);
> 793 continue;
>
> 794 }
> In the logs this message is also seen:
> MCCP-ADMIN-1|s-32436-VM CLOUDSTACK: 10:09:17,333 WARN TemplateLocation:196 -
> Format is invalid
> It is generated here:
> .//core/src/com/cloud/storage/template/TemplateLocation.java
> 192public boolean addFormat(FormatInfo newInfo) {
>
> 193 deleteFormat(newInfo.format);
>
> 194
>
> 195 if (!checkFormatValidity(newInfo)) {
>
> 196 s_logger.warn("Format is invalid ");
>
> 197 return false;
>
> 198 }
>
> 199
>
> 200 _props.setPropert
[jira] [Updated] (CLOUDSTACK-8848) ensure power state is up to date when handling missing VMs in pwerReport
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma updated CLOUDSTACK-8848:
-
Summary: ensure power state is up to date when handling missing VMs in
pwerReport (was: Unexpected VR reboot after out-of-band migration)
> ensure power state is up to date when handling missing VMs in pwerReport
>
>
> Key: CLOUDSTACK-8848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8848
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.5.2, 4.6.0
>Reporter: René Moser
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.5.3, 4.6.0
>
>
> In some conditions (race condition), VR gets rebooted after a out of band
> migration was done on vCenter.
> {panel:bgColor=#CE}
> Note, new global setting in 4.5.2 "VR reboot after out of band migration" is
> set to *false* and this looks more like a bug.
> {panel}
> After a VR migration to a host _and_ when the VM power state report gathering
> is running, the VR (and also any user VM as well) will get into the
> "PowerReportMissing".
> If the VM is a VR. it will be powered off and started again on vCenter. That
> is what we see. In can not be reproduced every time a migration was done, but
> it seems the problem is related to "powerReportMissing".
> I grep-ed the source and found this line related
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java#L3616
> and also it seems that the graceful period might be also related,
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachinePowerStateSyncImpl.java#L110
> In case it is a user VM, we see in the logs that the state will be set to
> powered-off, but the VM keeps running. After a while a new VM power state
> report is running and the state for the user VM gets updated to Running
> again. Below the logs
> h2. VR r-342-VM reboot log
> {code:none}
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) Run missing VM report. current time:
> 1442302626508
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) Detected missing VM. host: 19, vm id:
> 342, power state: PowerReportMissing, last state update: 1442302506000
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) vm id: 342 - time since last state
> update(120508ms) has passed graceful period
> 2015-09-15 09:37:06,517 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) VM state report is updated. host: 19,
> vm id: 342, power state: PowerReportMissing
> 2015-09-15 09:37:06,525 INFO [c.c.v.VirtualMachineManagerImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) VM r-342-VM is at Running and we
> received a power-off report while there is no pending jobs on it
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.t.Request]
> (DirectAgentCronJob-253:ctx-c4f59216) Seq 19-4511199451741686482: Sending {
> Cmd , MgmtId: 345051122106, via: 19(cu01-testpod01-esx03.stxt.media.int),
> Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}}]
> }
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.t.Request]
> (DirectAgentCronJob-253:ctx-c4f59216) Seq 19-4511199451741686482: Executing:
> { Cmd , MgmtId: 345051122106, via: 19(cu01-testpod01-esx03.stxt.media.int),
> Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}}]
> }
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-136:ctx-9bc0a401) Seq 19-4511199451741686482: Executing request
> 2015-09-15 09:37:06,532 INFO [c.c.h.v.r.VmwareResource]
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cmd:
> StopCommand) Executing resource StopCommand:
> {"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}
> 2015-09-15 09:37:06,551 DEBUG [c.c.h.v.m.HostMO]
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cmd:
> StopCommand) find VM r-342-VM on host
> 2015-09-15 09:37:06,551 INFO [c.c.h.v.m.HostMO]
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cmd:
> StopCommand) VM r-342-VM not found in host cache
> 2015-09-15 09:37:06,551 DEBUG [c.c.h.v.m.HostMO]
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cmd:
> StopCommand) load V
[jira] [Updated] (CLOUDSTACK-8848) Ensure power state is up to date when handling missing VMs in pwerReport
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma updated CLOUDSTACK-8848:
-
Summary: Ensure power state is up to date when handling missing VMs in
pwerReport (was: ensure power state is up to date when handling missing VMs in
pwerReport)
> Ensure power state is up to date when handling missing VMs in pwerReport
>
>
> Key: CLOUDSTACK-8848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8848
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.5.2, 4.6.0
>Reporter: René Moser
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.5.3, 4.6.0
>
>
> In some conditions (race condition), VR gets rebooted after a out of band
> migration was done on vCenter.
> {panel:bgColor=#CE}
> Note, new global setting in 4.5.2 "VR reboot after out of band migration" is
> set to *false* and this looks more like a bug.
> {panel}
> After a VR migration to a host _and_ when the VM power state report gathering
> is running, the VR (and also any user VM as well) will get into the
> "PowerReportMissing".
> If the VM is a VR. it will be powered off and started again on vCenter. That
> is what we see. In can not be reproduced every time a migration was done, but
> it seems the problem is related to "powerReportMissing".
> I grep-ed the source and found this line related
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java#L3616
> and also it seems that the graceful period might be also related,
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachinePowerStateSyncImpl.java#L110
> In case it is a user VM, we see in the logs that the state will be set to
> powered-off, but the VM keeps running. After a while a new VM power state
> report is running and the state for the user VM gets updated to Running
> again. Below the logs
> h2. VR r-342-VM reboot log
> {code:none}
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) Run missing VM report. current time:
> 1442302626508
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) Detected missing VM. host: 19, vm id:
> 342, power state: PowerReportMissing, last state update: 1442302506000
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) vm id: 342 - time since last state
> update(120508ms) has passed graceful period
> 2015-09-15 09:37:06,517 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) VM state report is updated. host: 19,
> vm id: 342, power state: PowerReportMissing
> 2015-09-15 09:37:06,525 INFO [c.c.v.VirtualMachineManagerImpl]
> (DirectAgentCronJob-253:ctx-c4f59216) VM r-342-VM is at Running and we
> received a power-off report while there is no pending jobs on it
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.t.Request]
> (DirectAgentCronJob-253:ctx-c4f59216) Seq 19-4511199451741686482: Sending {
> Cmd , MgmtId: 345051122106, via: 19(cu01-testpod01-esx03.stxt.media.int),
> Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}}]
> }
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.t.Request]
> (DirectAgentCronJob-253:ctx-c4f59216) Seq 19-4511199451741686482: Executing:
> { Cmd , MgmtId: 345051122106, via: 19(cu01-testpod01-esx03.stxt.media.int),
> Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}}]
> }
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-136:ctx-9bc0a401) Seq 19-4511199451741686482: Executing request
> 2015-09-15 09:37:06,532 INFO [c.c.h.v.r.VmwareResource]
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cmd:
> StopCommand) Executing resource StopCommand:
> {"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}
> 2015-09-15 09:37:06,551 DEBUG [c.c.h.v.m.HostMO]
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cmd:
> StopCommand) find VM r-342-VM on host
> 2015-09-15 09:37:06,551 INFO [c.c.h.v.m.HostMO]
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cmd:
> StopCommand) VM r-342-VM not found in host cache
> 2015-09-15 09:37:06,551 DEBUG [c.c.h.v.m.HostMO]
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cm
[jira] [Created] (CLOUDSTACK-8933) SSVm and CPVM do not survice a reboot from API
Remi Bergsma created CLOUDSTACK-8933: Summary: SSVm and CPVM do not survice a reboot from API Key: CLOUDSTACK-8933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8933 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.6.0 Environment: KVM Advanced / Basic zone Reporter: Remi Bergsma Priority: Blocker Fix For: 4.6.0 These tests fail: - integration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm - integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm Stopping works, then CloudStack successfully deploys a new one. Rebooting doesn’t work as it doesn’t complete the boot sequence. Looking at the agent.log I noticed the systemvm doesn’t get patched so it is probably waiting for that to happen. A successful start shows this: 2015-10-05 21:26:12,748 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Executing: /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n v-1-VM -p %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy.1%proxy_vm=1%disable_rp_filter=true%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8 2015-10-05 21:26:12,777 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Execution is successful. The reboot doesn’t do this. When I hit reboot and run this command manually, it works: /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n v-1-VM -p %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy1%proxy_vm=1%disable_rp_filter=tru%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8 I basically copy/pasted the patch line from the stop/start and used it when rebooting. Now everything works. We need to figure out why it doesn’t patch the system vms on reboot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8933) SSVm and CPVM do not survice a reboot from API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-8933: - Attachment: Console screenshot.png > SSVm and CPVM do not survice a reboot from API > -- > > Key: CLOUDSTACK-8933 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8933 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.6.0 > Environment: KVM Advanced / Basic zone >Reporter: Remi Bergsma >Priority: Blocker > Fix For: 4.6.0 > > Attachments: Console screenshot.png > > > These tests fail: > - integration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm > - integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm > Stopping works, then CloudStack successfully deploys a new one. Rebooting > doesn’t work as it doesn’t complete the boot sequence. Looking at the > agent.log I noticed the systemvm doesn’t get patched so it is probably > waiting for that to happen. > A successful start shows this: > 2015-10-05 21:26:12,748 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Executing: > /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n > v-1-VM -p > %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy.1%proxy_vm=1%disable_rp_filter=true%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8 > 2015-10-05 21:26:12,777 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Execution is successful. > The reboot doesn’t do this. When I hit reboot and run this command manually, > it works: > /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n > v-1-VM -p > %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy1%proxy_vm=1%disable_rp_filter=tru%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8 > I basically copy/pasted the patch line from the stop/start and used it when > rebooting. Now everything works. > We need to figure out why it doesn’t patch the system vms on reboot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8934) Default routes not configured for rVPC and RVR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-8934: - Priority: Blocker (was: Critical) > Default routes not configured for rVPC and RVR > -- > > Key: CLOUDSTACK-8934 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8934 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > > User VMs cannot reach the outside world due to missing default routes in > Redundant VPCs and Redundant Isolated Networks. > In order to work it around I had to: > route add default gw 192.168.23.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8934) Default routes not configured for rVPC and RVR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14944917#comment-14944917 ] Remi Bergsma commented on CLOUDSTACK-8934: -- Made it a blocker, without this nothing works in these network types. > Default routes not configured for rVPC and RVR > -- > > Key: CLOUDSTACK-8934 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8934 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > > User VMs cannot reach the outside world due to missing default routes in > Redundant VPCs and Redundant Isolated Networks. > In order to work it around I had to: > route add default gw 192.168.23.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8879) Depend on rados-java 0.2.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8879. -- Resolution: Fixed Merged in master > Depend on rados-java 0.2.0 > -- > > Key: CLOUDSTACK-8879 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8879 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.2 >Reporter: Wido den Hollander >Assignee: Wido den Hollander >Priority: Critical > Fix For: 4.5.3, 4.6.0 > > > Need to depend on rados-java 0.2.0 due to a couple of crashes which have > occured. > Will need some new imports in LibvirtComputingResource, but no major code > changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8879) Depend on rados-java 0.2.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-8879. > Depend on rados-java 0.2.0 > -- > > Key: CLOUDSTACK-8879 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8879 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.2 >Reporter: Wido den Hollander >Assignee: Wido den Hollander >Priority: Critical > Fix For: 4.5.3, 4.6.0 > > > Need to depend on rados-java 0.2.0 due to a couple of crashes which have > occured. > Will need some new imports in LibvirtComputingResource, but no major code > changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8918) [Install] Db Error after install - Unknown column 'iso_id1' in 'field list'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14951947#comment-14951947 ] Remi Bergsma commented on CLOUDSTACK-8918: -- Can you add some more info about your environment and what you did? I don't see this error. > [Install] Db Error after install - Unknown column 'iso_id1' in 'field list' > --- > > Key: CLOUDSTACK-8918 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8918 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Priority: Critical > Fix For: 4.6.0 > > > Following error is seen in the MS logs > 2015-09-28 07:52:52,756 ERROR [c.c.u.d.Upgrade410to420] (main:null) > migrateDatafromIsoIdInVolumesTable:Exception:Unknown column 'iso_id1' in > 'field list' > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column > 'iso_id1' in 'field list' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:525) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) > at com.mysql.jdbc.Util.getInstance(Util.java:386) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) > at > com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) > at > com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2283) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > at > com.cloud.upgrade.dao.Upgrade410to420.migrateDatafromIsoIdInVolumesTable(Upgrade410to420.java:2378) > at > com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:110) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:345) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:468) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55) > at > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) > at > org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) > at > org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) > at > org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143) > at > org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108) > at > org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:947) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117) > at > org.apache.cloudstack.spring.module.model.im
[jira] [Updated] (CLOUDSTACK-8775) [HyperV]NPE while attaching Local storage volume to instance whose root volume is on ZWPS.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma updated CLOUDSTACK-8775:
-
Priority: Major (was: Critical)
> [HyperV]NPE while attaching Local storage volume to instance whose root
> volume is on ZWPS.
> --
>
> Key: CLOUDSTACK-8775
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8775
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Deepthi Machiraju
> Fix For: 4.6.0
>
> Attachments: management-server.rar, mysqldump.dmp
>
>
> - Create a custom disk offering which has the tag of Localstorage.
> - Navigate to Storage and Click on Upload and select the above disk offering
> with the file URL.
> - After the upload is complete , try attaching the to the instance whose root
> volume resides on zone wide primary storage.
> Expected Result :
> - Attach should be sucessful
> Observation :
> Attach is failing with NPE and below is the trace.
> Note : When the root volume is on CLuster storage , volume attch of local
> storage is sucessful.
>
> 2015-08-26 08:07:59,045 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
> (Work-Job-Executor-69:ctx-754f463c job-182/job-183 ctx-20cae27f)
> ZoneWideStoragePoolAllocator to find storage pool
> 2015-08-26 08:07:59,045 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-69:ctx-754f463c job-182/job-183 ctx-20cae27f) Invocation
> exception, caused by: java.lang.NullPointerException
> 2015-08-26 08:07:59,045 INFO [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-69:ctx-754f463c job-182/job-183 ctx-20cae27f) Rethrow
> exception java.lang.NullPointerException
> 2015-08-26 08:07:59,045 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-69:ctx-754f463c job-182/job-183) Done with run of VM work
> job: com.cloud.vm.VmWorkAttachVolume for VM 3, job origin: 182
> 2015-08-26 08:07:59,045 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-69:ctx-754f463c job-182/job-183) Unable to complete
> AsyncJobVO {id:183, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkAttachVolume, cmdInfo:
> rO0ABXNyAB9jb20uY2xvdWQudm0uVm1Xb3JrQXR0YWNoVm9sdW1lB62v-WGH4hwCAAJMAAhkZXZpY2VJZHQAEExqYXZhL2xhbmcvTG9uZztMAAh2b2x1bWVJZHEAfgABeHIAE2NvbS5jbG91ZC52bS5WbVdvcmufmbZW8CVnawIABEoACWFjY291bnRJZEoABnVzZXJJZEoABHZtSWRMAAtoYW5kbGVyTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO3hwAAIAAgADdAAUVm9sdW1lQXBpU2VydmljZUltcGxwc3IADmphdmEubGFuZy5Mb25nO4vkkMyPI98CAAFKAAV2YWx1ZXhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cAAp,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 227345751881375, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Wed Aug 26 08:07:57 UTC 2015}, job origin:182
> java.lang.NullPointerException
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.copyVolumeFromSecToPrimary(VolumeOrchestrator.java:463)
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.copyVolume(VolumeOrchestrator.java:776)
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:796)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1321)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2837)
> at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2876)
> at sun.reflect.GeneratedMethodAccessor314.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at
> org.springfr
[jira] [Commented] (CLOUDSTACK-8697) Assign VPC Internal LB rule to a VM fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14957429#comment-14957429
]
Remi Bergsma commented on CLOUDSTACK-8697:
--
[~michaelandersen] That PR was just merged, so you may want to rebase against
current master.
> Assign VPC Internal LB rule to a VM fails
> -
>
> Key: CLOUDSTACK-8697
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8697
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.4.4, 4.6.0
>Reporter: Pavan Kumar Bandarupally
>Assignee: Michael Andersen
>Priority: Blocker
> Attachments: MS Log.rar, MSLog.rar
>
>
> Assigning an internal LB rule to a VM inside VPC network fails. Seems to be a
> configuration issue.
>
> 2015-07-31 21:13:49,059 ERROR [c.c.u.s.SshHelper]
> (DirectAgent-345:ctx-2bdddfcc) SSH execution of command
> /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.171
> load_balancer.json has an error status code in return. result output:
> 2015-07-31 21:13:49,062 DEBUG [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-345:ctx-2bdddfcc) Processing ScriptConfigItem, executing
> update_config.py load_balancer.json took 6656ms
> 2015-07-31 21:13:49,062 WARN [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-345:ctx-2bdddfcc) Expected 1 answers while executing
> LoadBalancerConfigCommand but received 2
> 2015-07-31 21:13:49,062 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Response Received:
> 2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request]
> (DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Processing: { Ans:
> , MgmtId: 6702933999656, via: 7, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.routing.GroupAnswer":{"results":["null - failed:
> ","null - failed: "],"result":false,"wait":0}}] }
> 2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) Seq
> 7-4435764157983228083: Received: { Ans: , MgmtId: 6702933999656, via: 7,
> Ver: v1, Flags: 0, { GroupAnswer } }
> 2015-07-31 21:13:49,133 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl]
> (API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) LB Rollback rule id: 6
> while attaching VM: [29]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14958754#comment-14958754 ] Remi Bergsma commented on CLOUDSTACK-8812: -- Does that even work? Because /usr/sbin/cloudstack-management is not in the package. At least not in 4.6. # rpm -qpl cloudstack-management-4.6.0-SNAPSHOT.el7.centos.x86_64.rpm | grep -v share /etc/cloudstack/management/Catalina /etc/cloudstack/management/Catalina/localhost /etc/cloudstack/management/Catalina/localhost/client /etc/cloudstack/management/Catalina/localhost/client/context.xml /etc/cloudstack/management/catalina.properties /etc/cloudstack/management/commons-logging.properties /etc/cloudstack/management/db.properties /etc/cloudstack/management/environment.properties /etc/cloudstack/management/java.security.ciphers /etc/cloudstack/management/log4j-cloud.xml /etc/cloudstack/management/server.xml /etc/cloudstack/management/tomcat-users.xml /etc/cloudstack/management/web.xml /etc/rc.d/init.d/cloudstack-ipallocator /etc/security/limits.d/cloud /etc/sudoers.d/cloudstack-management /etc/sysconfig/cloudstack-management /usr/bin/cloudstack-external-ipallocator.py /usr/bin/cloudstack-migrate-databases /usr/bin/cloudstack-set-guest-password /usr/bin/cloudstack-set-guest-sshkey /usr/bin/cloudstack-setup-databases /usr/bin/cloudstack-setup-encryption /usr/bin/cloudstack-setup-management /usr/bin/cloudstack-sysvmadm /usr/bin/cloudstack-update-xenserver-licenses /usr/lib/systemd/system/cloudstack-management.service /var/cache/cloudstack/management /var/cache/cloudstack/management/temp /var/cache/cloudstack/management/work /var/cloudstack/management /var/cloudstack/mnt /var/log/cloudstack/ipallocator /var/log/cloudstack/management /var/log/cloudstack/management/catalina.out /var/run/cloudstack-management.pid > CentOS 7 - systemd-tmpfiles - Operation not permitted > - > > Key: CLOUDSTACK-8812 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8812 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.2, 4.6.0 > Environment: KVM VM / CentOS Linux release 7.1.1503 (Core) >Reporter: Sven Vogel >Priority: Blocker > > installation of the shapeblue upstream 4.5.2 repository. setup of the > database works. when i start the service with systemctl start > cloudstack-management.service i get the following error. > Sep 04 17:14:34 cloudstack01.oscloud.local systemd[1]: Starting CloudStack > Management Server... > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/netreport) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/dev/net) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/dev/mapper) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/dev/vfio) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/dev/snd) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lock) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lock/subsys) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lock/lockdev) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/setrans) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lock/lvm) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lvm) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/console) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/faillock) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/sepermit) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/ppp) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/lock/ppp) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/user) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to > create
[jira] [Commented] (CLOUDSTACK-8923) Create storage network IP range failed, Unknown parameters : zoneid
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959276#comment-14959276
]
Remi Bergsma commented on CLOUDSTACK-8923:
--
[~nuxro] Can you please also add a comment to the PR that you reviewed it and
it works fine?
> Create storage network IP range failed, Unknown parameters : zoneid
> ---
>
> Key: CLOUDSTACK-8923
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8923
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs and MGMT
>Reporter: Nux
>Assignee: Rajani Karuturi
>Priority: Blocker
> Fix For: 4.6.0
>
> Attachments:
> 0001-CLOUDSTACK-8923-Create-storage-network-IP-range-fail.patch
>
>
> I am installing ACS from today's master (3ded3e9
> http://tmp.nux.ro/acs460snap/ ).
> Adding an initial zone via the web UI wizard fails at the secondary storage
> setup stage:
> 2015-09-29 14:07:40,319 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Add job-27 into job monitoring
> 2015-09-29 14:07:40,322 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-314bbaae ctx-2db63923) ===END=== 85.13.192.198 -- GET
> command=createStorageNetworkIpRange&response=json&gateway=192.168.200.67&netmask=255.255.255.0&vlan=123&startip=192.168.200.200&endip=192.168.200.222&zoneid=2f0efdcf-adf6-4373-858e-87de6af4cc08&podid=eb7814d2-9a22-4ca4-93af-4a6b8abac67c&_=1443532060283
> 2015-09-29 14:07:40,327 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Executing AsyncJobVO {id:27,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd,
> cmdInfo: {"response":"json","ctxDetails":"{\"interface
> com.cloud.dc.Pod\":\"eb7814d2-9a22-4ca4-93af-4a6b8abac67c\"}","cmdEventType":"STORAGE.IP.RANGE.CREATE","ctxUserId":"2","gateway":"192.168.200.67","podid":"eb7814d2-9a22-4ca4-93af-4a6b8abac67c","zoneid":"2f0efdcf-adf6-4373-858e-87de6af4cc08","startip":"192.168.200.200","vlan":"123","httpmethod":"GET","_":"1443532060283","ctxAccountId":"2","ctxStartEventId":"68","netmask":"255.255.255.0","endip":"192.168.200.222"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-09-29 14:07:40,330 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Received unknown
> parameters for command createStorageNetworkIpRange. Unknown parameters :
> zoneid
> 2015-09-29 14:07:40,391 WARN [o.a.c.a.c.a.n.CreateStorageNetworkIpRangeCmd]
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Create storage network
> IP range failed
> com.cloud.utils.exception.CloudRuntimeException: Unable to commit or close
> the connection.
> at
> com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:730)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
> at
> com.cloud.network.StorageNetworkManagerImpl.createIpRange(StorageNetworkManagerImpl.java:229)
> at
> org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd.execute(CreateStorageNetworkIpRangeCmd.java:118)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
> at
> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE
[jira] [Updated] (CLOUDSTACK-8952) The redundant routers are facing a race condition due to several KeepaliveD/ConntrackD restarts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-8952: - Priority: Blocker (was: Critical) > The redundant routers are facing a race condition due to several > KeepaliveD/ConntrackD restarts > --- > > Key: CLOUDSTACK-8952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > In the CsRedundant.py we have a line doing: > proc = CsProcess(['/usr/sbin/keepalived', '--vrrp']) > However, the CsProcess cannot find a process with the string search "--vrrp", > which makes it always return false and restart keepalived. > Due to the restart, the routers start a race condition to become master, > which makes network features unavailable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962022#comment-14962022 ] Remi Bergsma commented on CLOUDSTACK-8812: -- Hi [~paulangus], Thanks for looking into this. CentOS7 uses Tomcat 7 but what's in a name for a config file :-) Will you send a PR for this? I'd like to test it and include it in 4.6.0. Let me know if you need help. Regards, Remi > CentOS 7 - systemd-tmpfiles - Operation not permitted > - > > Key: CLOUDSTACK-8812 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8812 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.2, 4.6.0 > Environment: KVM VM / CentOS Linux release 7.1.1503 (Core) >Reporter: Sven Vogel >Priority: Blocker > > installation of the shapeblue upstream 4.5.2 repository. setup of the > database works. when i start the service with systemctl start > cloudstack-management.service i get the following error. > Sep 04 17:14:34 cloudstack01.oscloud.local systemd[1]: Starting CloudStack > Management Server... > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/netreport) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/dev/net) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/dev/mapper) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/dev/vfio) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/dev/snd) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lock) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lock/subsys) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lock/lockdev) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/setrans) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lock/lvm) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/lvm) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/console) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/faillock) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/sepermit) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/run/ppp) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/var/lock/ppp) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/user) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to > create file /var/log/wtmp: Permission denied > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to > create file /var/log/btmp: Permission denied > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/systemd/ask-password) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/systemd/seats) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/systemd/sessions) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/systemd/users) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/systemd/machines) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/systemd/shutdown) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/log/journal) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/run/log/journal/9b4671a20660436c8068d4f91eea0c1d) failed: Operation > not p > Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: > chmod(/tmp) failed: Operation not permitted > Sep 04 17:14:34 cloudstack01.osclou
[jira] [Commented] (CLOUDSTACK-8927) [VPC]Executing command in VR: /opt/cloud/bin/router_proxy.sh is failing whenever there is a configuration change in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962024#comment-14962024 ] Remi Bergsma commented on CLOUDSTACK-8927: -- We believe this should be resolved by a combi of the recent fixes. When PR 940 is merged, please test this again in master. The connectivity issues were due to unnecessary restarts of the network resolved in PR 940. Regards, Remi > [VPC]Executing command in VR: /opt/cloud/bin/router_proxy.sh is failing > whenever there is a configuration change in VR > -- > > Key: CLOUDSTACK-8927 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8927 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 >Reporter: manasaveloori >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > Attachments: management-server.rar, management-server.site-site.gz > > > Whenever there is a configuration change in VPC VR observing the connectivity > issues with VR. > Case1: > Created VPC and tier network with default allow. > Now created a new ACL list and rules. Changed the ACL list for the tier > network.Reboot VR > 2015-09-30 04:35:39,553 ERROR [c.c.u.s.SshHelper] > (DirectAgent-336:ctx-b9e5cdf1) SSH execution of command > /opt/cloud/bin/router_proxy.sh update_config.py 169.254.3.89 > guest_network.json has an error status code in return. result output: > 2015-09-30 04:35:39,554 DEBUG [c.c.a.r.v.VirtualRoutingResource] > (DirectAgent-336:ctx-b9e5cdf1) Processing ScriptConfigItem, executing > update_config.py guest_network.json took 21165ms > 2015-09-30 04:35:39,554 WARN [c.c.a.r.v.VirtualRoutingResource] > (DirectAgent-336:ctx-b9e5cdf1) Expected 1 answers while executing > SetupGuestNetworkCommand but received 2 > 2015-09-30 04:35:45,769 ERROR [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-94:ctx-56b18174 job-227/job-228 ctx-f92247d7) Failed to > start instance VM[DomainRouter|r-22-VM] > com.cloud.utils.exception.ExecutionException: Unable to start > VM[DomainRouter|r-22-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1083) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4576) > at sun.reflect.GeneratedMethodAccessor382.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4732) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at org.apache.cloudstack.managed.context.impl.Def > Case2: > Reboot VR with remote access VPN enabled on VPC VR: > Created VPC ,enabled vpn and rebooted the VR. > ERROR in logs: > 2015-09-30 04:46:18,663 ERROR [c.c.u.s.SshHelper] > (DirectAgent-46:ctx-3c355a22) SSH execution of command > /opt/cloud/bin/router_proxy.sh update_config.py 169.254.0.95 > vpn_user_list.json has an error status code in return. result output: > 2015-09-30 04:46:18,664 DEBUG [c.c.a.r.v.VirtualRoutingResource] > (DirectAgent-46:ctx-3c355a22) Processing ScriptConfigItem, executing > update_config.py vpn_user_list.json took 21168ms > 2015-09-30 04:46:18,664 WARN [c.c.a.r.v.VirtualRoutingResource] > (DirectAgent-46:ctx-3c355a22) Expected 1 answers while executing > VpnUsersCfgCommand but received 2 > 015-09-30 04:46:24,821 ERROR [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-101:ctx-fecf4919 job-240/job-242 ctx-44fde71b) Failed to > start instance VM[DomainRouter|r-23-VM] > com.cloud.utils.exception.ExecutionException: Unable to start > VM[DomainRouter|r-23-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1083) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4576) > at sun.reflect.GeneratedMethodAccessor382.inv
[jira] [Resolved] (CLOUDSTACK-8933) SSVm and CPVM do not survive a reboot from API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8933. -- Resolution: Fixed Resoled by PR #959 > SSVm and CPVM do not survive a reboot from API > -- > > Key: CLOUDSTACK-8933 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8933 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.6.0 > Environment: KVM Advanced / Basic zone >Reporter: Remi Bergsma >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > Attachments: Console screenshot.png, reboot.4.5.log, reboot.4.6.log > > > These tests fail: > - integration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm > - integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm > Stopping works, then CloudStack successfully deploys a new one. Rebooting > doesn’t work as it doesn’t complete the boot sequence. Looking at the > agent.log I noticed the systemvm doesn’t get patched so it is probably > waiting for that to happen. > A successful start shows this: > 2015-10-05 21:26:12,748 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Executing: > /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n > v-1-VM -p > %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy.1%proxy_vm=1%disable_rp_filter=true%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8 > 2015-10-05 21:26:12,777 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Execution is successful. > The reboot doesn’t do this. When I hit reboot and run this command manually, > it works: > /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n > v-1-VM -p > %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy1%proxy_vm=1%disable_rp_filter=tru%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8 > I basically copy/pasted the patch line from the stop/start and used it when > rebooting. Now everything works. > We need to figure out why it doesn’t patch the system vms on reboot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8935) Cannot remove VPC networks due to RTNETLINK error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14968037#comment-14968037 ] Remi Bergsma commented on CLOUDSTACK-8935: -- Is this issue resolved already [~wilder.rodrigues] ? > Cannot remove VPC networks due to RTNETLINK error > - > > Key: CLOUDSTACK-8935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Critical > > Sometimes, when trying to remove a network of a rVPC, I get the following > error in the router logs: > 2015-10-06 08:28:59,929 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) RTNETLINK answers: File existsRTNETLINK > answers: File exists[WARN] update_config.py :: Reconfiguring guest netwo > rk...[INFO] update_config.py :: Processing Guest Network.[INFO] Processing > JSON file guest_network.jsonTraceback (most recent call last): File > "/opt/cloud/bin/update_config.py", line 131, in process_ > file() File "/opt/cloud/bin/update_config.py", line 54, in process_file > finish_config() File "/opt/cloud/bin/update_config.py", line 44, in > finish_configreturncode = configure.main([]) File "/opt/cloud/ > bin/configure.py", line 888, in maindhcp.process() File > "/opt/cloud/bin/cs/CsDhcp.py", line 47, in processself.configure_server() > File "/opt/cloud/bin/cs/CsDhcp.py", line 71, in configure_serverline > = "dhcp-option=tag:interface-%s,6,%s" % (device, > ','.join(gn.get_dns()))TypeError: sequence item 0: expected string, NoneType > found > A way to work this around is: > 1. Stop and destroy the router(s) > 2. Remove the network -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14968042#comment-14968042 ] Remi Bergsma commented on CLOUDSTACK-8925: -- [~pavanb] Can you retest this please with current master? Pinging [~wilder.rodrigues] as well as he fixed many issues recently. > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Priority: Critical > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8984) VPC Network offerings tab missing from UI
Remi Bergsma created CLOUDSTACK-8984: Summary: VPC Network offerings tab missing from UI Key: CLOUDSTACK-8984 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8984 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.6.0 Reporter: Remi Bergsma Priority: Critical Home - Service Offerings - Network Offerings There used to be a tab to display the VPC offerings, but it's no longer there. See difference in screenshots. It was there in 4.4.4. Please add it again as you cannot add VPC offerings now (only through the API). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8984) VPC Network offerings tab missing from UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-8984: - Attachment: offerings_46.png offerings_44.png > VPC Network offerings tab missing from UI > - > > Key: CLOUDSTACK-8984 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8984 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.6.0 >Reporter: Remi Bergsma >Priority: Critical > Attachments: offerings_44.png, offerings_46.png > > > Home - Service Offerings - Network Offerings > There used to be a tab to display the VPC offerings, but it's no longer > there. See difference in screenshots. It was there in 4.4.4. > Please add it again as you cannot add VPC offerings now (only through the > API). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8984) VPC Network offerings tab missing from UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14969577#comment-14969577 ] Remi Bergsma commented on CLOUDSTACK-8984: -- Let's discuss if this is a blocker... > VPC Network offerings tab missing from UI > - > > Key: CLOUDSTACK-8984 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8984 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.6.0 >Reporter: Remi Bergsma >Priority: Critical > Attachments: offerings_44.png, offerings_46.png > > > Home - Service Offerings - Network Offerings > There used to be a tab to display the VPC offerings, but it's no longer > there. See difference in screenshots. It was there in 4.4.4. > Please add it again as you cannot add VPC offerings now (only through the > API). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8984) VPC Network offerings tab missing from UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14969715#comment-14969715 ] Remi Bergsma commented on CLOUDSTACK-8984: -- Can be done via API, so no blocker. > VPC Network offerings tab missing from UI > - > > Key: CLOUDSTACK-8984 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8984 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.6.0 >Reporter: Remi Bergsma >Priority: Critical > Attachments: offerings_44.png, offerings_46.png > > > Home - Service Offerings - Network Offerings > There used to be a tab to display the VPC offerings, but it's no longer > there. See difference in screenshots. It was there in 4.4.4. > Please add it again as you cannot add VPC offerings now (only through the > API). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8987) S3 XenServer plugin fails due to plugin not found
Remi Bergsma created CLOUDSTACK-8987:
Summary: S3 XenServer plugin fails due to plugin not found
Key: CLOUDSTACK-8987
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8987
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Environment: xenserver
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical
The plugin is called as 's3xenserver' but is named 's3xen' instead.
Regresion from a8212d9ef458dd7ac64b021e6fa33fcf64b3cce0
2015-10-22 21:42:30,372 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-261:ctx-862ebceb) callHostPlugin failed for cmd: s3 with args
maxErrorRetry: 10, secretKey: +XGy4yPPbAH9AijYxFTr1yVCCiVQuSfXWWj1Invs,
connectionTtl: null, iSCSIFlag: false, maxSingleUploadSizeInBytes: 5368709120,
bucket: mccx-nl2, endPoint: s3.storage.acc.schubergphilis.com, filename:
/var/run/sr-mount/9414f970-0afd-42db-972f-aa4743293430/2
cf0c24b-a596-4039-b50a-7ce87da4f273.vhd, accessKey: 16efbc4e870f24338141,
socketTimeout: null, https: false, connectionTimeout: 30, operation: put,
key: snapshots/2/10/2cf0c24b-a596-4039-b50a-7ce87da4f273
.vhd, useTCPKeepAlive: null, due to Task failed! Task record:
uuid: 4be8a515-1e2a-59de-6301-029fb0326651
nameLabel: Async.host.call_plugin
nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Oct 22 21:42:44 CEST 2015
finished: Thu Oct 22 21:42:44 CEST 2015
status: failure
residentOn: com.xensource.xenapi.Host@9c7aad90
progress: 1.0
type:
result:
errorInfo: [XENAPI_MISSING_PLUGIN, s3xenserver]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Task failed! Task record: uuid:
4be8a515-1e2a-59de-6301-029fb0326651
nameLabel: Async.host.call_plugin
nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Oct 22 21:42:44 CEST 2015
finished: Thu Oct 22 21:42:44 CEST 2015
status: failure
residentOn: com.xensource.xenapi.Host@9c7aad90
progress: 1.0
type:
result:
errorInfo: [XENAPI_MISSING_PLUGIN, s3xenserver]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8838) [KVM] agent setup failed when physical interface name is in ensX format (CentOS7)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972521#comment-14972521 ] Remi Bergsma commented on CLOUDSTACK-8838: -- Also for 'team' devices as per PR 966. > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > - > > Key: CLOUDSTACK-8838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.2 > Environment: CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 >Reporter: satoru nakaya > > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > My environment: > CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 > management.log: > 2015-09-12 08:19:41,930 WARN [o.a.c.alerts] > (AgentConnectTaskPool-2:ctx-4925d5ec) alertType:: 7 // dataCenterId:: 1 // > podId:: 1 // clusterId:: null // message:: Incorrect Network setup on agent, > Reinitialize agent after network names are setup, details : Can not find > network: cloudbr1 > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: ens32: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: ens33: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 5: cloudbr1: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 6: virbr0: mtu 1500 qdisc noqueue state > DOWN > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 >valid_lft forever preferred_lft forever > 7: virbr0-nic: mtu 1500 qdisc pfifo_fast master virbr0 > state DOWN qlen 500 > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > 8: cloud0: mtu 1500 qdisc noqueue state > UNKNOWN > link/ether 72:0f:e1:35:ac:6b brd ff:ff:ff:ff:ff:ff > inet 169.254.0.1/16 scope global cloud0 >valid_lft forever preferred_lft forever > inet6 fe80::700f:e1ff:fe35:ac6b/64 scope link >valid_lft forever preferred_lft forever > [root@acs ~]# > workaround: > Don't use ensX format. > add net.ifnames=0 biosdevname=0 to GRUB_CMDLINE_LINUX > [root@acs ~]# vi /etc/default/grub > : > GRUB_CMDLINE_LINUX="vconsole.keymap=jp106 crashkernel=auto > vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=0" > : > [root@acs ~]# grub2-mkconfig -o /boot/grub2/grub.cfg > And > Edit /etc/sysconfig/network-scripts/ifcfg-ensX > ensX-> ethX > [root@acs ~]# reboot >: > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: eth1: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >vali
[jira] [Commented] (CLOUDSTACK-8957) VR password server broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972527#comment-14972527 ] Remi Bergsma commented on CLOUDSTACK-8957: -- [~bhaisaab] If you are working on this, please give an update. If not working on this, let us know and unassign the ticket. Thanks! > VR password server broken > - > > Key: CLOUDSTACK-8957 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8957 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 > Environment: ACS 4.6.0 snapshot, CentOS6 HVs and mgmt >Reporter: Nux >Assignee: Rohit Yadav >Priority: Blocker > > Hello, > When deploying instances from password enabled templates, the instances do > not get the generated passwords. > The VR logs show something like this: > 'Oct 15 17:12:27 r-4-VM passwd_server_ip.py: serve_password: requested > password not found for 10.1.1.33' > In /var/cache/cloud the "passwords-10.1.1.1" is empty, but "passwords" is > not, I can see the passwords there. > Symlinking "passwords-10.1.1.1" to "passwords" and restarting the > passwd_server_ip script gets the feature working again, though I am not sure > how correct this approach is. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8838) [KVM] agent setup failed when physical interface name is in ensX format (CentOS7)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-8838: - Assignee: Daan Hoogland > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > - > > Key: CLOUDSTACK-8838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.2 > Environment: CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 >Reporter: satoru nakaya >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > My environment: > CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 > management.log: > 2015-09-12 08:19:41,930 WARN [o.a.c.alerts] > (AgentConnectTaskPool-2:ctx-4925d5ec) alertType:: 7 // dataCenterId:: 1 // > podId:: 1 // clusterId:: null // message:: Incorrect Network setup on agent, > Reinitialize agent after network names are setup, details : Can not find > network: cloudbr1 > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: ens32: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: ens33: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 5: cloudbr1: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 6: virbr0: mtu 1500 qdisc noqueue state > DOWN > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 >valid_lft forever preferred_lft forever > 7: virbr0-nic: mtu 1500 qdisc pfifo_fast master virbr0 > state DOWN qlen 500 > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > 8: cloud0: mtu 1500 qdisc noqueue state > UNKNOWN > link/ether 72:0f:e1:35:ac:6b brd ff:ff:ff:ff:ff:ff > inet 169.254.0.1/16 scope global cloud0 >valid_lft forever preferred_lft forever > inet6 fe80::700f:e1ff:fe35:ac6b/64 scope link >valid_lft forever preferred_lft forever > [root@acs ~]# > workaround: > Don't use ensX format. > add net.ifnames=0 biosdevname=0 to GRUB_CMDLINE_LINUX > [root@acs ~]# vi /etc/default/grub > : > GRUB_CMDLINE_LINUX="vconsole.keymap=jp106 crashkernel=auto > vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=0" > : > [root@acs ~]# grub2-mkconfig -o /boot/grub2/grub.cfg > And > Edit /etc/sysconfig/network-scripts/ifcfg-ensX > ensX-> ethX > [root@acs ~]# reboot >: > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: eth1: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid
[jira] [Resolved] (CLOUDSTACK-8838) [KVM] agent setup failed when physical interface name is in ensX format (CentOS7)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8838. -- Resolution: Fixed merged! > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > - > > Key: CLOUDSTACK-8838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.2 > Environment: CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 >Reporter: satoru nakaya >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > My environment: > CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 > management.log: > 2015-09-12 08:19:41,930 WARN [o.a.c.alerts] > (AgentConnectTaskPool-2:ctx-4925d5ec) alertType:: 7 // dataCenterId:: 1 // > podId:: 1 // clusterId:: null // message:: Incorrect Network setup on agent, > Reinitialize agent after network names are setup, details : Can not find > network: cloudbr1 > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: ens32: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: ens33: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 5: cloudbr1: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 6: virbr0: mtu 1500 qdisc noqueue state > DOWN > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 >valid_lft forever preferred_lft forever > 7: virbr0-nic: mtu 1500 qdisc pfifo_fast master virbr0 > state DOWN qlen 500 > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > 8: cloud0: mtu 1500 qdisc noqueue state > UNKNOWN > link/ether 72:0f:e1:35:ac:6b brd ff:ff:ff:ff:ff:ff > inet 169.254.0.1/16 scope global cloud0 >valid_lft forever preferred_lft forever > inet6 fe80::700f:e1ff:fe35:ac6b/64 scope link >valid_lft forever preferred_lft forever > [root@acs ~]# > workaround: > Don't use ensX format. > add net.ifnames=0 biosdevname=0 to GRUB_CMDLINE_LINUX > [root@acs ~]# vi /etc/default/grub > : > GRUB_CMDLINE_LINUX="vconsole.keymap=jp106 crashkernel=auto > vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=0" > : > [root@acs ~]# grub2-mkconfig -o /boot/grub2/grub.cfg > And > Edit /etc/sysconfig/network-scripts/ifcfg-ensX > ensX-> ethX > [root@acs ~]# reboot >: > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: eth1: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >
[jira] [Updated] (CLOUDSTACK-8838) [KVM] agent setup failed when physical interface name is in ensX format (CentOS7)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-8838: - Fix Version/s: 4.6.0 > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > - > > Key: CLOUDSTACK-8838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.2 > Environment: CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 >Reporter: satoru nakaya > Fix For: 4.6.0 > > > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > My environment: > CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 > management.log: > 2015-09-12 08:19:41,930 WARN [o.a.c.alerts] > (AgentConnectTaskPool-2:ctx-4925d5ec) alertType:: 7 // dataCenterId:: 1 // > podId:: 1 // clusterId:: null // message:: Incorrect Network setup on agent, > Reinitialize agent after network names are setup, details : Can not find > network: cloudbr1 > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: ens32: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: ens33: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 5: cloudbr1: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 6: virbr0: mtu 1500 qdisc noqueue state > DOWN > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 >valid_lft forever preferred_lft forever > 7: virbr0-nic: mtu 1500 qdisc pfifo_fast master virbr0 > state DOWN qlen 500 > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > 8: cloud0: mtu 1500 qdisc noqueue state > UNKNOWN > link/ether 72:0f:e1:35:ac:6b brd ff:ff:ff:ff:ff:ff > inet 169.254.0.1/16 scope global cloud0 >valid_lft forever preferred_lft forever > inet6 fe80::700f:e1ff:fe35:ac6b/64 scope link >valid_lft forever preferred_lft forever > [root@acs ~]# > workaround: > Don't use ensX format. > add net.ifnames=0 biosdevname=0 to GRUB_CMDLINE_LINUX > [root@acs ~]# vi /etc/default/grub > : > GRUB_CMDLINE_LINUX="vconsole.keymap=jp106 crashkernel=auto > vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=0" > : > [root@acs ~]# grub2-mkconfig -o /boot/grub2/grub.cfg > And > Edit /etc/sysconfig/network-scripts/ifcfg-ensX > ensX-> ethX > [root@acs ~]# reboot >: > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: eth1: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 5:
[jira] [Closed] (CLOUDSTACK-8838) [KVM] agent setup failed when physical interface name is in ensX format (CentOS7)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-8838. > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > - > > Key: CLOUDSTACK-8838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.2 > Environment: CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 >Reporter: satoru nakaya >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > [KVM] agent setup failed when physical interface name is in ensX format > (CentOS7) > My environment: > CloudStack 4.5.2 > (http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5) > CentOS 7.1.1503 / KVM > mariadb-5.5.44-1 > management.log: > 2015-09-12 08:19:41,930 WARN [o.a.c.alerts] > (AgentConnectTaskPool-2:ctx-4925d5ec) alertType:: 7 // dataCenterId:: 1 // > podId:: 1 // clusterId:: null // message:: Incorrect Network setup on agent, > Reinitialize agent after network names are setup, details : Can not find > network: cloudbr1 > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: ens32: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: ens33: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 5: cloudbr1: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 6: virbr0: mtu 1500 qdisc noqueue state > DOWN > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 >valid_lft forever preferred_lft forever > 7: virbr0-nic: mtu 1500 qdisc pfifo_fast master virbr0 > state DOWN qlen 500 > link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff > 8: cloud0: mtu 1500 qdisc noqueue state > UNKNOWN > link/ether 72:0f:e1:35:ac:6b brd ff:ff:ff:ff:ff:ff > inet 169.254.0.1/16 scope global cloud0 >valid_lft forever preferred_lft forever > inet6 fe80::700f:e1ff:fe35:ac6b/64 scope link >valid_lft forever preferred_lft forever > [root@acs ~]# > workaround: > Don't use ensX format. > add net.ifnames=0 biosdevname=0 to GRUB_CMDLINE_LINUX > [root@acs ~]# vi /etc/default/grub > : > GRUB_CMDLINE_LINUX="vconsole.keymap=jp106 crashkernel=auto > vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=0" > : > [root@acs ~]# grub2-mkconfig -o /boot/grub2/grub.cfg > And > Edit /etc/sysconfig/network-scripts/ifcfg-ensX > ensX-> ethX > [root@acs ~]# reboot >: > [root@acs ~]# ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast master > cloudbr0 state UP qlen 1000 > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft forever > 3: eth1: mtu 1500 qdisc pfifo_fast master > cloudbr1 state UP qlen 1000 > link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20c:29ff:fea9:949/64 scope link >valid_lft forever preferred_lft forever > 4: cloudbr0: mtu 1500 qdisc noqueue state UP > link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff > inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0 >valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fea9:93f/64 scope link >valid_lft forever preferred_lft for
[jira] [Resolved] (CLOUDSTACK-8935) Cannot remove [r]VPC networks due to RTNETLINK error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8935. -- Resolution: Fixed Thanks Wilder! > Cannot remove [r]VPC networks due to RTNETLINK error > > > Key: CLOUDSTACK-8935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Critical > > Sometimes, when trying to remove a network of a rVPC, I get the following > error in the router logs: > 2015-10-06 08:28:59,929 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) RTNETLINK answers: File existsRTNETLINK > answers: File exists[WARN] update_config.py :: Reconfiguring guest netwo > rk...[INFO] update_config.py :: Processing Guest Network.[INFO] Processing > JSON file guest_network.jsonTraceback (most recent call last): File > "/opt/cloud/bin/update_config.py", line 131, in process_ > file() File "/opt/cloud/bin/update_config.py", line 54, in process_file > finish_config() File "/opt/cloud/bin/update_config.py", line 44, in > finish_configreturncode = configure.main([]) File "/opt/cloud/ > bin/configure.py", line 888, in maindhcp.process() File > "/opt/cloud/bin/cs/CsDhcp.py", line 47, in processself.configure_server() > File "/opt/cloud/bin/cs/CsDhcp.py", line 71, in configure_serverline > = "dhcp-option=tag:interface-%s,6,%s" % (device, > ','.join(gn.get_dns()))TypeError: sequence item 0: expected string, NoneType > found > A way to work this around is: > 1. Stop and destroy the router(s) > 2. Remove the network -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8935) Cannot remove [r]VPC networks due to RTNETLINK error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-8935. > Cannot remove [r]VPC networks due to RTNETLINK error > > > Key: CLOUDSTACK-8935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Critical > > Sometimes, when trying to remove a network of a rVPC, I get the following > error in the router logs: > 2015-10-06 08:28:59,929 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) RTNETLINK answers: File existsRTNETLINK > answers: File exists[WARN] update_config.py :: Reconfiguring guest netwo > rk...[INFO] update_config.py :: Processing Guest Network.[INFO] Processing > JSON file guest_network.jsonTraceback (most recent call last): File > "/opt/cloud/bin/update_config.py", line 131, in process_ > file() File "/opt/cloud/bin/update_config.py", line 54, in process_file > finish_config() File "/opt/cloud/bin/update_config.py", line 44, in > finish_configreturncode = configure.main([]) File "/opt/cloud/ > bin/configure.py", line 888, in maindhcp.process() File > "/opt/cloud/bin/cs/CsDhcp.py", line 47, in processself.configure_server() > File "/opt/cloud/bin/cs/CsDhcp.py", line 71, in configure_serverline > = "dhcp-option=tag:interface-%s,6,%s" % (device, > ','.join(gn.get_dns()))TypeError: sequence item 0: expected string, NoneType > found > A way to work this around is: > 1. Stop and destroy the router(s) > 2. Remove the network -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma resolved CLOUDSTACK-8964.
--
Resolution: Fixed
Assignee: Wei Zhou
Fix Version/s: 4.6.0
PR 954 is merged, thx!
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,531 DEBUG [o.a
[jira] [Closed] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma closed CLOUDSTACK-8964.
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,531 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135 ctx-bd1cf294) template 207 is
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14975202#comment-14975202
]
Remi Bergsma commented on CLOUDSTACK-8964:
--
Super cool :-)
Sent from my iPhone
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,531 DEBUG [o.a.c.s.i.T
[jira] [Closed] (CLOUDSTACK-8991) IP address is not removed from VR even after disabling static NAT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-8991. > IP address is not removed from VR even after disabling static NAT > - > > Key: CLOUDSTACK-8991 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8991 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > > Test for port forwarding on source NAT ... === TestName: > test_01_port_fwd_on_src_nat | Status : SUCCESS === > ok > Test for port forwarding on non source NAT ... === TestName: > test_02_port_fwd_on_non_src_nat | Status : SUCCESS === > ok > Test for reboot router ... === TestName: test_reboot_router | Status : > SUCCESS === > ok > Test for Router rules for network rules on acquired public IP ... === > TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : > FAILED === > FAIL > Test for Router rules for network rules on acquired public IP ... === > TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : FAILED > === > FAIL > Test for Router rules for network rules on acquired public IP ... === > TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status > : FAILED === > FAIL > == > FAIL: Test for Router rules for network rules on acquired public IP > -- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ddt.py", line 146, in wrapper > return func(self, *args, **kwargs) > File "/data/git/cs1/cloudstack/test/integration/smoke/test_network.py", > line 1248, in test_network_rules_acquired_public_ip > not removed from VR even after disabling statin NAT") > AssertionError: IP address isnot removed from VR even after > disabling statin NAT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8991) IP address is not removed from VR even after disabling static NAT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-8991. -- Resolution: Fixed Fixed in PR 989 > IP address is not removed from VR even after disabling static NAT > - > > Key: CLOUDSTACK-8991 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8991 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > > Test for port forwarding on source NAT ... === TestName: > test_01_port_fwd_on_src_nat | Status : SUCCESS === > ok > Test for port forwarding on non source NAT ... === TestName: > test_02_port_fwd_on_non_src_nat | Status : SUCCESS === > ok > Test for reboot router ... === TestName: test_reboot_router | Status : > SUCCESS === > ok > Test for Router rules for network rules on acquired public IP ... === > TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : > FAILED === > FAIL > Test for Router rules for network rules on acquired public IP ... === > TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : FAILED > === > FAIL > Test for Router rules for network rules on acquired public IP ... === > TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status > : FAILED === > FAIL > == > FAIL: Test for Router rules for network rules on acquired public IP > -- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ddt.py", line 146, in wrapper > return func(self, *args, **kwargs) > File "/data/git/cs1/cloudstack/test/integration/smoke/test_network.py", > line 1248, in test_network_rules_acquired_public_ip > not removed from VR even after disabling statin NAT") > AssertionError: IP address isnot removed from VR even after > disabling statin NAT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
