On 09/15/2012 04:07 PM, Gene Czarcinski wrote:
On 09/14/2012 06:08 AM, Daniel P. Berrange wrote:
FYI, already libvirt aims to work with old dnsmasq, in general there is no problem with using features from new dnsmasq. If the host has an old dnsmasq, they simply won't be able to take advantage of new features libvirt might support. The key is simply that if the host has the old dnsmasq, we should be careful not to invoke it in the wrong way for existing features. I am not sure I understand the reasoning for continuing support of old versions of dnsmasq ... but so be it.
Upstream libvirt is targetted at many platforms, past and present, and must continue to build and function properly on a lot of different systems that aren't "the latest". For example, because there is a very large installed base of RHEL5 systems, we still check to make sure that upstream libvirt builds and runs properly on RHEL5.
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.