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 15:22:00 UTC
[jira] [Updated] (CLOUDSTACK-10204) VR DNSmasq lease file not
persistent across DHCP actions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag Sonstebo updated CLOUDSTACK-10204:
--------------------------------------
Description:
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 persistent across DHCP additions.
was:
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.
> 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 persistent across DHCP additions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)