Comment # 11 on bug 1015588 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.