Nomi di interfaccia di rete prevedibili interrompono la migrazione di VM


9

Come si reimposta /etc/networking/interfacesquando si utilizzano "nomi di interfaccia di rete prevedibili"?

Le versioni di Ubuntu precedenti alla 15.10 utilizzano nomi di schede di rete come:

  • eth0
  • eth1
  • eth2

La sostituzione di una scheda di rete o lo spostamento di un VM in un nuovo hypervisor causerebbe a Linux l'incremento del numero di interfaccia. L'eliminazione /etc/udev/rules.d/70-peristent-net.rulesfarebbe riutilizzare Linux eth0.

Ubuntu 15.10 e versioni successive utilizzano " Nomi di interfaccia di rete prevedibili ". Il nome della scheda di rete deriva dall'indirizzo mac.

  • ens3
  • ens32
  • ens192

Durante la migrazione di un VM, la rete non si avvia poiché fa /etc/network/interfacesancora riferimento alla vecchia scheda di rete inesistente.

# 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

Qual è il modo migliore per ripristinare il file / etc / network / interfaces?

Ho bisogno di fare questa azione prima di spegnere la VM e migrare verso un nuovo hypervisor poiché sto usando packer per creare immagini dorate automatizzate, basate sulle immagini dorate dello chef / bento .

Ho scoperto che l'eliminazione di / etc / network / interfaces non funziona poiché il file non viene rigenerato automaticamente all'avvio successivo dopo la migrazione.

Ho provato a modificare il mio file grub per tornare alla convenzione di denominazione 'eth0'. Mentre / etc / network / interfaces fa riferimento al vecchio nome (eth0), la VM non otterrà un IP e qualsiasi riavvio farà sì che la VM utilizzi la nuova convenzione di denominazione. Inoltre ho scoperto che systemd avrà sempre la precedenza a meno che non possa garantire che biosdevname=0 rimanga permanentemente nella configurazione di grub . Non sono sicuro di come applicare questo in modo permanente

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

Se possibile, preferirei non utilizzare cloud init o utilizzare qualsiasi script post avvio poiché preferirei mantenere le immagini dorate il più pulite possibile.

Sicuramente questo è un problema che i provider cloud (Azure, AWS, RackSpace, Openstack) hanno già risolto quando importano vms. Non posso essere il primo a provare a migrare un VM usando nomi di interfaccia di rete prevedibili.

Ho provato a eseguire questi comandi prima di spegnere e migrare la VM

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

Trovo che quando migra la VM, quello /etc/network/interfacese mi ip addressriferisco ancoraens32


Hai provato la soluzione dal sito gemello askubuntu? askubuntu.com/a/785442/467355 - fondamentalmente creare manualmente la regola udev e possibilmente utilizzare uno script di avvio singolo per inserire il nuovo mac al suo interno dopo il clone (o per crearlo fresco dopo ciascun clone)
Dani_l

Sì, l'ho visto. Queste sono immagini dorate generiche che possono essere utilizzate da chiunque, quindi non conosco l'indirizzo mac in anticipo.
spuder il

Questo è il punto "usa uno script di avvio singolo per inserire il nuovo mac al suo interno dopo il clone (o per crearlo di nuovo dopo ogni clone)" - inserisci un nuovo script di avvio nell'immagine dorata che all'avvio richiede e inserisce il mac corretto alla regola udev.
Dani_l

Risposte:


4

Sicuramente questo è un problema che i provider cloud (Azure, AWS, RackSpace, Openstack) hanno già risolto quando importano vms.

Penso che OpenStack utilizzi il formato cloud-init, ConfigDrive e fornisca una configurazione di rete che corrisponda all'hardware della VM. fonti:

Se si esclude uno script al primo avvio, c'è una risposta ovvia.

In precedenza era praticamente garantito che gli host dotati di una singola scheda Ethernet avessero un'unica interfaccia "eth0". Con questo nuovo schema in atto, un amministratore deve ora controllare prima qual è il nome dell'interfaccia locale prima di poter invocare i comandi su di esso, dove in precedenza aveva buone probabilità che "eth0" fosse il nome giusto.

Non mi piace, come posso disabilitarlo?

Fondamentalmente hai tre opzioni:

  1. Si disabilita l'assegnazione di nomi fissi, in modo che i nomi imprevedibili del kernel vengano riutilizzati. Per questo, maschera semplicemente il file .link di udev per la politica di default: ln -s / dev / null /etc/systemd/network/99-default.link

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

Il ritorno ai vecchi nomi di interfaccia persistenti non è una delle opzioni documentate.

L'altra alternativa è una configurazione in cui le interfacce di rete sono abilitate per impostazione predefinita, indipendentemente dal loro nome esatto. Penso che NetworkManager supporti questo per impostazione predefinita. si può anche dire a systemd-networkd di farlo .

Non appena avrai più di un dispositivo di rete per una VM, probabilmente avranno comunque bisogno di una configurazione specifica ...

Al di fuori delle macchine virtuali, esiste un evidente vantaggio dell'approccio in stile NetworkManager: un PC potrebbe avere più interfacce di rete, forse di diverso tipo, di cui solo una è connessa. Ad esempio, questo può essere visto su alcune schede madri premium o su un sistema in cui la prima interfaccia di rete non funzionava come desiderato e una seconda interfaccia è stata installata ad un certo punto.


Grandi suggerimenti. Trovo che ln -s /dev/null /etc/systemd/network/99-default.linknon faccia alcuna differenza. i miei vms usano ancora la nuova convenzione di denominazione.
spuder

3

Ho rinunciato a provare a farlo in modo pulito e ho escogitato il seguente trucco. Eseguendo il seguente script appena prima di spegnere vm e migrare, vm avrà eth0 come adattatore di rete quando acceso.

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;

A rigor di termini, apt-get remove biosdevnamenon è richiesto poiché quel pacchetto non è installato di default su Ubuntu 16.04. Inoltre, non è necessario aggiungere bios.devname=0a GRUB_CMDLINE_LINUX_DEFAULTpoiché non è installato biosdevname. Impedisce la rottura della rete se in futuro verrà mai installato biosdevname.


Perché impostare il collegamento e passare l'argomento del kernel? La documentazione afferma che uno dovrebbe essere sufficiente. Il controllo corsivo suggerisce che è davvero così.
0xC0000022L

2

Hai bisogno di nomi di interfaccia di rete prevedibili?

La mia soluzione è stata quella di disinstallare biosdevnamee ciò ha portato in modo affidabile ad avere sempre interfacce di rete denominate eth0, eth1 e così via. Non ho trovato un buon motivo per installare nomi di interfaccia di rete prevedibili né biosdevname.

in /etc/udev/rules.d/70-persistent-net.rulesè dove è possibile modificare quale indirizzo MAC dell'hardware viene chiamato in eth0, eth1 e così via. Di solito elimino il contenuto di questo file, lo salvo come file vuoto, riavvio, quindi ho una lavagna pulita con gli adattatori di rete corretti visualizzati ...

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

^^ dove xx: xx: xx: xx: xx: xx è l'indirizzo MAC univoco delle schede di rete.

So che accenni all'eliminazione di questo file non è la soluzione, ma inserisco l'esempio sopra perché almeno in Suse è /lib/udev/write_net_rulesquello che crea questo file. Quindi vedi se il tracciamento indietro a questo file aiuta, se è applicabile alla tua distribuzione potresti essere in grado di modificarlo per risolvere il tuo problema.

nota questo è quello che so da Suse versione 11 che è il vecchio modo di Init, prima di systemd. Non sono sicuro se questo è cambiato per le ultime versioni di Linux in systemd.


biosdevname è sostituito da udev "builtin" net_id freedesktop.org/wiki/Software/systemd/…
sourcejedi

0

Sono entrato in questo aggiornamento degli host Ubuntu 14.04 a 16.04. biosdevnamepacchetto non è installata in modo ricorso a "biosdevname=0 net.ifnames=0"in /etc/default.grubquanto affermato da OP.

Eseguo questo script e, se l'output ha un bell'aspetto, reindirizza l'output /etc/udev/rules.d/70-persistent-net.rulesper creare nuove regole udev nel caso in cui il kernel decida di enumerare le porte Ethernet in un ordine diverso.

#!/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
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.