<div class="gmail_quote">2013/2/28 Laine Stump <<a href="mailto:laine@laine.org" target="_blank">laine@laine.org</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">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? </div>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: <a href="http://libvirt.org/drvqemu.html#qemucommand" target="_blank">http://libvirt.org/drvqemu.html#qemucommand</a> 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.)</blockquote><div>I 'd better like 2nd solution,because as time goes by,people may need to use</div><div> tons of different options of dnsmasq to meet new requirments. </div> </div>