[libvirt] [Dnsmasq-discuss] Chaining instances?

Gao Yongwei itxx00 at gmail.com
Tue Feb 26 02:08:32 UTC 2013


2013/2/25 Laine Stump <laine at 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 at 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.
> >>
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130226/353a0abe/attachment-0001.htm>


More information about the libvir-list mailing list