0

I have an issue with a virtual machine taking time to connect to the local network on boot.

I create a virtual machine using the following command:

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

When I create the machine on a host running Ubuntu 14.04.4 LTS, everything works fine: the virtual machine boots and is connected to the LAN right before running systemd scripts. However, when the host runs Debian 8.5, it takes a while for the virtual machine to be connected, and systemd scripts start running before network resources could actually be used.

During the debugging, I've created the following 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

Here's the corresponding systemd configuration:

[Unit]
Description=Demo
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/demo-init

[Install]
WantedBy=multi-user.target

After the machine boots, ping.log contains the following:

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

It means that:

  • ping fails,
  • It takes 20 seconds to connect.

By comparison, when running the same machine on an Ubuntu host, this is what is stored in 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

Here:

  • ping is successful,
  • It takes 2 seconds, that is the time to do the actual ping.

The actual hosts (Debian and Ubuntu) have different hardware (including different number of NIC), making it difficult to compare the configuration. The virtual machine, however, is deployed in the exact same way, is based on the same base disk with pre-installed Debian, and has the exact same /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

I have two questions:

  • What could be the possible reasons for that enormous delay?

  • Have I misunderstood the purpose of network-online.target? I thought that it would guarantee basic connectivity when running the script. Since it's actually not the case, what is the purpose of it?

Community
  • 1
Arseni Mourzenko
  • 1,278

1 Answers1

0

Found it. In a similar case, the author complained that:

I have to wait for about 20 seconds until my network comes up.

It appeared that:

This delay is caused by Spanning Tree Protocol (STP)

Indeed, one of the differences was that the /etc/network/interfaces of Debian host contained bridge_stp on, while on Ubuntu, there was no bridge_stp statement.

Arseni Mourzenko
  • 1,278