Red Hat Bugzilla – Bug 502847
RFE: network: find a way to make VM hostnames resolvable from the host, out of the box
Last modified: 2017-01-04 09:53:11 EST
Description of problem:
VM hosts provide DHCP services to the guest machines through dnsmasq. It would be very handy for the host machine to automatically update the Network Manager configuration such that 192.168.122.1 (or appropriate equivalent) is included in /etc/resolv.conf so that it is easy to access the guests by hostname.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a guest of any kind with virtio networking
2. From the host, attempt to ping the hostname of the guest
Ping response from the guest
I don't have any idea about if this would be implemented or a more acceptable way of achieving the desired result, but this should be against libvirt.
„but this should be against libvirt.“
I don't think this should be against libvirt. The reason is it is in no way specific to virtualization.
The usual way with NetworkManager is to configure /etc/resolv.conf and let the apps use it for resolving.
But, there's a common alternative (currently used e.g. in OpenWRT routers). When dnsmasq is used, NetworkManager could instruct dnsmasq instead of writing /etc/resolv.conf (or possibly write a resolv.conf to an alternate location) and put localhost into /etc/resolv.conf.
Virtualized hosts are only one good reason for this. Another is when you want to use e.g. DNSSEC validation on localhost. Local apps would better listen to the validating nameserver then.
This is not even specific to dnsmasq. This feature request applies directly to NetworkManager and its DNS handling.
What can be done on libvirt side is to pass dnsmasq --resolv-file /path/to/file argument so that dnsmasq dumps guest entries into the file. However, I'm not sure libvirt should touch the resolv.conf file in any way. It will have to make sure no loop will ever occur which falls out of its scope.
As a workaround, if libvirt is learnt to run dnsmasq in desired way, users can use network hooks to alter the resolv.conf (if they are confident enough).
(In reply to Michal Privoznik from comment #3)
> What can be done on libvirt side is to pass dnsmasq --resolv-file
> /path/to/file argument so that dnsmasq dumps guest entries into the file.
> However, I'm not sure libvirt should touch the resolv.conf file in any way.
> It will have to make sure no loop will ever occur which falls out of its
> As a workaround, if libvirt is learnt to run dnsmasq in desired way, users
> can use network hooks to alter the resolv.conf (if they are confident
I think it would be better idea to work with NM developers, to be able to configure something like forward zone in NM. e.g. specify domain (*.local) to be forwarded to libvirt's dnsmasq instance. Other tools like dnssec-trigger then could fetch such configuration from NM.
With emerging changes in Fedora (local DNS resolver - unbound + dnssec-trigger) will result in 127.0.0.1 being added into resolv.conf. Also there are other new network daemons like systemd-resolved, systemd-networkd that are already in Fedora but not yet used.
This situation asks for well designed solution rather than hacking /etc/resolv.conf. The less daemons touch that file, the better IMHO.
I think this one is fixed. I've implemented nss plugin for libvirt a while ago. That way /etc/resolv.conf is not mangled and 'ping $myVM' works just fine. For more info see bug 1325996. Meanwhile, I am closing this one.
*** This bug has been marked as a duplicate of bug 1325996 ***