The problemImagine you want to test something in a demo setup with 5 machines. You create the necessary VMs in your local KVM/libvirt environment – but you cannot address them properly by name. With 5 machines you also need to write down the appropriate IP addresses – that’s hardly practical. It is possible to create static entries in the libvirt network configuration – however, that is still very inflexible, difficult to automate and only works for name resolution inside the libvirt environment. When you want to ssh into a running VM from the host, you again have to look up the IP. Name resolution in the host network would be possible by adding each entry to
/etc/hostsadditionally. But that would require the management of two lists at the same time. Not automated, far from dynamic, and very ponderous.
The solutionLuckily, there is an elegant solution: libvirt comes with its own in-build DNS server, dnsmasq. Configured properly, that can be used to serve DHCP and DNS to servers respecting a previous defined domain. Additionally, NetworkManager can be configured to use its own dnsmasq instance to resolve DNS entries – forwarding requests to the libvirt instance if needed. That way, the only thing which has to be done is setting a proper host name inside the VMs. Everything else just works out of the box (with a recently Linux, see below). The solution presented here is based on great post from Dominic Cleal.
Configuring libvirtFirst of all, libvirt needs to be configured. Given that the network “default” is assigned to the relevant VMs, the configuration should look like this:
$ sudo virsh net-dumpxml default <network connections='1'> <name>default</name> <uuid>158880c3-9adb-4a44-ab51-d0bc1c18cddc</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:fa:cb:e5'/> <domain name='qxyz.de' localOnly='yes'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.128' end='192.168.122.254'/> </dhcp> </ip> </network>The interesting part is below the mac address: a local domain is defined and marked as
localOnly. That domain will be the authoritative domain for the relevant VMs, and libvirt will configure dnsmasq to act as a resolver for that domain. The attribute makes sure that DNS requests regarding that domain will never be forwarded upstream. This is important to avoid loop holes.
Configuring the VM guestsWhen the domain is set, the guests inside the VMs need to be defined. With recent Linux releases this is as simple as setting the host name:
$ sudo hostnamectl set-hostname neon.qxyz.deThere is no need to enter the host name anywhere else: the command above takes care of that. And the default configuration of DHCP clients of recent Linux releases sends this hostname together with the DHCP request – dnsmasq picks the host name automatically up if the domain matches. If you are on a Linux where the
hostnamectlcommand does not work, or where the DHCP client does send the host name with the request – switch to a recent version of Fedora or RHEL In such cases the host name must be set manually, according to the documentation of the OS. Just ensure that the resolution of the name works locally. Also, the DHCP configuration must be altered to send along the host name. In older RHEL and Fedora versions for example the option
had to be added to
/etc/sysconfig/network-scripts/ifcfg-eth0. At this point automatic name resolution between VMs should already work after a restart of libvirt.
Configuring NetworkManagerThe last missing piece is the configuration of the actual KVM/libvirt host, so that the local domain, here
qxyz.de, is properly resolved. Adding another name server to
/etc/resolv.confmight work for a workstation with a fixed network connection, but certainly does not work for laptops which have changing network connections and DNS servers all the time. In such cases, the NetworkManager is often used anyway so we take advantage of its capabilities. First of all, NetworkManager needs to start its own version of dnsmasq. That can be achieved with a simple configuration option:
$ cat /etc/NetworkManager/conf.d/localdns.conf [main] dns=dnsmasqThis second dnsmasq instance just works out of the box. All DNS requests will automatically be forwarded to DNS servers acquired by NetworkManager via DHCP, for example. The only notable difference is that the entry in
# Generated by NetworkManager search whatever nameserver 127.0.0.1Now as a second step the second dnsmasq instance needs to know that for all requests regarding qxyz.de the libvirt dnsmasq instance has to be queried. This can be achieved with another rather simple configuration option, given the domain and the IP from the libvirt network configuration at the top of this blog post:
$ cat /etc/NetworkManager/dnsmasq.d/libvirt_dnsmasq.conf server=/qxyz.de/192.168.122.1And that’s it, already. Restart NetworkManager and everything should be working fine. As a side node: if the attribute
localOnlywould not have been set in the libvirt network configuration, queries for unknown qxyz.de entries would be forwarded from the libvirt dnsmasq to the NetworkManager dnsmasq – which would again forward them to the libvirt dnsmasq, and so on. That would quickly overload your dnsmasq servers, resulting in error messages:
dnsmasq: Maximum number of concurrent DNS queries reached (max: 150)
SummaryWith these rather few and simple changes a local domain is established for both guest and host, making it easy to resolve their names everywhere. There is no need to maintain one or even two lists of static IP entries, everything is done automatically. For me this is a huge relief, making it much easier in the future to set up demo and test environments. Also, it looks much nicer during a demo if you have FQDNs and not IP addresses. I can only recommend this setup to everyone who often uses libvirt/KVM on a local machine for test/demo environments.
Filed under: Debian & Ubuntu, Fedora & RHEL, HowTo, Linux, Shell, SUSE, Technology, Virtualization