[libvirt] libvirt plans: dns support for IPv6?

[Gene Czarcinski]

On 09/15/2012 05:10 PM, Laine Stump wrote:
> On 09/15/2012 04:07 PM, Gene Czarcinski wrote:
>> How is the version of dnsmasq being determined ... at [ugly] runtime
>> or during configuration/compilation?
> You can't rely on any information gathered at compile time, since the
> binary may be built on one system and run on another.
>
> Instead, I believe what Dan was talking about is that the default usage
> of dnsmasq uses only features that are available on the oldest dnsmasq
> we support (which is likely whatever version is currently shipping with
> RHEL5 / CentOS5), and any dnsmasq feature used by libvirt that requires
> a newer version of dnsmasq will only be attempted when some extra knob
> is turned on in the config (for example, if someone wants IPv6 DNS :-),
> and will generate an error and fail if dnsmasq on the system isn't new
> enough to support whatever feature is required.
>
>> Adding IPv6 dns capability to libvirt is turning out to be a little
>> more involve that I thought it would be.
>>
>> Right now you can define a IPv6 network manually, define static IPv6
>> addresses in the guests, and add the definitions to the host's
>> /etc/hosts file.  That works.
>>
>> The current dnsmasq 2.63 has a number of options for IPv6 and (to me)
>> appears to duplicate some/all of the functionality of radvd.  It is
>> not clear to me that all of these need to be supported.  However,
>> there is one mode which uses "slaac" IPv6 addresses on a network
>> running both IPv4 and IPv6 stacks.  It then does a "little dance" and
>> will add the IPv6 address to cache under the guest system's FQDN.  But
>> this is not dhcp support.
>>
>> I am doing some testing but I believe that NetworkManager is not doing
>> "the right thing" for stateful IPv6 addressing ... it is not sending
>> the FQDN (not the host name like in IPv4 but the FQDN).  I am trying
>> not to dig into the NetworkManager code and am doing some testing to
>> prove that this is the problem.
>>
>> Assuming that both of these approaches to IPv6 addressing and a dns
>> service are desirable, this means adding some kind of network
>> definition parameters so that libvirt knows what dnsmasq parameters to
>> use.
>>
>> Any comments appreciated.
> A general suggestion when adding things like this: try to make any
> required config options related to dhcp/dns terminology rather than the
> way they are presented in dnsmasq. Keep in mind that someone may some
> day want to provide a backend based on something other than dnsmasq.
OK, how about this approach...

Let's assume we only want the "real dhcp6" provided by dnsmasq.  If you 
do not specify a dhcp range for a family='ipv6' virtual network 
definition, then everything is as it is today.  If you do specify a 
dhcp-range for an 'ipv6" network, then the extra command line parameter 
is added and (assuming you are running something like dnsmasq-2.63), it 
works: you get stateful dhcp6 with updates to the dns.

The only other dnsmasq mode that might be of interest is "ra-names" and 
yes this is a dnsmasq thing. I need to do more testing to see if I want 
to bother with it.  Again, if it is implemented, the default would be 
nothing and the command line compatible with old dnsmasq versions.  Some 
special "parameter" would be needed for this to be invoked.

The only interest I have in the 'ra-names" is that I need NetworkManager 
to work correctly and send fqdn.fqdn information for IPv6 networks and 
until it does, ra-names works.  I have not looked at the code or done 
testing but, from looking at various documents, I believe that dhcpd-v6 
will also need the fqdn.fqdn sent for it to do dynamic dns updating for 
IPv6 addresses.

As I said earlier, static IPv6 addresses and /etc/hosts entries on the 
qemu/kvm/libvirt host work today with no changes.

I hope this is a "good enough" solution and I believe it is do-able.

Gene