Przewidywalne nazwy interfejsów sieciowych przerywają migrację VM

Jak zresetować /etc/networking/interfacesprzy użyciu „przewidywalnych nazw interfejsów sieciowych”?

Wersje Ubuntu starsze niż 15.10 używają nazw kart sieciowych, takich jak:

• eth0
• eth1
• eth2

Zastąpienie karty sieciowej lub przeniesienie maszyny wirtualnej do nowego hiperwizora spowodowałoby, że Linux zwiększyłby numer interfejsu. Usunięcie /etc/udev/rules.d/70-peristent-net.rulesspowoduje ponowne użycie Linuksa eth0.

Ubuntu 15.10 i nowsze używają „ przewidywalnych nazw interfejsów sieciowych ”. Nazwa karty sieciowej pochodzi od adresu mac.

• ens3
• ens32
• ens192

Podczas migracji maszyny wirtualnej sieć nie rozpocznie się, ponieważ /etc/network/interfacesnadal odwołuje się do starej nieistniejącej karty sieciowej.

# 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

Jaki jest najlepszy sposób na zresetowanie pliku / etc / network / interfaces?

Muszę wykonać tę czynność przed wyłączeniem vm i migracją do nowego hiperwizora, ponieważ używam programu pakującego do tworzenia automatycznych złotych obrazów na podstawie złotych obrazów szefa kuchni / bento .

Odkryłem, że usunięcie / etc / network / interfaces nie działa, ponieważ plik nie jest automatycznie regenerowany przy następnym uruchomieniu po migracji.

Próbowałem edytować mój plik grub, aby powrócić do konwencji nazewnictwa „eth0”. Podczas gdy / etc / network / interfaces odnosi się do starej nazwy (eth0), vm nie otrzyma adresu IP, a jakiekolwiek ponowne uruchomienie spowoduje, że vm użyje nowej konwencji nazewnictwa. Przekonałem się również, że systemd zawsze będzie miał pierwszeństwo, chyba że mogę zagwarantować, że na biosdevname=0 stałe pozostanie w konfiguracji grub . Nie wiesz, jak zastosować to na stałe

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

Jeśli to możliwe, wolałbym nie używać inicjowania w chmurze ani żadnych skryptów po uruchomieniu, ponieważ wolę, aby złote obrazy były tak czyste, jak to możliwe.

Z pewnością jest to problem, który dostawcy chmury (Azure, AWS, RackSpace, Openstack) już rozwiązali podczas importowania vms. Nie mogę być pierwszą osobą, która próbuje migrować maszynę wirtualną przy użyciu przewidywalnych nazw interfejsów sieciowych.

Próbowałem uruchomić te polecenia przed zamknięciem i migracją VM

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

Znajduję, kiedy migruję vm, /etc/network/interfacesi ip addressnadal się odwołujęens32

Z pewnością jest to problem, który dostawcy chmury (Azure, AWS, RackSpace, Openstack) już rozwiązali podczas importowania vms.

Wydaje mi się, że OpenStack korzysta z inicjowania w chmurze, formatu ConfigDrive i zapewnia konfigurację sieci zgodną ze sprzętem VM. Źródła:

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

Jeśli wykluczysz skrypt pierwszego uruchomienia, istnieje jedna oczywista odpowiedź.

Wcześniej praktycznie gwarantowano, że hosty wyposażone w jedną kartę Ethernet mają tylko jeden interfejs „eth0”. Po wprowadzeniu tego nowego schematu administrator musi najpierw sprawdzić, jaka jest nazwa interfejsu lokalnego, zanim będzie mógł wywoływać polecenia w tym miejscu, gdzie wcześniej miał dużą szansę, że nazwa „eth0” była poprawna.

Nie podoba mi się to, jak mogę to wyłączyć?

Zasadniczo masz trzy opcje:

1. Wyłączysz przypisywanie ustalonych nazw, aby ponownie użyć nieprzewidywalnych nazw jądra. W tym celu po prostu zamaskuj plik .link udev dla domyślnej polityki: ln -s / dev / null /etc/systemd/network/99-default.link

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

Powrót do starych trwałych nazw interfejsów nie jest jedną z udokumentowanych opcji.

Inną alternatywą jest konfiguracja, w której interfejsy sieciowe są domyślnie włączone, niezależnie od ich dokładnej nazwy. Myślę, że NetworkManager domyślnie obsługuje to. systemd-networkd może również zostać poproszony o zrobienie tego .

Jak tylko masz więcej niż jedno urządzenie sieciowe dla maszyny wirtualnej, prawdopodobnie i tak potrzebują one określonej konfiguracji ...

Poza maszynami wirtualnymi istnieje jedna oczywista zaleta podejścia w stylu NetworkManager: komputer PC może mieć wiele interfejsów sieciowych, być może różnych typów, a tylko jeden z nich jest podłączony. Na przykład można to zaobserwować na niektórych płytach głównych premium lub w systemie, w którym pierwszy interfejs sieciowy nie działał zgodnie z oczekiwaniami, a drugi interfejs został zainstalowany w pewnym momencie.

Zrezygnowałem z próby zrobienia tego czysto i wymyśliłem następujący hack. Uruchamiając następujący skrypt tuż przed wyłączeniem vm i migracją, vm będzie miał eth0 jako kartę sieciową po włączeniu.

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;

Ściśle mówiąc, apt-get remove biosdevnamenie jest wymagany, ponieważ ten pakiet nie jest domyślnie instalowany na Ubuntu 16.04. Ponadto dodawanie bios.devname=0do GRUB_CMDLINE_LINUX_DEFAULTnie jest wymagane, ponieważ nazwa biosdevname nie jest zainstalowana. Zapobiega to awarii sieci, jeśli nazwa biosdevname zostanie kiedykolwiek zainstalowana w przyszłości.

Czy potrzebujesz przewidywalnych nazw interfejsów sieciowych?

Moim rozwiązaniem było odinstalowanie biosdevname, a to niezawodnie skutkowało zawsze posiadaniem interfejsów sieciowych o nazwach eth0, eth1 itd. Nie znalazłem dobrego powodu do zainstalowania przewidywalnych nazw interfejsów sieciowych ani nazwy biosdevname.

in /etc/udev/rules.d/70-persistent-net.rulesjest miejscem, w którym możesz zmienić, jaki sprzętowy adres mac ma być nazwany eth0, eth1 itd. Zwykle usuwam zawartość tego pliku, zapisuję go jako pusty plik, uruchamiam ponownie, a następnie mam czystą tablicę z odpowiednimi kartami sieciowymi wyświetlanymi ...

# 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"

^^ gdzie xx: xx: xx: xx: xx: xx to unikalny adres mac twoich kart sieciowych.

Wiem, że wspomnienie o usunięciu tego pliku nie jest rozwiązaniem, ale zamieszczam powyższy przykład, ponieważ przynajmniej w Suse to /lib/udev/write_net_rulesten plik tworzy. Sprawdź, czy śledzenie wstecz do tego pliku pomaga, jeśli ma on zastosowanie do Twojej dystrybucji, możesz go zmodyfikować w celu rozwiązania problemu.

Zauważ, że to wiem z Suse w wersji 11, która jest starym sposobem Init, przed systemd. Nie jestem pewien, czy zmieniło się to w najnowszych wersjach systemu Linux w systemied.

Wpadłem na to uaktualnienie hostów Ubuntu 14.04 do 16.04. biosdevnamePakiet nie jest zainstalowany, więc uciekają się do "biosdevname=0 net.ifnames=0"w /etc/default.grubjak stwierdził OP.

Uruchamiam ten skrypt i jeśli dane wyjściowe wyglądają dobrze, przekierowują dane wyjściowe w /etc/udev/rules.d/70-persistent-net.rulescelu zbudowania nowych reguł udev na wypadek, gdyby jądro kiedykolwiek zdecydowało się wyliczyć porty Ethernet w innej kolejności.

#!/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