Udev mit virtuellen Maschinen

© Luciano De Polo, 123RF

Technisches K.O.

Für viele Cloud-Admins steht das Udev-System des Kernels und die zugehörigen Regeln für eine endlose Neunummerierung der Netzwerkschnittstellen und manuelle Anpassungen. Dass man auch ohne wildes Löschen von Systemdateien obenauf bleiben kann, zeigt dieser Artikel.
Der ADMIN 05/13 wirft einen Blick auf die frei verfügbaren Cloud-Frameworks von Eucalyptus über OpenNebula bis OpenStack. Gute Aussichten für skalierbare ... (mehr)

Das folgende Problem ist sicherlich jedem Administrator schon begegnet, der einmal ein virtuelles Suse-System geklont hat: Die frisch geklonte VM hängt beim Booten und wartet auf die Standard-Devices (Abbildung 1). Am Ende des verlängerten Bootvorgangs ist aus dem konfigurierten Netzwerk-Interface (NIC) »eth0« des Originals ein NIC mit Namen »eth1« geworden und die Nummern weiterer NICs wurden ebenfalls um eins erhöht. Ähnliches passiert bei nahezu allen anderen Linux-Distributionen und ist unabhängig vom eingesetzten Hypervisor. Damit verliert der Klon seine Netzwerk-Konfiguration, und man muss manuell über die Konsole nacharbeiten.

Abbildung 1: Ein geklonter SLES wartet beim Booten auf die Devices.

Den schwarzen Peter bekommt dabei schnell Udev zugeschoben. Der Udev-Geräteverwalter meint es dabei aber nur gut: Udev lädt während der Hardware-Erkennung des Kernels alle Module asynchron in unbestimmter Reihenfolge. Diese hängt von verschiedenen Bedingungen ab: der PCI-Bus-Topologie, den Gerätetreibern und der Art, wie diese nach ihrer Hardware suchen. Dabei kann es zu ständig wechselnden Gerätenamen kommen. Wenn nun zum Beispiel »eth0« und »eth1« vertauscht werden, kann das je nach System gravierende Auswirkungen haben: von Sicherheitsproblemen bis zum Ausfall zentraler Serverdienste.

Dauerhaft eingerichtet

Damit ergibt sich die Forderung nach persistenten Gerätenamen. Einmal eingerichtete Netzwerkkarten sollen ihre Konfiguration dauerhaft beibehalten, unabhängig davon, ob man weitere Karten hinzufügt oder wegnimmt. Viele Distributionen lösen diese Anforderung über Udev durch die sogenannten Persistent-Net-Regeln. Sie finden sich im Verzeichnis »/etc/udev/rules.d« und sorgen für eine gleichbleibende Benennung der Geräte durch eine Zuteilung der Namen aufgrund der MAC-Adresse eines Gerätes.

Problem: Virtualisierung

Diese Lösung bereitet in der Cloud Probleme, da eine einzelne Linux-VM in der Regel sehr oft geklont wird. Jeder neue Klon erhält neue virtuelle Hardware und VMware, Libvirt oder auch der Administrator generieren für die virtuellen Netzwerkkarten neue MAC-Adressen, um doppelte MAC-Adressen im Netzwerk zu vermeiden. Die neuen Schnittstellen erhalten neue Namen mit aufsteigender Nummerierung, da die ursprünglichen Namen schon für andere MAC-Adressen reserviert sind. Damit zeigt sich ein großer Nachteil dieses Konzeptes: ein installiertes und konfiguriertes Linux kann nicht mehr auf einer anderen (virtuellen) Hardware ausgeführt werden, denn es ändert sich dann auch dessen Konfiguration. Der Systemverwalter muss manuell das geklonte System einrichten.

Die oft vorgeschlagene und einfache Lösung, die Datei »70-persistent-net.rules« vor dem Klonen einfach zu löschen, ist leider nicht sehr nachhaltig: Bei vielen Distributionen wird beim nächsten Klon diese Regeldatei durch eine Persistent-Net-Generator-Regel neu erzeugt. Auch eigene Änderungen in diesen Regeln im Verzeichnis »/lib/udev« sind ungünstig – bei einem Update des Udev-Pakets werden sie überschrieben. Tabelle 1 zeigt die Namen und Speicherorte der Regeln bei unterschiedlichen Distributionen.

Tabelle 1

Udev-Speicherorte

Distribution

Pfad

Ubuntu 12.10, Debian 7.0, SLES 11 SP2

* /etc/udev/rules.d/70-persistent-net.rules* /lib/udev/rules.d/75-persistent-net-generator.rules

Open Suse, Red Hat 6

* /etc/udev/rules.d/70-persistent-net.rules* keine Net-Generator-Regeln seit 12.3. Stattdessen wird das Package »biosdevname« verwendet, um die NICs zu benennen.

Chakra Linux 2013.01

* /usr/lib/udev/rules.d/80-net-name-slot.rules* keine Net-Generator-Regeln, da Systemd v197

Bei der Arbeit mit Udev-Regeln ist zu beachten, dass es zu einem Wettlauf zwischen Kernel und den Udev-Rules kommen kann, wenn beide Namen der Form »eth*« vergeben wollen: Wer benennt zuerst das Netzwerk-Interface, der Kernel oder der Userspace? Daher wird auch empfohlen, für eigene Udev-Regeln den NICs andere Namen als »eth*« zu vergeben, wie zum Beispiel »net0« oder »wan1« . Wie so oft in der Open-Source-Welt werden Alternativen zu den Persistent-Net-Rules von verschiedenen Parteien auf unterschiedliche Weise entwickelt, auf die der Artikel im Folgenden näher eingeht.

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018