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

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

2013/2/25 Laine Stump <laine laine org>
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 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,,,,1440m
>> # subnet for VMs on server1
>> dhcp-range=set:vmlan1,,,,1440m
>> # default route (gateway)
>> dhcp-option=tag:phys,option:router,
>> dhcp-option=tag:vmlan1,option:router,
>> # DNS server
>> dhcp-option=6,
>> 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 redhat com
I thinks it's better that if we can put dnsmasq args or options in a conf file, so we can do some custom through this conf file.
I've added a Bug 913446 in redhat bugzilla,but seems no one take care of this bug? 

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