Hi, for isolated networks this shouldn't be a problem. A recreated
virtual router will keep the same IP on the guest network (10.1.1.1 by
default). For shared networks or for the network in a basic zone, I
guess this might be a problem.
dhclient and other DHCP clients will automatically try to renew their
DHCP based on the lease time. However, CloudStack assigns clients
infinite lease times. This causes dhclient to use a lease of 4294967295
seconds, and not try to renew the lease until about half that time, as
seen in the log:
Jul 16 18:37:58 web11 dhclient[5276]: bound to 10.1.1.152 -- renewal in
2147483646 seconds.
Luckily, dhclient is very configurable. You can force it to use a lease
or renewal time of your choice. For example:
[root@web11 ~]# cat /etc/dhcp/dhclient.conf
interface "eth0" {
supersede dhcp-renewal-time = encode-int(600, 32);
}
Result:
Jul 16 18:39:45 web11 dhclient[5914]: bound to 10.1.1.152 -- renewal in
544 seconds.
Best regards,
Kirk
On 07/16/2013 12:54 PM, Nick Wales wrote:
> Does anyone have advice for how to deal with linux hosts when the virtual
> router gets destroyed and comes back on a different IP address?
>
> I'm no dhclient expert, having run everything in a traditional datacenter
> up until now with static IP's so looking for some useful advice / best
> practise ideas here!
>
> My experience so far is that guests no longer know their fully qualified
> hostname which can cause problems with agent software that has to check in
> with an SSL cert like puppet or a known name like teamcity.
>
> In theory something that caused dhclient to re-check for newly active dhcp
> servers on a regular basis would do the job for me.
>
> Nick
>
