Any admin who has ever cloned a virtual SUSE system has probably encountered the following issue: The newly cloned VM hangs when booting and waits for the default devices (Figure 1). At the end of the extended boot procedure, the configured network interface (NIC) eth0 on the original has mutated into a NIC named eth1, and the numbers of other NICs have been increased by one. A similar thing happens with almost all other Linux distributions, and the problem is independent of the hypervisor. Thus, the clone loses its network configuration, and you have to revise it manually at the console.

Figure 1: A cloned SLES waiting for devices while booting.

The blame is quickly placed on udev, but the udev device manager is actually doing its job. During the kernel's hardware detection phase, udev loads all the modules asynchronously in no particular order. The process depends on several conditions – the PCI bus topology and the device drivers and the way they look for their hardware  – that can lead to infinitely changing device names. If, for example, eth0 and eth1 are reversed, the consequences can be serious depending on the system – from security problems to failure of central services.

Permanently Set

This situation thus leads to a requirement for persistent device names. Once they are established, network cards should retain their configuration permanently, regardless of whether more cards are added or taken away. Many distributions solve this requirement with udev using persistent net rules. They are found in the /etc/udev/rules.d directory and ensure consistent device naming by assigning names on the basis of the device's MAC address.

Problem: Virtualization

This solution causes problems in the cloud because, as a rule, a single Linux VM is cloned multiple times. Each new clone is assigned new virtual hardware, and VMware, libvirt, or the administrator generate new MAC addresses for the virtual NICs to avoid duplicate MAC addresses on the network. The new interfaces are given new names in ascending order because the original names are already reserved for other MAC addresses. This approach reveals a major drawback of this concept: An installed and configured Linux cannot be run on some other (virtual) hardware, because its configuration then also changes. The system administrator needs to set up the cloned system manually.

The often proposed and easy solution of deleting the 70-persistent-net.rules file before cloning is, unfortunately, not very sustainable. In many distributions, a new rule file is generated by a persistent net generator rule the next time you clone. Making your own changes to these rules in the /lib/udev directory is also less than useful – they are overwritten when you update the udev package. Table 1 shows the names and locations of the rules for different distributions.

When working with udev rules, please note that a race condition can occur between the kernel and udev rules if both attempt to assign eth*-type names: Who names the first network interface, the kernel or userspace? It is thus also advisable to use names different from eth* for the NICs in your own udev rules, such as net0 or wan1. As is often the case in the open source world, alternatives to the persistent network rules have been developed by different parties in different ways; I will look at them in more detail.

Dell's Solution

In a whitepaper [1], Dell describes a specially developed software package called biosdevname. This auxiliary tool for udev assigns device names according to where the hardware is located. This ensures consistent and meaningful names for your network cards at the same time: NICs on the motherboard start with a prefix of em, followed by the port number starting at one. PCI cards have the following naming scheme: p<Slotnumber>p<Portnumber>. Examples of this are em1 for the first internal interface and p4p1 for the first port on a network card in slot number 4.

The utility acquires the necessary information using the System Management BIOS Specification (SMBIOS [2]). This specification describes where the BIOS stores information on slots and network cards. If the BIOS does not support the corresponding entries, biosdevname resorts to the IRQ routing table.