[
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)
