Open Stack

Hello,

(cross-posting from openstack at lists.openstack.org)

I am reaching out in the hopes that someone may have seen this issue before
or have some ideas on what might be going wrong. Apologies if this has
already been discussed elsewhere, I did search quite a bit but only found
mention of a similar issue here
https://ask.openstack.org/en/question/66105/dnsmasq-dhcp-server-doesnt-lease-a-released-ip-address/
which does not have any answers for it yet.

The problem I am seeing is that when nova-network calls dhcp_release upon
instance termination (due to force_dhcp_release=True) the address is not
always released. Sometimes I do see in nova-dhcpbridge.log that there is an
'old' followed by 'del' command from dnsmasq, but it will sometimes only
have the 'old'. Then later on if nova assigned a new instance the same ip
address that was *not* released the DHCP request is ignored and an error in
the syslog will show that dnsmasq saw the request and refused because the
ip address was already leased to a different MAC address (the one belonging
to the old, terminated, VM).

Some details about my setup:
* Kilo release
* Ubuntu 14.04
* Followed the install guide
http://docs.openstack.org/kilo/install-guide/install/apt/content/ and did
the legacy (nova-) network setup initially, but have since modified it a
little to allow for my hosts with only a single management/external network
connection.

When hosts are able to get their ip address from the DHCP server everything
appears to be working perfectly fine. It seems as though the error is only
when an ip fails to be released and blocks subsequent use of it for future
VM's.

I checked for any errors in my nova-* logs and don't see any. The only
errors are in my syslog when dnsmasq refuses to lease the ip address due to
the conflicting MAC addresses.

Any info or suggestions would be much appreciated.

Thanks!


Patrick East
patrick.east at purestorage.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150610/70449f49/attachment.html>