Bug 502847 - RFE: network: find a way to make VM hostnames resolvable from the host, out of the box
RFE: network: find a way to make VM hostnames resolvable from the host, out o...
Status: CLOSED DUPLICATE of bug 1325996
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
All Linux
low Severity medium
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks: libvirtTodoNetwork
  Show dependency treegraph
 
Reported: 2009-05-27 09:32 EDT by Stephen Gallagher
Modified: 2017-01-04 09:53 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-04 09:53:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen Gallagher 2009-05-27 09:32:51 EDT
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):
python-virtinst-0.400.3-8.fc11.noarch

How reproducible:
Every time

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
  
Actual results:
Unknown host 


Expected results:
Ping response from the guest


Additional info:
Comment 1 Cole Robinson 2009-06-15 13:54:21 EDT
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.
Comment 2 Pavel Šimerda (pavlix) 2011-07-01 18:49:14 EDT
„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.
Comment 3 Michal Privoznik 2015-02-04 06:55:28 EST
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).
Comment 4 Tomáš Hozza 2015-02-04 08:33:47 EST
(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
> 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).

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.
Comment 5 Michal Privoznik 2017-01-04 09:53:11 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.