[libvirt] dnsmasq supporting RA instead of radvd patch

Gene Czarcinski gene at czarc.net
Thu Nov 8 19:30:31 UTC 2012

On 11/08/2012 01:55 PM, Eric Blake wrote:
> On 11/08/2012 08:26 AM, Doug Goldstein wrote:
>>>> I'm still not thrilled that you're pushing forward with requiring 2.63
>>>> + a few patches backported from 2.64 into 2.63 and only checking
>>>> against 2.63.
>> My point is if you're going to add a check for 2.63
>> but really require 2.63 + 3 patches that Fedora has backported into
>> their 2.63 version which was your original proposal, this would cause
>> lots of headaches for every other distro out there unless they
>> backported those very same patches into 2.63. So better to wait for
>> 2.64 and go forward from there. libvirt works on and targets many more
>> systems than Fedora.
> Agreed.  Upstream, libvirt should require 2.64.  If Fedora (or any other
> distro) cares about shipping 2.63 + patches, then they can also patch
> their backport of libvirt to relax things to 2.63.  But upstream cannot
> assume that 2.63 is patched.
Understood ... I think.

1.  For RADVD, if dnsmasq version => 2.63, then dnsmasq will handle the 
RA service.  Otherwise, it will be radvd.  My submitted patches 
implement that.  Granted, the patches are, more or less, chained 
together and that will make life difficult.

2.  Currently, there are NO version checks in the DHCP6 implementation 
(all DHCPv6 stuff is in one patch file currently v6-7).  If I understand 
you correctly, you want dnsmasq version checks performed.  Some of this 
is simple and some is not so simple.

2a. If the dsnmasq version is => 2.64, all the DHCPv6 stuff is OK.  This 
check is fairly easy to do and I will try to get an implementation in 
today so that things might move along.  I would like to see this as a 
minimum since I had modified and added to the tests performed.  Pulling 
a piece out of the middle will be "difficult."

2b. If dnsmasq version is <=2.63, then ??

   -- fail/error out the dnsmasq startup because the xml specification 
is invalid.

   -- or, just ignore the any DHCPv6 dhcp-range or dhcp-host 
specifications but issue a syslog warning message that it is being 
ignored because of the dnsmasq version.

   -- or ? ... any suggestions?

3.  I would like to make it "easy" for any system administratiors or 
system maintainers who want DHCPv6 but also need to keep dnsmasq 2.63.  
It it is too difficult, they will simply use dnsmasq 2.64test or 2.64rc 
or 2.64 ... unlike libvirt, it only takes about 15 seconds to rebuild 
the dnsmasq rpms.  At some point in time in the not so distant future, 
this becomes a non-issue ... it is the transition period.

3a. Do nothing!  Screw it. If someone wants DHCPv6 support, then they 
can get some version of dnsmasq 2.64 since it will be here "real soon 
now".  It has always been my contention that if someone wants libvirt 
with DHCPV6 support, they can got the little extra to get a dnsmasq that 
supports it.

3b. Add a configuration/compile-time options allowing 2.63.

Right now I am inclined to do 3a.  But, the question I have is what to 
do for 2b.  The simplest way (and this is my inclination for today) is 
to error out.

Right now I feel a little pressured because I am going to be unavailable 
for the next week to ten days.


More information about the libvir-list mailing list