You are not logged in.
I want to have a virtual machine be assigned an IP on my host's network from the same DHCP server as my host
For example:
host ip: 10.0.0.2
VM ip: 10.0.0.3
I am using nmtui to try to create the bridge. I have followed the steps on this wiki page and this video I found - but to no avail. I get to the step of assigning an interface to the bridge then exiting out of the TUI and trying to start the bridge. In my KDE plasma network manager applet it gets stuck saying 'assigning IP address'. Are there any special DHCP settings I need to configure on my routing appliance to get this to work or are these just outdated guides I am following?
Any pointers would help a bunch and thanks in advance ![]()
Offline
How does your host network looks like?
ip aIs your main network card a wireless one?
Offline
How does your host network looks like?
ip aIs your main network card a wireless one?
My main card is ethernet and I am configuring it for ethernet.
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
3: wlo1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
Last edited by talowicz (2025-11-10 19:56:18)
Offline
Since you mentioned DHCP: Are you aware that the bridge device chooses it's own (artificial) MAC address and the Ethernet device "loses" it's network functionality as a slave to the bridge?
Offline
Since you mentioned DHCP: Are you aware that the bridge device chooses it's own (artificial) MAC address and the Ethernet device "loses" it's network functionality as a slave to the bridge?
So I wont be able to have network connection on the host and the guest at the same time?
Offline
So I wont be able to have network connection on the host and the guest at the same time?
No - you just need to be aware that your bridge requests the DHCP lease with a different MAC.
Offline
talowicz wrote:So I wont be able to have network connection on the host and the guest at the same time?
No - you just need to be aware that your bridge requests the DHCP lease with a different MAC.
I am guessing that STP must be enabled for this to work, otherwise the DHCP server will not know of a new host?
Offline
i recommend cockpit for managing VMs using libvirt, you can create a network bridge very easily with a few clicks
Offline
I am guessing that STP must be enabled for this to work, otherwise the DHCP server will not know of a new host?
I am not aware of a simple bridge setup like yours needing STP. I have always disabled it.
Maybe it's time you share some more info on your setup (not shortened / only redacted).
ip asudo ls -l /etc/NetworkManager/system-connectionsOffline
I've had the same issues with trying to set up a bridge with Network Manager, I think the Plasma integration is just buggy. In the end I ditched NetworkManager for that system and used systemd-networkd instead, which solved all issues for me.
Offline
talowicz wrote:I am guessing that STP must be enabled for this to work, otherwise the DHCP server will not know of a new host?
I am not aware of a simple bridge setup like yours needing STP. I have always disabled it.
Maybe it's time you share some more info on your setup (not shortened / only redacted).
ip asudo ls -l /etc/NetworkManager/system-connections
Here is my output of 'ip a':
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff permaddr XX:XX:XX:XX:XX:XX
inet 192.168.0.3/24 brd 192.168.0.255 scope global dynamic noprefixroute enp2s0
valid_lft 7102sec preferred_lft 7102sec
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff permaddr XX:XX:XX:XX:XX:XX
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb state DOWN group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 192.168.211.1/24 brd 192.168.211.255 scope global virbr0
valid_lft forever preferred_lft foreverAnd my network manager connections (for ethernet and virbr0 which is a defconf NAT bridge for VMs - I dont use my wireless card):
'New 802-3-ethernet connection.nmconnection'
'Wired connection 1.nmconnection'These are the connections before I try to add a bridge. When I add a bridge, a new br0 interface is created as expected and being tied to enp2s0, disappears when it is DOWN.
Offline
So here's your situation as far as I understand it:
Your Ethernet adapter still works as a standalone device and is not attached to any kind of bridge.
You have installed qemu & libvirt. The latter installed a "NAT" bridge "vibr0" with it's own IPv4 subnet. For full NAT functionality this bridge needs to add a physical adapter to the "NAT" bridge. This bridge needs an physical adapter to forward packets to. Now you try to install an additional "bridge" ("br0") for your VM to have direct access to your LAN and that bridge also needs a physical adapter as a member.
Looks to me like you have to choose: Either manage your bridge connection through libvirt and it's "vibr0" or do it manually via "br0" - but the latter means to prevent "vibr0" from interfering and "grabbing" your Ethernet adapter,.
Since I use bridged VMs but not libvirt I am unable to say what's the best approach here.
Edit: I just implemented (manually w/o libvirt) a setup like yours. A "NAT" bridge can forward packets to another bridge ("LAN access") that has an Ethernet slave. VMs can be connected to either bridge depending on their network access.
Last edited by -thc (2025-11-25 16:13:27)
Offline