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(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. >> -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On 02/25/2013 09:08 PM, Gao Yongwei wrote: > > 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? This has been discussed extensively on the list before, and we specifically *don't* want to do it. Gene Czarcinski even submitted a patch that would do it, and that patch was rejected (and I *think* he agreed with our reasoning :-) The problem is that when you allow a user to silently subvert the config that is shown in libvirt's XML, and the system stops working, the user will send a plea for help to irc/mailing list (or open a ticket with their Linux support vendor), and the people they ask for support will say "show us the output of 'virsh net-dumpxml mynetwork'", which they will send, and then a comedy of errors will ensue until someone finally realizes that there is some "extra" configuration that the user isn't telling us about. There are two solutions to that: 1) add an element for the specific option you want to control in libvirt's network XML. Some knobs are already there, and others are being added. 2) add a private "dnsmasq" namespace to libvirt's network xml, with provisions for directly passing through dnsmasq commandline options from the xml to the conf file. This would be similar to what has already been done for qemu: http://libvirt.org/drvqemu.html#qemucommand The difference between these and the idea of simply allowing a user-written conf file is that everything about the network's config would then be available in "virsh net-dumpxml $netname". As far as the bug you've filed, it takes awhile for bugs to be triaged. (At a first glance, it seems reasonable to add such an option, since it is a standard part of the dhcp protocol. We might need to do something about specifying different units for the lease time.)