Re: [libvirt] Proposal: no dnsmasq (no dhcp and no dns) and no radvd option
On 11/20/2012 05:29 PM, Laine Stump wrote:
On 11/20/2012 02:36 PM, Gene Czarcinski wrote:
> >Laine mentioned something yesterday that got me to thinking: being
> >able to specify that dnsmasq is not to be started for an interface.
> >
> >Let me expand that by saying that libvirt would not start dnsmasq for
> >either dns or dhcp and also would not start radvd. However, the IPv4
> >and IPv6 gateway addresses would be defined on the virtual network
> >interface and the "usual" iptables and ip6tables rules would be in
force.
> >
> >This would allow a user to configure dnsmasq to meet any user desires
> >or use something completely different instead of dnsmasq.
> >
> >Questions: Useful? Worth the time and effort?
That was already determined before I mentioned it to you - it's been
requested several times, and I've told some people it was "going to
happen", although didn't say when:-).
OK, color this "almost done" (doc and schemas need updating).
Three new parameters are added:
<network disableDnsmasq='yes' logDnsQueries='yes'
logDhcp='yes' >
If nothing is specified, then the default is no, no, no so that things
work as they do now. Currently, if the boolean value is 'no' or false,
then that parameter is not written out. I could easily change that
depending on what others want to do.
Laine, I changed this to be disableDnsmasq because that is the real
result. If this is specified, then starting radvd will also be
suppressed. It is as if no IPv4 or IPv6 addresses were specified.
However, the iptables and ip6tables rules will remain the same since it
is assumed that gateway addresses will be specified.
I have scratched an itch of mine by providing a way to specify that
dns-queries and dhcp activity should be logged and that this is
specified separately for each virtual network interface.
Dan suggested that a user might still want to run dnsmasq's dns service
even if no IP addresses are specified. However, in that case I am not
sure what dnsmasq is suppose to monitor for queries ... it needs some
kind of address or we will have the problems which the bind-dynamic
update is suppose to fix.
I have not integrated this with the bind-dynamic update but plan to
before I submit it. I will be submitting this patch with the IPV6
enhancement, DHCPv6, etc. series since it is yet again messing with the
same code.
If any of the series get rejected rather than accepted, it will not be
too much of a problem to rework them.
Gene