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

[Doug Goldstein]

On Sun, Nov 4, 2012 at 6:26 AM, Gene Czarcinski <gene at czarc.net> 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.

-- 
Doug Goldstein