cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alena Prokharchyk (JIRA)" <>
Subject [jira] [Resolved] (CLOUDSTACK-4605) VPC router loses config after reboot
Date Thu, 12 Sep 2013 00:44:53 GMT


Alena Prokharchyk resolved CLOUDSTACK-4605.

    Resolution: Won't Fix

Its by design. CS does lots of things (besides configuring ips)on router reboot when called
from CS - for example, configuring userdata/metadata. If reboot is called outside of the CS,
all this information will be missed as the only one way to determine of what needs to be configured
- by extracting this info from the CS DB and applying as a part of reboot process.

If router Vm gets shutdown from the inside by some reason, you should leave it for CloudStack
HA to handle. The HA process will stop the router and restart it with applying all the configs
> VPC router loses config after reboot
> ------------------------------------
>                 Key: CLOUDSTACK-4605
>                 URL:
>             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
> 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
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message