Virtual Machine Manager | Bridged Network | Why so complicated to achiev?

(I use the Mate-Compiz spin on my desktop computer [IntensePC])

How I was able to achieve it:

  1. Connection Details, Virtual Networks, clicking on the "+" change mode to "Open" (the rest is all default). This creates me a "virbr0"
  2. Now I stop "virbr0" on the red minus icon and while clicking o the trash it disappears in the connection details. While changing to terminal and type nmcli c it is still active. I stop it with nmcli c down virbr0
  3. Back in the “Connection Details” i do create "+"a new virtual network using the default as name: network
    This time I choose Mode: NAT and do let everything as it was (default). This creates me a Network connected to virbr0
  4. Opening my VM (QEMU/KVM) under NIC I select the Network source: Virtual network 'network :NAT'
  5. Now i can start the WM and do get DHCP working. I am able to ping my host and also able to communicate between them.

I used Virtualbox before and had the option there to create a bridged connection on the vm guest choosing the Host’s NW-adapter I wanted to use as bridge.

Is there a simpler way to achieve this? And is there a tool where i can control the status of the connections? A script I can use in terminal would be ok.


If you want to bridge the physical network to the VM, you first have to create the bridge in NetworkManager and add the physical NIC as a port of the bridge.

In this example, I’m bridging eth0 to a new bridge br0:

# nmcli con add con-name br0 ifname br0 type bridge autoconnect yes ipv4.method auto ipv6.method auto
# nmcli con add con-name br0-port ifname eth0 type ethernet slave-type bridge master br0 autoconnect yes

Note that your existing connection for the ethernet interface will have to be removed:

# nmcli con    # (Get the connection name)
# nmcli con delete "Wired connection 1"

With that in place, you can choose br0 as the bridge for your VMs.


Thanks that worked. What I observed is that the connection is much slower this way.

It also created me an Auto Ethernet connection. Is this normal ?

I’m not sure about that. I’d disable the autoconnect option of that new connection just to make sure it doesn’t get in the way:

# nmcli con modify "Auto Ethernet" connection.autoconnect no
1 Like

Would like to link a topic from Ask-fp-org who shows that I’m not alone with this libvirt/networking issues.

Learning by doing :muscle: :wink:

Since i use the bridged network as here described, and restrict the network management by using nmcli or nm-connection-editor I do have much more peace with libvirt :grin:

In Virtual Machine Manager > Edit > Connection Details > Virtual Networks, remove all networks.

Afterwards check the two points @glb mentions in the topic below.
Br0 suddenly stopped passing traffic - #5 by glb

When this done, do select the network on the specific VM as in the picture below:


Now you can start the VM

With this procedure you theoretically created you a virtual x-port switch where you connect all your VM’s.

If you use Fedora Workstation please do you the favor and use the nm-connection-editor instead of the build in Network editor in the Settings of Gnome 4.2x. Otherwise you will get bothered wit auto network etc … really annoying.

Of course, if you are a happy :grinning: Terminal user make use of nmcli to manage your network.

If you can, try to include toolbox or ‘podman’ with rootless containers, in your workflow.
I think this way you not have to fight wit this unnecessary routing troubles.

I will add this mini tutorial to the discussion on Might be that I will get some more Tricks/Tips to tweak the libvirt/network workflow.

Good luck

Thanks again @jorti

1 Like

Since middle of may i do use this kind of bridge. It serves very well.

Sometimes i do switch of the network with nmcli n off and nmcli n on
In this case it takes me quite a while till i get a network connection.

Comparing with a default network connection I saw that there is not ip4.route in the details while the default connection has one, like:                          Wired connection 1
IP4.ROUTE[1]:                           dst =, nh =, mt = 100
IP4.ROUTE[2]:                           dst =, nh =, mt = 100

My question is now how this route get added, and what it means. A part I understand:
dst=destination nh=next hop mt=?

Route 1 = to all addresses (no restriction ?) to default Gateway
Route 2 = to my network to all /24 (254) addresses in it.

Would this speed up the availability of the bridge (br0) if i would have this route set too?
I guess I have to set the network manually?

Thanks in advance for some hints.

Thanks! Will give it a go!

This thread is a bit confusing as it starts with configuring a virtual network and then shifts to a shared bridged wired connection.

Those are essentially different connectivity methods with their own pros and cons.

Yes … I was confused trying to make it the way as I described in my first request. I marked now the second request as solution. So the idea is doing it straight away as marked as solution.

Ask and discussion where still separate when I made the request on discussion and reached out for different audience.

1 Like

On a new installed Fedora 38 I used the above instructions and had also a look on the manual here:

To create a bridge and add a adapter/port to it. Now it looks like this:

nmcli c
NAME                  UUID                                  TYPE      DEVICE  
bridge-br0            xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxaaa  bridge    br0     
lo                    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxcb2  loopback  lo      
bridge-slave-enp0s25  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx3c3  ethernet  enp0s25

This works.
While the computer comes back from suspend an additional connection is created and it looks like this:

nmcli c
NAME                  UUID                                  TYPE      DEVICE  
bridge-br0            xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxaaa  bridge    br0     
lo                    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxcb2  loopback  lo      
enp0s25               xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx5ba  ethernet  enp0s25 
bridge-slave-enp0s25  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx3c3  ethernet  --     

I can not switch this auto connection off. It really seams that this auto networking from Gnome is making me a hard live. Can someone tell me how to deactivate that I like it documented here ?

sudo tee /etc/NetworkManager/conf.d/00-bridge.conf << EOF > /dev/null
sudo systemctl restart NetworkManager.service

NetworkManager.conf: NetworkManager Reference Manual

Unfortunately I can not make it work. I created the file as you proposed and even after boot i checked if it is still there (it is!) and in the file sudo cat /var/lib/NetworkManager/no-auto-default.state where it should list the mac address, from the enp0s25 I could not find it. There was just a mac-address from the inactive, unconnected adapter.
I added the mac-address of enp0s25 manually but it is not ignored as intended, even not after a reboot.

The suspend I made with the power button as I did set this option in gnome settings.

It looks like a race condition, and the result depends on the order of instructions and currently active connections.

The bridge works fine for me when created like this:

sudo nmcli connection delete bridge-br0 bridge-slave ethernet enp0s25
sudo nmcli connection add type bridge ifname br0 bridge.stp no
sudo nmcli connection add type bridge-slave master bridge-br0
sudo systemctl restart NetworkManager.service 

But I can reproduce the issue this way:

sudo nmcli connection delete bridge-br0 bridge-slave ethernet enp0s25
sudo nmcli connection add type bridge ifname br0 bridge.stp no
sudo nmcli connection add type ethernet
sudo nmcli connection modify ethernet master bridge-br0 slave-type bridge
sudo systemctl restart NetworkManager.service 

A workaround is to explicitly put down the automatic connection:

sudo nmcli connection down enp0s25
sudo nmcli connection up ethernet

The automatic connection seems to be runtime-only and disappears when disconnected.

If the issue persists, I recommend replacing NetworkManager with systemd-networkd.
In my experience, the latter is more predictable and better suits the server.

1 Like