Quoting Laine Stump (laine@xxxxxxxxx): > On 12/02/2015 02:50 PM, Serge Hallyn wrote: > >Some people want to define a libvirt network but have dns served > >by another daemon. Libvirt used to support that, but hasn't for > >several years. Two long-open bugs on this are > > > >https://bugzilla.redhat.com/show_bug.cgi?id=636115 > >https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/584862 > > > >I'm not certain whether we really want to support this, as another > >option is to simply create the bridge with external tools and tell > >libvirt vms to use that bridge. However, if we do want to support > >it, this patch provides that support. > > > >This patch allows an admin to set <nodnsmasq>true</nodnsmasq> in a > >bridge definition to avoid having libvirt start a dnsmasq. > > Actually someone asked about making an option for this a long time > ago, and I made a suggestion on how to do it, but neither I nor the > person who asked ever got around to doing it. > > First, about your proposal: I think that allowing a user to > completely disable everything done by dnsmasq (i.e. DHCP and DNS > services) is something reasonable for us to support. The option that > you've defined gets the job done, but it is specific to a backend > implementation that uses dnsmasq, and we want to avoid that in case > someone in the future makes a different implementation that uses > something else for dhcp and/or dns > > When there is no <dhcp> element in a network, the dhcp part of > dnsmasq already isn't enabled (so dnsmasq isn't listening on the > dhcp port), but the dns server is always enabled and listening on > port 53. It makes sense that we should be able to disable the DNS > server regardless of whether or not we are using dnsmasq's dhcp > server. If both are disabled, then dnsmasq simply wouldn't be > started (after it's not listening on any ports, so there's no point > :-). > > There is already a <dns> element in a network definition, so the > logical place for the option that enables/disables DNS would be as > an attribute to that element: > > <dns enable='no'/> Yup, that does make more sense. I can aim to send a patch along those lines, but I'm particularly un-familiar with the xml parsing code so if someone else wants to do it i won't feel my toes being stepped on :) > So if there is no enable attribute (or if it is set to "yes"), DNS > is turned on. If enable='no', then it is turned off. If dhcp is > enabled for the network, then dnsmasq would still be started up for > that, but would get the proper options so it didn't listen for DNS > requests. > > A couple notes: > > * For backward compatibility, we have to have the default be that > DNS is enabled. > * yes/no is much more commonly used in libvirt's XML than > true/false, so that is the preferred setting (there is an enum for > that, virTristateBool, so you can use > virTristateBoolType(To|From)String when parsing (be sure to reject > if the return value of *FromString() is <= 0, so nobody can enter > "enable='default'"). Ok, thanks -serge -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list