The system administrator needs to set up the cloned system manually. 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 new interfaces are given new names in ascending order because the original names are already reserved for other MAC addresses. 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. This solution causes problems in the cloud because, as a rule, a single Linux VM is cloned multiple times. 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. Many distributions solve this requirement with udev using persistent net rules. Once they are established, network cards should retain their configuration permanently, regardless of whether more cards are added or taken away. This situation thus leads to a requirement for persistent 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. 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. During the kernel's hardware detection phase, udev loads all the modules asynchronously in no particular order. The blame is quickly placed on udev, but the udev device manager is actually doing its job. Figure 1: A cloned SLES waiting for devices while booting.
0 kommentar(er)
