Bug 502847
| Summary: | RFE: network: find a way to make VM hostnames resolvable from the host, out of the box | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Stephen Gallagher <sgallagh> |
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | berrange, cra, crobinso, mprivozn, psimerda, thozza, xen-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-04 14:53:11 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 636029 | ||
|
Description
Stephen Gallagher
2009-05-27 13:32:51 UTC
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 > 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. 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 *** |