[
https://issues.apache.org/jira/browse/CLOUDSTACK-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wilder Rodrigues resolved CLOUDSTACK-4605.
------------------------------------------
Resolution: Fixed
After configuration save the ipdated in files
/etc/iptables/router_rules.v4 and /etc/iptables/router_rules.v6
Reload the configuration on reboot via the /etc/rc.local using iptables-restore
All the information about the router VMs is now persisted due to the work on
the rVPC/Persistent SystemVM done in the few months ago. The missing bit was
the iptables configuration, which was not surviving a crash or reboot not done
via the management server.
Manual tests
Create single VPC, 3 Tiers, 3 VMs, 3 pub IPs
Connect to router and reboot it
Wait for the router to come back and check IPtables/connect to VMs
Create redundant VPC, 3 Tiers, 3 VMs, 3 pub IPs
Connect to router and reboot it
Wait for the router to come back and check IPtables/connect to VMs
Create isolated network, 1 VM, 1 pub IP
Connect to router and reboot it
Wait for the router to come back and check IPtables/connect to VM
Tests executed against XenServer 6.2 compliant host
> VPC router loses config after reboot
> ------------------------------------
>
> Key: CLOUDSTACK-4605
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4605
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
> Affects Versions: 4.1.1
> Reporter: Roeland Kuipers
> Assignee: Wilder Rodrigues
>
> When rebooting a VPC router outside of cloudstack it will come up without
> proper configuration.
> All interfaces are unconfigured except for eth0.
> All other systemvm's are completely configured by kernel parameters and these
> parameters are also cached in /var/cache/cloud/cmdline. So configurations are
> persistent across reboots.
> VPC routers are configured only when rebooting them by cloudstack.
> We like to see the same method as for normal routers for the following reason:
> We have experienced a serious outage on redundant routing vm pair due to the
> OOM killer. Somehow the master node ran OoM and the OOM killer decided to
> kill random processes causing HAproxy to go down. But since keepalived was
> still running and functioning, a failover never happened.
> In our experience we rather panic on OOM instead of praying that the
> OOM-killer will do the right thing while it in 99% percent of the cases it
> just renders a machine useless.
> If this RvR would have panicked and rebooted we would have had a nice
> keepalived failure/failover without much impact on our customer.
> See also CLOUDSTACK-4607 and CLOUDSTACK-4606
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
