Re: Trouble with network using tap device

[Pascal]

hello,

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

https://wiki.archlinux.org/index.php/Talk:QEMU#VDE

regards, lacsaP.

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

Hello,

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
done

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:127.0.0.1:9918 -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
happen.

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.

Thanks.



--
Filipe David Manana,

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