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. How is the version of dnsmasq
being determined ... at [ugly] runtime or during configuration/compilation?
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.
Gene
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list