http://bugzilla.suse.com/show_bug.cgi?id=1015588 http://bugzilla.suse.com/show_bug.cgi?id=1015588#c11 --- Comment #11 from Martin Wilck --- Mail sent to libvirt-devel on Jan 5th: Here is a summary of how dnsmasq behaves: A) without "dhcp-authoritative", it only responds to DHCPREQUEST messages after a preceding DHCPDISCOVER/DHCPOFFER, or if a non-expired lease for the requesting MAC address is found. This holds also for clients with static host entries. B) with "dhcp-authoritative", dnsmasq always replies to DHCPREQUEST messages. It will send DHCPNAK if the lease is currently taken by a different MAC address (either via a static entry or via a non-expired lease), and DHCPACK otherwise. Independent of dhcp-authoritative, dnsmasq responds to DHCPDISCOVER if and only if it has addresses to hand out, thus either the MAC address of the client matches a static entry or there are free addresses in the dynamic pool. I can see no difference between a "static" configuration and a configuration with zero-length or exhausted dynamic pool. In case A), every attempt to re-obtain a previous IP address is delayed because the client needs to wait for several DHCPREQUEST messages to time out before it sends a new DHCPDISCOVER. In case B) it will receive either ACK or NAK immediately. This seems to be an advantage of "dhcp- authoritative". So the answer to 1)/2) above is "positive response only in the defined dynamic dhcp range". If there's no dynamic range, no positive responses will be sent to unkown clients. *But* in authoritative mode it will send DHCPNAKs, which may confuse clients. If there's another DHCP server on the virtual network, properly configured (no overlap between dynamic ranges), and the client sends a DHCPREQUEST, it may get an DHCPNAK from the libvirt dnsmasq and DHCPACK from the other DHCP server. What then happens is probably dependent on timing (which response is received first). RFC2131 is not clear about this scenario, AFAICS. Sooo, if customers run DHCP servers in VMs concurrently with the libvirt DHCP server, problems may arise with "dhcp-authoritative". My "don't use dhcp-authoritative on static networks" patch fixes this for cases where the libvirt network is "static", but problems may remain for cases with non-overlapping dynamic DHCP ranges. It's not an easy question whether or not this outweighs the benefits of using "dhcp- authoritative". Of course I'd hate to have my previous patch introducing "dhcp-authoritative" reverted :-) Maybe we need yet another config option for the network XML. I'm unsure whether this should be an attribute of the "<network>, <ip>, or <dhcp> element, or something else. There is a relationship to the "localOnly" attribute of "<domain>", but I think the two should still be independent settings. Anyway, I'll wait what you're saying. -- You are receiving this mail because: You are on the CC list for the bug.