[
https://issues.apache.org/jira/browse/CLOUDSTACK-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886044#comment-13886044
]
Sheng Yang commented on CLOUDSTACK-5986:
----------------------------------------
To reproduce the issue(or verify the fix), you can:
1. Create a set of vms (e.g. 10), use API to assign each one of them a
pre-determined IP(e.g. 10.1.1.10-10.1.1.19).
2. Destroy them
3. Create another set of VM, use the same IP address range but different IP for
each of them
For example.
VM1 used name: VM1, 10.1.1.10
VM2 used name: VM2, 10.1.1.11
VM3 used name: VM3, 10.1.1.12
VM4 used name: VM4, 10.1.1.13
VM5 used name: VM5, 10.1.1.14
Then the new one can be:
VM1 used name: VM1, 10.1.1.14
VM2 used name: VM2, 10.1.1.13
VM3 used name: VM3, 10.1.1.12
VM4 used name: VM4, 10.1.1.11
VM5 used name: VM5, 10.1.1.10
Then you would find some of VMs cannot get the IP.
> 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)
