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

[Laine Stump]

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?