On Fri, Sep 10, 2021 at 04:57:56PM +0200, Peter Boy wrote: > Hi all, > > I’m working on an update of the Fedora Server virtlib documentation (https://docs.fedoraproject.org/en-US/fedora-server/virtualization-install/), specifically the part about the DNS configration. > > I would like to include and integrate the solutions presented in this thread by Daniel Berrange and by Juan Alcaine. But unfortunately none of the solutions worked in my test installations. I would be grateful if I could get some hints on what I might have missed. > > The main challenge is to enable the host to resolve the internal name of the VMs. For this purpose, the DNS server provided by libvirt must be included in the search path (default virbr0 192.168.122.1). The server itself works fine. If you use dig or nsloookup to assign the servers, the names of the VMs are resolved correctly. > > > > (a) === Installing libvirt-nss. (Daniel Berrange) === > > I did the following > > 1. dnf install libvirt-nss > > 2. Modified following the libvirt documentation and the docs included with the files /etc/authselect/user-nsswitch.conf and edited the hosts item to "hosts: files myhostname libvirt resolve [!UNAVAIL=return] dns“ > > 3. executed: authselect apply-changes > > 4. reboot > > Neither using standard DNS without systems-resolved activated nor using systemd-resolved could resolve the internal names of the VM I think you possibly mis-interpret what the libvirt-nss module is going to be doing here. Applications on the host will use glibc APIs for resolving host names into IP addresses. GLibc will use the nsswitch config to determine what data sources to use for the host -> IP translation. Adding "libvirt" to the nsswitch config for "hosts:" simply tells GLibc to talk to the libvirt-nss module to try to resolve a hostname. This doesn't involve DNS at all. libvirt-nss will be queried before GLibc even gets to trying DNS. It also won't affect results reported by systemd-resolved AFAICT. You don't mention what VM configuration you're using for networking, but basically if you "virsh dumpxlm $guest", then the <interface> element *must* be configured for type=network. If it is using type=bridge or any other option, then the libvirt-nss module has no effect. Finally, libvirt-nss provides two modules. - "libvirt" does lookups against the hostname configured by the guest OS when acquiring its DHCP lease. This hostname is either set by the guest OS admin, or can be the hostname in the libvirt network XML config (virsh net-dumpxml default) if you're using fixed host<->ip<->mac mappings. - "libvirt_guest" does lookups against the guest name known to libvirt in the host. (ie name reported by 'virsh list') If you want to debug libvirt-nss problems there are two things to try "virsh domifaddr $GUEST" if that doesn't report any IP addresses, then the libvirt-nss module won't do anything. "virsh net-dhcp-leases default" will meanwhile report all IP addresses known the libvirt's dnsmasq instance currently - domifaddr is just filtering those to extract a specific guest. Personally I always use the "libvirt_guest" NSS module, so get host lookups using the libvirt guest name, but either NSS module is valid based on your desired outcome. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
