[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [libvirt] Proposal: no dnsmasq (no dhcp and no dns) and no radvd option
- From: Gene Czarcinski <gene czarc net>
- To: libvir-list redhat com
- Subject: Re: [libvirt] Proposal: no dnsmasq (no dhcp and no dns) and no radvd option
- Date: Sun, 25 Nov 2012 08:25:30 -0500
On 11/24/2012 04:19 PM, Laine Stump wrote:
On 11/23/2012 02:18 PM, Gene Czarcinski wrote:
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
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' >
Don't refer to dnsmasq specifically in the XML unless it's something
that is unique to dnsmasq (and then we should seriously consider if
we're thinking about it the right way before adding it). The intent is
that the XML should describe the desired configuration in a manner high
level enough that a new driver using different backend components would
be able to use the same XML attributes and arrive at similar
functionality. For example, there is active work right now to support
libvirt's server side on FreeBSD, and they may decide that they want to
implement their networks using different implementations of DNS and dhcp
servers (they will already need to do something different in place of
Linux host brdges and iptables, so it will have to be a completely new
Obviously there are cases where something specific to the backend needs
to be in the XML; for example the virtio-net drivers can specify <driver
name='qemu' ...> and in that case can have an option ioeventfd and
event_idx options which would probably be meaningless to any netdev
driver for another hypervisor, but we aim to keep that to a minimum, and
use it only when the characteristic described really is unique to
(At any rate, it seems reasonable to me that someone may want us to
provide a dhcp server but no dns server. Yes, this also implies that we
should have a way in the config to feed in the address of an alternative
DNS server ("--dhcp-option=option:dns-server,x.x.x.x" and
"--dhcp-option=option6:dnsserver,xxxx::xxxx") to send to dhcp clients
when they've disabled dnsmasq's own dns server (in case you hadn't found
it in the manpage yet - you can run dnsmasq with no dns server by adding
"--port=0" to the commandline). As soon as I hit send on this, I'm going
to type up a short mail asking for comments on how to add support for
any standard dhcp option.
As for the other two - any reason why you used "logDnsQueries" instead
of "logDns"? Also, do you think we might want the ability to specify a
level in the future? (I guess if we did, that could coexist with yes|no).
And while we're on the topic of logging: one thing that's bothered me a
lot, and we've had other people complain about it as well, is that every
single DHCP lease renewal results in a message to /var/log/messages, and
there doesn't seem to be any way to suppress it. Is that correct?
OK, I had not realized that it was possible to not have dns while
continuing to do dhcp. So, it now becomes disableDns="yes" which
results in --port=0 being passed to dnsmasq. For completeness, I
suggest that disableDhcp="yes" and disableRA="yes" be added.
I have changed my mind and will make it logDns=, logDhcp= and (again for
completeness) logRA= ... this last one may require a small dnsmasq update.
However, I still like the idea of not starting anything and, as I state
below, you can start dnsmasq even if it is configured to do nothing.
Therefore, I propose adding "disableDaemons=" which is not specific to
any package but would mean not to start either dnsmasq or radvd
regardless of whether or not they would be started.
Lease renewal messages should not be that frequent it is probably a
"small matter of programming" to get an option to suppress them ... if
Simon Kelley would add that.
Speaking of logging, if you do not like the lease renewal messages, then
you will have a bigger problem with the "RTR-ADVERT" messages that
dnsmasq issues every 3//4/5 seconds for every started interface. I have
submitted a "tiny" patch to dnsmasq which ties issuing this message to
log-dhcp being enabled.
Easy enough to implement but what is the purpose. If there are no rules
at all (and perhaps no gateway addresses), then the interface will not
work for guest-to-guest communications either. But wait, if there are
no rules at all the the "default" "--reject-with icmp-port-unreachable"
will not be there either so maybe things will work. However, I thought
that filters were specified as part of the <interface> definition, not
the <network> definition.
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.
Actually that's yet another switch that we need to add - the ability to
suppress all iptables rules for a particular network (unless it is in
NAT mode, in which case it makes no sense, because it's the difference
in rules that changes it from mode='route' to mode='nat'). Perhaps it
could be something like filter='none|open|restricted', although I don't
know if that's descriptive enough - even without getting into specific
protocols (which I don't think should be done - at that point they
should really be using a guest-specific filterref) you might still want
to know if there should be any rules at all, allow everything, allow
outgoing sessions but not incoming, allow inter-guest traffic but not
incoming from the outside, allow nothing (all of these could be
overridden by a particular guest's filterref)
So, where should this be handled? It makes some sense to me that for
the types of networks src/network/bridge_driver.c handles, maybe
<network> is more appropriate.
Believe it or not, it is possible to start dnsmasq on an interface which
has no gateway addresses and --port=0 so that there no dns ... it runs
and appears to do nothing. Again, what purpose is there to starting
dnsmasq in this situation?
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.
Yeah, I didn't understand that either - If the bridge has no IP address,
there's no target IP for a DNS request to be sent to. I just assumed he
was thinking of something else.
One last question. Considering all of these various new xml
parameters/attributes, should they all be on the <network> statement,
only part of them on <network> and others on a (perhaps) a <logging>
defintion, or maybe an <options> statement.
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.
[Date Prev][Date Next] [Thread Prev][Thread Next]