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

[Gene Czarcinski]

On 11/05/2012 12:29 AM, Doug Goldstein wrote:
> 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.
OK, I give up (mostly).  First of all, I will check with Simon Kelley as 
to which version has solid RA support for stateful (enable-ra) and 
stateless (ra-only) support.  This may be 2.60 but it also may be 
later.  I will also check as to the best method of obtaining support 
info from dnsmasq ... likely it is --version.

This is for dnsmasq-RA versus radvd only.

Since I am doing this test, I could also check to see if dnsmasq is 2.63 
or later for DHCPv6.  Yes, it will take dnsmasq-2./63+patches or 
dnsmasq-2.64test7 or later for it to really work.  If you try it with an 
earlier or unpatched version, you quickly fine out from the descriptive 
message in syslog.

Gene