CentOS 7 Vagrant VM parcialmente perdendo conectividade de rede

1

Eu estou usando uma caixa de base do Vagrant que executa uma instalação mínima do CentOS 7 (eu criei seguindo a documentação do Vagrant - se você quiser mais informações, eu delineei o processo em um artigo no meu site e você pode baixar a máquina daqui).

Antes de provisionar a máquina com Ansible (o que é irrelevante para esta questão) eu uso o Vagrantfile a seguir para abrir a caixa:

Vagrant.configure(2) do |config|
  config.vm.box = "relativkreativ/centos-7-minimal"
  config.vm.network "public_network", ip: "192.168.0.100", bridge: 'en0: WLAN (AirPort)'

  config.vm.provision "file", source: "~/.ssh/id_rsa.pub", destination: "~/id_rsa.pub"
  config.vm.provision "shell", inline: <<-END.gsub(/^\s{4}/, '')
    mkdir -m 0700 /root/.ssh
    mv /home/vagrant/id_rsa.pub /root/.ssh/authorized_keys
    chmod 0600 /root/.ssh/authorized_keys
    chown root:root /root/.ssh/authorized_keys
  END
end

Não há nada de especial aqui, apenas adicionando uma interface de rede adicional e copiando minha chave pública.

Ao efetuar login no servidor como root ( ssh [email protected] ), eu algumas vezes obtenho um canal quebrado após alguns segundos e o servidor não é pingável (às vezes, mesmo durante a execução do manifesto Ansible). Na maioria das vezes eu consigo reconectar depois de algumas tentativas, mas quando isso não é possível, eu tenho que usar o Vagrant para logar ( vagrant ssh - isso sempre funciona) e reiniciar o serviço de rede ( systemctl restart network.service ). Depois disso, o SSH funciona novamente por algum tempo.

As rotas do servidor:

[root@localhost ~]# ip route
default via 10.0.2.2 dev enp0s3 
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15 
169.254.0.0/16 dev enp0s3  scope link  metric 1002 
169.254.0.0/16 dev enp0s8  scope link  metric 1003 
192.168.0.0/24 dev enp0s8  proto kernel  scope link  src 192.168.0.100

As interfaces de rede:

[root@localhost ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:c0:9e:5b brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 84324sec preferred_lft 84324sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:b6:45:8c brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.100/24 brd 192.168.0.255 scope global enp0s8
       valid_lft forever preferred_lft forever

Seus arquivos de configuração:

[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-lo 
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback

[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp0s3
HWADDR="08:00:27:C0:9E:5B"
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="enp0s3"
UUID="957d70e5-1097-4952-b3a4-dc67b919b934"
ONBOOT="yes"

[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp0s8
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
NM_CONTROLLED=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.0.100
NETMASK=255.255.255.0
DEVICE=enp0s8
PEERDNS=no
#VAGRANT-END

Desativei o IPv6 para a solução de problemas, mas isso não fez diferença.

Isso também acontece quando eu executo exatamente o mesmo fluxo de trabalho com a minha caixa Vagrant do CentOS 6 (que eu construí exatamente da mesma forma), e também com as caixas do Vagrant que outras pessoas construíram.

Estou usando a versão mais recente do Vagrant (1.7.2), bem como o VirtualBox (4.3.20). Eu não mudei nada na configuração de rede padrão do VirtualBox.

Alguém tem alguma idéia do que está acontecendo aqui? Não consigo rastrear este problema.

Muito obrigado!

    
por Michael Trojanek 10.01.2015 / 11:19

1 resposta

0

Para mim, funcionou desativar o NetworkManager quando tive o mesmo problema (mas com rede somente host)

    
por 21.05.2015 / 21:49