Thierry Carrez wrote: > @Simon: what are the options from a dnsmasq perspective ? >
Some background: dnsmasq can run in two modes. Default mode: dnsmasq binds the wildcard address and does network magic to determine which interface request packets actually come from, so that the results can be send back with the correct source address. This has the advantage that network interfaces can come and go and change IP address and dnsmasq will keep working. It's possible to restrict dnsmasq to only reply to requests on some interfaces; requests from other interfaces will be read by dnsmasq and then silently dropped. Telling dnsmasq to use an interface which doesn't exist but might in the future will result in a logged warning, but dnsmasq will still start and when the interface comes up it will work. Bind-interfaces mode: This is the traditional way to do UDP servers. At startup dnsmasq enumerates all the extant interfaces and then opens a socket for each one, listening on the interfaces's IP address. Interfaces may be skipped if excluded by the --interface and --except-interface flags, and any interface specified in --interface which doesn't exist at start-up will generate a fatal error. In almost all cases, default mode is better: --bind-interfaces is only there to cope with old platforms which don't support enough socket options to do default mode. The only time when --bind-interfaces works better is when it's desirable to run more than one instance of dnsmasq. This is not possible in default mode, but it does work in bind-interfaces mode, providing than _all_ instances are in bind-interfaces mode, and that they listen on a disjoint set of interfaces. This is what the libvirt package attempts to do, as I understand it: it starts its own dnsmasq in --bind-interfaces mode listening on a virtual interface and it forces any "system" dnsmasq into --bind-interfaces mode and away from the the virtual interface by dropping a configuration fragment into /etc/dnsmasq.d This method brings the disadvantages of --bind-interfaces to the private libvirt dnsmasq instance (the race condition at start-up) and to the "system" dnsmasq (which will no longer cope with changes to network interfaces.) Options. 1) Keep doing what you're doing, work around the race condition and accept that installing libvirt will limit the functionality of a system dnsmasq by forcing it into --bind-interfaces mode. 2) Arrange that if libvirt and a "system" dnsmasq co-exist, libvirt uses the system dnsmasq, rather than starting its own. It should be possible to drop some configuration to make the system dnsmasq do what is needed for libvirt. There's a problem here if libvirt is installed alone and using a private dnsmasq, and then subsequently a system dnsmasq is installed. 3) Make some changes to dnsmasq to improve the situation when two instances are running. This may be possible, but I don't have many clues what could be done. 4) Look at some sort of partitioning in the kernel so that the virtual interface is in some sort of separate partition with effectively two network stacks. A sort of chroot for networking. I don't know if this exists in the Linux container stuff, or could be done. It's not really my area. HTH Simon. -- packages dnsmasq and libvirt-bin conflict with each other https://bugs.launchpad.net/bugs/231060 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
