Lead Image © orangeline, 123RF.com

Udev with virtual machines

Technical Knockout

Article from ADMIN 17/2013

By Martin Braun

For many cloud admins, the kernel's udev system and associated rules equate to infinite renumbering of network interfaces and manual adjustment. We show how to keep on top of these tasks without deleting system files en masse.

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.