Re: Static DHCP lease never distributed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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='10.0.0.1' prefix='24'>
         <dhcp>
            <host mac='02:99:92:43:eb:b8' name='dhcp-test' ip='10.0.0.10' />

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)     0.0.0.0.68 > 255.255.255.255.67: 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,10.0.0.10,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.




[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux