QEMU - network bridge

I am currently struggling with this problem as well. I've come a bit closer to the solution than you.

I am on Debian 10 and I decidd to only use the a package iproute2 (ip link, ip addr, bridge link...) which is part of a kernel and will be available on any Linux. and package qemu-kvm. This is everything you need.

---

---

---

STEP 1

Open 1st terminal and write this down, so that you will be able to see your progres:

while true; do ip addr; sleep 1; clear; done

---

---

---

STEP 2

Open 2nd terminal and execute these commmands while you look at the progress in the 1st terminal:

sudo ip link add virtual_bridge type bridge
sudo ip link set virtual_bridge up

And you have a bridge which is up.

---

---

---

JUST AN EXPERIMENT BEFORE YOU CONTINUE

Your virtual_bridge is now up but your ethernet card might be up or down. Now read these two scenarios I figured out by trial and error. It is very important (!) so that you will understand how your ethernet card reacts. You might try this or not, but I advise you to do it exactly like described below while watching the 1st terminal for changes.

Scenario A:

If your ethernet card is down try to assign a master to it with a command below. It will work:

sudo ip link set enx24f5a2f17b27 master virtual_bridge

and now turn it on:

sudo ip link set enx24f5a2f17b27 up

you will be surprised that card won't connect you to the internet. It won't make it even if you restart it:

sudo ip link set enx24f5a2f17b27 down
sudo ip link set enx24f5a2f17b27 up

and not even if you restart the bridge that is card's master who should control it:

sudo ip link set virtual_bridge down
sudo ip link set virtual_bridge up

the only way I managed to make it connect to the internet was to restart the card, remove the master, flush it to remove all IP (maybe this isn't needed), manualy assign a known & working IP and then assign the master:

sudo ip link set enx24f5a2f17b27 down
sudo ip link set enx24f5a2f17b27 up
sudo ip addr flush enx24f5a2f17b27
sudo ip addr add 192.168.64.100/24 dev enx24f5a2f17b27
sudo ip link set enx24f5a2f17b27 master virtual_bridge

At this point internet should start working.

Scenario B:

If your ethernet card is up it probably has an IP and your internet must be working. So now try to assign it a master with a command below. It will work!

sudo ip link set enx24f5a2f17b27 master virtual_bridge

Now reset the bridge multiple times and pay attention what happens to a card:

sudo ip link set virtual_bridge down
sudo ip link set virtual_bridge up
sudo ip link set virtual_bridge down
sudo ip link set virtual_bridge up

You will see that whenever you enable the bridge ethernet card will also be enabled, it will get IP and connect to the internet. But once you turn off the card:

sudo ip link set enx24f5a2f17b27 down

it won't be able to reconect to the internet no mater how many times you reset the bridge.

So this is why it is most important that you first turn on the ethernet card and second asign it a master and not the other way around! In other words card should be enabled when you are assigning a master.

---

---

---

STEP 3

As we learned from the example above, we first (!) turn on the ethernet card which will get an IP:

sudo ip link set enx24f5a2f17b27 up

and then we assign it a master:

sudo ip link set enx24f5a2f17b27 master virtual_bridge

we create a TAP device which is like a virtual ethernet card for the virtual machine. It is important (!) that you assign a user and a group to it, because it might not have proper privileges otherwise:

sudo ip tuntap add virtual_tap mode tap user ziga group ziga

Now that you created it, you can try to enable it, but you won't suceed, because only virtual machine can do that:

sudo ip link set virtual_tap up

so it will remain in the down state. Just apply the master to it as well:

sudo ip link set virtual_tap master virtual_bridge

and you are done with setting up the network. Pay attention that at this point your TAP device won't have IP. It will be assigned to it when you start the virtual machine and wait for virtual machine to set itself up.

---

---

---

STEP 4

Now it is time to properly start the virtual machine. I do it using the newest -nic command which is shorter and more capable (!) than old commands (read). Well anyway... I use this command:

qemu-system-x86_64 -enable-kvm -cpu host -smp cores=3,threads=1 -m 4096 -nic tap,ifname=virtual_tap,script=no,downscript=no -boot order=c -cdrom ~/Dropbox/workspace/racunalnistvo/programi/kvm/iso/centos-8.1.1911-x86_64-dvd1.iso -drive file=~/Dropbox/workspace/racunalnistvo/programi/kvm/vm/windows.qcow2,format=qcow2

If you ommit options script=no and downscript=no the above comand will return a harmless warning:

RTNETLINK answers: Operation not permitted
W: /etc/qemu-ifup: no bridge for guest interface found

which happens because prior to emulation Qemu tryies to auto set up it's own bridge & TAP with a script /etc/qemu-ifup. It will also try to remove the bridge & TAP after it is finished with a script /etc/qemu-ifdown. If you look into these scripts you will see that they use command brctl which is part of a package bridge-utils that I don't have installed and scripts fail!

We created the bridge & TAP devices manually anyway so we don't need those scripts and we prevent Qemu to call them with script=no and downscript=no.

It would be interesting to rewrite these scripts to use iproute2 instead of bridge-utils but you would need root privileges to run them and experts disadvise us running virtual machines as root.

Virtual machine will start, connect to the internet, but it won't be able to ping host! Also the host will be able to connect to the internet and will be able to ping the same gateway. But it won't be able to ping a virtual machine!

Also pay attention to the 1st terminal where you will see that TAP device is now enabled and it got an IP, but this IP here is different than the one you see from inside the virtual machine! Can anyone explain this?

---

---

---

TODO

This is how much I was able to figure out and I hope it helps someone. I stil don't know why host and virtual machine can't ping eachother as TAP device should enable TCP, UDP & ICMP... I suspect that it is because I have to somehow assign IP to the bridge (read, read) but I don't know how to choose the right one. Can anyone help in the comments?

I've just had a very similar problem with a QEMU Linux guest and it has turned out that iptables was blocking the traffic. If I set up a static IP address for the guest then the host and the guest could ping each other but that was it. The internet and the rest of my network couldn't be reached from the guest machine.

I highly recommend you to use something like Wireshark or tcpdump to investigate the problem.

I've captured the bridge interface from the host using Wireshark and it seemed like requests were coming out from the virtual machine but no response was received.

TL;DR: This clue led me to the magic iptable commands (it was magical for me because I'm not experienced enough with iptables :)) in the following answer:

https://serverfault.com/a/165786

It worked and even if I don't fully understand it at this very moment I thought I would leave my two cents here.

Good luck!