dhcp_release doesn't support IPv6, though it won't return failure(that's a bug
that has been fixed in recent release). So if it's IPv6, we would still use the
old way(restart dnsmasq) to refresh the lease.
This reverts commit f37567ef45fe6e41469a176d387e91840bfae23c.
This deletes the duplicate entry when new vm came with deleted vm ip.
So will not fix the bug CLOUDSTACK 3424 fully. So this changes will be committed into new bug
for number of commands participating in Vm deployment process, as parallel deployment is supported on the hypervisor side.
The behavior is controlled by global config varirables:
"execute.in.sequence.hypervisor.commands" (false by default) sets/resets the synchronization for commands:
=========================
StartCommand
StopCommand
CreateCommand
CopyVolumeCommand
"execute.in.sequence.network.element.commands" (false by default) sets/resets the synchronization for commands:
==========================
DhcpEntryCommand
SavePasswordCommand
UserDataCommand
VmDataCommand
As a part of the fix, increased the global lock timeout to 30 mins in several VR scripts:
===========================
edithosts.sh
savepassword.sh
userdata.sh
to support situations when multiple concurrent calls to the script are being made.
This signal will force the dnsmasq daemon to reload the configuration directly. This is much faster than restarting the daemon, which result in a much smaller window during which no dns server is available.
Tested by using the replaced version of edithosts.sh on a running vrouter causing dns problems.
The already deleted same hostname is not deleted from /etc/hosts of
vRouter.
vRouter's /etc/hosts format:
$ip $host
This patch fixes deletion logic below.
sed -i /"$host "/d $HOSTS
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Signed-off-by: Chip Childers <chip.childers@gmail.com>
I've assumed that Gavin's commit is appropriate, based
on an assumption that we will keep these files in the source
tree. If https://issues.apache.org/jira/browse/LEGAL-146
results in a different opionion from the members, then we
will end up having to do something more drastic anyway.
The routing table with two nics may be messed up, due to we sent same
router(gateway) information from different DHCP server, in order to specify
default gateway. E.g.
Network A: 192.168.1.0/24, gw 192.168.1.1
Network B: 192.168.2.0/24, gw 192.168.2.1
User VM: Nic 1 connect to network A, get ip 192.168.1.10; nic 2 connect to
network B, get ip 192.168.2.10.
Set network A as the default network of user VM.
Currently we would send this information to user VM through DHCP offer:
In network A: dhcp-option:router 192.168.1.1
In network B: dhcp-option:router 192.168.1.1
So both NIC in the guest VM would receive 192.168.1.1 as router(gateway).
But, in CentOS 5.6, dhclient-scripts try to tell if the gateway is reachable
for current subnet.
So when we try to enable nic 2(eth1) of user VM, dhclient would receive:
IP: 192.168.2.10
Mask: 255.255.255.0
Router: 192.168.1.1
Then it would found that the specified gateway(router) is not within its own
subnet(192.168.2.0/24). But since we send out this ip(192.168.1.1) as the
gateway for it, dhclient thought that it should got someway to access the
network through this IP. So it would execute:
ip route add 192.168.1.1 dev eth1
ip route replace default via 192.168.1.1 dev eth1
But it can never reach 192.168.1.1(which is in the eth0's subnet and the
gateway of eth0) by go through eth1 interface. So it is messed up.
We've tested Windows 2008 R2, CentOS 5.3, CentOS 5.6 and Ubuntu 10.04. Windows
and Ubuntu are fine with above policy.
To solve this, we send different dhcp:router option according to the guest OS
type now.
We may need expand this list later, but for now we only know that CentOS and
RHEL would behavior in this way.
status 14042: resolved fixed
This message may show during redundant router start up:
FAULT (Restarting DNS forwarder and DHCP server: dnsmasq failed!)
This caused by edithost.sh is racy with keepalived process. They both want to
restart dnsmasq.
Even in normal condition, it's very hard to reproduce this bug. Add file lock
for edithost.sh should solve it.
