You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Sheng Yang (JIRA)" <ji...@apache.org> on 2014/01/30 01:04:09 UTC

[jira] [Created] (CLOUDSTACK-5986) dnsmasq racy condition result in dnsmasq failed to handout IP address

Sheng Yang created CLOUDSTACK-5986:
--------------------------------------

             Summary: 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)