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:
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
On 02/24/2013 05:09 AM, TJ wrote: directly in libvirt, but you may want to contact libvirt's upstream developers (at libvir-list@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.