Vorhersagbare Netzwerkschnittstellennamen unterbrechen die VM-Migration

Wie werden Sie zurückgesetzt, /etc/networking/interfaceswenn Sie "vorhersehbare Netzwerkschnittstellennamen" verwenden?

Ubuntu-Versionen älter als 15.10 verwenden Netzwerkadapternamen wie:

• eth0
• eth1
• eth2

Das Ersetzen einer Netzwerkkarte oder das Verschieben einer VM auf einen neuen Hypervisor würde dazu führen, dass Linux die Schnittstellennummer erhöht. Durch das Löschen /etc/udev/rules.d/70-peristent-net.ruleswürde Linux wiederverwendet eth0.

Ubuntu 15.10 und höher verwenden ' Vorhersagbare Netzwerkschnittstellennamen '. Der Name des Netzwerkadapters wird von der Mac-Adresse abgeleitet.

• ens3
• ens32
• ens192

Bei der Migration einer VM wird das Netzwerk nicht gestartet, da /etc/network/interfacesimmer noch auf den alten nicht vorhandenen Netzwerkadapter verwiesen wird.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens32
iface ens32 inet dhcp
pre-up sleep 2

Wie kann die Datei / etc / network / interfaces am besten zurückgesetzt werden?

Ich muss diese Aktion ausführen, bevor ich die VM herunterfahre und auf einen neuen Hypervisor migriere, da ich Packer verwende , um automatisierte goldene Bilder basierend auf den goldenen Bildern des Küchenchefs / Bento zu erstellen.

Ich habe festgestellt, dass das Löschen von / etc / network / interfaces nicht funktioniert, da die Datei beim nächsten Start nach der Migration nicht automatisch neu generiert wird.

Ich habe versucht, meine Grub-Datei zu bearbeiten, um zur Namenskonvention 'eth0' zurückzukehren. Während sich / etc / network / interfaces auf den alten Namen (eth0) bezieht, erhält die VM keine IP und bei Neustarts verwendet die VM die neue Namenskonvention. Außerdem habe ich festgestellt, dass systemd immer Vorrang hat, es sei denn, ich kann garantieren, dass es biosdevname=0 dauerhaft in der grub-Konfiguration bleibt . Ich bin mir nicht sicher, wie ich das dauerhaft anwenden soll

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 bios.devname=0"

Wenn möglich, würde ich lieber keine Cloud-Init oder Skripte nach dem Start verwenden, da ich die goldenen Bilder lieber so sauber wie möglich halten möchte.

Dies ist sicherlich ein Problem, das Cloud-Anbieter (Azure, AWS, RackSpace, Openstack) bereits beim Importieren von VMs gelöst haben. Ich kann unmöglich die erste Person sein, die versucht, eine VM mit vorhersehbaren Netzwerkschnittstellennamen zu migrieren.

Ich habe versucht, diese Befehle auszuführen, bevor ich die VM heruntergefahren und migriert habe

apt-get remove biosdevname -y;
ln -s /dev/null /etc/systemd/network/99-default.link;

Ich finde, wenn ich die VM migriere, das /etc/network/interfacesund ip addressverweise immer noch aufens32

Dies ist sicherlich ein Problem, das Cloud-Anbieter (Azure, AWS, RackSpace, Openstack) bereits beim Importieren von VMs gelöst haben.

Ich denke, OpenStack verwendet Cloud-Init im ConfigDrive-Format und bietet eine Netzwerkkonfiguration, die der VM-Hardware entspricht. Quellen:

• https://bugs.launchpad.net/cloud-init/+bug/1577747
• https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html?highlight=configdrive
• https://ask.openstack.org/de/question/63105/ways-to-inject-networking-configuration-on-instance-boot/
• https://access.redhat.com/documentation/de/red-hat-enterprise-linux-atomic-host/version-7/installation-and-configuration-guide/#setting_up_cloud_init

Wenn Sie ein First-Boot-Skript ausschließen, gibt es eine offensichtliche Antwort.

Bisher war praktisch garantiert, dass Hosts, die mit einer einzigen Ethernet-Karte ausgestattet waren, nur eine einzige "eth0" -Schnittstelle hatten. Mit diesem neuen Schema muss ein Administrator nun zuerst den Namen der lokalen Schnittstelle überprüfen, bevor er Befehle darauf aufrufen kann, bei denen er zuvor eine gute Chance hatte, dass "eth0" der richtige Name war.

Ich mag das nicht, wie deaktiviere ich das?

Sie haben grundsätzlich drei Möglichkeiten:

1. Sie deaktivieren die Zuweisung fester Namen, damit die unvorhersehbaren Kernelnamen erneut verwendet werden. Maskieren Sie dazu einfach die .link-Datei von udev für die Standardrichtlinie: ln -s / dev / null /etc/systemd/network/99-default.link

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Das Zurückschalten auf die alten persistenten Schnittstellennamen ist keine der dokumentierten Optionen.

Die andere Alternative ist ein Setup, bei dem Netzwerkschnittstellen unabhängig von ihrem genauen Namen standardmäßig aktiviert sind. Ich denke, NetworkManager unterstützt dies standardmäßig. systemd-networkd kann auch dazu aufgefordert werden .

Sobald Sie mehr als ein Netzwerkgerät für eine VM haben, benötigen diese wahrscheinlich ohnehin eine bestimmte Konfiguration ...

Außerhalb von VMs gibt es einen offensichtlichen Vorteil des NetworkManager-Ansatzes: Ein PC verfügt möglicherweise über mehrere Netzwerkschnittstellen, möglicherweise unterschiedlicher Art, von denen nur eine verbunden ist. Dies kann beispielsweise auf einigen Premium-Motherboards oder auf einem System beobachtet werden, auf dem die erste Netzwerkschnittstelle nicht wie gewünscht funktioniert hat und irgendwann eine zweite Schnittstelle installiert wurde.

Ich gab es auf, dies sauber zu machen, und fand den folgenden Hack. Wenn Sie das folgende Skript ausführen, bevor Sie die VM herunterfahren und migrieren, hat die VM beim Einschalten eth0 als Netzwerkadapter.

ln -s /dev/null /etc/systemd/network/99-default.link;
echo '# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp
pre-up sleep 2' > /etc/network/interfaces

sed -i.bak 's/GRUB_CMDLINE_LINUX_DEFAULT=.*/GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 bios.devname=0 quiet"/' /etc/default/grub
update-grub
apt-get remove biosdevname -y || true;

Genau genommen apt-get remove biosdevnameist dies nicht erforderlich, da dieses Paket unter Ubuntu 16.04 nicht standardmäßig installiert ist. Außerdem ist das Hinzufügen bios.devname=0zum GRUB_CMDLINE_LINUX_DEFAULTnicht erforderlich, da biosdevname nicht installiert ist. Es verhindert, dass das Netzwerk unterbrochen wird, wenn biosdevname jemals in der Zukunft installiert wird.

Benötigen Sie vorhersehbare Netzwerkschnittstellennamen?

Meine Lösung war die Deinstallation biosdevname, und das hat zuverlässig dazu geführt, dass immer Netzwerkschnittstellen mit den Namen eth0, eth1 usw. vorhanden waren. Ich habe keinen guten Grund gefunden, vorhersehbare Netzwerkschnittstellennamen oder Biosdevnamen zu installieren.

In /etc/udev/rules.d/70-persistent-net.ruleskönnen Sie ändern, welche Hardware-Mac-Adresse in eth0, eth1 usw. benannt wird. Normalerweise lösche ich den Inhalt dieser Datei, speichere sie als leere Datei, starte neu und habe dann einen sauberen Slate mit den richtigen Netzwerkadaptern ...

# This file was automatically generated by the /lib/udev/write_net_rules
# program,run by the persistent-net-generator.rules rules file.
#
# This file was automatically generated by the /lib/udev/write_net_rules
# program,run by the persistent-net-generator.rules rules file.
#
# You can modify it,as long as you keep each rule on a single
# line,and change only the value of the NAME= key.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

^^ wobei xx: xx: xx: xx: xx: xx die eindeutige Mac-Adresse Ihrer Netzwerkadapter ist.

Ich weiß, dass Sie erwähnen, dass das Löschen dieser Datei nicht die Lösung ist, aber ich poste das obige Beispiel, weil zumindest in Suse /lib/udev/write_net_rulesdiese Datei erstellt wird. Sehen Sie also nach, ob die Rückverfolgung dieser Datei hilfreich ist. Wenn sie für Ihre Distribution gilt, können Sie sie möglicherweise ändern, um Ihr Problem zu lösen.

Beachten Sie, dass dies das ist, was ich aus Suse Version 11 kenne, die der alte Init-Weg vor systemd ist. Ich bin mir nicht sicher, ob sich dies für die neuesten Linux-Versionen unter systemd geändert hat.

Bin auf dieses Upgrade von Ubuntu 14.04 Hosts auf 16.04 gestoßen. biosdevnamePaket nicht installiert ist, so zurückgegriffen "biosdevname=0 net.ifnames=0"in /etc/default.grubwie OP angegeben.

Ich führe dieses Skript aus, und wenn die Ausgabe gut aussieht, leiten Sie die Ausgabe /etc/udev/rules.d/70-persistent-net.rulesum, um neue udev-Regeln zu erstellen, falls der Kernel jemals beschließt, die Ethernet-Ports in einer anderen Reihenfolge aufzulisten.

#!/bin/bash
count=0

# build array of network devices starting with eth? from /proc
for dev in `cat /proc/net/dev | egrep 'eth.*:' | awk '{print $1};' | cut -d':' -f1 | sort`; do
   edev[$count]="$dev"
   let count="$count+1"
done

# use array to find mac address
for d in ${edev[@]}; do
   mac=`ip addr show "$d" | grep ether | awk '{print $2};'`
   if [ -n "$mac" ]; then
      echo "# mac for $d is $mac"
   fi 

   printf 'SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="%s", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="%s"\n' $mac $d
done