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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list