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

On Sun, Nov 4, 2012 at 6:26 AM, Gene Czarcinski <gene(a)czarc.net&gt; wrote: > 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 > > > -- This sounds like the bastard love child between Laine's option 1 and option 2. I would say it it suffers from all of the cons that Laine mentioned that weren't listed here. Laine's option 3 still sounds the best.