Re: [libvirt] [Dnsmasq-discuss] Chaining instances?

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. >