[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trouble with network using tap device

From: Pascal
Subject: Re: Trouble with network using tap device
Date: Mon, 6 Jul 2020 15:30:09 +0200

I had a similar problem with VDE.
I didn't get an answer, but don't despair.
Unfortunately I haven't tried again since.
regards, lacsaP.

Le jeu. 11 juin 2020 à 02:53, Filipe Manana <fdmanana@gmail.com> a écrit :

Using any qemu version from 3.x to 5.0, on Linux, I experience a weird thing.

So I use the following script to start a vm with qemu:

#!/bin/bash -x

sudo modprobe tun
sudo modprobe kvm
sudo modprobe kvm-intel

# br0 was already setup
sudo tunctl -t tap3 -u fdmanana
sudo ifconfig tap3 up
sudo brctl addif br0 tap3

mkdir -p /home/fdmanana/vmdisks/debian8
rm -f /home/fdmanana/vmdisks/debian8/*

for ((i = 2; i <= 10; i++)); do
        qemu-img create -f raw /home/fdmanana/vmdisks/debian8/disk$i 20G

qemu-system-x86_64 -m 8G \
        -device virtio-scsi-pci \
        -boot c \
        -drive if=none,file=debian8.raw,cache=none,aio=native,cache.direct=on,format=raw,id=drive0,discard=on
        -device scsi-hd,drive=drive0,bus=scsi.0 \
        -drive if=none,file=/home/fdmanana/vmdisks/debian8/disk2,cache=$cache_type,format=raw,id=drive1,discard=on
        -device scsi-hd,drive=drive1,bus=scsi.0 \
        -drive if=none,file=/home/fdmanana/vmdisks/debian8/disk3,cache=$cache_type,format=raw,id=drive2,discard=on
        -device scsi-hd,drive=drive2,bus=scsi.0 \
        -drive if=none,file=/home/fdmanana/vmdisks/debian8/disk4,cache=$cache_type,format=raw,id=drive3,discard=on
        -device scsi-hd,drive=drive3,bus=scsi.0 \
        -drive if=none,file=/home/fdmanana/vmdisks/debian8/disk5,cache=$cache_type,format=raw,id=drive4,discard=on
        -device scsi-hd,drive=drive4,bus=scsi.0 \
        -drive if=none,file=/home/fdmanana/vmdisks/debian8/disk6,cache=$cache_type,format=raw,id=drive5,discard=on
        -device scsi-hd,drive=drive5,bus=scsi.0 \
        -drive if=none,file=/home/fdmanana/vmdisks/debian8/disk7,cache=$cache_type,format=raw,id=drive6,discard=on
        -device scsi-hd,drive=drive6,bus=scsi.0 \
        -drive if=none,file=/home/fdmanana/vmdisks/debian8/disk8,cache=$cache_type,format=raw,id=drive7,discard=on
        -device scsi-hd,drive=drive7,bus=scsi.0 \
        -drive if=none,file=/home/fdmanana/vmdisks/debian8/disk9,cache=$cache_type,format=raw,id=drive8,discard=on
        -device scsi-hd,drive=drive8,bus=scsi.0 \
        -drive if=none,file=/home/fdmanana/vmdisks/debian8/disk10,cache=$cache_type,format=raw,id=drive9,discard=on
        -device scsi-hd,drive=drive9,bus=scsi.0 \
        -net nic,macaddr=52:54:00:12:34:db,model=virtio-net-pci -net
tap,ifname=tap3,script=no,downscript=no \
        -rtc base=localtime -enable-kvm -machine accel=kvm -smp 4 -cpu host \
        -k pt -serial tcp: -display vnc=:8

Then I start multiple ssh sessions, using different terminals, to
access the guests (all Debian). The host is Ubuntu (but happens with
Debian hosts too).

After a random period of time, and for no apparent reason, all
connectivity stops, the terminals using the ssh connection just
freeze, and I can't ssh or ping the guest anymore. Usually this
happens after at least 1 hour of using the guest will multiple active
ssh connections to it. Sometimes it takes 3, 4 or more hours to

However the VNC connection works, and I can see that when doing "ip a"
(replacement for "ifconfig -a") the ens3 interface in the guest lost
its IPv4 address, but the IPv6 is still there. If I use the IPv6
address to ssh to the guest, eventually the same issue happens.
Usually after a short while I can just run 'dhclient' in the guest
through VNC and connectivity is back, and I can access the guest
through ssh again (and ping it, etc).

Why does this happen? It's a bit annoying.
Is this a know issue, a problem with my configuration or is there a workaround?

This happens both with a qemu installed from a debian/ubuntu package
and with a qemu built from source.


Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

reply via email to

[Prev in Thread] Current Thread [Next in Thread]