libvirt launches dnsmasq for non-dhcp networks.

On natty libvirt seems to start dnsmasq on lo by default despite "--except-interface lo".

@Steffen

could you please open a new bug for your issue, preferably using 'ubuntu-bug libvirt' ?

i would like to point out, that it starts dnsmasq but it does not listen for dhcp.
it listen to dns, even if no dns entries are defined for the network.

# virsh net-dumpxml default
<network>
  <name>default</name>
  <uuid>ff2d70f9-7613-05fe-7c67-40b2d7f6b0e4</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <mac address='52:54:00:24:08:E3'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
  </ip>
  <ip address='192.168.10.0' netmask='255.255.255.0'>
  </ip>
  <ip address='192.168.20.0' netmask='255.255.255.0'>
  </ip>
</network>

# ps -e --format=args | grep dnsmasq
dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --listen-address 192.168.10.0 --listen-address 192.168.20.0

# netstat --listen --numeric --tcp --udp --programs | grep dnsmasq
tcp 0 0 1...

I am also currently struggeling with this behaviour:

I would like to configure bridges with libvirt but start my own universal dnsmasq separately.
iirc, earlier versions of libvirt did not launch dnsmasq (not even for serving dns), when
the <dhcp> section was not present in the network xml file.

I am running libvirt Version: 0.9.2-4ubuntu15.2 on oneric (11.10).

I am wondering what should be done with this bug report since it has not seen any update for so long. I believe even at the time of it being reported this looks to be an intentional mode of operation. From searching through the upstream git repo I found this commit which at least re-introduced this (this followed 0.8.8 and appears to be some security related change as well):

commit 7892edc9cc45e4fb1079b627bda3f571ac27041f
Author: Laine Stump <email address hidden>
Date: Fri Mar 11 11:47:58 2011 -0500

    network driver: Start dnsmasq even if no dhcp ranges/hosts are specified.

In this situation dnsmasq will purely act as a DNS cache. It should be possible to set up ones own DHCP service though maybe not using dnsmasq (since I don't see a no-dns mode there). isc-dhcp-server should work. Generally I think the idea in libvirt seems to be that any network defined via libvirt will also get those services provided. And for any more complex setup one has to do the network definitions outside libvirt.

For example I often use a transparent bridge which I define in /etc/network/interfaces and then attach VMs to that bridge. This can be defined within libvirt as a mode='bridge' network. Though in practice I don't have that and actually assign VMs the "shared device" (the bridge) directly. Not sure this is good practice, though. Both methods work.

So generally I would be tending to close this bug as "won't fix" since this is intended behaviour by upstream. Maybe needs a better documentation somewhere (not sure where) but maybe there already is. After all this all was 3y ago...

it is getting worse with virsh and lxc containers.
i have 60 lxc containers running, each of them connected to 4 networks.
thats alot of overhead for no usefull functionality, DHCP and DNS is already served by standalone servers.

it might be ok if you got a standalone home server with one or two VMs on it. but if you have a productive server which can handle hundreds of lxc containers it is getting out of control.

Ok, I've not yet written the patch, but have proposed on the libvirt channel a way to resolve this. Hoping to send a patch to the mailing list next week.

In
https://www.redhat.com/archives/libvir-list/2015-December/msg00086.html

Laine gave some good feedback. I will not have time this year to follow up on it, but there is good guidance there for someone who wants to give it a try.

Note that as smb pointed out this really is low priority since most people define their own bridge outside of libvirt and just attach vms to those.

(Closed per discussion in the rh bug)