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)