[libvirt] [PATCH] network: Add support for configuring dhcp lease time

[Laine Stump]

On 09/23/2016 02:43 PM, Martin Wilck wrote:
> On Fri, 2016-09-23 at 11:56 -0400, Laine Stump wrote:
>
>> Martin's patch tries to solve the problem with "dhcp-authoritative"
>> which, as far as I understand, tells dnsmasq "you are the keeper of
>> *all* lease information on this network, so if you think the address
>> is
>> unused, it really is unused"; dnsmasq uses this information to
>> freely
>> grant a guest any address it asks for, as long as there is no
>> current
>> lease for it. This sounds troublesome to me - If client A's lease
>> has
>> expired (because it's turned off for a bit), is it okay for client B
>> to
>> come barging in and insist on grabbing the address that client A has
>> just lost even though there are many other addresses still
>> available?
>> Sure, technically it's legal, but it seems unnecessarily disruptive.
> I am not sure what you mean. What scenario would be "disrupted" by this
> approach?

Disruptive may not have been the best word. What I mean is that an 
unfriendly guest with proper information could take advantage of this 
"give any currently-unused address to anyone who asks for it" policy by 
purposefully taking over an IP address that it knew had previously been 
leased to a different guest (and who was expecting on getting the 
address back the next time it booted). Of course 1) it would take a lot 
of inside knowledge / good timing / luck to make this happen, and 2) you 
can argue that any guest who relied on a dhcp address remaining 
unchanged deserves what it gets (and the same for any other machine 
trying to contact that guest via the IP address).

>
> Without dhcp_authoritative, client A will not get its lease back,

Is that true even if dnsmasq isn't restarted, and even if leasefile-ro 
isn't used? The Openstack discussion on this topic implies that the 
behavior only exists because they aren't saving a leasefile, not just 
because the lease is expired.

> whether or not B applied for it in the meantime, and B wouldn't get the
> lease, either. The user wouldn't be able to ping either one. If
> dhcp_authoritative is used, at least one of them will get what it needs
> (and serving both is impossible - it's hard to tell what's the Right
> Thing in the situation you describe!).

Well, I guess it's a policy decision, but I would tend toward *not* 
allowing B to demand a particular IP address that it has never before 
been given.

>
> Anyway, unless the virtual network is really crowded (in which case it
> might make sense for the admin to use a class B network instead) the
> probability of such clashes should be rather minimal in the real world.
> It's much more likely that A itself tries to reacquire the lease, and
> that situation is fixed by dhcp_authoritative.


Yeah, as long as the guests are all friendly. My concern is with 
unfriendly guests.


>
>> I think the *real* solution is to fix the lease handling so that
>> dnsmasq
>> remembers leases after they've expired (assuming that can be done
>> once
>> leasefile-ro is set). They would be marked as "expired", and
>> probably
>> not even reported externally, but all their info would still be
>> there
>> internally for dnsmasq's use when considering what to do with
>> incoming
>> requests for specific IP addresses.
> Is that possible at all with the current leasehelper setup?

"maybe"? See Nehal's recent email - we weren't notifying dnsmasq of 
expired leases, and that could be the source of the problem (or not, I 
didn't understand if he's verified whether doing so actually causes 
dnsmasq to accept the requests for expired addresses). If that works, 
then  the problem is solved. If not, then we may need to consider using 
dhcp-authoritative.

>   I have to
> admit that, being new to this discussion, I haven't understood the
> purpose of the leasehelper yet. What benefit does it have for the
> operation of the virtual network, compared to dnsmasq alone? Why is the
> "custom leases file" needed at all? I tried to find a rationale on the
> web, but I didn't.


libvirt previously allowed dnsmasq to handle the lease files, but 
apparently they didn't have enough information for the APIs that report 
guest IP info, so Nehal replaced dnsmasq's automatic leasefile handling 
with custom handling that stores the extra data in addition to what 
dnsmasq needs. He can provide more info if you need it.