+++ This bug was initially created as a clone of Bug #637055 +++ Description of problem: Currently libvirtd runs dnsmasq without setting domain or giving possibility to specify domain search list. This makes DHCP NAT networking unfriendly as host "appserver" won't get resolved, one needs to use FQDN "appserver.a.example.com". In many customer environments there are scripts, applications, and services which depend on properly specified domain search list. Killing the libvirtd instance started by dnsmasq and running the same command manually but also using a proper configuration file solves this issue. It would be very helpful if either the configuration file could be specified in the network XML file or the related options could be added to XML directly. The following dnsmasq options would be most needed: expand-hosts domain=a.example.com dhcp-option=119,"a.example.com b.example.com example.com"
Since someone has added themselves to the Cc list, indicating interest, I thought I should copy the following comment over from the RHEL6 version of the bug (Bug 637055): Note that this option: domain=a.example.com is added to the dnsmasq configuration whenever the line: <domain name='a.example.com'/> is put in the network definition XML. This feature has been present since libvirt version 0.4.5, so it is already in RHEL6.0. the "expand-hosts' option has also been present since libvirt 0.9.3 (it is always added, without need for any extra configuration option). That leaves only: dhcp-option=119,"a.example.com b.example.com example.com" to be implemented.
My suggestion would be an addition to libvirt's networking <dhcp> configuration along the lines of: <option code="123" value="something"/> which translates into the dnsmasq command line parameter: --dhcp-option=123,"something"
Yes, and there are patches that were *almost* in the last upstream release (1..0.3) to do exactly that. However, to make the XML more compatible with a further extension to recognize names and properly validate those options that can take multiple values, we decided we need to rework it to be something like: <option code='119'> <value type='domain' data='a.example.com'/> <value type='domain' data='b.example.com'/> <value type='domain' data='c.example.com'/> </option> Discussion is ongoing upstream, and something will definitely be in the next upstream release (1.0.4). Here's a message I just posted to hopefully arrive at a proper XML that won't come back later to bite us: https://www.redhat.com/archives/libvir-list/2013-March/msg00166.html Thanks for posting to this long-dormant BZ to remind me of its existence!
Doesn't appear those patches ever went upstream. Laine, were the patches rejected or just forgotten?
*** Bug 683516 has been marked as a duplicate of this bug. ***
I never got beyond the stage of proposing something that (if implemented) would hopefully stand the test of time / new options / different dhcp implementations, but it was too complicated and not high enough priority, so that's as far as I ever got :-(
Honestly, given the realistic possibility that libvirt will _never_ support another comprehensive network driver besides bridge_driver.c, maybe we just side step the whole question and add a new xmlns similar to what we did with qemu that allows dnsmasq specific dhcp-option passthrough. So something like <dnsmasq:commandline> <dnsmasq:dhcpOption code=XXX value='some big string'/> </dnsmasq:commandline> Or even simpler and more powerful, full qemu style <dnsmasq:arg value='XXX'/>
Repurposing this but to track generically specifying dhcp-option, since there's other bugs in that vein too
*** Bug 1033171 has been marked as a duplicate of this bug. ***
Bug 824573 is the one the details the discussion of adding nice/tidy support for the options. It's odd that I don't even remember creating this BZ, but here it is :-/. I think that for a large number of common options, we could easily add something specific as outlined in But 824573, which would be easier for users to understand. But as a catchall for the strange things, someone could certainly add commandline passthrough as we did for qemu. (No, I'm not volunteering :-)
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.
For any spelunkers coming across this BZ in the future - similar (but not "officially" supported) functionality was added to libvirt awhile back - the <dnsmasq:options> element in the network XML (documented here: https://libvirt.org/formatnetwork.html#elementsNamespaces ) allows adding arbitrary options to the dns masq config file for a network.