Re: [libvirt] Proposed: replace radvd with dnsmasq for Router Advertizing

On 11/03/2012 08:58 PM, Laine Stump wrote: > > On 11/02/2012 12:39 PM, Gene Czarcinski wrote: >> >> On 11/02/2012 11:58 AM, Jiri Denemark wrote: >>> >>> On Fri, Nov 02, 2012 at 08:25:42 -0400, Gene Czarcinski wrote: >>>> >>>> I have been doing some testing and dnsmasq is capable of handling the >>>> service currently provided by radvd. To implement this in dnsmasq >>>> requires the following: >>>> >>>> if an IPv6 dhcp-range is specified, then add: >>>> enable-ra >>>> >>>> if no IPv6 dhcp-range is specified, then add: >>>> dhsp-range=<IPv6-subnet>,ra-only >>>> >>>> Tested. The second one will work with basic dnsmasq-2.6.3. The first >>>> one and dhcp-range itself only works with dnsmasq-2.64 (when released) >>>> or dnsmasq-2.63+patches. >>>> >>>> Since dnsmasq-2.48 does not support IPv6 dhcp but does handle IPv6 for >>>> dns and CentOS 6 does include radvd, I also propose that a >>>> libvirtd.conf >>>> option be added. If the option is not present or set off, then >>>> radvd is >>>> used. If the option is set on, then dnsmasq is used. >>> >>> I think this should rather be handled by configure script (perhaps >>> with an >>> additional option if needed). Otherwise, I agree with the plan. >> >> I can do that but then the individual backporting to (for example) >> CentOS 6 with dnsmasq-2.48 would have to do nothing if DHCPv6 is not >> wanted and, if DHCPv6 is wanted, to simply install dnsmasq-2.63+ and >> change a libvirtd.conf parameter. > > (actually, the parameter/config option wouldn't need to be changed just > to use dhcpv6, it would only need to be changed if you wanted to use > dnsmasq for ipv6 router advertisement instead of radvd) > > > So there are 3 possibilities for deciding whether to use radvd or > dnsmasq for router advertisement: > > 1) configure-time option to set a compile flag which will compile the > code to use either radvd or dnsmasq. > > 2) libvirtd.conf parameter which will be checked at runtime. > > 3) runtime probe of dnsmasq version (similar to how we currently run > "qemu-kvm -help" to learn the qemu version / available options). > > Option (1) puts the burden on the distro package maintainer (or the > individual, if they're building for themselves). It could be setup to > autodetect the dnsmasq version and provide the most logical setting as > default. As you say, though, if someone on a distro that's using an old > dnsmasq wanted to switch to using dnsmasq for RA instead of radvd, they > would need to build their own libvirt, rather than just upgrading dnsmasq. > > Option (2) puts the burden on the admin, and leaves open the possibility > of a misinformed/uninformed admin seeing the option and tweaking it when > they shouldn't, leading to support headaches. > > Option (3) would be the most reliable as long as we never need to > manually disable use of dnsmasq for RA due to a bug in a newer version > of dnsmasq. Another potential problem is if the output of "dnsmasq > --version" changes in some way that's incompatible with whatever code we > have to parse the version number, we could potentially make the wrong > choice. > > > (Another thing in favor of either (2) or (3) is that all the code would > always be compiled, and I've seen Eric advocate that recently as a way > to prevent code going "stale" because it's #ifdef'ed out most of the > time.) > > >> If the default is to use dnsmasq, then there are going to be mistakes >> made. If the default is to use radvd, then many systems will not change. > > I'm kind of leaning towards making the decision automatically based on a > runtime examination of the dnsmasq version. Any other opinions? > Trying to probe the dnsmasq to find out if it could or could not handle RA is not something that makes sense to me. Supporting RA was first implemented in dnsmasq-2.60 so we know that both 2.59 (F16 and original F17) and 2.48 (CentOS 6 and RHEL 6) will need to use radvd. Let me say again, I assume that anyone wishing to run libvirt-1.0.0 or later will likely rebuild the rpm on that system and given what it takes to rebuild libvirt, rebuilding dnsmasq is trivial. Anyway, I am now proposing option 4: 1. Add the code to have dnsmasq support RA. 2. Add a boolean switch which determines whether radvd or dnsmasq is being used for RA. 3. Add code so that the boolean switch is set by a libvirtd.conf parameter at runtime. 4. Add code to specify the default setting of the libvirtd.conf parameter at build/compile time. My recommendation is that the default should be set to dnsmasq. Pro: Moves things forward; allows older systems which do not want to update dnsmasq a relatively easy way to make things work. If the system backported libvirt does later update dnsmasq, it is an easy change to libvirtd.conf to switch. Con: While the radvd related code will be compiled in, if the default is to use dnsmasq, there will need to be a special regression test to ensure that it still works. Gene --