[
https://issues.apache.org/jira/browse/CLOUDSTACK-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886170#comment-13886170
]
ASF subversion and git services commented on CLOUDSTACK-5986:
-------------------------------------------------------------
Commit 30419cac26993d279e589674faa084c15f2694ee in branch refs/heads/4.2 from
[~yasker]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=30419ca ]
CLOUDSTACK-5986: Make dnsmasq handle dnsmasq.leases when dhcp_release is
available
The original issue has been exposed due to CloudStack VR would modify the
dnsmasq.leases, thus make it unsync with dnsmasq's memory lease.
Make the modification to let dnsmasq handle the lease file if dhcp_release is
available.
> dnsmasq racy condition result in dnsmasq failed to handout IP address
> ---------------------------------------------------------------------
>
> Key: CLOUDSTACK-5986
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5986
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
> Affects Versions: 4.2.0, 4.2.1
> Reporter: Sheng Yang
> Assignee: Sheng Yang
> Priority: Critical
> Fix For: 4.2.1, 4.3.0
>
>
> In the past, dnsmasq.leases is managed by cloudstack, and would be updated
> after new entry is added(and the entry with same IP or host would be removed).
> In 4.2, we introduced dhcp_release try to speed up the dnsmasq reload
> process, thus result in this issue.
> So in this scenario:
> 1. VM1 would create entry: "mac A, IP A, host A"
> 2. VM2 would create entry: "mac B, IP B, host B"
> 3. VM1 destroyed and VM 2 destroyed, no change to lease file, two records
> still existed.
> 4. VM1 created with IP B: "mac C, IP B, host A".
> At this time, lease file would only contain: "mac C, IP B, host A", because
> the original entries would be removed by either IP match or host name match.
> In fact dnsmasq still holds lease of IP A with mac A in memory, but record is
> already removed from lease file by cloudstack. The lease file is out of sync
> now.
> 5. VM2 recreated with IP A, dhcp_release would be used to release the lease.
> But there is no "mac A, IP A" record in the lease file, so dhcp_release
> failed.
> So result in dnsmasq cannot handle out the IP A to new mac D, because dnsmasq
> was still holding lease for IP A with mac A and haven't been released yet.
> So it only happened when user create and destroy different VMs which share
> the same name but get different IPs.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
