Bug 816185 - Doesn't start dnsmasq for bridged network if system-wide dnsmasq is running
Doesn't start dnsmasq for bridged network if system-wide dnsmasq is running
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F17-accepted/F17FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2012-04-25 09:06 EDT by Nils Philippsen
Modified: 2012-04-26 10:39 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-26 10:39:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nils Philippsen 2012-04-25 09:06:59 EDT
Description of problem:

I have a system-wide dnsmasq service running on my machine which binds to localhost and localhost6. Libvirtd then doesn't start dnsmasq for its bridged (default) network, therefore guests don't get DHCP leases.

Version-Release number of selected component (if applicable):
libvirt-0.9.11-1.fc17.x86_64
libvirt-daemon-0.9.11-1.fc17.x86_64
dnsmasq-2.59-5.fc17.x86_64

How reproducible:
Reproducible.

Steps to Reproduce:
0. On a system with dnsmasq configured to bind to loopback addresses 127.0.0.1 and ::1, and libvirtd having a default bridged network, and both set up to be started at boot time from systemd:
1. Boot the system
2. "pgrep -lf dnsmasq"
  
Actual results:

6236 /usr/sbin/dnsmasq -s gibraltar

Expected results:

6236 /usr/sbin/dnsmasq -s gibraltar
5930 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile

Additional info:
Stopping both libvirtd and dnsmasq services, then starting libvirtd again, then dnsmasq works as expected. I can only guess that libvirtd thinks the system-wide dnsmasq process is responsible for the bridged network as well (which it isn't). This setup worked in Fedora 16.
Comment 1 Nils Philippsen 2012-04-25 09:11:27 EDT
NB: this is not bug #734903
Comment 2 Daniel Berrange 2012-04-25 09:20:50 EDT
libvirt does not do any apriori checks for a global dnsmasq process - it will unconditionally launch its dnsmasq when starting the default network

Your global dnsmasq process needs to be explicitly configured to play nicely with libvirt. By default it will immediately try to bind to all interfaces on the system, which then causes libvirt's dnsmasq to quit

Your dnsmasq args posted above don't include the suitable config args, and I'm guessing your config file doesn't either

http://wiki.libvirt.org/page/Libvirtd_and_dnsmasq

NB, nothing has changed in the way libvirt deals with dnsmasq between F16 and F17 - the same rules should apply
Comment 3 Nils Philippsen 2012-04-26 07:18:15 EDT
(In reply to comment #2)
> libvirt does not do any apriori checks for a global dnsmasq process - it will
> unconditionally launch its dnsmasq when starting the default network
> 
> Your global dnsmasq process needs to be explicitly configured to play nicely
> with libvirt. By default it will immediately try to bind to all interfaces on
> the system, which then causes libvirt's dnsmasq to quit
> 
> Your dnsmasq args posted above don't include the suitable config args, and I'm
> guessing your config file doesn't either

You're guess is off ;-):

--- 8< --- /etc/dnsmasq.d/local_config ---
[...]
interface=lo
bind-interfaces
--- >8 -----------------------------------

I've also checked this with lsof on dnsmasq processes and none of them bound to 0.0.0.0, only to 127.0.0.1/::1 ("my" dnsmasq process) and 192.168.122.1 (libvirt's). That's why I mentioned that this isn't bug #734903 :-P. 

> NB, nothing has changed in the way libvirt deals with dnsmasq between F16 and
> F17 - the same rules should apply

This is odd. I have run "strace -Ff -e execve /usr/sbin/libvirtd" and it seemed as if it didn't even attempt to start dnsmasq. I've just applied a bunch of updates and will reboot the system to observe behavior starting from a "clean slate".

NB: I'm on vacation from tomorrow on and will be back on May 10th.
Comment 4 Nils Philippsen 2012-04-26 10:39:09 EDT
With the updates installed, both dnsmasq processes come up well after booting.

Note You need to log in before you can comment on or make changes to this bug.