[16:59] <wdop_> Hello, I have a problem bridging ethernet on Ubuntu 21.04 (Host) into kvm/qemu. I had a working configuration until for some reason I deleted the bridge using nm-connection-editor. Now the "wired connection" inside the vm is not working anymore. Anyone could help me?
[17:01] <wdop_> I asked in #ubuntu and someone sent me here..
[17:03] <wdop_> I tried setting up a bridge but when I want to add a bridged connection "ethernet" on the next dialog I cannot choose a device.
[17:41] <tomreyn> wdop_: you can also use brctl to set it up
[18:00] <wdop_> @tomreyn, I look into that now. Thanks!
[18:05] <wdop_> @tomreyn, "brctl show" returns:
[18:05] <wdop_> virbr0		8000.525400423a34	yes
[18:06] <wdop_> just one line. I am wondering how to proceed from here. In fact, my knowledge is very limited concerning this things.
[18:16] <tomreyn> wdop_: you can create a bridge using "brctl", then optionally attach interfaces to it using "brctl addif", btut you can actually do this with "ip", too.
[18:17] <tomreyn> either command provides help on usage and a man page
[18:18] <wdop_> Thanks, I barely understand the terms :( Are there good examples of how to do this? I am looking here atm: https://computingforgeeks.com/managing-kvm-network-interfaces-in-linux/
[18:19] <tomreyn> !man
[18:19] <tomreyn> https://www.linux-kvm.org/page/Networking
[18:20] <tomreyn> you seem to want a "Private Virtual Bridge"
[18:21] <tomreyn> actually i don't know that, you might as well want a public one
[18:21] <wdop_> Yes :) I all worked until I deleted the bridge in a stupid move yesterday. Thanks again. I will try my best!
[18:22] <wdop_> I am on 21.04 on a laptop and have 20.04 running inside kvm (w/o working wired connection)
[18:24] <wdop_> One more question: What is the type of bridge that is used when first installing kvm on a clean system and then running another Ubuntu in the vm?
[18:24] <TJ-> wdop_: that's not done with kvm; I think what you may be using is libvirt/virt-manager ?
[18:24] <wdop_> yes
[18:25] <TJ-> wdop_: in which case if it's the virbr0 you deleted, restarting libvirtd service will recreate it
[18:25] <TJ-> virbr0 is used as part of the default network for the hypervisor
[18:26] <wdop_> How would I check if it is recreated? 
[18:27] <TJ-> wdop_: restart the service (stop the guest first) "sudo systemctl restart libvirtd"
[18:27] <wdop_> done
[18:27] <TJ-> wdop_: then "ip link show dev virbr0" should show it has been recreated
[18:28] <wdop_> 5: virbr0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
[18:28] <wdop_>     link/ether 52:54:00:42:3a:34 brd ff:ff:ff:ff:ff:ff
[18:28] <TJ-> wdop_: now restart the guest and you should be OK
[18:28] <wdop_> really? ok, lat's see
[18:28] <TJ-> wdop_: first guest using that bridge should cause the bridge to be put into state UP
[18:29] <wdop_> no
[18:29] <wdop_> In the UI it shows Wired connecting...
[18:29] <TJ-> wdop_: then it is possible you have some other form of network configured in libvirt/virt-manager
[18:30] <wdop_> how would I check?
[18:31] <TJ-> wdop_: what does "virsh net-list" report?
[18:31] <wdop_>  Name      State    Autostart   Persistent
[18:31] <wdop_> --------------------------------------------
[18:31] <wdop_>  default   active   yes         yes
[18:32] <wdop_> ip link show dev virbr0
[18:32] <wdop_> 5: virbr0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
[18:32] <wdop_>     link/ether 52:54:00:42:3a:34 brd ff:ff:ff:ff:ff:ff
[18:32] <TJ-> wdop_: show us "virsh net-dumpxml default" (in a pastebin)
[18:33] <wdop_> https://pastebin.com/VasyuLs4
[18:34] <TJ-> wdop_: now lets check the guest(s) and what they are connected to. " virsh list --all | nc terbmin.com 9999 "
[18:35] <TJ-> oops, typo
[18:35] <TJ-> wdop_: now lets check the guest(s) and what they are connected to. " virsh list --all | nc termbin.com 9999 "
[18:35] <TJ-> got the m and b swapped!
[18:35] <wdop_> https://termbin.com/qg8j
[18:36] <TJ-> so it'll be ubuntu20.04 ?
[18:36] <wdop_> Both are the same image.
[18:36] <wdop_> Let's take the MPI-Ae
[18:37] <TJ-> " virsh dumpxml MPI-AE | nc termbin.com 9999 "
[18:37] <wdop_> virsh dumpxml MPI-AE | nc termbin.com 9999
[18:38] <wdop_> https://termbin.com/fn54
[18:40] <TJ-> you've got the correct linkage in there " <interface type='network'>"
[18:41] <TJ-> so starting the guest should work
[18:42] <TJ-> if the problem is solely the guest cannot get to the Internet, then you may affected the host iptables rules
[18:42] <TJ-> libvirt sets up IP Masquerading for IPv4 via iptables
[18:42] <wdop_> It is in state "connecting" again. no luck
[18:43] <TJ-> wdop_: what is 'it' ? the guest's GUI network applet ?
[18:44] <wdop_> sorry! yes. the applet on the top right says "Wired Connectiong" and also under Settings -> Network
[18:45] <TJ-> wdop_: ok, in the guest start a terminal, then check the log with "journalctl -u NetworkManager -n 50" 
[18:45] <wdop_> Now on the guest: "Activation of the network connection failed"
[18:45] <TJ-> that'll show the last 50 messages, and in there should be a clue as to why
[18:45] <wdop_> You give me hope!
[18:46] <wdop_> Should I pate the output? patebin?
[18:46] <wdop_> *paste
[18:46] <TJ-> if the interface is set to use IPv4 DHCP and that is what is failing, then there's a problem with the hypervisor's DHCP service
[18:47] <TJ-> If I recall correctly, the libvirt makes uses of private dnsmasq instances 
[18:47] <TJ-> so on the host check if any are active, with "ps -efly | grep dnsmasq "
[18:47] <wdop_> https://pastebin.com/vKnmM8uc
[18:48] <TJ-> "dhcp4 (enp1s0): request timed out"
[18:48] <TJ-> so we've now confirmed that is the cause
[18:48] <wdop_> ps -efly | grep dnsmasq
[18:48] <wdop_> S libvirt+    1513       1  0  80   0  1948  2439 -      03:36 ?        00:00:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
[18:48] <wdop_> S root        1514    1513  0  80   0   332  2432 -      03:36 ?        00:00:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
[18:49] <TJ-> wdop_: other than deleting the virbr0 using nmcli, did you do anything else network related, like add/remove iptables rules?
[18:49] <TJ-> wdop_: those are the expected processes, owned by libvirt too
[18:49] <wdop_> 1. I deleted the bridge using the nm-connection-manager
[18:50] <wdop_> 2. I installed/purged protonvpn
[18:51] <wdop_> 3. Then installed protonvpn again
[18:51] <TJ-> wdop_: I'm thinking you've altered something in iptables by doing that. Show us "sudo iptables-save | nc termbin.com 9999 "
[18:51] <wdop_> Currently it is not running
[18:52] <wdop_> https://termbin.com/8fli
[18:55] <TJ-> wdop_: that all looks correct too
[18:55] <wdop_> To ansswer your question from before, I didn't execute any iptables commands before.
[18:55] <TJ-> I'm wondering if it is routing, which the vpn may have messed with
[18:56] <TJ-> show us " ip route show | nc termbin.com 9999 "
[18:56] <wdop_> ip route show | nc termbin.com 9999
[18:56] <wdop_> https://termbin.com/jbh4
[18:58] <TJ-> It's a while since I used IPv4 networking but that looks correct; nothing there affecting the virbr0 network
[18:59] <wdop_> hm. I will now completely purge the protonvpn, in the meantime
[18:59] <TJ-> I don't see anything affecting it right now
[19:00] <wdop_> ok
[19:04] <wdop_> Would a "apt purge" for kvm/qemu maybe help in resetting the configuration? Thanks so much for your help so far. 
[19:04] <TJ-> is the guest active right now? if so, is the bridge in state UP? "ip lnk show dev virbr0"
[19:04] <TJ-> oops, another typo. "ip link show dev virbr0"
[19:05] <wdop_> 5: virbr0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
[19:05] <wdop_>     link/ether 52:54:00:42:3a:34 brd ff:ff:ff:ff:ff:ff
[19:05] <wdop_> no problem, a realized this ;)
[19:05] <TJ-> hmmm, it's still down! try "sudo ip link set up dev virbr0"
[19:06] <wdop_> done
[19:06] <wdop_> ip link show dev virbr0
[19:06] <wdop_> 5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
[19:06] <wdop_>     link/ether 52:54:00:42:3a:34 brd ff:ff:ff:ff:ff:ff
[19:06] <TJ-> !!
[19:06] <wdop_> I return nothing, btw
[19:06] <TJ-> wdop_: have you by chance enabled systemd-networkd on this host?
[19:06] <wdop_> idk
[19:07] <TJ-> if there were a config, and it is somehow set to manage virbr0, then it could be forcing this
[19:07] <TJ-> that interface should be UP now
[19:08] <TJ-> wdop_: show us " ip -d link show | nc termbin.com 9999 "
[19:09] <wdop_> https://termbin.com/f13hk
[19:10] <TJ-> ahhh "vnet1" is "tun type tap" 
[19:11] <wdop_> If I knew what this means really..
[19:13] <TJ-> I'm setting up an identical config here to compare
[19:14] <wdop_> wow
[19:15] <wdop_> I will copy the chat history and work through this again to understand the steps we took!
[19:17] <TJ-> is it working for you? I'm seeing identical results here to commands but the guest got an address from DHCP without a problem
[19:18] <TJ-> turns out virbr9 showing state DOWN is correct :s
[19:19] <wdop_> How should I check, just starting the guest and "journalctl -u NetworkManager -n 50"
[19:19] <TJ-> actually no, virbr0 is state UP here
[19:19] <wdop_> aha
[19:21] <TJ-> I'm not sure what you've done!
[19:23] <TJ-> let's see if the host's NM is doing something. " journalctl -u NetworkManager -n 250 | nc termbin.com 9999 !
[19:24] <wdop_> https://termbin.com/b97oa
[19:26] <wdop_> doing nothing...
[19:27] <wdop_> >Reminder: Host is 21.04, Guest is 20.04
[19:29] <TJ-> that looks ok;I can see you deleted the 2 NM connections that were attached to the bridge and vnet port
[19:29] <TJ-> so NM isn't trying to manage them as far as that log shows
[19:30] <TJ-> I'd have thought that "device (virbr0): carrier: link connected" would imply "ip link show dev virbr0" should show state UP now
[19:30] <wdop_> 5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
[19:30] <wdop_>     link/ether 52:54:00:42:3a:34 brd ff:ff:ff:ff:ff:ff
[19:30] <wdop_> It is up now.
[19:30] <wdop_> ?
[19:32] <TJ-> aha!
[19:32] <TJ-> so has the guest been able to get an IPv4 address ?
[19:32] <wdop_> No.
[19:33] <TJ-> hmmph
[19:33] <TJ-> when (date/time) did you delete the working config? I want to find the log entries from before then to learn how it was configured when it worked
[19:34] <wdop_> hwo to I check? dhclient?
[19:34] <TJ-> was it today? yesterday?
[19:34] <wdop_> yesterday.
[19:34] <TJ-> so 3rd Oct
[19:34] <TJ-> roughly what time of day?
[19:34] <wdop_> yes
[19:35] <wdop_> start from 18:00, but not 100% sure
[19:37] <wdop_> Should I reboot the guest?
[19:37] <TJ-> no, it doesn't look to be the problem
[19:38] <TJ-> show us " journalctl -u NetworkManager --since="2021-10-03 12:00" --until="2021-10-03 22:00" | nc termbin.com 9999 "
[19:39] <wdop_> https://termbin.com/aojo
[19:40] <wdop_> hmmm, too big?
[19:40] <TJ-> ow, looks like loads of VPN errors
[19:40] <wdop_> I grep them out?
[19:41] <TJ-> lets filter it:  " journalctl -u NetworkManager --since="2021-10-03 12:00" --until="2021-10-03 22:00" | grep -v AEAD | nc termbin.com 9999 "
[19:41] <wdop_> https://termbin.com/nrp2
[19:45] <wdop_> I had this problem with the pvpn-killswitch that was still there in the table of connections after uninstalling protonvpn yesterday. This prevented wifi from connecting. So I deleted the bridge first. but this didn't help. Then deleted the two protonvpn connections that were still there. After that WIFI on the host worked again.
[19:45] <wdop_> But the guest then had this current issue which we are working on now.
[19:46] <TJ-> hmmm. Can't see anything useful in the log, aside from an apparent confirmation it was working at "Okt 03 21:23:49 nador NetworkManager[1332]: <info>  [1633289029.9938] device (virbr0): bridge port vnet5 was attached"
[19:46] <wdop_> Wait maybe it was after midnight?
[19:47] <wdop_> https://termbin.com/c1xy
[19:47] <TJ-> unfortunately there's not enough info in the logs to reconstruct how it was configured
[19:56] <wdop_> I am thankful for your help, even when we cannot solve it. What would you advice me to do? 
[19:57] <TJ-> one thing we haven't done is look at the libvirtd log
[19:57] <wdop_> ok
[19:57] <TJ-> show us " journalctl -u libvirtd -n 500 | nc termbin.com 9999 "
[19:58] <TJ-> I notice here it reports some dnsmasq DHCP actions
[19:58] <wdop_> https://termbin.com/9wwu
[19:59] <TJ-> aha! "DHCP packet received on virbr0 which has no address"
[19:59] <TJ-> so, either libvirt isn't adding the address, or something is removing it whwn libvirt does
[20:00] <TJ-> lets try it manually to begin with, from the options we saw earlier
[20:00] <TJ-> " sudo ip addr add 192.168.122.1/24 dev virbr0 "
[20:00] <TJ-> then ensure it 'stuck' with "ip addr show dev virbr0 "
[20:01] <wdop_> ip addr show dev virbr0
[20:01] <wdop_> 5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
[20:01] <wdop_>     link/ether 52:54:00:42:3a:34 brd ff:ff:ff:ff:ff:ff
[20:01] <wdop_>     inet 192.168.122.1/24 scope global virbr0
[20:01] <wdop_>        valid_lft forever preferred_lft forever
[20:01] <wdop_>     inet6 fe80::5054:ff:fe42:3a34/64 scope link 
[20:01] <wdop_>        valid_lft forever preferred_lft forever
[20:01] <TJ-> good, now poke the guest see if it'll get an address
[20:01] <wdop_> yeah!!!!
[20:01] <TJ-> the libvirt 'default' network config you showed earlier says it should be setting that address
[20:02] <TJ-> https://pastebin.com/VasyuLs4
[20:02] <TJ-> so either that had a glitch, or something else is removing the address when it is added
[20:03] <wdop_> just reboot and see if it is permanently fixed?
[20:03] <TJ-> last time it worked: "Okt 03 21:23:59 nador dnsmasq-dhcp[1946]: DHCPACK(virbr0) 192.168.122.111 52:54:00:e2:cb:27 franks"
[20:03] <wdop_> ok
[20:04] <TJ-> reboot should never be needed on Linux, just stop/start the correct services
[20:04] <TJ-> so, lets manually clean up and stop things then start them again
[20:04] <wdop_> yes I know ;) it has always been "networking" but this is gone in 21.04, no?
[20:04] <TJ-> 1. Shutdown the guest  2. on host "sudo systemctl stop libvirtd" 
[20:05] <TJ-> 3. check if virbr0 has gone "ip link show dev virbr0"
[20:06] <wdop_> 1. DONE 2. sudo systemctl stop libvirtd
[20:06] <wdop_> Warning: Stopping libvirtd.service, but it can still be activated by:
[20:06] <wdop_>   libvirtd-admin.socket
[20:06] <wdop_>   libvirtd-ro.socket
[20:06] <wdop_>   libvirtd.socket
[20:06] <wdop_> ip link show dev virbr0
[20:06] <wdop_> 5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
[20:06] <wdop_>     link/ether 52:54:00:42:3a:34 brd ff:ff:ff:ff:ff:ff
[20:07] <TJ-> hmm
[20:07] <TJ-> make sure the service stopped "systemctl status libvirtd"
[20:07] <wdop_> Start it manually?
[20:08] <TJ-> we want virbr0 to disappear
[20:08] <wdop_> ● libvirtd.service - Virtualization daemon
[20:08] <wdop_>      Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
[20:08] <wdop_>      Active: inactive (dead) since Mon 2021-10-04 22:06:07 CEST; 1min 54s ago
[20:08] <TJ-> good, dead
[20:08] <TJ-> let's manually remove the interface: "sudo ip link del dev virbr0"
[20:09] <wdop_> DONE
[20:09] <TJ-> check if has gone "ip link show dev virbr0"
[20:09] <wdop_> Device "virbr0" does not exist.
[20:09] <TJ-> great
[20:09] <TJ->  "systemctl start libvirtd" and then "ip link show dev virbr0; ip addr show dev virbr0"
[20:11] <wdop_> systemctl start libvirtd
[20:11] <wdop_> efemha@nador:~$ ip link show dev virbr0; ip addr show dev virbr0
[20:11] <wdop_> Device "virbr0" does not exist.
[20:11] <wdop_> Device "virbr0" does not exist.
[20:11] <TJ-> it's not re-adding it is it?
[20:11] <TJ-> I'm doing the same ops here
[20:12] <wdop_> sudo systemctl status libvirtd
[20:12] <wdop_> ● libvirtd.service - Virtualization daemon
[20:12] <wdop_>      Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
[20:12] <wdop_>      Active: active (running) since Mon 2021-10-04 22:10:39 CEST; 1min 24s ago
[20:13] <wdop_> ip link show dev virbr0; ip addr show dev virbr0
[20:13] <wdop_> Device "virbr0" does not exist.
[20:13] <wdop_> Device "virbr0" does not exist.
[20:13] <TJ-> ok do "virsh net-start default" and that should do it
[20:13] <wdop_> Network default started
[20:13] <TJ-> check it has an IP address
[20:13] <wdop_> ip link show dev virbr0; ip addr show dev virbr0
[20:13] <wdop_> 57: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
[20:13] <wdop_>     link/ether 52:54:00:42:3a:34 brd ff:ff:ff:ff:ff:ff
[20:13] <wdop_> 57: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
[20:13] <wdop_>     link/ether 52:54:00:42:3a:34 brd ff:ff:ff:ff:ff:ff
[20:13] <wdop_>     inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
[20:13] <wdop_>        valid_lft forever preferred_lft forever
[20:13] <shibboleth> wdop_, also: i highly recommend apt-get install virt-manager
[20:13] <TJ-> yes!
[20:14] <TJ-> wdop_: so, that seems to have solved it. Make sure the 'default' libvirt network is set to autostart. "virsh net-autostart default"
[20:15] <wdop_> virsh net-autostart default
[20:15] <wdop_> Network default marked as autostarted
[20:15] <wdop_> ok
[20:15] <wdop_> start the guest?
[20:16] <TJ-> so, from now on we know the key is that the bridge must have the IP address set
[20:16] <TJ-> Yes
[20:16] <wdop_> ok, it is not everything 100% clear to me but I will go through it again.
[20:17] <TJ-> I'm not clear why libvirt didn't add the address to the bridge, but that was the cause
[20:17] <shibboleth> wdop_, install virt-manager on your client and you'll have a local gui to administer this on the server/host through ssh
[20:17] <TJ-> shibboleth: please don't interfere; you lack context
[20:18] <wdop_> @shibboleth I have it already installed.
[20:18] <shibboleth> or, read up on ifupdown, bridges, vlans, and... woldermort/netplan :P
[20:18] <shibboleth> TJ-, 10-4
[20:19] <TJ-> shibboleth: we use virsh since it is precise in giving commands and seeing output via pastebins
[20:19] <shibboleth> sure
[20:19] <shibboleth> 10-4: police code/rtx for received and understood
[20:19] <wdop_> @TJ so rebooting the host should not change anything ?
[20:20] <TJ-> wdop_: in theory, it should remain good (libvirt/default network)
[20:21] <TJ-> wdop_: good to know we fixed your issues faster than Facebook are fixing theirs :D
[20:21] <wdop_> OK, I will do the restart shortly. How can I thank you / tipp you. Are you paid fior this service you are giving.  
[20:22] <wdop_> ?
[20:22] <TJ-> no, it's community support (and education)
[20:24] <wdop_> I want to give something back, but don't know how. This is the least I can do. I am so thankful!
[20:28] <TJ-> pay forward; give your expertise in whatever areas you're good at to others
[20:32] <wdop_> @TJ-, Yes, will do. These experiences strengthen altruism. 
[20:33] <wdop_> @TJ-, I will now reboot... and pray ;)
[20:34] <TJ-> wdop_: :D
[20:35] <wdop_> @TJ-, Bye. It was a pleasure having you as someone getting me out of this mess!