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