1:05 a.m.
This discussion should really be taking place on libvir-list - I'm
Cc'ing it there.
On 02/24/2013 04:11 PM, TJ wrote:
On 24/02/13 19:19, Laine Stump wrote:
> On 02/24/2013 05:09 AM, TJ wrote:
>> I wondered if maybe configuring the libvirtd dnsmasq instances to be dhcp proxies
for the LAN dnsmasq, and use multiple dhcp-range's with tags might do it?
>>
>> My brain is a bit fried right now having had to fix several bugs in vmbuilder and
libvirt, plus add new functionality to libvirtd to allow its dnsmasq instance to read a
conf-file and use a separate log-facility,
> What you're talking about doing sounds *very* useful to have supported
> directly in libvirt, but you may want to contact libvirt's upstream
> developers (at libvir-list(a)redhat.com, or on irc.oftc.net in #virt)
> prior to expending a lot of effort on libvirt code - in general a
> problem may already be solved in a different manner, or somebody else
> may already be working on it. Failing that, there may have already been
> considerable debate on a particular subject, and a path to a solution
> generally agreed on, but with nobody yet working on the code.
It turns out that what I need(ed) to do was completely *disable* libvirt's use of
dnsmasq
and instead use Simon's related "dhcp-helper" program which acts as a full
dhcp-relay using, f.e:
/usr/sbin/dhcp-helper -u libvirt-dnsmasq -i virbr1 -b eth0
This forwards all requests to the primary dnsmasq DHCP server on the LAN which matches
against the
appropriate dhcp-range:
# physical network leases
dhcp-range=set:phys,10.254.251.50,10.254.251.199,255.255.255.0,1440m
# subnet for VMs on server1
dhcp-range=set:vmlan1,10.254.1.100,10.254.1.199,255.255.255.0,1440m
# default route (gateway)
dhcp-option=tag:phys,option:router,10.254.251.1
dhcp-option=tag:vmlan1,option:router,10.254.1.1
# DNS server
dhcp-option=6,10.254.251.1
To that end this evening I added two additional options to libvirt:
<dnsmasq enabled='true'/>
<dhcphelper enabled='false'/>
libvirt's XML should remain implementation-agnostic. We don't want to
have an option to disable the specific implementation of dns+dhcp called
"dnsmasq"; rather we want to be able to enable/disable a network's dhcp
server and/or dns server. (The reason for this is that we want to leave
the door open for someone to implement a different backend using a
different dhcp server and/or dns server and be able to use the same
configuration.)
We have actually previously discussed disabling dns and/or dhcp (see
http://www.redhat.com/archives/libvir-list/2012-November/msg00861.html).
It is already possible to completely disable dhcp - simply don't include
a <dhcp> element in the network definition. As for dns, from the very
beginning dns has been *always* enabled on all networks, so even though
there is a <dns> element, simply having not having one is not a valid
way to say "no dns server" (as it would cause backward compatibility
problems with existing installations).
Instead, the conclusion of the above-mentioned thread was that the
proper way to handle this would be to add an "enable" element to the
existing <dns> element, which would default to "yes". To disable
libvirt-supplied dns services for a subnet, you would just put:
<dns enable='no'/>
in the network definition. In the case that dns had enable='no' AND
there was no <dhcp> element, dnsmasq simply wouldn't be started at all.
That hasn't been implemented yet, but shouldn't be too complex to do.
As for dhcp-helper, aside from the fact that again you've created an
option that is specific to a particular implementation of what is
needed, that command isn't universally available anyway (it's not in any
package for Fedora/RHEL, for example), and I'm not sure that it's really
necessary to have it started up by libvirt anyway - can it detect newly
created/upped interfaces as dnsmasq can? If so, it could be started up
by regular host system config even before libvirt was started.
These are the default values when the options are *not* defined. They allow the admin to
disable dnsmasq entirely:
<dnsmasq enabled='false'/>
and to enable dhcp-helper:
<dhcphelper enabled='true'/>
Using two new functions:
int networkBuildDhcphelperArgv(...)
int networkBuildDhcpHelperCommandLine(...)
the existing function:
int networkStartDhcpDaemon(...)
is able to launch either or both of dnsmasq and dhcp-helper with the correct options.
dhcp-helper's "-i" option is filled from network->def->bridge and its
"-b" option is taken from
the first forward device declared in a <forward dev='?'/> or <interface
dev='?'/>. If no forward
device is declared it throws a VIR_ERR_INVALID_INTERFACE error with appropriate
explanatory text.