Re: [Dnsmasq-discuss] Chaining instances?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]