[SOLVED] No internet on local PVE install (VMs are fine)

[goldsteal]

Hello proxmox nerds!

In the last few months I decided to use PVE more in my private projects, which is why I installed it again on a private desktop computer with an AM4-base (read: consumer hardware).

After I created a few VMs and gave one of them a GPU I now have the following issue. I never get it configured correctly so that both my VMs have access to the Internet with IPv4 at the same time as the host/PVE.

I tried to use the standard config but nothing I changed worked.

Please let me know which outputs and information you require in order to help me.

This is what

ip a

yields right now:

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: enp5s0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether 70:85:c2:c1:bb:59 brd ff:ff:ff:ff:ff:ff
    inet 169.254.140.52/16 brd 169.254.255.255 scope global enp5s0
       valid_lft forever preferred_lft forever
    inet6 fe80::7285:c2ff:fec1:bb59/64 scope link
       valid_lft forever preferred_lft forever
3: bridge1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether ea:7e:8e:ba:f8:05 brd ff:ff:ff:ff:ff:ff
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 70:85:c2:c1:bb:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.66/24 scope global vmbr0
       valid_lft forever preferred_lft forever

My

/etc/network/interfaces

:

# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!
auto lo
iface lo inet loopback

iface enp5s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.66/24
        gateway 192.168.1.1
        bridge-ports enp5s0
        bridge-stp off
        bridge-fd 0

I am sure it's obvious stuff, but I seem to be blind here.

Greetings and thanks for trying to help

goldsteal

 

[UdoB]

Your "enp5s0" has an IP address. Is the default route set on that (APIPA) network? With or without an really existing gateway? You see my point.

ip route show please...

 

[goldsteal]

ip route show

0.0.0.0 dev enp5s0 scope link
default dev enp5s0 scope link
default via 192.168.1.1 dev vmbr0 proto kernel onlink
1.1.1.1 dev enp5s0 scope link
169.254.0.0/16 dev enp5s0 proto kernel scope link src 169.254.193.206
192.168.1.0/24 dev vmbr0 proto kernel scope link src 192.168.1.66

Ok. There seem to be plenty of things wrong here. Would you mind going through it with me as if I was the dumbest user imaginable?

 

[UdoB]

Well..., I can tell you what I would do. Though I have no idea where that mess came from ;-)

If possible reboot. Perhaps "ip addr show"/"ip route" looks cleaner afterwards.

If not: remove the wrong entries manually. This will not be persistent as we do not know the source of these configuration bits. And of course I can not test it, so from my mind, as a first try:

ip route del 0.0.0.0 dev enp5s0
ip route del default dev enp5s0

ip addr del 169.254.193.206/16 dev enp5s0 
ip addr del 1.1.1.1 dev enp5s0

Possibly you get an error with this commands. Change the order and repeat, or report here.


At the end "ip route show" ideally lists only two lines, similar like this:

default via 192.168.1.1 dev enp5s0 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.66

Good luck...

 

[goldsteal]

Thank you, Udo! This helped somewhat, yet of course it's not persistent.
I figured out the culprit eventually:
It was network management of one or possibly even multiple DEs I installed on the PVE.

Sadly I also renamed the PVE, while trouble shooting PVE and while trying to rectify that it behaved *weirdly* as alluded to in the documentation, deleting the entire /etc/pve/* on reboot and also corrupting the database. After trying for a few hours I reinstalled PVE and thankfully I had all the virtual drives on a different HDD. So hopefully I can get my VMs back.

This is solved for me. Be careful renaming the host while the node is still attached, when you try to forcefully move /etc/pve/old_node to etc/pve/new_node – it WILL result in data loss AFAICS.