Los nombres de interfaz de red predecibles interrumpen la migración de VM

¿Cómo se restablece /etc/networking/interfacesal usar "nombres de interfaz de red predecibles"?

Las versiones de Ubuntu anteriores a 15.10 usan nombres de adaptadores de red como:

• eth0
• eth1
• eth2

Reemplazar una tarjeta de red, o mover un vm a un nuevo hipervisor, causaría que Linux incremente el número de interfaz. La eliminación /etc/udev/rules.d/70-peristent-net.rulesharía que Linux se reutilizara eth0.

Ubuntu 15.10 y versiones posteriores usan ' Nombres de interfaz de red predecibles '. El nombre del adaptador de red se deriva de la dirección mac.

• ens3
• ens32
• ens192

Al migrar una máquina virtual, la red no se iniciará ya que /etc/network/interfacestodavía hace referencia al antiguo adaptador de red inexistente.

# 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

¿Cuál es la mejor manera de restablecer el archivo / etc / network / interfaces?

Necesito hacer esta acción antes de cerrar el vm y migrar a un nuevo hipervisor ya que estoy usando el empaquetador para crear imágenes doradas automatizadas, basadas en las imágenes doradas chef / bento .

Descubrí que eliminar / etc / network / interfaces no funciona ya que el archivo no se regenera automáticamente en el siguiente arranque después de la migración.

Intenté editar mi archivo grub para volver a la convención de nomenclatura 'eth0'. Si bien / etc / network / interfaces hace referencia al nombre anterior (eth0), el vm no obtendrá una ip, y cualquier reinicio hará que el vm use la nueva convención de nomenclatura. También he encontrado que systemd siempre tendrá prioridad a menos que pueda garantizar biosdevname=0 permanentemente los restos en la configuración de grub . No estoy seguro de cómo aplicar esto permanentemente

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

Si es posible, prefiero no usar cloud init ni usar ningún script posterior al inicio, ya que prefiero mantener las imágenes doradas lo más limpias posible.

Seguramente este es un problema que los proveedores de la nube (Azure, AWS, RackSpace, Openstack) ya han resuelto cuando importan vms. No puedo ser la primera persona en intentar migrar una máquina virtual utilizando nombres de interfaz de red predecibles.

He intentado ejecutar estos comandos antes de apagar y migrar el vm

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

Encuentro cuando migro el vm, /etc/network/interfacesy ip addresstodavía me refiero aens32

Seguramente este es un problema que los proveedores de la nube (Azure, AWS, RackSpace, Openstack) ya han resuelto cuando importan vms.

Creo que OpenStack usa cloud-init, formato ConfigDrive, y proporciona una configuración de red que coincide con el hardware de VM. Fuentes:

• 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 descarta un script de primer arranque, hay una respuesta obvia.

Anteriormente estaba prácticamente garantizado que los hosts equipados con una sola tarjeta ethernet solo tenían una única interfaz "eth0". Con este nuevo esquema, un administrador ahora tiene que verificar primero cuál es el nombre de la interfaz local antes de poder invocar comandos allí donde antes tenía una buena posibilidad de que "eth0" fuera el nombre correcto.

No me gusta esto, ¿cómo desactivo esto?

Básicamente tienes tres opciones:

1. Deshabilita la asignación de nombres fijos, para que los nombres de kernel impredecibles se usen nuevamente. Para esto, simplemente enmascare el archivo .link de udev para la política predeterminada: ln -s / dev / null /etc/systemd/network/99-default.link

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

Volver a los antiguos nombres de interfaz persistentes no es una de las opciones documentadas.

La otra alternativa es una configuración donde las interfaces de red están habilitadas de forma predeterminada, independientemente de su nombre exacto. Creo que NetworkManager admite esto de forma predeterminada. También se le puede decir a systemd-networkd que haga esto .

Tan pronto como tenga más de un dispositivo de red para una VM, es probable que de todos modos necesiten una configuración específica ...

Fuera de las máquinas virtuales, hay una ventaja obvia del enfoque de estilo NetworkManager: una PC puede tener múltiples interfaces de red, quizás de diferentes tipos, con solo una de ellas conectada. Por ejemplo, esto se puede ver en algunas placas base premium, o en un sistema donde la primera interfaz de red no funcionó como se deseaba y se instaló una segunda interfaz en algún momento.

Dejé de intentar hacer esto limpiamente y se me ocurrió el siguiente truco. Al ejecutar el siguiente script justo antes de apagar el vm y migrar, el vm tendrá eth0 como el adaptador de red cuando esté encendido.

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;

Estrictamente hablando, apt-get remove biosdevnameno es necesario ya que ese paquete no está instalado por defecto en ubuntu 16.04. Además, la adición bios.devname=0a la GRUB_CMDLINE_LINUX_DEFAULTque no es necesario ya que biosdevname no está instalado. Evita que la red se rompa si biosdevname se instala en el futuro.

¿Necesita nombres de interfaz de red predecibles?

Mi solución ha sido la desinstalación biosdevname, y eso ha resultado en tener siempre interfaces de red llamadas eth0, eth1, etc. No he encontrado una buena razón para tener nombres predecibles de interfaz de red ni biosdevname instalados.

en /etc/udev/rules.d/70-persistent-net.ruleses donde puede modificar qué dirección de hardware mac recibe el nombre de eth0, eth1, etc. Normalmente borro el contenido de este archivo, lo guardo como un archivo en blanco, reinicio, luego tengo una pizarra limpia con los adaptadores de red correctos que aparecen ...

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

^^ donde xx: xx: xx: xx: xx: xx es la dirección MAC única de sus adaptadores de red.

Sé que mencionas que eliminar este archivo no es la solución, pero publico el ejemplo anterior porque al menos en Suse es /lib/udev/write_net_rulesque crea este archivo. Por lo tanto, vea si el seguimiento de este archivo es útil, si es aplicable a su distribución, puede modificarlo para resolver su problema.

Tenga en cuenta que esto es lo que sé de Suse versión 11, que es la antigua forma de Init, antes de systemd. No estoy seguro si esto ha cambiado para las últimas versiones de Linux en systemd.

Me encontré con esta actualización de hosts Ubuntu 14.04 a 16.04. biosdevnamepaquete no está instalado de manera recurrió a "biosdevname=0 net.ifnames=0"en /etc/default.grubcomo se indica por la OP.

Ejecuto este script, y si la salida se ve bien, redirija la salida /etc/udev/rules.d/70-persistent-net.rulespara construir nuevas reglas de udev en caso de que el núcleo decida enumerar los puertos ethernet en un orden diferente.

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