Static DHCP lease never distributed

Laine Stump laine at
Wed Feb 10 23:49:47 UTC 2021

On 2/9/21 8:28 PM, Brooks Swinnerton wrote:
> Hi there,
> I have a libvirt network defined as so:
> <network>
>      <name>customers</name>
>      <bridge name='customers' macTableManager='libvirt' />
>      <port isolated='yes' />

At first I was suspicious that your problem could be related to the 
<port isolated='yes'/> (because not many people use it), but I added 
that to my own test, and it still worked.

Same for macTableManager='libvirt' - this has been around a few years 
longer, but I suspect that also nobody uses it (in spite of the promise 
of performance gains, it turns out that if something isn't the default, 
most people just never know that it exists).

>      <dns enable='no' />
>      <ip address='' prefix='24'>
>          <dhcp>
>              <host mac='02:99:92:43:eb:b8' name='dhcp-test' 
> ip='' />

After reading a bit, I thought maybe we were missing the statement for 
and "empty" range that dnsmasq requires when there are only static 
addresses, but then I tried out a test and it worked. Just out of 
curiousity I looked back through libvirt's history and found that bug 
was fixed in September 2010! (and has remained fixed since then)

(going back up) Then I noticed you have <dns enable='no'/>, which is 
also very uncommonly used. So I tried adding that to my config and 
restarting the net. I am *still* unable to get it to fail.

>          </dhcp>
>      </ip>
> </network>
> And that network is attached to a virtual machine:
>      <interface type='network'>
>        <mac address='02:99:92:43:eb:b8'/>
>        <source network='customers'/>
>        <model type='virtio'/>
>        <address type='pci' domain='0x0000' bus='0x00' slot='0x03' 
> function='0x0'/>
>      </interface>
> But for some reason when the domain starts, it never gets an address. If 
> I tcpdump the bridge that was created by the network I can see it 
> sending out discover packets, but dnsmasq never seems to respond:
> 01:26:25.039987 02:99:92:43:eb:b8 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
> (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], 
> proto UDP (17), length 328)
> > BOOTP/DHCP, Request from 
> 02:99:92:43:eb:b8, length 300, xid 0xc7283f76, secs 228, Flags [none]
>            Client-Ethernet-Address 02:99:92:43:eb:b8
>            Vendor-rfc1048 Extensions
>              Magic Cookie 0x63825363
>              DHCP-Message Option 53, length 1: Discover
>              Client-ID Option 61, length 7: ether 02:99:92:43:eb:b8
>              MSZ Option 57, length 2: 576
>              Parameter-Request Option 55, length 7:
>                Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
>                Domain-Name, BR, NTP
>              Vendor-Class Option 60, length 3: "d-i"
> Despite that appearing to be the correct mac address.
> Looking in /var/lib/libvirt/dnsmasq/customers.hostsfile, it's returning 
> what I would expect to be there:
> 02:99:92:43:eb:b8,,dhcp-test
> If I add a <range> stanza to the configuration, that does appear to 
> work, so it seems this is only related to static addresses.

Do you mean that if you add a <range> that the guests can then get their 
static addresses? Or are they given different (dynamic) addresses within 
the range?

> This is libvirtd 5.8.0.

That's a year and a half old, but nothing in this area of the code has 
changed in a way that should affect this behavior.

Of course it could be that your specific kernel isn't properly dealing 
with one of the above "unusual" options I mentioned. If I were in your 
position, I would try removing mactableManager='libvirt', <port 
isolated='yes'/>, and <dns enable='no'/> (remember you need to destroy 
and restart the network after any change.

If none of those helps, you may want to start looking into iptables 
rules (although the fact that it works with a range enabled implies that 
there are no iptables issues.

More information about the libvirt-users mailing list