Eu tenho um problema com uma máquina virtual que leva tempo para se conectar à rede local durante a inicialização.
Eu crio uma máquina virtual usando o seguinte comando:
virt-install \
--connect qemu:///system \
--name demo \
--noautoconsole \
--disk path=/demo.qcow2,device=disk,format=qcow2,bus=virtio,cache=writeback \
--disk path=/base.qcow2,device=disk,format=qcow2,bus=virtio,cache=writeback \
--import \
--vcpus 1 \
--virt-type kvm \
--ram 256 \
--hvm \
--os-type linux
Quando eu crio a máquina em um host executando o Ubuntu 14.04.4 LTS, tudo funciona bem: a máquina virtual inicializa e está conectada à LAN logo antes de executar systemd scripts. No entanto, quando o host executa o Debian 8.5, a máquina virtual demora um pouco para ser conectada, e os scripts systemd começam a ser executados antes que os recursos de rede possam realmente ser usados.
Durante a depuração, criei o seguinte script:
#!/bin/bash
date >> /ping.log
ping -c 3 -W 3 "192.168.1.7" >> /ping.log
date >> /ping.log
curl google.com >> ping.log
date >> /ping.log
Aqui está a configuração systemd correspondente:
[Unit]
Description=Demo
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
ExecStart=/demo-init
[Install]
WantedBy=multi-user.target
Após a inicialização da máquina, ping.log contém o seguinte:
Tue Jul 19 12:57:56 UTC 2016
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
From 192.168.1.35 icmp_seq=1 Destination Host Unreachable
From 192.168.1.35 icmp_seq=2 Destination Host Unreachable
From 192.168.1.35 icmp_seq=3 Destination Host Unreachable
--- 192.168.1.7 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2001ms
pipe 3
Tue Jul 19 12:57:59 UTC 2016
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
[...]
</BODY></HTML>^M
Tue Jul 19 12:58:16 UTC 2016
Isso significa que:
ping falha, Por comparação, ao rodar a mesma máquina em um host Ubuntu, isso é o que é armazenado em ping.log :
Tue Jul 19 13:18:12 UTC 2016
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
64 bytes from 192.168.1.7: icmp_seq=1 ttl=64 time=2.27 ms
64 bytes from 192.168.1.7: icmp_seq=2 ttl=64 time=0.711 ms
64 bytes from 192.168.1.7: icmp_seq=3 ttl=64 time=5.47 ms
--- 192.168.1.7 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.711/2.819/5.472/1.981 ms
Tue Jul 19 13:18:14 UTC 2016
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
[...]
</BODY></HTML>^M
Tue Jul 19 13:18:14 UTC 2016
Aqui:
ping é bem sucedido, ping. Os hosts atuais (Debian e Ubuntu) têm hardware diferente (incluindo diferentes números de NIC), dificultando a comparação da configuração. A máquina virtual, no entanto, é implantada da mesma maneira, é baseada no mesmo disco base com Debian pré-instalado, e tem exatamente o mesmo /etc/network/interfaces :
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.35
netmask 255.255.240.0
network 192.168.0.0
broadcast 192.168.3.255
gateway 192.168.1.1
dns-nameservers 192.168.1.3 192.168.1.4 8.8.8.8 8.8.4.4
Eu tenho duas perguntas:
Quais poderiam ser as possíveis razões para esse enorme atraso?
Eu entendi mal o objetivo de network-online.target ? Eu pensei que isso garantiria conectividade básica ao executar o script. Como na verdade não é esse o caso, qual é o objetivo disso?
Encontrei. Em um caso similar , o autor reclamou que:
I have to wait for about 20 seconds until my network comes up.
This delay is caused by Spanning Tree Protocol (STP)
De fato, uma das diferenças foi que /etc/network/interfaces do host Debian continha bridge_stp on , enquanto no Ubuntu não havia bridge_stp .