[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906139#comment-15906139
 ] 

Remi Bergsma commented on CLOUDSTACK-9811:
--

[~bstoyanov] [~ustcweiz...@gmail.com] This is due to a change introduced here: 
https://github.com/apache/cloudstack/pull/1741 (the cs_ip.py file is changed 
https://github.com/apache/cloudstack/pull/1741/files#diff-a7d6f7150cca74029f23c19b72ad0622R49)

> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> --
>
> Key: CLOUDSTACK-9811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: Boris Stoyanov
>Priority: Blocker
> Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9266) Delete static route on private gw doesn't actually delete it on the router

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9266.
--
Resolution: Fixed

> Delete static route on private gw doesn't actually delete it on the router
> --
>
> Key: CLOUDSTACK-9266
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9266
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> It is removed from the json file, instead of put there with revoke=true. The 
> script that parses the json now doesn't find it and thus does not delete it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9266) Delete static route on private gw doesn't actually delete it on the router

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9266.


> Delete static route on private gw doesn't actually delete it on the router
> --
>
> Key: CLOUDSTACK-9266
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9266
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> It is removed from the json file, instead of put there with revoke=true. The 
> script that parses the json now doesn't find it and thus does not delete it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9202) SSH commands to VR timeout sometimes

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9202.
--
Resolution: Fixed

> SSH commands to VR timeout sometimes
> 
>
> Key: CLOUDSTACK-9202
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9202
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> Error seen:
> 2015-12-28 14:35:18,201 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-1:ctx-34ff7f80 job-39723/job-39726 ctx-d63de41b) Timed out 
> in waiting SSH execution result
> 2015-12-28 14:35:18,201 WARN  [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-1:ctx-34ff7f80 job-39723/job-39726 ctx-d63de41b) Command: 
> com.cloud.agent.api.Command failed while starting virtua
> l router
> 2015-12-28 14:35:18,201 INFO  [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-1:ctx-34ff7f80 job-39723/job-39726 ctx-d63de41b) The guru 
> did not like the answers so stopping VM[DomainRouter|r-1534-VM]
> .Answer":{"result":true,"wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Timed
>  out in waiting SSH execution result","wait":0}}] }
> It needs to be investigated why 60 second timeout is not enough, for now 
> bumping it would help.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9256) Static routes get lost after network restart

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9256.


> Static routes get lost after network restart
> 
>
> Key: CLOUDSTACK-9256
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9256
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> Static routes that are being set do not show up in the static_routes.json 
> file. The reason for this is that the index that is used, is the gateway 
> address, which is not unique. Hence stuff is overwritten and lost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9256) Static routes get lost after network restart

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9256.
--
   Resolution: Fixed
Fix Version/s: 4.7.1

> Static routes get lost after network restart
> 
>
> Key: CLOUDSTACK-9256
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9256
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> Static routes that are being set do not show up in the static_routes.json 
> file. The reason for this is that the index that is used, is the gateway 
> address, which is not unique. Hence stuff is overwritten and lost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9181) Syntax error in checkrouter.sh when interface is missing

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9181.


> Syntax error in checkrouter.sh when interface is missing
> 
>
> Key: CLOUDSTACK-9181
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9181
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>
> Error seen in mgt server:
> 2015-12-15 14:30:32,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (RedundantRouterStatusMonitor-7:ctx-0dd8ef3e) Details from executing class 
> com.cloud.agent.api.CheckRouterCommand: Status: UNKNOWN
> /opt/cloud/bin/checkrouter.sh: line 28: [: =: unary operator expected
> /opt/cloud/bin/checkrouter.sh: line 31: [: =: unary operator expected
> root@r-1191-VM:/opt/cloud/bin# ./checkrouter.sh
> ./checkrouter.sh: line 28: [: =: unary operator expected
> ./checkrouter.sh: line 31: [: =: unary operator expected
> Status: UNKNOWN
> Somehow a nic was missing.
> After fix the script can handle this:
> root@r-1191-VM:/opt/cloud/bin# ./checkrouter.sh
> Status: UNKNOWN



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9254) Name of logged in user in UI is not always lined out properly

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9254.


> Name of logged in user in UI is not always lined out properly
> -
>
> Key: CLOUDSTACK-9254
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9254
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.2
>
> Attachments: Screenshot_23_01_16_21_10.png
>
>
> The name of the logged in user is not always layed out properly. Right top.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9181) Syntax error in checkrouter.sh when interface is missing

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9181.
--
Resolution: Fixed

> Syntax error in checkrouter.sh when interface is missing
> 
>
> Key: CLOUDSTACK-9181
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9181
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>
> Error seen in mgt server:
> 2015-12-15 14:30:32,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (RedundantRouterStatusMonitor-7:ctx-0dd8ef3e) Details from executing class 
> com.cloud.agent.api.CheckRouterCommand: Status: UNKNOWN
> /opt/cloud/bin/checkrouter.sh: line 28: [: =: unary operator expected
> /opt/cloud/bin/checkrouter.sh: line 31: [: =: unary operator expected
> root@r-1191-VM:/opt/cloud/bin# ./checkrouter.sh
> ./checkrouter.sh: line 28: [: =: unary operator expected
> ./checkrouter.sh: line 31: [: =: unary operator expected
> Status: UNKNOWN
> Somehow a nic was missing.
> After fix the script can handle this:
> root@r-1191-VM:/opt/cloud/bin# ./checkrouter.sh
> Status: UNKNOWN



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-9181) Syntax error in checkrouter.sh when interface is missing

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma reassigned CLOUDSTACK-9181:


Assignee: Remi Bergsma

> Syntax error in checkrouter.sh when interface is missing
> 
>
> Key: CLOUDSTACK-9181
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9181
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>
> Error seen in mgt server:
> 2015-12-15 14:30:32,371 DEBUG [c.c.a.m.AgentManagerImpl] 
> (RedundantRouterStatusMonitor-7:ctx-0dd8ef3e) Details from executing class 
> com.cloud.agent.api.CheckRouterCommand: Status: UNKNOWN
> /opt/cloud/bin/checkrouter.sh: line 28: [: =: unary operator expected
> /opt/cloud/bin/checkrouter.sh: line 31: [: =: unary operator expected
> root@r-1191-VM:/opt/cloud/bin# ./checkrouter.sh
> ./checkrouter.sh: line 28: [: =: unary operator expected
> ./checkrouter.sh: line 31: [: =: unary operator expected
> Status: UNKNOWN
> Somehow a nic was missing.
> After fix the script can handle this:
> root@r-1191-VM:/opt/cloud/bin# ./checkrouter.sh
> Status: UNKNOWN



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9202) SSH commands to VR timeout sometimes

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9202.


> SSH commands to VR timeout sometimes
> 
>
> Key: CLOUDSTACK-9202
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9202
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> Error seen:
> 2015-12-28 14:35:18,201 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-1:ctx-34ff7f80 job-39723/job-39726 ctx-d63de41b) Timed out 
> in waiting SSH execution result
> 2015-12-28 14:35:18,201 WARN  [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-1:ctx-34ff7f80 job-39723/job-39726 ctx-d63de41b) Command: 
> com.cloud.agent.api.Command failed while starting virtua
> l router
> 2015-12-28 14:35:18,201 INFO  [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-1:ctx-34ff7f80 job-39723/job-39726 ctx-d63de41b) The guru 
> did not like the answers so stopping VM[DomainRouter|r-1534-VM]
> .Answer":{"result":true,"wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Timed
>  out in waiting SSH execution result","wait":0}}] }
> It needs to be investigated why 60 second timeout is not enough, for now 
> bumping it would help.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9264) Create of /32 static route on private gw fails

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9264.
--
Resolution: Fixed

> Create of /32 static route on private gw fails
> --
>
> Key: CLOUDSTACK-9264
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9264
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> The /32 static route creation fails. When trying manual the command it runs 
> we see why:
> root@r-2934-VM:~# route add -net 172.16.1.4/32 gw 172.16.1.1
> SIOCADDRT: Invalid argument
> Let's use 'ip' toolset or use -host for /32



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9264) Create of /32 static route on private gw fails

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9264.


> Create of /32 static route on private gw fails
> --
>
> Key: CLOUDSTACK-9264
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9264
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> The /32 static route creation fails. When trying manual the command it runs 
> we see why:
> root@r-2934-VM:~# route add -net 172.16.1.4/32 gw 172.16.1.1
> SIOCADDRT: Invalid argument
> Let's use 'ip' toolset or use -host for /32



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9221) Admin cannot see VMs on port forwarding page

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9221.


> Admin cannot see VMs on port forwarding page
> 
>
> Key: CLOUDSTACK-9221
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9221
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> When you go to the UI as root admin and go to a VPC of a user, you can see 
> lots of options. However, when you select an IP and want to configure port 
> forwarding, the list of VMs shows ERROR (due to missing parameters). These 
> need to be added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9220.
--
Resolution: Fixed

> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9220.


> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9222) cloud.log is filling up disk space

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9222.


> cloud.log is filling up disk space
> --
>
> Key: CLOUDSTACK-9222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> Delay Compress results in more space usage than needed. Since we have copy 
> truncate we don't need it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9137) Domain admins cannot create nor delete a private gateway

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9137.
--
   Resolution: Fixed
Fix Version/s: 4.7.0

> Domain admins cannot create nor delete a private gateway
> 
>
> Key: CLOUDSTACK-9137
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9137
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.0
>
>
> To create a private gateway you need a root admin account. This does not make 
> sense, as you can do a lot more with such a powerful account. Other network 
> related API calls can be made by a domain admin.
> Let's change it so domain admins can create their own private gateways.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9204) Delete static route fails when it's already gone

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9204.
--
Resolution: Fixed

> Delete static route fails when it's already gone
> 
>
> Key: CLOUDSTACK-9204
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9204
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> When you try to delete a static route, this fails when it's no longer there 
> on the router (not sure why that happens).
> Error seen:
> [INFO] update_config.py :: Processing incoming file => 
> static_routes.json.1451560145
> [INFO] Processing JSON file static_routes.json.1451560145
> Traceback (most recent call last):
>   File "/opt/cloud/bin/update_config.py", line 140, in 
> process_file()
>   File "/opt/cloud/bin/update_config.py", line 52, in process_file
> qf.load(None)
>   File "/opt/cloud/bin/merge.py", line 258, in load
> proc = updateDataBag(self)
>   File "/opt/cloud/bin/merge.py", line 91, in __init__
> self.process()
>   File "/opt/cloud/bin/merge.py", line 131, in process
> dbag = self.process_staticroutes(self.db.getDataBag())
>   File "/opt/cloud/bin/merge.py", line 179, in process_staticroutes
> return cs_staticroutes.merge(dbag, self.qFile.data)
>   File "/opt/cloud/bin/cs_staticroutes.py", line 26, in merge
> del dbag[key]
> KeyError: u'192.168.0.3'
> When deleting fails because it isn't there any more, it should succeed ;-)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9240.
--
Resolution: Fixed

> Templatesize >40GB doesn't work properly
> 
>
> Key: CLOUDSTACK-9240
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the 
> size of the template that gets created. I could not find any justification of 
> that. I am just removing them as they caused us a huge headache when we tried 
> to create bigger templates and they failed without any good error.
> Source: https://github.com/apache/cloudstack/pull/1223



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9221) Admin cannot see VMs on port forwarding page

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9221.
--
Resolution: Fixed

> Admin cannot see VMs on port forwarding page
> 
>
> Key: CLOUDSTACK-9221
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9221
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> When you go to the UI as root admin and go to a VPC of a user, you can see 
> lots of options. However, when you select an IP and want to configure port 
> forwarding, the list of VMs shows ERROR (due to missing parameters). These 
> need to be added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9222) cloud.log is filling up disk space

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9222.
--
Resolution: Fixed

> cloud.log is filling up disk space
> --
>
> Key: CLOUDSTACK-9222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> Delay Compress results in more space usage than needed. Since we have copy 
> truncate we don't need it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9204) Delete static route fails when it's already gone

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9204.


> Delete static route fails when it's already gone
> 
>
> Key: CLOUDSTACK-9204
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9204
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> When you try to delete a static route, this fails when it's no longer there 
> on the router (not sure why that happens).
> Error seen:
> [INFO] update_config.py :: Processing incoming file => 
> static_routes.json.1451560145
> [INFO] Processing JSON file static_routes.json.1451560145
> Traceback (most recent call last):
>   File "/opt/cloud/bin/update_config.py", line 140, in 
> process_file()
>   File "/opt/cloud/bin/update_config.py", line 52, in process_file
> qf.load(None)
>   File "/opt/cloud/bin/merge.py", line 258, in load
> proc = updateDataBag(self)
>   File "/opt/cloud/bin/merge.py", line 91, in __init__
> self.process()
>   File "/opt/cloud/bin/merge.py", line 131, in process
> dbag = self.process_staticroutes(self.db.getDataBag())
>   File "/opt/cloud/bin/merge.py", line 179, in process_staticroutes
> return cs_staticroutes.merge(dbag, self.qFile.data)
>   File "/opt/cloud/bin/cs_staticroutes.py", line 26, in merge
> del dbag[key]
> KeyError: u'192.168.0.3'
> When deleting fails because it isn't there any more, it should succeed ;-)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9137) Domain admins cannot create nor delete a private gateway

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9137.


> Domain admins cannot create nor delete a private gateway
> 
>
> Key: CLOUDSTACK-9137
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9137
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.0
>
>
> To create a private gateway you need a root admin account. This does not make 
> sense, as you can do a lot more with such a powerful account. Other network 
> related API calls can be made by a domain admin.
> Let's change it so domain admins can create their own private gateways.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9240.


> Templatesize >40GB doesn't work properly
> 
>
> Key: CLOUDSTACK-9240
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the 
> size of the template that gets created. I could not find any justification of 
> that. I am just removing them as they caused us a huge headache when we tried 
> to create bigger templates and they failed without any good error.
> Source: https://github.com/apache/cloudstack/pull/1223



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-9254) Name of logged in user in UI is not always lined out properly

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma reassigned CLOUDSTACK-9254:


Assignee: Remi Bergsma

> Name of logged in user in UI is not always lined out properly
> -
>
> Key: CLOUDSTACK-9254
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9254
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.2
>
> Attachments: Screenshot_23_01_16_21_10.png
>
>
> The name of the logged in user is not always layed out properly. Right top.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9254) Name of logged in user in UI is not always lined out properly

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9254.
--
   Resolution: Fixed
Fix Version/s: 4.7.2

> Name of logged in user in UI is not always lined out properly
> -
>
> Key: CLOUDSTACK-9254
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9254
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.2
>
> Attachments: Screenshot_23_01_16_21_10.png
>
>
> The name of the logged in user is not always layed out properly. Right top.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8810) Async jobs are not cleaned due to foreign key constraint failure resulting in many blocking jobs

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-8810.
--
Resolution: Fixed

> Async jobs are not cleaned due to foreign key constraint failure resulting in 
> many blocking jobs
> 
>
> Key: CLOUDSTACK-8810
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8810
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.4.4
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> 2015-09-02 10:52:37,688 ERROR [c.c.v.VirtualMachineManagerImpl] 
> (Vm-Operations-Cleanup-1:ctx-54137067) VM Operations failed due to 
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@74bd25c9: DELETE FROM async_job WHERE 
> async_job.id= 2094487
>   at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1178)
>   at 
> org.apache.cloudstack.framework.jobs.dao.VmWorkJobDaoImpl.expungeCompletedWorkJobs(VmWorkJobDaoImpl.java:149)
>   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.$Proxy182.expungeCompletedWorkJobs(Unknown Source)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl$CleanupTask.runInContext(VirtualMachineManagerImpl.java:2392)
>   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 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>   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: 
> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: 
> Cannot delete or update a parent row: a foreign key constraint fails 
> (`cloud`.`async_job_join_map`, CONSTRAINT 
> `fk_async_job_join_map__join_job_id` FOREIGN KEY (`join_job_id`) REFERENCES 
> `async_job` (`id`))
>   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:526)
>   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:1040)
>   at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597)
>   

[jira] [Closed] (CLOUDSTACK-8810) Async jobs are not cleaned due to foreign key constraint failure resulting in many blocking jobs

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-8810.


> Async jobs are not cleaned due to foreign key constraint failure resulting in 
> many blocking jobs
> 
>
> Key: CLOUDSTACK-8810
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8810
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.4.4
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> 2015-09-02 10:52:37,688 ERROR [c.c.v.VirtualMachineManagerImpl] 
> (Vm-Operations-Cleanup-1:ctx-54137067) VM Operations failed due to 
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@74bd25c9: DELETE FROM async_job WHERE 
> async_job.id= 2094487
>   at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1178)
>   at 
> org.apache.cloudstack.framework.jobs.dao.VmWorkJobDaoImpl.expungeCompletedWorkJobs(VmWorkJobDaoImpl.java:149)
>   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.$Proxy182.expungeCompletedWorkJobs(Unknown Source)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl$CleanupTask.runInContext(VirtualMachineManagerImpl.java:2392)
>   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 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>   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: 
> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: 
> Cannot delete or update a parent row: a foreign key constraint fails 
> (`cloud`.`async_job_join_map`, CONSTRAINT 
> `fk_async_job_join_map__join_job_id` FOREIGN KEY (`join_job_id`) REFERENCES 
> `async_job` (`id`))
>   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:526)
>   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:1040)
>   at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597)
>   at 

[jira] [Assigned] (CLOUDSTACK-8810) Async jobs are not cleaned due to foreign key constraint failure resulting in many blocking jobs

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma reassigned CLOUDSTACK-8810:


Assignee: Remi Bergsma

> Async jobs are not cleaned due to foreign key constraint failure resulting in 
> many blocking jobs
> 
>
> Key: CLOUDSTACK-8810
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8810
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.4.4
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> 2015-09-02 10:52:37,688 ERROR [c.c.v.VirtualMachineManagerImpl] 
> (Vm-Operations-Cleanup-1:ctx-54137067) VM Operations failed due to 
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@74bd25c9: DELETE FROM async_job WHERE 
> async_job.id= 2094487
>   at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1178)
>   at 
> org.apache.cloudstack.framework.jobs.dao.VmWorkJobDaoImpl.expungeCompletedWorkJobs(VmWorkJobDaoImpl.java:149)
>   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.$Proxy182.expungeCompletedWorkJobs(Unknown Source)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl$CleanupTask.runInContext(VirtualMachineManagerImpl.java:2392)
>   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 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>   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: 
> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: 
> Cannot delete or update a parent row: a foreign key constraint fails 
> (`cloud`.`async_job_join_map`, CONSTRAINT 
> `fk_async_job_join_map__join_job_id` FOREIGN KEY (`join_job_id`) REFERENCES 
> `async_job` (`id`))
>   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:526)
>   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:1040)
>   at 

[jira] [Resolved] (CLOUDSTACK-8300) Add index on archived field in cloud.event table

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-8300.
--
Resolution: Fixed

> 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
>Assignee: Remi Bergsma
>Priority: Minor
> Fix For: 4.9.0
>
>
> 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 

[jira] [Closed] (CLOUDSTACK-8300) Add index on archived field in cloud.event table

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-8300.


> 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
>Assignee: Remi Bergsma
>Priority: Minor
> Fix For: 4.9.0
>
>
> 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 

[jira] [Updated] (CLOUDSTACK-8300) Add index on archived field in cloud.event table

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-8300:
-
Fix Version/s: 4.9.0

> 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
>Assignee: Remi Bergsma
>Priority: Minor
> Fix For: 4.9.0
>
>
> 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 

[jira] [Assigned] (CLOUDSTACK-8300) Add index on archived field in cloud.event table

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma reassigned CLOUDSTACK-8300:


Assignee: Remi Bergsma

> 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
>Assignee: Remi Bergsma
>Priority: Minor
> Fix For: 4.9.0
>
>
> 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 

[jira] [Commented] (CLOUDSTACK-7836) S2S VPN CIDR list max 200 chars and only RFC1918

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15124999#comment-15124999
 ] 

Remi Bergsma commented on CLOUDSTACK-7836:
--

The PR above addresses point 2 only.

> S2S VPN CIDR list max 200 chars and only RFC1918
> 
>
> Key: CLOUDSTACK-7836
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7836
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.1.0
>Reporter: Thijs Houtenbos
>Priority: Minor
>
> When creating a S2S VPN within Cloudstack there are two problems with the 
> CIDR list field:
> 1. It only accepts RFC1918 addresses
> 2. It's length is limited to 200 characters, which is too short



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9264) Create of /32 static route on private gw fails

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9264:


 Summary: Create of /32 static route on private gw fails
 Key: CLOUDSTACK-9264
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9264
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.7.0, 4.7.1
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical


The /32 static route creation fails. When trying manual the command it runs we 
see why:

root@r-2934-VM:~# route add -net 172.16.1.4/32 gw 172.16.1.1
SIOCADDRT: Invalid argument

Let's use 'ip' toolset or use -host for /32



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9256) Static routes get lost after network restart

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9256:


 Summary: Static routes get lost after network restart
 Key: CLOUDSTACK-9256
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9256
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Assignee: Remi Bergsma


Static routes that are being set do not show up in the static_routes.json file. 
The reason for this is that the index that is used, is the gateway address, 
which is not unique. Hence stuff is overwritten and lost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9254) Name of logged in user in UI is not always lined out properly

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9254:


 Summary: Name of logged in user in UI is not always lined out 
properly
 Key: CLOUDSTACK-9254
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9254
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Remi Bergsma
 Attachments: Screenshot_23_01_16_21_10.png

The name of the logged in user is not always layed out properly. Right top.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9254) Name of logged in user in UI is not always lined out properly

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9254:
-
Attachment: Screenshot_23_01_16_21_10.png

> Name of logged in user in UI is not always lined out properly
> -
>
> Key: CLOUDSTACK-9254
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9254
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Remi Bergsma
> Attachments: Screenshot_23_01_16_21_10.png
>
>
> The name of the logged in user is not always layed out properly. Right top.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9240:


 Summary: Templatesize >40GB doesn't work properly
 Key: CLOUDSTACK-9240
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical
 Fix For: 4.7.1


Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the 
size of the template that gets created. I could not find any justification of 
that. I am just removing them as they caused us a huge headache when we tried 
to create bigger templates and they failed without any good error.

Source: https://github.com/apache/cloudstack/pull/1223



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9222) cloud.log is filling up disk space

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9222:


 Summary: cloud.log is filling up disk space
 Key: CLOUDSTACK-9222
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9222
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical
 Fix For: 4.7.1


Delay Compress results in more space usage than needed. Since we have copy 
truncate we don't need it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9220:


 Summary: List of domains in Domain tab in UI is not sorted
 Key: CLOUDSTACK-9220
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Assignee: Remi Bergsma
 Fix For: 4.7.1


The list of domains in the UI is not sorted which is unhandy when there are 
large amounts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9221) Admin cannot see VMs on port forwarding page

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9221:


 Summary: Admin cannot see VMs on port forwarding page
 Key: CLOUDSTACK-9221
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9221
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Assignee: Remi Bergsma
 Fix For: 4.7.1


When you go to the UI as root admin and go to a VPC of a user, you can see lots 
of options. However, when you select an IP and want to configure port 
forwarding, the list of VMs shows ERROR (due to missing parameters). These need 
to be added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9017) VPC VR DHCP broken for multihomed guest VMs

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9017:
-
Priority: Major  (was: Minor)

> VPC VR DHCP broken for multihomed guest VMs
> ---
>
> Key: CLOUDSTACK-9017
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9017
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router
>Affects Versions: 4.5.2, 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: CloudStack 4.5.2, XenServer back end.
>Reporter: Dag Sonstebo
>  Labels: systemvm, virtualrouter, vpc
>
> Bug: VPC VR DHCP broken for multihomed guest VMs
> Affected version: CloudStack 4.5.2 only tested
> Summary: When attaching a guest VM to more than one VPC tier DHCP will only 
> work for the last NIC to be added. This is according to end user new 
> behaviour after the CS4.5.2 upgrade.
> Workarounds:
> 1) Only use single NICs on VPC connected VMs and configure L3 routing and 
> ACLs to handle traffic between tiers.
> 2) Configure additional tier NICs with the static IP addresses reported by 
> CloudStack.
>   
> 
> Steps to recreate:
> 1) Create a VPC with two tiers, in this case
>   - VPC on 10.3.0.0/16
>   - Tier 1 on 10.3.1.0/24
>   - Tier 2 on 10.3.2.0/24
> 2) Create a new VM attached to tier 1 only. This will cause a new entry to be 
> written to /etc/dhcphosts.txt on the VPC VR:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:21:fd:00:08,set:10_3_1_162,10.3.1.162,BatVM2,infinite
> root@r-20-VM:~#
> When the VM starts up the following is displayed in /var/log/dnsmasq.log when 
> the VM requests it's IP address:
> Oct 30 15:50:12 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPOFFER(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPACK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 BatVM2
> The following is displayed in the dnsmasq leases file:
> root@r-20-VM:~# cat /var/lib/misc/dnsmasq.leases 
> 0 02:00:21:fd:00:08 10.3.1.162 BatVM2 *
> And the following in the cloud DHCP configuration file:
> root@r-20-VM:~# cat /etc/dnsmasq.d/cloud.conf 
> dhcp-hostsfile=/etc/dhcphosts.txt
> dhcp-range=interface:eth3,set:interface-eth3,10.3.2.1,static
> dhcp-option=tag:interface-eth3,15,batvpc.net
> dhcp-range=interface:eth2,set:interface-eth2,10.3.1.1,static
> dhcp-option=tag:interface-eth2,15,batvpc.net
> root@r-20-VM:~# 
> 3) Checking the VM locally IP configuration will show DHCP lease in place for 
> eth0.
> 4) Add a new NIC to the VM, attached to Tier 2.   This results in the 
> following entries in the dnsmasq log:
> Oct 30 16:23:02 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2.batvpc.net to the 
> DHCP lease of 10.3.1.162 because the name exists in /etc/hosts with address 
> 10.3.2.111
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2 to the DHCP lease 
> of 10.3.1.162 because the name exists in /etc/hosts with address 10.3.2.111
> In other words the Tier 2 address has taken precedence over the initial Tier 
> 1 address.
> The /etc/dhcphosts.txt file has now lost the Tier 1 entry and now contains:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:26:94:00:06,set:10_3_2_111,10.3.2.111,BatVM2,infinite
> 5) When restarting the VM it will fail to get a DHCP lease on eth0.
> Note: in some cases it will reuse the old lease which is cached in the local 
> leases database - note this IP lease does not come from the VPC VR.
> The dnsmasq log will now display the following:
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPNAK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 address not available
> Oct 30 16:30:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:30:58 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:31:13 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:31:22 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:31:32 dnsmasq-dhcp[8246]: 

[jira] [Commented] (CLOUDSTACK-9017) VPC VR DHCP broken for multihomed guest VMs

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076373#comment-15076373
 ] 

Remi Bergsma commented on CLOUDSTACK-9017:
--

This seems a DNSmasq thing. This has some hints on how to resolve it: 
http://stackoverflow.com/questions/9326438/dnsmasq-serve-different-ip-addresses-based-on-interface-used
 We will need to alter dnsmasq on our VR/VPC routers to support this.

> VPC VR DHCP broken for multihomed guest VMs
> ---
>
> Key: CLOUDSTACK-9017
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9017
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router
>Affects Versions: 4.5.2, 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: CloudStack 4.5.2, XenServer back end.
>Reporter: Dag Sonstebo
>Priority: Minor
>  Labels: systemvm, virtualrouter, vpc
>
> Bug: VPC VR DHCP broken for multihomed guest VMs
> Affected version: CloudStack 4.5.2 only tested
> Summary: When attaching a guest VM to more than one VPC tier DHCP will only 
> work for the last NIC to be added. This is according to end user new 
> behaviour after the CS4.5.2 upgrade.
> Workarounds:
> 1) Only use single NICs on VPC connected VMs and configure L3 routing and 
> ACLs to handle traffic between tiers.
> 2) Configure additional tier NICs with the static IP addresses reported by 
> CloudStack.
>   
> 
> Steps to recreate:
> 1) Create a VPC with two tiers, in this case
>   - VPC on 10.3.0.0/16
>   - Tier 1 on 10.3.1.0/24
>   - Tier 2 on 10.3.2.0/24
> 2) Create a new VM attached to tier 1 only. This will cause a new entry to be 
> written to /etc/dhcphosts.txt on the VPC VR:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:21:fd:00:08,set:10_3_1_162,10.3.1.162,BatVM2,infinite
> root@r-20-VM:~#
> When the VM starts up the following is displayed in /var/log/dnsmasq.log when 
> the VM requests it's IP address:
> Oct 30 15:50:12 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPOFFER(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPACK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 BatVM2
> The following is displayed in the dnsmasq leases file:
> root@r-20-VM:~# cat /var/lib/misc/dnsmasq.leases 
> 0 02:00:21:fd:00:08 10.3.1.162 BatVM2 *
> And the following in the cloud DHCP configuration file:
> root@r-20-VM:~# cat /etc/dnsmasq.d/cloud.conf 
> dhcp-hostsfile=/etc/dhcphosts.txt
> dhcp-range=interface:eth3,set:interface-eth3,10.3.2.1,static
> dhcp-option=tag:interface-eth3,15,batvpc.net
> dhcp-range=interface:eth2,set:interface-eth2,10.3.1.1,static
> dhcp-option=tag:interface-eth2,15,batvpc.net
> root@r-20-VM:~# 
> 3) Checking the VM locally IP configuration will show DHCP lease in place for 
> eth0.
> 4) Add a new NIC to the VM, attached to Tier 2.   This results in the 
> following entries in the dnsmasq log:
> Oct 30 16:23:02 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2.batvpc.net to the 
> DHCP lease of 10.3.1.162 because the name exists in /etc/hosts with address 
> 10.3.2.111
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2 to the DHCP lease 
> of 10.3.1.162 because the name exists in /etc/hosts with address 10.3.2.111
> In other words the Tier 2 address has taken precedence over the initial Tier 
> 1 address.
> The /etc/dhcphosts.txt file has now lost the Tier 1 entry and now contains:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:26:94:00:06,set:10_3_2_111,10.3.2.111,BatVM2,infinite
> 5) When restarting the VM it will fail to get a DHCP lease on eth0.
> Note: in some cases it will reuse the old lease which is cached in the local 
> leases database - note this IP lease does not come from the VPC VR.
> The dnsmasq log will now display the following:
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPNAK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 address not available
> Oct 30 16:30:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:30:58 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 

[jira] [Updated] (CLOUDSTACK-9017) VPC VR DHCP broken for multihomed guest VMs

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9017:
-
Affects Version/s: 4.6.2
   4.6.1
   4.7.0
   4.6.0

> VPC VR DHCP broken for multihomed guest VMs
> ---
>
> Key: CLOUDSTACK-9017
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9017
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router
>Affects Versions: 4.5.2, 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: CloudStack 4.5.2, XenServer back end.
>Reporter: Dag Sonstebo
>Priority: Minor
>  Labels: systemvm, virtualrouter, vpc
>
> Bug: VPC VR DHCP broken for multihomed guest VMs
> Affected version: CloudStack 4.5.2 only tested
> Summary: When attaching a guest VM to more than one VPC tier DHCP will only 
> work for the last NIC to be added. This is according to end user new 
> behaviour after the CS4.5.2 upgrade.
> Workarounds:
> 1) Only use single NICs on VPC connected VMs and configure L3 routing and 
> ACLs to handle traffic between tiers.
> 2) Configure additional tier NICs with the static IP addresses reported by 
> CloudStack.
>   
> 
> Steps to recreate:
> 1) Create a VPC with two tiers, in this case
>   - VPC on 10.3.0.0/16
>   - Tier 1 on 10.3.1.0/24
>   - Tier 2 on 10.3.2.0/24
> 2) Create a new VM attached to tier 1 only. This will cause a new entry to be 
> written to /etc/dhcphosts.txt on the VPC VR:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:21:fd:00:08,set:10_3_1_162,10.3.1.162,BatVM2,infinite
> root@r-20-VM:~#
> When the VM starts up the following is displayed in /var/log/dnsmasq.log when 
> the VM requests it's IP address:
> Oct 30 15:50:12 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPOFFER(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPACK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 BatVM2
> The following is displayed in the dnsmasq leases file:
> root@r-20-VM:~# cat /var/lib/misc/dnsmasq.leases 
> 0 02:00:21:fd:00:08 10.3.1.162 BatVM2 *
> And the following in the cloud DHCP configuration file:
> root@r-20-VM:~# cat /etc/dnsmasq.d/cloud.conf 
> dhcp-hostsfile=/etc/dhcphosts.txt
> dhcp-range=interface:eth3,set:interface-eth3,10.3.2.1,static
> dhcp-option=tag:interface-eth3,15,batvpc.net
> dhcp-range=interface:eth2,set:interface-eth2,10.3.1.1,static
> dhcp-option=tag:interface-eth2,15,batvpc.net
> root@r-20-VM:~# 
> 3) Checking the VM locally IP configuration will show DHCP lease in place for 
> eth0.
> 4) Add a new NIC to the VM, attached to Tier 2.   This results in the 
> following entries in the dnsmasq log:
> Oct 30 16:23:02 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2.batvpc.net to the 
> DHCP lease of 10.3.1.162 because the name exists in /etc/hosts with address 
> 10.3.2.111
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2 to the DHCP lease 
> of 10.3.1.162 because the name exists in /etc/hosts with address 10.3.2.111
> In other words the Tier 2 address has taken precedence over the initial Tier 
> 1 address.
> The /etc/dhcphosts.txt file has now lost the Tier 1 entry and now contains:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:26:94:00:06,set:10_3_2_111,10.3.2.111,BatVM2,infinite
> 5) When restarting the VM it will fail to get a DHCP lease on eth0.
> Note: in some cases it will reuse the old lease which is cached in the local 
> leases database - note this IP lease does not come from the VPC VR.
> The dnsmasq log will now display the following:
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPNAK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 address not available
> Oct 30 16:30:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:30:58 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:31:13 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:31:22 dnsmasq-dhcp[8246]: 

[jira] [Created] (CLOUDSTACK-9204) Delete static route fails when it's already gone

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9204:


 Summary: Delete static route fails when it's already gone
 Key: CLOUDSTACK-9204
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9204
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: SystemVM
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical
 Fix For: 4.7.1


When you try to delete a static route, this fails when it's no longer there on 
the router (not sure why that happens).

Error seen:
[INFO] update_config.py :: Processing incoming file => 
static_routes.json.1451560145
[INFO] Processing JSON file static_routes.json.1451560145
Traceback (most recent call last):
  File "/opt/cloud/bin/update_config.py", line 140, in 
process_file()
  File "/opt/cloud/bin/update_config.py", line 52, in process_file
qf.load(None)
  File "/opt/cloud/bin/merge.py", line 258, in load
proc = updateDataBag(self)
  File "/opt/cloud/bin/merge.py", line 91, in __init__
self.process()
  File "/opt/cloud/bin/merge.py", line 131, in process
dbag = self.process_staticroutes(self.db.getDataBag())
  File "/opt/cloud/bin/merge.py", line 179, in process_staticroutes
return cs_staticroutes.merge(dbag, self.qFile.data)
  File "/opt/cloud/bin/cs_staticroutes.py", line 26, in merge
del dbag[key]
KeyError: u'192.168.0.3'

When deleting fails because it isn't there any more, it should succeed ;-)




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6448) VPC router won't be created when a private gateway is defined.

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076127#comment-15076127
 ] 

Remi Bergsma commented on CLOUDSTACK-6448:
--

Error seen on 4.7:

2015-12-31 18:38:20,653 WARN  [c.c.n.v.VpcManagerImpl] 
(API-Job-Executor-10:ctx-5dc3a60a job-44358 ctx-c7ad79a8) Failed to start vpc 
[VPC [732-vpctest] due to
java.lang.NullPointerException
at 
com.cloud.network.router.NicProfileHelperImpl.createPrivateNicProfileForGateway(NicProfileHelperImpl.java:74)
at 
com.cloud.network.router.VpcNetworkHelperImpl.reallocateRouterNetworks(VpcNetworkHelperImpl.java:96)
at 
com.cloud.network.router.NetworkHelperImpl.deployRouter(NetworkHelperImpl.java:497)
at 
org.cloud.network.router.deployment.VpcRouterDeploymentDefinition.deployAllVirtualRouters(VpcRouterDeploymentDefinition.java:173)
at 
org.cloud.network.router.deployment.RouterDeploymentDefinition.executeDeployment(RouterDeploymentDefinition.java:351)
at 
org.cloud.network.router.deployment.RouterDeploymentDefinition.findOrDeployVirtualRouter(RouterDeploymentDefinition.java:214)
at 
org.cloud.network.router.deployment.VpcRouterDeploymentDefinition.findOrDeployVirtualRouter(VpcRouterDeploymentDefinition.java:138)
at 
org.cloud.network.router.deployment.RouterDeploymentDefinition.deployVirtualRouter(RouterDeploymentDefinition.java:197)
at 
com.cloud.network.element.VpcVirtualRouterElement.implementVpc(VpcVirtualRouterElement.java:159)
at 
com.cloud.network.vpc.VpcManagerImpl.startVpc(VpcManagerImpl.java:1202)
at 
com.cloud.network.vpc.VpcManagerImpl.startVpc(VpcManagerImpl.java:1174)
at 
com.cloud.network.vpc.VpcManagerImpl.restartVpc(VpcManagerImpl.java:1530)
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)


NicProfileHelperImpl.java:
 74 final Nic privateNic = 
_nicDao.findByIp4AddressAndNetworkId(ipVO.getIpAddress(), 
privateNetwork.getId());


privateNetwork.getId() is used above so cannot be NULL. So, ipVO.getIpAddress() 
must be NULL



> VPC router won't be created when a private gateway is defined. 
> ---
>
> Key: CLOUDSTACK-6448
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6448
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices, Virtual Router
>Affects Versions: 4.3.0, 4.4.0, 4.3.1, 4.5.2, 4.6.0, 4.7.0, 4.7.1
>Reporter: Anton Opgenoort
>Assignee: Saksham Srivastava
>
> Reproduce by creating a VPC, adding a gateway, and destroy the associated 
> virtual router. Then try to start a VM in one of the VPC network tiers; this 
> results in message below, and routerVM is not started for VPC network. 
> Then remove the private gateway, and start a VM again. Now the routerVM is 
> started normally, and the VM is being provisioned. 
> 2014-04-18 10:35:04,895 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) VM is being created in podId: 1
> 2014-04-18 10:35:04,907 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Network id=1143 is already 
> implemented
> 2014-04-18 10:35:04,943 DEBUG [c.c.n.NetworkModelImpl] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Service SecurityGroup is not 
> supported in the network id=1143
> 2014-04-18 10:35:04,958 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Changing active number of nics 
> for network id=1143 on 1
> 2014-04-18 10:35:04,973 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Asking VpcVirtualRouter to 
> prepare for Nic[98879-15684-e51a9969-e1f1-4c45-ad65-761e51435b90-10.1.1.98]
> 2014-04-18 10:35:04,979 DEBUG [c.c.n.r.VpcVirtualNetworkApplianceManagerImpl] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Deploying Virtual Router in VPC 
> [VPC [313-mccoat1]
> 2014-04-18 10:35:05,006 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Adding nic for Virtual Router in 
> Control network 
> 2014-04-18 10:35:05,014 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Found existing network 
> configuration for offering [Network Offering 
> [5-Control-System-Control-Network]: Ntwk[202|Control|5]
> 2014-04-18 10:35:05,014 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Releasing lock for 
> 

[jira] [Resolved] (CLOUDSTACK-8987) S3 XenServer plugin fails due to plugin not found

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-8987.
--
   Resolution: Fixed
Fix Version/s: 4.6.0

was already resolved.

> 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
> Fix For: 4.6.0
>
>
> 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] [Closed] (CLOUDSTACK-8987) S3 XenServer plugin fails due to plugin not found

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-8987.


> 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
> Fix For: 4.6.0
>
>
> 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] [Updated] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9154:
-
Priority: Critical  (was: Major)

> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> 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, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the 
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 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
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
> "add": true,
>   

[jira] [Created] (CLOUDSTACK-9202) SSH commands to VR timeout sometimes

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9202:


 Summary: SSH commands to VR timeout sometimes
 Key: CLOUDSTACK-9202
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9202
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical
 Fix For: 4.7.1


Error seen:

2015-12-28 14:35:18,201 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(Work-Job-Executor-1:ctx-34ff7f80 job-39723/job-39726 ctx-d63de41b) Timed out 
in waiting SSH execution result
2015-12-28 14:35:18,201 WARN  [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(Work-Job-Executor-1:ctx-34ff7f80 job-39723/job-39726 ctx-d63de41b) Command: 
com.cloud.agent.api.Command failed while starting virtua
l router
2015-12-28 14:35:18,201 INFO  [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-1:ctx-34ff7f80 job-39723/job-39726 ctx-d63de41b) The guru 
did not like the answers so stopping VM[DomainRouter|r-1534-VM]

.Answer":{"result":true,"wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Timed
 out in waiting SSH execution result","wait":0}}] }

It needs to be investigated why 60 second timeout is not enough, for now 
bumping it would help.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9181) Syntax error in checkrouter.sh when interface is missing

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9181:


 Summary: Syntax error in checkrouter.sh when interface is missing
 Key: CLOUDSTACK-9181
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9181
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.7.0
Reporter: Remi Bergsma


Error seen in mgt server:
2015-12-15 14:30:32,371 DEBUG [c.c.a.m.AgentManagerImpl] 
(RedundantRouterStatusMonitor-7:ctx-0dd8ef3e) Details from executing class 
com.cloud.agent.api.CheckRouterCommand: Status: UNKNOWN
/opt/cloud/bin/checkrouter.sh: line 28: [: =: unary operator expected
/opt/cloud/bin/checkrouter.sh: line 31: [: =: unary operator expected

root@r-1191-VM:/opt/cloud/bin# ./checkrouter.sh
./checkrouter.sh: line 28: [: =: unary operator expected
./checkrouter.sh: line 31: [: =: unary operator expected
Status: UNKNOWN

Somehow a nic was missing.

After fix the script can handle this:

root@r-1191-VM:/opt/cloud/bin# ./checkrouter.sh
Status: UNKNOWN




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9170) Register template in UI does not show zones in dropdown listbox

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059127#comment-15059127
 ] 

Remi Bergsma commented on CLOUDSTACK-9170:
--

Can you please post a screenshot?




> Register template in UI does not show zones in dropdown listbox
> ---
>
> Key: CLOUDSTACK-9170
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9170
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
> Attachments: Screen Shot 2015-12-15 at 15.16.51.png
>
>
> The only option listed is "All zones". No API call is done to query the zones.
> Check screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9169) createNetwork API call takes a long time when ispersistent=True

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9169:


 Summary: createNetwork API call takes a long time when 
ispersistent=True
 Key: CLOUDSTACK-9169
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9169
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Priority: Critical


When one create a network offering with ispersistent=True it will take a long 
time because the routerVM is created immediately. Since the call is not 
asynchonous, this will take minutes and most of the time timeout.

Steps to reproduce:

Create offering:

cloudmonkey create networkoffering \
ispersistent=True \
name=Redundant-SNAT \
conservemode=False \
displaytext="Regular redundant router with Source NAT and IP conservation" \
guestiptype=Isolated \
traffictype=GUEST \
specifyvlan=False \
availability=Optional \
supportedservices=UserData,PortForwarding,Dhcp,Vpn,Dns,SourceNat,Connectivity,StaticNat
 \
serviceproviderlist[0].service=UserData 
serviceproviderlist[0].provider=VirtualRouter \
serviceproviderlist[1].service=PortForwarding 
serviceproviderlist[1].provider=VirtualRouter \
serviceproviderlist[2].service=Dhcp 
serviceproviderlist[2].provider=VirtualRouter \
serviceproviderlist[3].service=Vpn 
serviceproviderlist[3].provider=VirtualRouter \
serviceproviderlist[4].service=Dns 
serviceproviderlist[4].provider=VirtualRouter \
serviceproviderlist[5].service=SourceNat 
serviceproviderlist[5].provider=VirtualRouter \
serviceproviderlist[6].service=Connectivity 
serviceproviderlist[6].provider=VirtualRouter \
serviceproviderlist[7].service=StaticNat 
serviceproviderlist[7].provider=VirtualRouter \
serviceofferingid=some-id

Then enable it.

Then create a network using this. The fastest way is to use the Create Instance 
wizard and there create a new network using this offering.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9170) Register template in UI does not show zones in dropdown listbox

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9170:


 Summary: Register template in UI does not show zones in dropdown 
listbox
 Key: CLOUDSTACK-9170
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9170
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Remi Bergsma


The only option listed is "All zones". No API call is done to query the zones.

Check screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9170) Register template in UI does not show zones in dropdown listbox

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9170:
-
Affects Version/s: 4.7.0

> Register template in UI does not show zones in dropdown listbox
> ---
>
> Key: CLOUDSTACK-9170
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9170
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>
> The only option listed is "All zones". No API call is done to query the zones.
> Check screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9171) Templates registered with CrossZones have no zone name listed

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9171:


 Summary: Templates registered with CrossZones have no zone name 
listed
 Key: CLOUDSTACK-9171
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9171
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API, UI
Affects Versions: 4.7.0
Reporter: Remi Bergsma


Register template without specifying a zone.

See screenshot, no name is listed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9172) Templates registered with CrossZones cannot be deleted in UI

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9172:


 Summary: Templates registered with CrossZones cannot be deleted in 
UI
 Key: CLOUDSTACK-9172
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9172
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Remi Bergsma
 Fix For: 4.7.0
 Attachments: Screen Shot 2015-12-15 at 15.32.12.png

The zoneid is missing and the API call fails. See screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9172) Templates registered with CrossZones cannot be deleted in UI

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9172:
-
Attachment: Screen Shot 2015-12-15 at 15.32.12.png

> Templates registered with CrossZones cannot be deleted in UI
> 
>
> Key: CLOUDSTACK-9172
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9172
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Remi Bergsma
> Fix For: 4.7.0
>
> Attachments: Screen Shot 2015-12-15 at 15.32.12.png
>
>
> The zoneid is missing and the API call fails. See screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9155) Log rotate of cloud.log doesn't work properly

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9155.


> Log rotate of cloud.log doesn't work properly
> -
>
> Key: CLOUDSTACK-9155
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9155
> 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, 4.7.0, 4.6.1
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.0, 4.6.2
>
>
> Many processes log into the cloud.log file. When log rotate is called, many 
> of them keep logging to the old inode and fill up the disk like that.
> These have cloud.log open:
> ```
> root@r-1023-VM:~# lsof| grep cloud | awk {'print $1'} | sort -u
> apache2
> conntrack
> keepalive
> logger
> passwd_se
> _plutoloa
> _plutorun
> python
> xl2tpd
> ```
> Current log rotate config:
> ```
> /var/log/cloud.log {
> rotate 4
> daily
> size 10M
> missingok
> notifempty
> compress
> delaycompress
> }
> ```
> After log rotate this happens:
> ```
> root@r-996-VM:/etc# lsof | grep cloud.log.1
> _plutorun   767  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> logger  768  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutorun   772  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutoloa   773  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> xl2tpd  843  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  854  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  863  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  871  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> ```



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9170) Register template in UI does not show zones in dropdown listbox

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9170:
-
Attachment: Screen Shot 2015-12-15 at 15.16.51.png

> Register template in UI does not show zones in dropdown listbox
> ---
>
> Key: CLOUDSTACK-9170
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9170
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
> Attachments: Screen Shot 2015-12-15 at 15.16.51.png
>
>
> The only option listed is "All zones". No API call is done to query the zones.
> Check screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9171) Templates registered with CrossZones have no zone name listed

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9171:
-
Attachment: Screen Shot 2015-12-15 at 15.19.39.png

> Templates registered with CrossZones have no zone name listed
> -
>
> Key: CLOUDSTACK-9171
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9171
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
> Attachments: Screen Shot 2015-12-15 at 15.19.39.png
>
>
> Register template without specifying a zone.
> See screenshot, no name is listed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9155) Log rotate of cloud.log doesn't work properly

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9155.
--
Resolution: Fixed

> Log rotate of cloud.log doesn't work properly
> -
>
> Key: CLOUDSTACK-9155
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9155
> 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, 4.7.0, 4.6.1
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.0, 4.6.2
>
>
> Many processes log into the cloud.log file. When log rotate is called, many 
> of them keep logging to the old inode and fill up the disk like that.
> These have cloud.log open:
> ```
> root@r-1023-VM:~# lsof| grep cloud | awk {'print $1'} | sort -u
> apache2
> conntrack
> keepalive
> logger
> passwd_se
> _plutoloa
> _plutorun
> python
> xl2tpd
> ```
> Current log rotate config:
> ```
> /var/log/cloud.log {
> rotate 4
> daily
> size 10M
> missingok
> notifempty
> compress
> delaycompress
> }
> ```
> After log rotate this happens:
> ```
> root@r-996-VM:/etc# lsof | grep cloud.log.1
> _plutorun   767  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> logger  768  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutorun   772  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutoloa   773  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> xl2tpd  843  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  854  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  863  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  871  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> ```



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network scavenger

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9154:


 Summary: rVPC doesn't recover from cleaning up of network scavenger
 Key: CLOUDSTACK-9154
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
 Environment: ACS 4.7
Reporter: Remi Bergsma


- deploy a rVPC
- deploy VM in it
- make port forwarding (2nd ip, firewall and such)
- confirm it works
- stop the vm
- after some time the network scavenger will come and tear down the network 
since there are no more VMs
- keepalived will enter FAULT state because of missing eth2 nic (which was 
first network tier)
- all is left is ethic (link local) and lo0
- then start the vm again
- the nics get plugged again and keepalived will decide on a new master
- the nics are screwed up after this:

```
root@r-1021-VM:~# ip a
1: lo:  mtu 16436 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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
inet x.y.238.24/24 brd x.y.238.255 scope global eth1
inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
inet x.y.238.25/24 brd x.y.238.255 scope global eth2
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
root@r-1021-VM:~#
```

Public and tier ip addresses are mixed up.

/etc/cloudstack/ips.json has the wrong info:
```
{   

 [44/959]
"eth0": [
{
"add": true,
"broadcast": "169.254.255.255",
"cidr": "169.254.2.146/16",
"device": "eth0",
"gateway": "None",
"netmask": "255.255.0.0",
"network": "169.254.0.0/16",
"nic_dev_id": "0",
"nw_type": "control",
"one_to_one_nat": false,
"public_ip": "169.254.2.146",
"size": "16",
"source_nat": false
}
],
"eth1": [
{
"add": true,
"broadcast": "x.y.238.255",
"cidr": "x.y.238.24/24",
"device": "eth1",
"first_i_p": true,
"gateway": "x.y.238.1",
"netmask": "255.255.255.0",
"network": "x.y.238.0/24",
"new_nic": false,
"nic_dev_id": 1,
"nw_type": "public",
"one_to_one_nat": false,
"public_ip": "x.y.238.24",
"size": "24",
"source_nat": true,
"vif_mac_address": "06:fc:da:00:00:1c"
},
{
"add": true,
"broadcast": "10.0.0.255",
"cidr": "10.0.0.51/24",
"device": "eth1",
"gateway": "10.0.0.1",
"netmask": "255.255.255.0",
"network": "10.0.0.0/24",
"nic_dev_id": "1",
"nw_type": "guest",
"one_to_one_nat": false,
"public_ip": "10.0.0.51",
"size": "24",
"source_nat": false
}
],
"eth2": [
{
"add": false,
"broadcast": "10.0.0.255",
"cidr": "10.0.0.173/24",
"device": "eth2",
"gateway": "10.0.0.1",
"netmask": "255.255.255.0",
"network": "10.0.0.0/24",
"nic_dev_id": "2",
"nw_type": "guest",
"one_to_one_nat": false,
"public_ip": "10.0.0.173",
"size": "24",
"source_nat": false
},
{
"add": true,
"broadcast": "x.y.238.255",
"cidr": "x.y.238.25/24",
"device": "eth2",
"first_i_p": true,
"gateway": "x.y.238.1",
"netmask": "255.255.255.0",
"network": "x.y.238.0/24",
"new_nic": false,
"nic_dev_id": 2,
"nw_type": "public",
"one_to_one_nat": false,
"public_ip": "x.y.238.25",
"size": "24",
"source_nat": true,
"vif_mac_address": "06:d5:4e:00:00:1d"
}
],
"id": "ips"
```

Pinging [~wilder.rodrigues]



--
This message was sent by 

[jira] [Created] (CLOUDSTACK-9155) Log rotate of cloud.log doesn't work properly

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9155:


 Summary: Log rotate of cloud.log doesn't work properly
 Key: CLOUDSTACK-9155
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9155
 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, 4.7.0, 4.6.1, 4.6.2
Reporter: Remi Bergsma
Priority: Critical


Many processes log into the cloud.log file. When log rotate is called, many of 
them keep logging to the old inode and fill up the disk like that.

These have cloud.log open:
```
root@r-1023-VM:~# lsof| grep cloud | awk {'print $1'} | sort -u
apache2
conntrack
keepalive
logger
passwd_se
_plutoloa
_plutorun
python
xl2tpd
```

Current log rotate config:
```
/var/log/cloud.log {
rotate 4
daily
size 10M
missingok
notifempty
compress
delaycompress
}

```

After log rotate this happens:
```
root@r-996-VM:/etc# lsof | grep cloud.log.1
_plutorun   767  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
logger  768  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
_plutorun   772  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
_plutoloa   773  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
xl2tpd  843  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
python  854  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
passwd_se   860  root1w  REG 202,10 26054919
 71 /var/log/cloud.log.1
passwd_se   860  root2w  REG 202,10 26054919
 71 /var/log/cloud.log.1
passwd_se   860  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
python  863  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
passwd_se   869  root1w  REG 202,10 26054919
 71 /var/log/cloud.log.1
passwd_se   869  root2w  REG 202,10 26054919
 71 /var/log/cloud.log.1
passwd_se   869  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
python  871  root3w  REG 202,10 26054919
 71 /var/log/cloud.log.1
```



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9155) Log rotate of cloud.log doesn't work properly

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054906#comment-15054906
 ] 

Remi Bergsma commented on CLOUDSTACK-9155:
--

Steps to reproduce:

- Check open files: lsof | grep cloud.log
- make sure cloud.log is >10MB
- run log rotate: log rotate /etc/logrotate.conf
- check that file is rotated (cloud.log.1 exists)
- you now see all processes use the old indoor (and write to cloud.log.1): 
lsog| grep cloud.log

> Log rotate of cloud.log doesn't work properly
> -
>
> Key: CLOUDSTACK-9155
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9155
> 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, 4.7.0, 4.6.1, 4.6.2
>Reporter: Remi Bergsma
>Priority: Critical
>
> Many processes log into the cloud.log file. When log rotate is called, many 
> of them keep logging to the old inode and fill up the disk like that.
> These have cloud.log open:
> ```
> root@r-1023-VM:~# lsof| grep cloud | awk {'print $1'} | sort -u
> apache2
> conntrack
> keepalive
> logger
> passwd_se
> _plutoloa
> _plutorun
> python
> xl2tpd
> ```
> Current log rotate config:
> ```
> /var/log/cloud.log {
> rotate 4
> daily
> size 10M
> missingok
> notifempty
> compress
> delaycompress
> }
> ```
> After log rotate this happens:
> ```
> root@r-996-VM:/etc# lsof | grep cloud.log.1
> _plutorun   767  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> logger  768  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutorun   772  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutoloa   773  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> xl2tpd  843  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  854  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  863  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  871  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> ```



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network scavenger

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054890#comment-15054890
 ] 

Remi Bergsma commented on CLOUDSTACK-9154:
--

rebooting them doesn't help.

> rVPC doesn't recover from cleaning up of network scavenger
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network scavenger will come and tear down the network 
> since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 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
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.25/24",
> "device": "eth2",
> "first_i_p": true,
> 

[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network scavenger

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054894#comment-15054894
 ] 

Remi Bergsma commented on CLOUDSTACK-9154:
--

Stopping the vm, destroying both routers, then starting the vm resolves it.

```
root@r-1023-VM:~# ip a
1: lo:  mtu 16436 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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:03:f9 brd ff:ff:ff:ff:ff:ff
inet 169.254.3.249/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:d8:6e:00:00:1c brd ff:ff:ff:ff:ff:ff
inet x.y.238.24/24 brd x.y.238.255 scope global eth1
inet x.y.238.25/24 brd x.y.238.255 scope global secondary eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:57:12:00:06 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.178/24 brd 10.0.0.255 scope global eth2
inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth2x.y
```

At least we have a work-around.

> rVPC doesn't recover from cleaning up of network scavenger
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network scavenger will come and tear down the network 
> since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 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
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": 

[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network scavenger

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054895#comment-15054895
 ] 

Remi Bergsma commented on CLOUDSTACK-9154:
--

The network scevenger should kill the router vms!

> rVPC doesn't recover from cleaning up of network scavenger
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network scavenger will come and tear down the network 
> since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 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
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.25/24",
> "device": "eth2",
> 

[jira] [Resolved] (CLOUDSTACK-9151) As a Developer I want the VRID to be set within the limits of KeepaliveD

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9151.
--
Resolution: Fixed

PR merged

> As a Developer I want the VRID to be set within the limits of KeepaliveD
> 
>
> Key: CLOUDSTACK-9151
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9151
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router, VPC
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.7.0, 4.6.2
>
>
> Dec 12 14:36:10 r-996-VM Keepalived_vrrp[28477]: VRRP Error : VRID not valid !
> Dec 12 14:36:10 r-996-VM Keepalived_vrrp[28477]:  must be between 
> 1 & 255. reconfigure !
> ​[3:38] 
> inside the /etc/keepalived/keepalived.conf
> ​[3:38] 
> vrrp_instance inside_network {
>   state EQUAL
>   interface eth4
>   virtual_router_id 459
> ​[3:43]
> The current code uses the VPC ID as VRID, but it doesn't have to be unique 
> per VPC, but for NIC. So, we can simply use 51, as the KeepaliveD suggests.
> # arbitary unique number 0..255 # used to differentiate multiple instances of 
> vrrpd # running on the same NIC (and hence same socket). virtual_router_id 51



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9151) As a Developer I want the VRID to be set within the limits of KeepaliveD

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9151.


> As a Developer I want the VRID to be set within the limits of KeepaliveD
> 
>
> Key: CLOUDSTACK-9151
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9151
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router, VPC
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.7.0, 4.6.2
>
>
> Dec 12 14:36:10 r-996-VM Keepalived_vrrp[28477]: VRRP Error : VRID not valid !
> Dec 12 14:36:10 r-996-VM Keepalived_vrrp[28477]:  must be between 
> 1 & 255. reconfigure !
> ​[3:38] 
> inside the /etc/keepalived/keepalived.conf
> ​[3:38] 
> vrrp_instance inside_network {
>   state EQUAL
>   interface eth4
>   virtual_router_id 459
> ​[3:43]
> The current code uses the VPC ID as VRID, but it doesn't have to be unique 
> per VPC, but for NIC. So, we can simply use 51, as the KeepaliveD suggests.
> # arbitary unique number 0..255 # used to differentiate multiple instances of 
> vrrpd # running on the same NIC (and hence same socket). virtual_router_id 51



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9143) Setup routes for RFC 1918 ip space

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9143.
--
Resolution: Fixed

PR merged

> Setup routes for RFC 1918 ip space
> --
>
> Key: CLOUDSTACK-9143
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9143
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.0
>
>
> Setup general route for RFC 1918 space, as otherwise it will be sent to the 
> public gateway and likely to be dropped (internet providers do not route ip 
> space that is meant for internal use). More specific routes that may be set 
> have preference over this generic routes so this works even with private 
> ranges used for public ip space (as shown below).
> When using an internal DNS server some hosts may resolve to an RFC 1918 ip 
> address. The SSVM has a default gw to public so if it has no route for this 
> ip address space, it will not work. This PR makes generic RFC 1918 (so all 
> internal ip adresses like 10.0.0.10 etc) to the local management gateway. 
> This makes them reachable. Without this fix, it is sent upstream and it is 
> dropped there.
> Should there be a more generic route (smaller prefix), this has preference 
> over the generic routes.
> Example in my dev environment:
> ```
> root@v-1-VM:~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse Iface
> 0.0.0.0 192.168.23.10.0.0.0 UG0  00 eth2
> 10.0.0.0192.168.22.1255.0.0.0   UG0  00 eth1
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
> 172.16.0.0  192.168.22.1255.240.0.0 UG0  00 eth1
> 192.168.0.0 192.168.22.1255.255.0.0 UG0  00 eth1
> 192.168.22.00.0.0.0 255.255.255.0   U 0  00 eth1
> 192.168.23.00.0.0.0 255.255.255.0   U 0  00 eth2
> ```
> Route `192.168.0.0/16` goes via `eth1` but `192.168.23.0/24` is more specific 
> and has preference and goes via `eth2`. It works:
> ```
> root@v-1-VM:~# ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 48 data bytes
> 56 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=7.179 ms
> ^C--- 8.8.8.8 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 7.179/7.179/7.179/0.000 ms
> ```
> This solves a lot of the 'internal resolving' issues we face.
> When the public ip address is RFC1918 itself, we do not set the routes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9143) Setup routes for RFC 1918 ip space

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9143.


> Setup routes for RFC 1918 ip space
> --
>
> Key: CLOUDSTACK-9143
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9143
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.0
>
>
> Setup general route for RFC 1918 space, as otherwise it will be sent to the 
> public gateway and likely to be dropped (internet providers do not route ip 
> space that is meant for internal use). More specific routes that may be set 
> have preference over this generic routes so this works even with private 
> ranges used for public ip space (as shown below).
> When using an internal DNS server some hosts may resolve to an RFC 1918 ip 
> address. The SSVM has a default gw to public so if it has no route for this 
> ip address space, it will not work. This PR makes generic RFC 1918 (so all 
> internal ip adresses like 10.0.0.10 etc) to the local management gateway. 
> This makes them reachable. Without this fix, it is sent upstream and it is 
> dropped there.
> Should there be a more generic route (smaller prefix), this has preference 
> over the generic routes.
> Example in my dev environment:
> ```
> root@v-1-VM:~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse Iface
> 0.0.0.0 192.168.23.10.0.0.0 UG0  00 eth2
> 10.0.0.0192.168.22.1255.0.0.0   UG0  00 eth1
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
> 172.16.0.0  192.168.22.1255.240.0.0 UG0  00 eth1
> 192.168.0.0 192.168.22.1255.255.0.0 UG0  00 eth1
> 192.168.22.00.0.0.0 255.255.255.0   U 0  00 eth1
> 192.168.23.00.0.0.0 255.255.255.0   U 0  00 eth2
> ```
> Route `192.168.0.0/16` goes via `eth1` but `192.168.23.0/24` is more specific 
> and has preference and goes via `eth2`. It works:
> ```
> root@v-1-VM:~# ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 48 data bytes
> 56 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=7.179 ms
> ^C--- 8.8.8.8 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 7.179/7.179/7.179/0.000 ms
> ```
> This solves a lot of the 'internal resolving' issues we face.
> When the public ip address is RFC1918 itself, we do not set the routes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9143) Setup routes for RFC 1918 ip space

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9143:


 Summary: Setup routes for RFC 1918 ip space
 Key: CLOUDSTACK-9143
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9143
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical
 Fix For: 4.7.0


Setup general route for RFC 1918 space, as otherwise it will be sent to the 
public gateway and likely to be dropped (internet providers do not route ip 
space that is meant for internal use). More specific routes that may be set 
have preference over this generic routes so this works even with private ranges 
used for public ip space (as shown below).

When using an internal DNS server some hosts may resolve to an RFC 1918 ip 
address. The SSVM has a default gw to public so if it has no route for this ip 
address space, it will not work. This PR makes generic RFC 1918 (so all 
internal ip adresses like 10.0.0.10 etc) to the local management gateway. This 
makes them reachable. Without this fix, it is sent upstream and it is dropped 
there.

Should there be a more generic route (smaller prefix), this has preference over 
the generic routes.

Example in my dev environment:

```
root@v-1-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 192.168.23.10.0.0.0 UG0  00 eth2
10.0.0.0192.168.22.1255.0.0.0   UG0  00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
172.16.0.0  192.168.22.1255.240.0.0 UG0  00 eth1
192.168.0.0 192.168.22.1255.255.0.0 UG0  00 eth1
192.168.22.00.0.0.0 255.255.255.0   U 0  00 eth1
192.168.23.00.0.0.0 255.255.255.0   U 0  00 eth2
```

Route `192.168.0.0/16` goes via `eth1` but `192.168.23.0/24` is more specific 
and has preference and goes via `eth2`. It works:

```
root@v-1-VM:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 48 data bytes
56 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=7.179 ms
^C--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.179/7.179/7.179/0.000 ms
```

This solves a lot of the 'internal resolving' issues we face.

When the public ip address is RFC1918 itself, we do not set the routes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9131.


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9131.
--
Resolution: Fixed

PR merged

> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9137) Domain admins cannot create nor delete a private gateway

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9137:


 Summary: Domain admins cannot create nor delete a private gateway
 Key: CLOUDSTACK-9137
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9137
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical


To create a private gateway you need a root admin account. This does not make 
sense, as you can do a lot more with such a powerful account. Other network 
related API calls can be made by a domain admin.

Let's change it so domain admins can create their own private gateways.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9131:
-
Affects Version/s: 4.7.0

> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9131:
-
Attachment: Screen Shot 2015-12-09 at 11.08.47.png

> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9131:
-
Component/s: UI

> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9131:


 Summary: User/Domain admin cannot login to UI
 Key: CLOUDSTACK-9131
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Remi Bergsma
Priority: Blocker
 Attachments: Screen Shot 2015-12-09 at 11.08.47.png

The Quota plugin checks whether the plugin is enabled but the call it uses it 
only available for root admins. As a result, no one can login except for root 
admins.

Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9111) cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15043824#comment-15043824
 ] 

Remi Bergsma commented on CLOUDSTACK-9111:
--

It is in the admin guide already. 



> cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)
> ---
>
> Key: CLOUDSTACK-9111
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9111
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.1
> Environment: CloudStack 4.6.1 , CentOS7
> http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/
>Reporter: satoru nakaya
>
> Steps to reproduce:
> 1)clean install CloudStack 4.6.1 on CentOS7
>   use http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/
> [root@acs ~]# cat /etc/redhat-release
> CentOS Linux release 7.1.1503 (Core)
> [root@acs ~]#
> [root@acs ~]# rpm -qa | grep cloudstack
> cloudstack-management-4.6.1-shapeblue0.el7.centos.x86_64
> cloudstack-common-4.6.1-shapeblue0.el7.centos.x86_64
> [root@acs ~]#
> 2)cloudstack-setup-databases...(snip)
> 3)cloudstack-setup-management　(Failed)
> [root@acs ~]# cloudstack-setup-management
> Starting to configure CloudStack Management Server:
> Configure Firewall ...[OK]
> Configure CloudStack Management Server ...[Failed]
> Cannot find /etc/cloudstack/management/server-nonssl.xml or 
> /etc/cloudstack/management/tomcat6-nonssl.conf, https enable failed
> Try to restore your system:
> Restore Firewall ...  [OK]
> Restore CloudStack Management Server ...[OK]
> [root@acs ~]#
> 4)check log (/var/log/messages)
> Dec  6 10:08:51 acs server: WARNING: Unable to load server configuration from 
> [/usr/share/cloudstack-management/conf/server.xml]
> 5)check service status (failed)
> [root@acs ~]# systemctl status cloudstack-management.service
> cloudstack-management.service - CloudStack Management Server
>Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 
> enabled)
>Active: failed (Result: exit-code) since Sun 2015-12-06 10:08:52 JST; 11s 
> ago
>   Process: 3061 ExecStop=/usr/libexec/tomcat/server stop (code=exited, 
> status=1/FAILURE)
>   Process: 3026 ExecStart=/usr/libexec/tomcat/server start (code=exited, 
> status=0/SUCCESS)
>  Main PID: 3026 (code=exited, status=0/SUCCESS)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> java.io.FileInputStream.(FileInputStream.java:146)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> org.apache.catalina.startup.Catalina.stopServer(Catalina.java:466)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI...va:43)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> java.lang.reflect.Method.invoke(Method.java:606)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:370)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:457)
> Dec 06 10:08:52 acs.dom.local systemd[1]: cloudstack-management.service: 
> control process exited, code=exited status=1
> Dec 06 10:08:52 acs.dom.local systemd[1]: Unit cloudstack-management.service 
> entered failed state.
> Hint: Some lines were ellipsized, use -l to show in full.
> [root@acs ~]#
> workaround:
> The correct do not know whether or not , but it worked.
> 6)check file
> [root@acs ~]# ls -la /etc/cloudstack/management
> total 132
> drwxr-xr-x. 3 root root   4096 Dec  5 17:59 .
> drwxr-xr-x. 3 root root   4096 Dec  5 17:53 ..
> drwxrwx---. 3 root cloud  4096 Dec  5 17:53 Catalina
> -rw-r--r--. 1 root root   8945 Dec  1 20:22 catalina.policy
> -rw-r--r--. 1 root root   3794 Dec  1 20:22 catalina.properties
> -rw-r--r--. 1 root root   1653 Dec  1 20:22 classpath.conf
> -rw-r--r--. 1 root root   1357 Dec  1 20:22 commons-logging.properties
> -rw-r-. 1 root cloud  3137 Dec  5 17:59 db.properties
> -rw-r--r--. 1 root root979 Dec  1 20:22 environment.properties
> -rw-r--r--. 1 root root927 Dec  1 20:22 java.security.ciphers
> -rw-r--r--. 1 root root  8 Dec  5 17:55 key
> -rw-r--r--. 1 root root   7020 Dec  1 20:22 log4j-cloud.xml
> -rw-r--r--. 1 root root   6722 Dec  1 20:22 server7-nonssl.xml
> -rw-r--r--. 1 root root   7251 Dec  1 20:22 server7-ssl.xml
> -rw-r--r--. 1 root root   1383 Dec  1 20:22 tomcat-users.xml
> -rw-r--r--. 1 root root  50475 Dec  1 20:22 web.xml
> [root@acs ~]
> 7)copy file
> [root@acs ~]# cd 

[jira] [Closed] (CLOUDSTACK-9097) Extra public ip addresses do not work immediately

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9097.


> Extra public ip addresses do not work immediately
> -
>
> Key: CLOUDSTACK-9097
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9097
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> Sometimes public ip addresses do not work immediately, this is in case they 
> are used as a secondary ip on an interface.
> Service on secondary ip which is recently used by other routervm and 
> therefore cached on the gateway:
> root@r-547-VM:~# tcpdump -e -i eth1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:23:27.709762 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 
> 10107, seq 1127, length 64
> 13:23:28.701694 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 
> 10107, seq 1128, length 64
> ^C
> Packets arrive, but with incorrect / cached mac and are ignored by the 
> routervm kernel.
> Run arping to update the arp-cache on the gateway and things start to work:
> root@r-547-VM:~# arping -S x.y.237.226 x.y.237.129
> ARPING x.y.237.129
> 60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=0 time=1.372 msec
> 60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=1 time=893.665 usec
> ^C
> --- x.y.237.129 statistics ---
> 2 packets transmitted, 2 packets received,   0% unanswered (0 extra)
> root@r-547-VM:~# tcpdump -e -i eth1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:23:51.922328 5c:5e:ab:29:bf:ca (oui Unknown) > 06:47:88:00:00:24 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.yy.237.226: ICMP echo request, id 
> 8422, seq 9, length 64
> 13:23:51.922368 06:47:88:00:00:24 (oui Unknown) > 00:00:5e:00:01:a0 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: x.y.237.226 > 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl: ICMP echo reply, id 8422, seq 9, length 64
> Suggested solution: update routervm scripting to run arping when adding a 
> secondary ip.
> Ping [~wilder.rodrigues]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9097) Extra public ip addresses do not work immediately

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9097.
--
Resolution: Fixed

PR merged

> Extra public ip addresses do not work immediately
> -
>
> Key: CLOUDSTACK-9097
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9097
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> Sometimes public ip addresses do not work immediately, this is in case they 
> are used as a secondary ip on an interface.
> Service on secondary ip which is recently used by other routervm and 
> therefore cached on the gateway:
> root@r-547-VM:~# tcpdump -e -i eth1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:23:27.709762 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 
> 10107, seq 1127, length 64
> 13:23:28.701694 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 
> 10107, seq 1128, length 64
> ^C
> Packets arrive, but with incorrect / cached mac and are ignored by the 
> routervm kernel.
> Run arping to update the arp-cache on the gateway and things start to work:
> root@r-547-VM:~# arping -S x.y.237.226 x.y.237.129
> ARPING x.y.237.129
> 60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=0 time=1.372 msec
> 60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=1 time=893.665 usec
> ^C
> --- x.y.237.129 statistics ---
> 2 packets transmitted, 2 packets received,   0% unanswered (0 extra)
> root@r-547-VM:~# tcpdump -e -i eth1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:23:51.922328 5c:5e:ab:29:bf:ca (oui Unknown) > 06:47:88:00:00:24 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.yy.237.226: ICMP echo request, id 
> 8422, seq 9, length 64
> 13:23:51.922368 06:47:88:00:00:24 (oui Unknown) > 00:00:5e:00:01:a0 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: x.y.237.226 > 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl: ICMP echo reply, id 8422, seq 9, length 64
> Suggested solution: update routervm scripting to run arping when adding a 
> secondary ip.
> Ping [~wilder.rodrigues]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-9097) Extra public ip addresses do not work immediately

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma reassigned CLOUDSTACK-9097:


Assignee: Remi Bergsma

> Extra public ip addresses do not work immediately
> -
>
> Key: CLOUDSTACK-9097
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9097
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> Sometimes public ip addresses do not work immediately, this is in case they 
> are used as a secondary ip on an interface.
> Service on secondary ip which is recently used by other routervm and 
> therefore cached on the gateway:
> root@r-547-VM:~# tcpdump -e -i eth1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:23:27.709762 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 
> 10107, seq 1127, length 64
> 13:23:28.701694 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 
> 10107, seq 1128, length 64
> ^C
> Packets arrive, but with incorrect / cached mac and are ignored by the 
> routervm kernel.
> Run arping to update the arp-cache on the gateway and things start to work:
> root@r-547-VM:~# arping -S x.y.237.226 x.y.237.129
> ARPING x.y.237.129
> 60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=0 time=1.372 msec
> 60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=1 time=893.665 usec
> ^C
> --- x.y.237.129 statistics ---
> 2 packets transmitted, 2 packets received,   0% unanswered (0 extra)
> root@r-547-VM:~# tcpdump -e -i eth1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:23:51.922328 5c:5e:ab:29:bf:ca (oui Unknown) > 06:47:88:00:00:24 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.yy.237.226: ICMP echo request, id 
> 8422, seq 9, length 64
> 13:23:51.922368 06:47:88:00:00:24 (oui Unknown) > 00:00:5e:00:01:a0 (oui 
> Unknown), ethertype IPv4 (0x0800), length 98: x.y.237.226 > 
> 52D9557D.cm-11-1b.dynamic.ziggo.nl: ICMP echo reply, id 8422, seq 9, length 64
> Suggested solution: update routervm scripting to run arping when adding a 
> secondary ip.
> Ping [~wilder.rodrigues]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9097) Extra public ip addresses do not work immediately

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9097:


 Summary: Extra public ip addresses do not work immediately
 Key: CLOUDSTACK-9097
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9097
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: SystemVM
Affects Versions: 4.6.0, 4.6.1
Reporter: Remi Bergsma
Priority: Critical


Sometimes public ip addresses do not work immediately, this is in case they are 
used as a secondary ip on an interface.

Service on secondary ip which is recently used by other routervm and therefore 
cached on the gateway:

root@r-547-VM:~# tcpdump -e -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:23:27.709762 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui 
Unknown), ethertype IPv4 (0x0800), length 98: 
52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 10107, 
seq 1127, length 64
13:23:28.701694 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui 
Unknown), ethertype IPv4 (0x0800), length 98: 
52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 10107, 
seq 1128, length 64
^C

Packets arrive, but with incorrect / cached mac and are ignored by the routervm 
kernel.
Run arping to update the arp-cache on the gateway and things start to work:

root@r-547-VM:~# arping -S x.y.237.226 x.y.237.129
ARPING x.y.237.129
60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=0 time=1.372 msec
60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=1 time=893.665 usec
^C
--- x.y.237.129 statistics ---
2 packets transmitted, 2 packets received,   0% unanswered (0 extra)
root@r-547-VM:~# tcpdump -e -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:23:51.922328 5c:5e:ab:29:bf:ca (oui Unknown) > 06:47:88:00:00:24 (oui 
Unknown), ethertype IPv4 (0x0800), length 98: 
52D9557D.cm-11-1b.dynamic.ziggo.nl > x.yy.237.226: ICMP echo request, id 8422, 
seq 9, length 64
13:23:51.922368 06:47:88:00:00:24 (oui Unknown) > 00:00:5e:00:01:a0 (oui 
Unknown), ethertype IPv4 (0x0800), length 98: x.y.237.226 > 
52D9557D.cm-11-1b.dynamic.ziggo.nl: ICMP echo reply, id 8422, seq 9, length 64

Suggested solution: update routervm scripting to run arping when adding a 
secondary ip.

Ping [~wilder.rodrigues]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9078) Scripts inside folder /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ aren't executable.

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022016#comment-15022016
 ] 

Remi Bergsma commented on CLOUDSTACK-9078:
--

Is that in a specific package or for all packages?

> Scripts inside folder 
> /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ 
> aren't executable.
> -
>
> Key: CLOUDSTACK-9078
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9078
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging
>Affects Versions: 4.6.0
>Reporter: Boris Schrijver
>Assignee: Boris Schrijver
> Fix For: 4.7.0, 4.6.1
>
>
> Scripts inside folder 
> /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ 
> aren't executable. Therefore, when cloudstack tries to run one, it will get a 
> permission error and fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9079) ipsec service is not running after restarting virtual router

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9079:
-
Priority: Critical  (was: Major)

> ipsec service is not running after restarting virtual router
> 
>
> Key: CLOUDSTACK-9079
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9079
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router
>Affects Versions: 4.6.0
> Environment: ACS 4.5.1 upgraded to 4.6.0
>Reporter: Erik Weber
>Priority: Critical
>  Labels: systemvm, virtualrouter, vpn
>
> after upgrading to 4.6.0 the ipsec service does no longer automatically start 
> and as an effect vpn does not work.
> manually starting the ipsec service, or doing any vpn related configuration 
> (adding/deleting users) remedies the problem.
> Steps to reproduce:
> 1) Install ACS 4.6.0
> 2) Configure a VPC (I haven't tested with normal isolated networks)
> 3) Enable remote access VPN, configure a user
> 4) Confirm that VPN works
> 5) Restart the VR
> 6) Confirm that VPN does NOT work, either by trying to connect or by issuing 
> 'service ipsec status' on the VR



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9079) ipsec service is not running after restarting virtual router

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022014#comment-15022014
 ] 

Remi Bergsma commented on CLOUDSTACK-9079:
--

Bumped to critical to be able to see it in my filters.

> ipsec service is not running after restarting virtual router
> 
>
> Key: CLOUDSTACK-9079
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9079
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router
>Affects Versions: 4.6.0
> Environment: ACS 4.5.1 upgraded to 4.6.0
>Reporter: Erik Weber
>Priority: Critical
>  Labels: systemvm, virtualrouter, vpn
>
> after upgrading to 4.6.0 the ipsec service does no longer automatically start 
> and as an effect vpn does not work.
> manually starting the ipsec service, or doing any vpn related configuration 
> (adding/deleting users) remedies the problem.
> Steps to reproduce:
> 1) Install ACS 4.6.0
> 2) Configure a VPC (I haven't tested with normal isolated networks)
> 3) Enable remote access VPN, configure a user
> 4) Confirm that VPN works
> 5) Restart the VR
> 6) Confirm that VPN does NOT work, either by trying to connect or by issuing 
> 'service ipsec status' on the VR



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9015.


> Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
> --
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9015.
--
Resolution: Fixed

PR 1064 is merged

> Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
> --
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9077) injectkeys.sh doesn't work on CentOS7

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021072#comment-15021072
 ] 

Remi Bergsma commented on CLOUDSTACK-9077:
--

[~pdion] Can we use one of the methods described here [1] to detect if we're in 
a container instead of the current check?

[1] 
http://stackoverflow.com/questions/20010199/determining-if-a-process-runs-inside-lxc-docker

> injectkeys.sh doesn't work on CentOS7
> -
>
> Key: CLOUDSTACK-9077
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9077
> 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: Remi Bergsma
>Priority: Critical
>
> Regression from: 
> https://github.com/apache/cloudstack/commit/3381154fafb7fa4f0a61d538f7c2550e48247787
> CentOS7 doesn't have /dev/loop0 so it fails. Removing the check makes it work 
> again.
> ```
> 2015-11-20 21:51:16,145 DEBUG [c.c.s.ConfigurationServerImpl] 
> (localhost-startStop-1:null) Executing: /bin/bash 
> /var/lib/tomcat/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh
>  /usr/share/tomc
> at5/.ssh/id_rsa.pub /usr/share/tomcat5/.ssh/id_rsa 
> /var/lib/tomcat/webapps/client/WEB-INF/classes/vms/systemvm.iso
> 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] 
> (localhost-startStop-1:null) Execution is successful.
> 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] 
> (localhost-startStop-1:null) No loop device found, skipping ssh key insertion 
> in systemvm.iso
> 2015-11-20 21:51:16,162 INFO  [c.c.s.ConfigurationServerImpl] 
> (localhost-startStop-1:null) Injected public and private keys into systemvm 
> iso with result : null
> ```
> Pinging [~pdion]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9077) injectkeys.sh doesn't work on CentOS7

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9077:


 Summary: injectkeys.sh doesn't work on CentOS7
 Key: CLOUDSTACK-9077
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9077
 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: Remi Bergsma
Priority: Critical


Regression from: 
https://github.com/apache/cloudstack/commit/3381154fafb7fa4f0a61d538f7c2550e48247787

CentOS7 doesn't have /dev/loop0 so it fails. Removing the check makes it work 
again.

```
2015-11-20 21:51:16,145 DEBUG [c.c.s.ConfigurationServerImpl] 
(localhost-startStop-1:null) Executing: /bin/bash 
/var/lib/tomcat/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh
 /usr/share/tomc
at5/.ssh/id_rsa.pub /usr/share/tomcat5/.ssh/id_rsa 
/var/lib/tomcat/webapps/client/WEB-INF/classes/vms/systemvm.iso
2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] 
(localhost-startStop-1:null) Execution is successful.
2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] 
(localhost-startStop-1:null) No loop device found, skipping ssh key insertion 
in systemvm.iso

2015-11-20 21:51:16,162 INFO  [c.c.s.ConfigurationServerImpl] 
(localhost-startStop-1:null) Injected public and private keys into systemvm iso 
with result : null
```

Pinging [~pdion]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6967) OVM3 support

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006282#comment-15006282
 ] 

Remi Bergsma commented on CLOUDSTACK-6967:
--

Yes, ovm3 support is in 4.6. 

Sent from my iPhone



> OVM3 support
> 
>
> Key: CLOUDSTACK-6967
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6967
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.0
>Reporter: Funs Kessen
>
> We need ovm3 support in cloudstack!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9059) Snapshot on S3 fails when delta is zero

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9059:


 Summary: Snapshot on S3 fails when delta is zero
 Key: CLOUDSTACK-9059
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9059
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Snapshot
Affects Versions: 4.6.0
 Environment: XenServer and S3
Reporter: Remi Bergsma
Priority: Critical


- Create a vm
- make snapshot
Verify it works and makes it to S3. This should work.
- make another snapshot
It fails: Failed to create snapshot due to an internal error creating snapshot 
for volume 220

Logs from management:
2015-11-12 16:26:15,103 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Add job-1669 into job monitoring
2015-11-12 16:26:15,107 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Executing AsyncJobVO {id:1669, 
userId: 4, accountId: 2, instanceType: Snapshot, instanceId: 12, cmd: org.apa
che.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: 
{"quiescevm":"false","httpmethod":"GET","ctxAccountId":"2","uuid":"2a2b67ce-e6a5-4dd3-85f5-823f14d9fbbe","cmdEventType":"SNAPSHOT.CREATE","respons
e":"json","ctxUserId":"4","volumeId":"0137c81d-aedb-469a-bcbb-cf7df2985c82","name":"nog
 een","ctxStartEventId":"2906","id":"12","ctxDetails":"{\"interface 
com.cloud.storage.Snapshot\":\"2a2b67ce-e6a5-4dd3-85f5-823f1
4d9fbbe\",\"interface 
com.cloud.storage.Volume\":\"0137c81d-aedb-469a-bcbb-cf7df2985c82\"}","_":"1447341974884"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 28867301
26, completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2015-11-12 16:26:15,109 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-26:ctx-f0fd7270 ctx-2f203261) ===END===  10.200.22.3 -- GET 
 
command=createSnapshot=json=0137c81d-aedb-469a-bcbb-cf7df2985c82
iescevm=false=nog+een&_=1447341974884
2015-11-12 16:26:15,181 INFO  [o.a.c.a.c.u.s.CreateSnapshotCmd] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669 ctx-2f94ce7b) VOLSS: 
createSnapshotCmd starts:1447341975181
2015-11-12 16:26:15,231 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669 ctx-2f94ce7b) Sync job-1670 execution 
on object VmWorkJobQueue.220
2015-11-12 16:26:18,143 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-17:ctx-0304676c) ===START===  10.200.22.3 -- GET  
command=queryAsyncJobResult=5a6748af-cb5f-41b6-82c6-a17971c63d09=json&_=144734197
8124
2015-11-12 16:26:18,178 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-17:ctx-0304676c ctx-321af332) ===END===  10.200.22.3 -- GET 
 
command=queryAsyncJobResult=5a6748af-cb5f-41b6-82c6-a17971c63d09=json&
_=1447341978124
2015-11-12 16:26:19,497 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-4:ctx-4fd0fb68) AutoScaling Monitor is running...
2015-11-12 16:26:21,180 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-14:ctx-7690a426) ===START===  10.200.22.3 -- GET  
command=queryAsyncJobResult=5a6748af-cb5f-41b6-82c6-a17971c63d09=json&_=144734198
1124
2015-11-12 16:26:21,216 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-14:ctx-7690a426 ctx-61c72bab) ===END===  10.200.22.3 -- GET 
 
command=queryAsyncJobResult=5a6748af-cb5f-41b6-82c6-a17971c63d09=json&
_=1447341981124
2015-11-12 16:26:21,316 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Complete async job-1669, jobStatus: 
FAILED, resultCode: 530, result: org.apache.cloudstack.api.response.Exce
ptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed to create 
snapshot due to an internal error creating snapshot for volume 220"}
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Publish async job-1669 complete on 
message bus
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Wake up jobs related to job-1669
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Update db status for job-1669
2015-11-12 16:26:21,321 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Wake up jobs joined with job-1669 
and disjoin all subjobs created from job- 1669
2015-11-12 16:26:21,326 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Done executing 
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-1669
2015-11-12 16:26:21,326 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Remove job-1669 from job monitoring

2015-11-12 16:26:18,280 ERROR [c.c.v.VmWorkJobDispatcher] 
(Work-Job-Executor-3:ctx-fbda09ad job-1669/job-1670) Unable to complete 
AsyncJobVO {id:1670, userId: 4, accountId: 2, instanceType: null, instanceId: 
null, c
md: 

[jira] [Commented] (CLOUDSTACK-9060) Create volume / template from S3 snapshot fails

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15002279#comment-15002279
 ] 

Remi Bergsma commented on CLOUDSTACK-9060:
--

Ping [~pdion] is this the same issue as you reported on Swift?

[~borisroman] is currently debugging it.

> Create volume / template from S3 snapshot fails
> ---
>
> Key: CLOUDSTACK-9060
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9060
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.6.0
> Environment: KVM / XenServer and S3 compatible sec storage
>Reporter: Remi Bergsma
>Priority: Critical
>
> Create a vm
> Create a snapshot
> This works fine. Now create a template from this snapshot:
> Error: Failed to create templatejava.lang.NullPointerException
> java.lang.NullPointerException
> at 
> org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.createTemplateFromSnapshot(AncientDataMotionStrategy.java:490)
> at 
> org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:441)
> at 
> org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:68)
> at 
> org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:73)
> at 
> org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:657)
> at 
> org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:663)
> at 
> com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1484)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy187.createPrivateTemplate(Unknown Source)
> at 
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin.execute(CreateTemplateCmdByAdmin.java:43)
> 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:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> 

[jira] [Created] (CLOUDSTACK-9060) Create volume / template from S3 snapshot fails

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9060:


 Summary: Create volume / template from S3 snapshot fails
 Key: CLOUDSTACK-9060
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9060
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Snapshot
Affects Versions: 4.6.0
 Environment: KVM / XenServer and S3 compatible sec storage
Reporter: Remi Bergsma
Priority: Critical


Create a vm
Create a snapshot
This works fine. Now create a template from this snapshot:

Error: Failed to create templatejava.lang.NullPointerException

java.lang.NullPointerException
at 
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.createTemplateFromSnapshot(AncientDataMotionStrategy.java:490)
at 
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:441)
at 
org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:68)
at 
org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:73)
at 
org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:657)
at 
org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:663)
at 
com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1484)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy187.createPrivateTemplate(Unknown Source)
at 
org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin.execute(CreateTemplateCmdByAdmin.java:43)
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:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
2015-11-12 15:16:45,413 DEBUG [c.c.t.TemplateManagerImpl] 
(API-Job-Executor-2:ctx-e0bc8a04 job-1665 ctx-ce0e40f4) Failed to create 
templatejava.lang.NullPointerException
2015-11-12 15:16:45,449 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-2:ctx-e0bc8a04 job-1665) Unexpected exception while executing 

[jira] [Updated] (CLOUDSTACK-9059) Snapshot on S3 fails when delta is zero

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9059:
-
Description: 
- Create a vm
- make snapshot
Verify it works and makes it to S3. This should work.
- make another snapshot
It fails: Failed to create snapshot due to an internal error creating snapshot 
for volume 220

Logs from management:
2015-11-12 16:26:15,103 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Add job-1669 into job monitoring
2015-11-12 16:26:15,107 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Executing AsyncJobVO {id:1669, 
userId: 4, accountId: 2, instanceType: Snapshot, instanceId: 12, cmd: org.apa
che.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo: 
{"quiescevm":"false","httpmethod":"GET","ctxAccountId":"2","uuid":"2a2b67ce-e6a5-4dd3-85f5-823f14d9fbbe","cmdEventType":"SNAPSHOT.CREATE","respons
e":"json","ctxUserId":"4","volumeId":"0137c81d-aedb-469a-bcbb-cf7df2985c82","name":"nog
 een","ctxStartEventId":"2906","id":"12","ctxDetails":"{\"interface 
com.cloud.storage.Snapshot\":\"2a2b67ce-e6a5-4dd3-85f5-823f1
4d9fbbe\",\"interface 
com.cloud.storage.Volume\":\"0137c81d-aedb-469a-bcbb-cf7df2985c82\"}","_":"1447341974884"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 28867301
26, completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2015-11-12 16:26:15,109 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-26:ctx-f0fd7270 ctx-2f203261) ===END===  10.200.22.3 -- GET 
 
command=createSnapshot=json=0137c81d-aedb-469a-bcbb-cf7df2985c82
iescevm=false=nog+een&_=1447341974884
2015-11-12 16:26:15,181 INFO  [o.a.c.a.c.u.s.CreateSnapshotCmd] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669 ctx-2f94ce7b) VOLSS: 
createSnapshotCmd starts:1447341975181
2015-11-12 16:26:15,231 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669 ctx-2f94ce7b) Sync job-1670 execution 
on object VmWorkJobQueue.220
2015-11-12 16:26:18,143 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-17:ctx-0304676c) ===START===  10.200.22.3 -- GET  
command=queryAsyncJobResult=5a6748af-cb5f-41b6-82c6-a17971c63d09=json&_=144734197
8124
2015-11-12 16:26:18,178 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-17:ctx-0304676c ctx-321af332) ===END===  10.200.22.3 -- GET 
 
command=queryAsyncJobResult=5a6748af-cb5f-41b6-82c6-a17971c63d09=json&
_=1447341978124
2015-11-12 16:26:19,497 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-4:ctx-4fd0fb68) AutoScaling Monitor is running...
2015-11-12 16:26:21,180 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-14:ctx-7690a426) ===START===  10.200.22.3 -- GET  
command=queryAsyncJobResult=5a6748af-cb5f-41b6-82c6-a17971c63d09=json&_=144734198
1124
2015-11-12 16:26:21,216 DEBUG [c.c.a.ApiServlet] 
(http-bio-8080-exec-14:ctx-7690a426 ctx-61c72bab) ===END===  10.200.22.3 -- GET 
 
command=queryAsyncJobResult=5a6748af-cb5f-41b6-82c6-a17971c63d09=json&
_=1447341981124
2015-11-12 16:26:21,316 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Complete async job-1669, jobStatus: 
FAILED, resultCode: 530, result: org.apache.cloudstack.api.response.Exce
ptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed to create 
snapshot due to an internal error creating snapshot for volume 220"}
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Publish async job-1669 complete on 
message bus
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Wake up jobs related to job-1669
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Update db status for job-1669
2015-11-12 16:26:21,321 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Wake up jobs joined with job-1669 
and disjoin all subjobs created from job- 1669
2015-11-12 16:26:21,326 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Done executing 
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-1669
2015-11-12 16:26:21,326 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Remove job-1669 from job monitoring

2015-11-12 16:26:18,280 ERROR [c.c.v.VmWorkJobDispatcher] 
(Work-Job-Executor-3:ctx-fbda09ad job-1669/job-1670) Unable to complete 
AsyncJobVO {id:1670, userId: 4, accountId: 2, instanceType: null, instanceId: 
null, c
md: com.cloud.vm.VmWorkTakeVolumeSnapshot, cmdInfo: 
rO0ABXNyACVjb20uY2xvdWQudm0uVm1Xb3JrVGFrZVZvbHVtZVNuYXBzaG90BL5gG4Li1c8CAARaAAlxdWllc2NlVm1MAAhwb2xpY3lJZHQAEExqYXZhL2xhbmcvTG9uZztMAApzbmFwc2hvdElkcQB-AAFMAAh2b2x

[jira] [Updated] (CLOUDSTACK-9049) Fix deployment in CentOS 7 with Tomcat 7

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-9049:
-
Priority: Critical  (was: Major)

> Fix deployment in CentOS 7 with Tomcat 7
> 
>
> Key: CLOUDSTACK-9049
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9049
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: David Amorim Faria
>Assignee: David Amorim Faria
>Priority: Critical
>
> The centos 7 packaging is using custom config files instead of the files 
> sourced from the webapp. Also, the library used by 
> cloudstack-setup-management expects to find tomcat6 files in the config 
> directory, and they are not valid for tomcat7 which comes as default in 
> centos7.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)