[SOLVED] Nach Aktivierung SR-IOV (NIC) ist die PVE GUI nicht erreich- & pingbar

T

tricorax

New Member
Feb 19, 2026
4
0
1
Germany
Hallo Forum !

Vorweg: Ich bin Linux Anfänger, verstehe Netzwerktechnik -gut- und habe ein Problem mit meinem PVE Node.

Ausgangsituation:
Lenovo P330 Tiny mit Dual 10GbE NIC (SM AOC-STGN-i2s) nachgerüstet. PVE(ZFS) frisch installiert (v9.1.0) und für die NIC SR-IOV gemäß folgendem Thread erfolgreich eingerichtet. Nach Reboot startet die PVE Umgebung problemlos.
  • Port 8006 ist offen,
  • Prozesse PVEdaemon, PVEproxy laufen
  • (Autostart) VMs (W11 Sandbox, Paperless-Instanz) starten problemlos.
  • Einträge aus /etc/hosts & /etc/hostname scheinen für mich ebenfalls in Ordnung.
  • In meiner Unifi Oberfläche werden keine IP-Addresskonflikte oder Portprobleme (STP) erkannt
  • Ein zweiter PVE-Node mit den grundsätzlich gleichen Einstellungen ist problemlos erreichbar (ältere PVE Version ohne SR-IOV)
Trotzdem kann ich nicht auf die PVE ManagementGUI zugreifen und die Maschine ist nicht pingbar/per SSH erreichbar. Der ganze Traffic läuft derzeit (noch) über vmbr0 (eno1). Die beiden Ports der 10G NIC haben jeweils eine IP-Adresse (im gleichen Netz) zugewiesen aber keinen Link zum LAN (disconnected).

Auszüge der aktuellen Config des PVE-Nodes:

Code: 
root@pve:~# cat /etc/hosts

127.0.0.1 localhost.localdomain localhost
10.200.10.111 pve.primary pve

# The following lines are desirable for IPv6 capable hosts

::1 ip6-localhost

fe00::0 ip6-localnet  ip6-loopback
ff00::0 1p6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
root@pve:~#

Code: 
root@pve:~# cat /etc/hostname
pve

root@pve:~#
Code: 
pve root@pve:~# cat /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 eno1 inet manual

auto enp1s0f0
iface enp1s0f0 inet static
    address 10.200.10.50/24

auto enp1s0f1
iface enp1s0f1 inet static
    address 10.200.10.55/24

auto vmbr0
iface vmbr0 inet static
address 10.200.10.111/24
gateway 10.200.10.1

bridge-ports eno1
bridge-stp off
bridge-fd e

source /etc/network/interfaces.d/*

root@pve:~#
Code: 
root@pve:~# ip addr

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: eno1: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc fq_codel master vmbro state UP group default qlen 1000
    link/ether 98:fa:9b:0c:ce:ef brd ffffffffff:ff
    altname enp0s31f6
    altname enx98fa9b0cceef
3: enp1s0f0: <NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 0c:c4:7a:bc:60:5e brd ffffff:ff:ff:ff
    altname enx0cc47abc605e
    inet 10.200.10.50/24 scope global enp1s0f0
    valid_lft forever preferred_lft forever
4: enpis0f1: <NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 0c:c4:7a:bc:60:5f brd ffffffff:ff:ff
    altname enx0cc47abc605f
    inet 10.200.10.55/24 scope global enp1s0f1
    valid_lft forever preferred_lft forever
5 : vmbr0: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 98:fa:9b:0c:ce:ef brd ffffffffff:ff
    inet 10.200.10.111/24 scope global vmbr0
    valid_lft forever preferred_lft forever
    inet6 fe80::9afa:9bff:fe@c:ceef/64 scope link proto kernel_11
    valid_lft forever preferred_lft forever
6: tap10010: <BROADCAST, MULTICAST, PROMISC, UP, LOWER_UP> mtu 1500 qdisc fq_codel master vmbr0 state UNKNOWN group default qlen 1000
    link/ether @a:8d:5b:e6:de: 13 brd ffffffffff:ff
7: veth1201@@if2: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
     link/ether fe:e0:fb:b5:75:c9 brd ffffffffffff link-netnside
root@pve:~#

Weiß hier jemand Rat?
 
Last edited:
Bitte konvertiere keine Bilder zu Text. Das erzeugt eine unansehnliche Formatierung und schleicht kleine Fehler wie vmbro oder bridge-fd e oder 1p6-mcastprefix ein. Man kann sich auf nichts was man sieht verlassen.
Ich nutze bei solchen Netzwerk Problemen gerne temporär DHCP wie folgt
Bash: 
# Für PVE 8 / Debian 12
ifdown vmbr0; dhclient -v
dhclient -r; ifup vmbr0

# Für PVE 9 / Debian 13
ifdown vmbr0; dhcpcd -d
dhcpcd -k; ifup vmbr0
Dann kannst du dir mal den Auszug ansehen sowie ip a und ip r und ping testen.
Die zweiten Befehle sind jeweils am Ende nach den Tests auszuführen um den Urspungszustand wiederherzustellen.
 
Last edited:
  • Like
Reactions: tricorax
Impact said:
Bitte konvertiere keine Bilder zu Text. Das erzeugt eine unansehnliche Formatierung und schleicht kleine Fehler wie vmbro oder bridge-fd e oder 1p6-mcastprefix ein. Man kann sich auf nichts was man sieht verlassen.
Ich nutze bei solchen Netzwerk Problemen gerne temporär DHCP wie folgt
Bash: 
# Für PVE 8 / Debian 12
ifdown vmbr0; dhclient -v
dhclient -r; ifup vmbr0

# Für PVE 9 / Debian 13
ifdown vmbr0; dhcpcd -d
dhcpcd -k; ifup vmbr0
Dann kannst du dir mal den Auszug ansehen sowie ip a und ip r und ping testen.
Die zweiten Befehle sind jeweils am Ende nach den Tests auszuführen um den Ursprungszustand wiederherzustellen.
Click to expand...
Danke für die schnelle Rückmeldung. Mir schien es am praktikabelsten zu sein mittels Texterkennung den Console-Output in den Beitrag zu bekommen. Gerne nehme ich Ratschläge an, wie ich das besser umsetzen kann (außer alles händisch abzuschreiben was mehr Fehler produzieren dürfte).

Habe dhcpcd gemäß deinen Vorgaben ausgeführt. Als Linux Anfänger kann ich die Ausgabe nur bedingt interpretieren. Er hat das Interface vmbr0 deaktiviert (vmbr0 nicht als iface gelistet) und eno1 hat die festgelegte IP 10.200.10.111 vom DHCP zugewiesen bekommen. Zusätzlich hat das virtuelle iface veth120i0@if2 ebenfalls eine IP aus dem 169.254.x.x/16 Netz bezogen (keine Ahnung woher das kommt).


Geändert hat dhcpcd an meiner Problematik nichts. Das Problem besteht weiterhin.
Zusatzinfo: Auch die VM IP-Adressen erhalten eine ICMP Timeout. RDP-Verbindung auf die Win11 Sandbox VM (10.200.10.207) macht er ohne Probleme. ICMP geht nicht durch.

Da konvertieren böse ist, hier ein Screenshot der Console: o_O
screen.jpg

Nachtrag: Ein Ping über das Interface vmbr0 an das Gateway (10.200.10.1), den anderen PVE Node (.222) und Clients in anderen Subnetzen (.25.87) funktionieren. Insofern kann ich ausschließen, dass der Switch den Port aufgrund von Konflikten "dicht macht".
 
Last edited:
Hmm. Du kannst in diesem Falle mal DHCP mit den anderen NICs testen. Zum Beispiel
Bash: 
ifdown enp1s0f0; dhcpcd -d enp1s0f0
 
fba said:
bei enp1s0f0 und enp1s0f1 steht NO-CARRIER
Click to expand...
Das ist korrekt, da ich die SFP+-Ports der NiC nur nutzen kann, wenn der Tiny im Serverrack verbaut ist. Da ich derzeit nicht per SSH oder GUI draufkomme kann ich nur die integrierte i219 für das Netzwerk nutzen, da er für die direkte Administration in Arbeitszimmer stehen muss.

Wo kann ich im PVE Node die Konfiguration nachvollziehen, welches Interface als Management Interface initial eingerichtet wurde? Ich habe bei Recherchen nachlesen können, dass ggf. durch SR-IOV die Interface-Namen verändert wurden und dadurch die GUI nicht funktioniert.
 
Das Problem besteht nicht mehr. Es lag nicht am PVE-Node. Ich habe in der UniFi Oberfläche aus der Geräteübersicht den Node-Eintrag herausgelöscht. Danach war eine Verbindung zur GUI möglich. Ich nehme an, das irgendwie die ARP-Tabelle in UniFi den Fehler verursacht hat.
 
You must log in or register to reply here.
Top Bottom
Back