Les noms d'interface réseau prévisibles interrompent la migration VM

Comment réinitialiser /etc/networking/interfaceslors de l'utilisation de "noms d'interface réseau prévisibles"?

Les versions d'Ubuntu antérieures à 15.10 utilisent des noms de carte réseau comme:

• eth0
• eth1
• eth2

Le remplacement d'une carte réseau ou le déplacement d'un VM vers un nouvel hyperviseur entraînerait l'incrémentation du numéro d'interface par Linux. La suppression /etc/udev/rules.d/70-peristent-net.rulesentraînerait la réutilisation de Linux eth0.

Ubuntu 15.10 et les versions plus récentes utilisent des « noms d'interface réseau prévisibles ». Le nom de la carte réseau est dérivé de l'adresse mac.

• ens3
• ens32
• ens192

Lors de la migration d'un VM, la mise en réseau ne démarre pas car fait /etc/network/interfacestoujours référence à l'ancienne carte réseau inexistante.

# 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

Quelle est la meilleure façon de réinitialiser le fichier / etc / network / interfaces?

J'ai besoin de faire cette action avant d' arrêter le vm et de migrer vers un nouvel hyperviseur car j'utilise packer pour créer des images dorées automatisées, basées sur les images dorées chef / bento .

J'ai trouvé que la suppression de / etc / network / interfaces ne fonctionne pas car le fichier n'est pas automatiquement régénéré au prochain démarrage après la migration.

J'ai essayé de modifier mon fichier grub pour revenir à la convention de dénomination «eth0». Alors que / etc / network / interfaces fait référence à l'ancien nom (eth0), le vm n'obtiendra pas d'ip et tout redémarrage obligera le vm à utiliser la nouvelle convention de dénomination. De plus, j'ai trouvé que systemd aura toujours la priorité à moins que je ne puisse garantir de biosdevname=0 façon permanente les restes dans la configuration de grub . Je ne sais pas comment appliquer ceci de façon permanente

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

Si possible, je préfère ne pas utiliser cloud init ou utiliser des scripts de post-démarrage car je préfère garder les images dorées aussi propres que possible.

C'est sûrement un problème que les fournisseurs de cloud (Azure, AWS, RackSpace, Openstack) ont déjà résolu lorsqu'ils importent des vms. Je ne peux pas être la première personne à essayer de migrer un VM en utilisant des noms d'interface réseau prévisibles.

J'ai essayé d'exécuter ces commandes avant d'arrêter et de migrer le VM

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

Je trouve quand je migre le vm, /etc/network/interfaceset je me ip addressréfère toujours àens32

C'est sûrement un problème que les fournisseurs de cloud (Azure, AWS, RackSpace, Openstack) ont déjà résolu lorsqu'ils importent des vms.

Je pense que OpenStack utilise cloud-init, le format ConfigDrive, et fournit une configuration réseau qui correspond au matériel de la machine virtuelle. Sources:

• 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

Si vous excluez un script de premier démarrage, il y a une réponse évidente.

Auparavant, il était pratiquement garanti que les hôtes équipés d'une seule carte Ethernet n'avaient qu'une seule interface "eth0". Avec ce nouveau schéma en place, un administrateur doit maintenant vérifier d'abord le nom de l'interface locale avant de pouvoir y invoquer des commandes là où auparavant il avait de bonnes chances que "eth0" soit le bon nom.

Je n'aime pas ça, comment puis-je le désactiver?

Vous avez essentiellement trois options:

1. Vous désactivez l'attribution de noms fixes, afin que les noms de noyau imprévisibles soient réutilisés. Pour cela, masquez simplement le fichier .link d'udev pour la politique par défaut: ln -s / dev / null /etc/systemd/network/99-default.link

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

Le retour aux anciens noms d'interface persistants ne fait pas partie des options documentées.

L'autre alternative est une configuration où les interfaces réseau sont activées par défaut, quel que soit leur nom exact. Je pense que NetworkManager prend en charge cela par défaut. systemd-networkd peut également être invité à le faire .

Dès que vous avez plus d'un périphérique réseau pour une machine virtuelle, ils ont probablement besoin d'une configuration spécifique de toute façon ...

En dehors des VM, il existe un avantage évident de l'approche de type NetworkManager: un PC peut avoir plusieurs interfaces réseau, peut-être de types différents, avec une seule d'entre elles connectée. Par exemple, cela peut être vu sur certaines cartes mères premium, ou sur un système où la première interface réseau n'a pas fonctionné comme souhaité et une deuxième interface a été installée à un moment donné.

J'ai renoncé à essayer de le faire proprement et j'ai trouvé le hack suivant. En exécutant le script suivant juste avant d'arrêter le VM et de migrer, le VM aura eth0 comme carte réseau lors de la mise sous tension.

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;

À proprement parler, apt-get remove biosdevnamen'est pas requis car ce paquet n'est pas installé par défaut sur ubuntu 16.04. De plus, l'ajout bios.devname=0à GRUB_CMDLINE_LINUX_DEFAULTn'est pas requis car biosdevname n'est pas installé. Cela empêche le réseau de se casser si biosdevname est installé à l'avenir.

Avez-vous besoin de noms d'interface réseau prévisibles?

Ma solution a été de désinstaller biosdevname, et cela a abouti de manière fiable à toujours avoir des interfaces réseau nommées eth0, eth1, etc. Je n'ai pas trouvé de bonne raison d'avoir installé des noms d'interface réseau prévisibles ni biosdevname.

dans /etc/udev/rules.d/70-persistent-net.rulesest l'endroit où vous pouvez modifier l'adresse matérielle de mac qui sera nommée eth0, eth1, etc. Je supprime normalement le contenu de ce fichier, l'enregistre en tant que fichier vierge, redémarre, puis j'ai une liste claire avec les adaptateurs réseau corrects qui apparaissent ...

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

^^ où xx: xx: xx: xx: xx: xx est l'adresse mac unique de vos adaptateurs réseau.

Je sais que vous mentionnez que la suppression de ce fichier n'est pas la solution, mais je poste l'exemple ci-dessus car au moins dans Suse c'est lui /lib/udev/write_net_rulesqui crée ce fichier. Vérifiez donc si le suivi de ce fichier est utile, s'il est applicable à votre distribution, vous pourrez peut-être le modifier pour résoudre votre problème.

notez que c'est ce que je sais de la version 11 de Suse qui est l'ancienne méthode Init, avant systemd. Je ne sais pas si cela a changé pour les dernières versions de linux sous systemd.

Exécutez cette mise à niveau des hôtes Ubuntu 14.04 vers 16.04. biosdevnamepackage n'est pas installé de façon eu recours à "biosdevname=0 net.ifnames=0"dans /etc/default.grubcomme indiqué par OP.

J'exécute ce script, et si la sortie semble bonne, redirigez la sortie dans /etc/udev/rules.d/70-persistent-net.rulespour construire de nouvelles règles udev au cas où le noyau déciderait d'énumérer les ports Ethernet dans un ordre différent.

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