Linux-VMs mit geänderter virtueller Netzwerkkarte erhalten neue MAC-Adresse

Gebloggt: Virtuelle Netzwerkkarte reaktivieren

| Redakteur: Thomas Drilling

Drillings Open-Source-Eck
Drillings Open-Source-Eck (Bild: Thomas Drilling)

Bei einem Kunden hatte ich im Zusammenhang mit dem Thema Virtualisierung neulich folgenden Problem. Der Kunde betreibt einen auf Debian basierenden Univention Corporate Server in einer virtuellen Maschine unter KVM. Nach dem Austausch der virtuellen Netzwerkkarte bootete das Sytsme gänzlich ohne Ethernet-Device und kannte nur noch das Loopback-Gerät.

Nach den Tauschen der virtuellen Netzwerkkarte der virtuelle Maschine bindet z.B. Debian die neue Netzwerkkarte nicht wieder unter der bisherigen Bezeichnung, z.B: "eth0“ ein. Das gleiche Phänomen ereignet sich auch bei einer V2V-Migration, z.B. von VirtualBox auf KVM oder VMware, bzw. wenn man den Netzwerkkarten-Typ von Legacy auf virtio ändert.

Dass damit keine Netzwerkdienste mehr zur Verfügung stehen,  ist bei einem Server sagen wir mal "suboptimal". Bei einem Univention Corporate Server beispielsweise funktioniert dann kaum noch ein Dienst sinnvoll und auch die webbbasierte Administrationsoberfläche ist dann nicht mehr verfügbar.

Das Verhalten ist eigentlich plausibel und die Lösung liegt nahe. Man loggt sich lokal an der Konsole ein, sucht in den Log-Dateien der VM nach der zuvor verwendeten MAC-Adresse und trägt diese Host-seitig beim verwendeten Netzwerk-Interface ein. Ansonsten erzeugen Virtualisierungs-Manager wie Virt Manager oder VMware Player die MAC-Adresse bei einem neuen Netzwerkinterface generisch.

Noch einfacher ist allerdings folgender Tipp: Bei aktuellen Linux-Distributionen erfolgt die Zuordnung der Netzwerkkarte an eine physische Hardwareadresse in der Datei /etc/udev/rules.d/70-persistent-net.rules. Durch einfaches Löschen bringt man Linux dazu, die Konfiguration beim nächsten Systemstart einfach neu zu erzeugen. Debian generiert dann eine neue /etc/udev/rules.d/70-persistent-net.rules auf Basis der neuen MAC-Adresse(n) und verfügt dann automatisch wieder über ein eth0-Device.

PS: Bekanntlich kann ein Univention Corporate Server auch selbst als Xen- oder KVM-Virtualisierungs-Host dienen. Alles was man z.B. über das Einrichten virtueller Netzwerkkarten wissen muss, findet sich in der  Univention-Doku. Das ist aber ein komplett anderes Thema und hat mit o.g. Sachverhalt nichts zu tun. Wollte nur noch mal auf die Vielseitigkeit von UCS hinweisen.