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.