You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Dag Sonstebo (JIRA)" <ji...@apache.org> on 2017/12/22 13:12:00 UTC
[jira] [Created] (CLOUDSTACK-10204) VR DNSmasq lease file not
persistent across DHCP actions
Dag Sonstebo created CLOUDSTACK-10204:
-----------------------------------------
Summary: VR DNSmasq lease file not persistent across DHCP actions
Key: CLOUDSTACK-10204
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10204
Project: CloudStack
Issue Type: Improvement
Security Level: Public (Anyone can view this level - this is the default.)
Components: Virtual Router
Affects Versions: 4.10.0.0, 4.9.2.0, 4.9.1.0, 4.11.0.0, 4.9.3.0
Environment: - CloudStack 4.9.x / 4.10.x / 4.11
- Any hypervisor
- Tested with both 4.6, 4.10 and 4.11 system VM templates
Reporter: Dag Sonstebo
Priority: Minor
Steps to reproduce:
* Add 1 VMs on new isolated or shared network.
* Make a note of DHCP config file and leases file:
{code}
root@r-161-VM:~# cat /etc/dhcphosts.txt
02:00:1a:26:00:01,10.1.1.99,VM1,743h
root@r-161-VM:~# cat /var/lib/misc/dnsmasq.leases
1516621995 02:00:1a:26:00:01 10.1.1.99 VM1 01:02:00:1a:26:00:01
root@r-161-VM:~#
{code}
* Add another VM and check the files again:
{code}
root@r-161-VM:~# cat /etc/dhcphosts.txt
02:00:1a:26:00:01,10.1.1.99,VM1,726h
02:00:2c:f3:00:03,10.1.1.164,VM2,737h
root@r-161-VM:~# cat /var/lib/misc/dnsmasq.leases
1516600548 02:00:2c:f3:00:03 10.1.1.164 VM2 01:02:00:2c:f3:00:03
root@r-161-VM:~#
{code}
Result:
* /var/lib/misc/dnsmasq.leases is overwritten every time a new DHCP entry is added.
* This causes the guest VM dhcp client to get an "NAK" DHCP deny on DHCP renewal, and have to go through the normal procedure again of DISCOVER>OFFER>REQUEST>ACK.
* For some guest OS versions (RedHat has shown this) where static routes are used the initial "NAK" will break these static routes, leading to problems in the guest OS.
Analysis:
* The deletion of the leases file is a conscious decision done in /opt/cloud/bin/cs/CsDhcp.py, where on line 52+53 the delete_leases procedure is called:
{code}
52 if self.cloud.is_changed():
53 self.delete_leases()
{code}
with the procedure being:
{code}
107 def delete_leases(self):
108 try:
109 open(LEASES, 'w').close()
110 except IOError:
111 return
{code}
* Since this is a conscious coding decision the rationale behind this needs investigated and an improved procedure considered where the leases file is kept consistent across DHCP additions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)