Os nomes de interface de rede previsíveis interrompem a migração de vm

8

Como você redefine /etc/networking/interfaces ao usar "nomes de interface de rede previsíveis"?

Versões do Ubuntu anteriores a 15.10 usam nomes de adaptadores de rede como:

  • eth0
  • eth1
  • eth2

Substituir uma placa de rede ou mover uma vm para um novo hipervisor faria com que o Linux aumentasse o número da interface. A exclusão de /etc/udev/rules.d/70-peristent-net.rules faria o Linux reutilizar eth0 .

Ubuntu 15.10 e uso mais recente ' Nomes previsíveis da interface de rede '. O nome do adaptador de rede é derivado do endereço MAC.

  • ens3
  • ens32
  • ens192

Ao migrar um vm, a rede não será iniciada, pois /etc/network/interfaces ainda faz referência ao antigo adaptador de rede 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

Qual é a melhor maneira de redefinir o arquivo / etc / network / interfaces?

Eu preciso fazer essa ação antes desligar a VM e migrar para um novo hipervisor, já que estou usando o packer para criar imagens douradas automatizadas, com base nas imagens douradas chef / bento .

Descobri que a exclusão de / etc / network / interfaces não funciona, pois o arquivo não é regenerado automaticamente na próxima inicialização após a migração.

Eu tentei editar meu arquivo grub para reverter para a convenção de nomenclatura 'eth0'. Embora / etc / network / interfaces se refira ao nome antigo (eth0), o vm não obterá um ip e qualquer reinicialização fará com que o vm use a nova convenção de nomenclatura. Também achei systemd sempre terá precedência, a menos que eu possa garantir biosdevname=0 permanece permanentemente na configuração do grub . Não tenho certeza de como aplicar permanentemente isso

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

Se possível, prefiro não usar o cloud init ou usar scripts de inicialização, pois prefiro manter as imagens douradas o mais limpas possível.

Certamente, esse é um problema que os provedores de nuvem (Azure, AWS, RackSpace, Openstack) já resolveram quando importaram vms. Não posso ser a primeira pessoa a tentar migrar uma vm usando nomes de interface de rede previsíveis.

Eu tentei executar esses comandos antes de desligar e migrar o vm

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

Quando migro a VM, descubro que /etc/network/interfaces e ip address referem-se a ens32

    
por spuder 06.01.2017 / 19:45

4 respostas

3

Eu desisti de tentar fazer isso de forma limpa e encontrei o seguinte hack. Ao executar o script a seguir antes de desligar a VM e migrar, a VM terá a eth0 como o adaptador de rede quando estiver ligada.

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;

Estritamente falando, apt-get remove biosdevname não é necessário, já que o pacote não é instalado por padrão no Ubuntu 16.04. Além disso, adicionar bios.devname=0 ao GRUB_CMDLINE_LINUX_DEFAULT não é necessário, pois o biosdevname não está instalado. Ele impede que a rede quebre se o biosdevname já estiver instalado no futuro.

    
por 26.01.2017 / 21:39
5

Surely this is a problem that cloud providers (Azure, AWS, RackSpace, Openstack) have already solved when they import vms.

Acho que o OpenStack usa cloud-init, formato ConfigDrive e fornece uma configuração de rede que corresponde ao hardware da VM. Fontes:

Se você descartar um script de primeira inicialização, há uma resposta óbvia.

Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name.

I don't like this, how do I disable this?

You basically have three options:

  1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: ln -s /dev/null /etc/systemd/network/99-default.link

link

Mudar de volta para os antigos nomes de interface persistentes não é uma das opções documentadas.

A outra alternativa é uma configuração em que as interfaces de rede são ativadas por padrão, independentemente de seu nome exato. Eu acho que o NetworkManager suporta isso por padrão. systemd-networkd também pode ser instruído a fazer isso .

Assim que você tiver mais de um dispositivo de rede para uma VM, eles provavelmente precisarão de configuração específica ...

Fora da VM, há uma vantagem óbvia da abordagem do estilo NetworkManager: um PC pode ter várias interfaces de rede, talvez de tipos diferentes, com apenas uma delas conectada. Por exemplo, isso pode ser visto em algumas placas-mãe premium ou em um sistema em que a primeira interface de rede não funcionou como desejado e uma segunda interface foi instalada em algum momento.

    
por 19.01.2017 / 22:57
3

Você precisa de nomes de interface de rede previsíveis?

Minha solução foi desinstalar biosdevname , e isso sempre resultou em interfaces de rede sempre nomeadas como eth0, eth1 e assim por diante. Não encontrei um bom motivo para ter nomes de interface de rede previsíveis nem o biosdevname instalado.

em /etc/udev/rules.d/70-persistent-net.rules é onde você pode modificar qual endereço de hardware mac é nomeado para eth0, eth1 e assim por diante. Eu normalmente apago o conteúdo deste arquivo, salvá-lo como um arquivo em branco, reinicie, então eu tenho uma ardósia limpa com adaptadores de rede correta aparecendo ...

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

^^ onde xx: xx: xx: xx: xx: xx é o endereço MAC exclusivo dos seus adaptadores de rede.

Eu sei que você menciona a exclusão deste arquivo não é a solução, mas eu posto o exemplo acima porque pelo menos em Suse é /lib/udev/write_net_rules que cria este arquivo. Portanto, veja se o rastreamento de retorno para este arquivo ajuda, se for aplicável à sua distribuição, você poderá modificá-lo para solucionar seu problema.

note que isto é o que eu sei da versão 11 do Suse, que é a antiga maneira Init, antes do systemd. Não tenho certeza se isso mudou para as versões mais recentes do Linux no systemd.

    
por 19.01.2017 / 23:03
0

Corri para esta atualização dos hosts do Ubuntu 14.04 para 16.04. O pacote biosdevname não está instalado, então recorreu a "biosdevname=0 net.ifnames=0" em /etc/default.grub como declarado pelo OP.

Eu executo este script, e se a saída parecer boa, redirecione a saída para /etc/udev/rules.d/70-persistent-net.rules para criar novas regras do udev caso o kernel decida enumerar as portas ethernet em uma ordem 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
    
por 05.09.2018 / 21:55