On 02/25/2013 02:05 AM, Laine Stump wrote: > This discussion should really be taking place on libvir-list - I'm > Cc'ing it there. Bah. I'm not sure what happened, but I ended up not actually Cc'ing... > > > 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@xxxxxxxxxx, 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. >> -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list