[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [libvirt] libvirt/dnsmasq integration.
- From: Simon Kelley <simon thekelleys org uk>
- To: "Daniel P. Berrange" <berrange redhat com>
- Cc: libvir-list redhat com
- Subject: Re: [libvirt] libvirt/dnsmasq integration.
- Date: Mon, 01 Mar 2010 13:54:44 +0000
Daniel P. Berrange wrote:
> I imagine you've already seen this, but as an example of the ARGV that
> libvirt generates for its dnsmasq instances:
> /usr/sbin/dnsmasq \
> --strict-order \
> --bind-interfaces \
> --pid-file=/var/run/libvirt/network/default.pid \
> --conf-file= \
> --listen-address 192.168.122.1 \
> --except-interface lo \
> --dhcp-range 192.168.122.2,192.168.122.254 \
That's useful to know. For new releases, --dhcp-lease-max is no longer
needed,(the default changed from 150 to 1000). Why are you using
--strict-order? That's not normally a sensible choice.
> I'm wondering if there's any way we can arrange things so that we will
> always be able to use a system dnsmasq instance, regardless of whether
> the host already has it running.
(The following applies directly to Debian and Ubuntu packaging, I
imagine other systems are similar.)
That would be trivial to do: just depend on the "dnsmasq" package,
rather than "dnsmasq-base". The downside is that installing libvirt
would pull in a system daemon that provides DNS service to all
interfaces by default. It would be possible to change the dnsmasq
package to not provide any services until configured to do so, but the
ability to just install DNS and make a machine into a DNS server without
any configuration is a useful one, and I wouldn't loose it lightly.
> My other concern with writing libvirt configs into /etc/dnsmasq.d is that
> users will then get the impression that this is something that they can
> freely edit / modify at will. They'll be unhappy with libvirt overwrites
> their changes whenever it starts. This could perhaps be addressed by
> allowing use to put the configs into /var/lib/dnsmasq/ instead of
> /etc/dnsmasq.d, which is more common location for non-user editable
> configs generated at runtime.
That's a packaging, rather then dnsmasq, issue: /etc/dnsmasq.d is not
hard-coded into the binary, it's supplied on the command line by the
start-up script. (again this is for Debian and Ubuntu). There's no
reason why /var/lib/dnsmasq/ couldn't be added too. The downside of that
would be more that it's more mysterious for users trying to work out
exactly where all this configuration is coming from. Maybe a good
compromise might be a DO NOT EDIT header in /etc/dnsmasq.d/libvirt.
> Your general plan of having a single dnsmasq instance though does sound
> desirable, given the way the sockets() APIs work wrt binding to addresses
> The total set of DNSMASQ args that we currently use are
> --domain DOMAIN-NAME (optional)
> --dhcp-range=IPRANGE (optional, multiple times)
> --dhcp-lease-max=RANGE-SIZE (optional)
> --dhcp-host=STATIC-HOST-MAPPING (optional)
> --enable-tftp (optional)
> --tftp-root=/some/path (optional)
> --dhcp-boot=PXE-BOOT-SERVER (optional)
OK, the use of TFTP by libvirt is new to me. Looks like I'll have to
pull some similar tricks to allow libvirt to enable TFTP on on interface
without disturbing things elsewhere.
> NB, we explicitly give a NULL conf-file in order to prevent any of the
> user's settings from the system instance from conflicting with libvirts
> settings. We don't really want users to be able to specify arbitrary
> other configuration settings for the libvirt dnsmasq instances, other
> than those we enable via the libvirt XML configuration.
> I've used 'optional' to denote flags we only pass when explicitly
> configured via libvirt's XML format. The others we pass all the
> The 'lease-max' arg we calculate to be exactly matching the number of
> addresses in the configured dhcp-range args. This is because some of
> our users had configured dhcp ranges larger than 150 addresses in len.
See comment earlier - the default has gone up to 1000, so you may not
need this now.
> Would this scheme allow libvirt to guarantee that no DHCP is present
> on its interface ? We currently support running in DNS-only mode, or
> DNS+DHCP. It is desirable to keep that regardless of how the host's
> system dnsmasq is currently configured for other interfaces.
> If I am understanding your suggestion, this allows libvirt to easily
> enable DNS+DHCP mode on its own interface, without us accidentally
> enabling DHCP on other host interfaces.
> If libvirt doesn't use any --dhcp-range flags, there is still a chance
> that DHCP could be enabled on libvirt's interface if the system dnsmasq
> had any dhcp-range args. Though assuming the IP ranges don't overlap
> this should be effectively a no-op ?
instead of a dhcp-range. That solves that problem.
> I think you've got the general picture of what we're doing with dnsmasq.
> At a very high level our original goals were
> - Support multiple independantly configured networks (virbr0, virbr1, etc)
> - Isolation between libvirt network interface config & host inteface config
> - Only support configuratin of options via libvirt network XML format
> Overall, libvirt aims to provide a standard representation of configuration
> of services regardless of underlying implementation. Thus ideal would be
> that end users would not need to know or care that libvirt was using dnsmasq
> as its implementation. Obviously we're failing here due to the inevitable
> conflict with the system dnsmasq that operates in wildcard addressing mode.
> Your proposal certainly helps us deal with that conflict in a better way.
> My main concern is that it has the potential to significantly reduce the
> isolation of configuration between interfaces. eg, does libvirt's use of
> the --enable-tftp arg suffer from the same problem as --dhcp-range, where
> libvirt setting it for one interface inadvertantly enables it for all others
> This would seem to imply that many other dnsmasq arguments would need to gain
> an extra 'interface' parameter to restrict their scope, which sounds like
> quite a burden for your code to support ? In essence we're trying to have
> 1 single dnsmasq process, but at the same time ensure that everything in the
> extra /etc/dnsmasq.d/libvirt-virbr0 file is scoped to a single interface.
> I could almost see that file containing 'scope=virbr0' as a short-cut for
> saying that every config flag listed there only apply to that one interface.
I think it's reasonable to think about that in two parts. DNS and
Since a function of dnsmasq is to export the DNS environment of the
machine on which it runs to DNS clients, it seems sensible not to worry
about dnsmasq configuration which affects that (--address, --bogus-priv,
etc etc) You're already accepting the contents of /etc/hosts and
/etc/resolv.conf on the host machine, which not the other things too?
For DHCP there is inherently rather more isolation, --dhcp-host
declarations are only valid when the IP address is on the correct
subnet, so that's pretty isolated.
Any dhcp-option declarations in the main configuration will apply to
virtual networks too. You may consider that a problem. You don't seem to
send any DHCP options at the moment, but if you did, it is trivial to
ensure that on the virtual networks, options set through libvirt take
priority over options configured elsewhere.
A formal "scope" mechanism is something I'd certainly consider, if it
were demonstrated to have serious utility.
> Nb, I've not said it explicitly, but although the default libvirt config
> starts with a single dnsmasq instance attached to virbr0 interface, we
> have the ability to start many dnsmasq instances each on a different bridge
and something I didn't mention which is related to this: by using only
one dnsmasq instance, all you virtual machines are resovlable by name in
the DNS from everywhere: cross virtual network and between real and
> On a completely unrelated topic, do you have any plans to support IPv6 in
> dnsmasq in the future ? eg things like DHCPv6, listen on IPv6 for DNS
> requests, and serving of AAAA records.
DHCPv6, no plans, at least for the time being. The other two features
are already there, and have been for many years.
[Date Prev][Date Next] [Thread Prev][Thread Next]