Bootproblem wegen Netzwerkkarte: "A start job is running for Network Initialization"

[Sebi-S]

Hallo,

seit dem letzten Reboot bleibt einer unserer Nodes beim Bootvorgang stehen. Grund dafür ist offenbar die Initialisierung der Netzwerkkarte und/oder Bonds.


In dem Status bleibt der Node auch über Stunden stehen.

Das Booten in Version 5.15.83 ist erfolgreich, aber sobald ich 5.15.102 benutze, wiederholt sich das Problem.


Bisher habe ich nur wenig zum Problem finden können.

Parallel kommt dazu das Problem, dass auf dem Node Ceph/OSD nicht mehr funktionieren und für Fehlermeldungen auf dem Cluster sorgen.

Hier Inhalt von /etc/network/interfaces:

auto lo
iface lo inet loopback

auto ens259f0
iface ens259f0 inet manual
        mtu 8950

auto ens259f1
iface ens259f1 inet manual
        mtu 8950

auto bond0
iface bond0 inet manual
        bond-slaves ens259f0 ens259f1
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4
        mtu 8950

#Management
auto vmbr0
iface vmbr0 inet static
        address 192.168.80.241/24
        gateway 192.168.80.254
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        mtu 8950

#Ceph
auto vmbr0.100
iface vmbr0.100 inet static
        address 192.168.81.241/24
        mtu 8800

#OSD
auto vmbr0.101
iface vmbr0.101 inet static
        address 192.168.82.241/24
        mtu 8800

 

[Fab1984]

Hallo,

ich arbeite auch mit an dem Problem und möchte noch ein paar Angaben ergänzen:

1.) Wir haben einen 3-Node Cluster die alle gleich assembliert und konfiguriert sind, aber das Problem tritt nur bei dem besagten Node auf. Auch alle Netzwerkeinstellungen sind identische(bis auf die letzte Oktette der IP-Adresse.
2.) Die physischen Switches sind auf allen Ports und Portchannels (natürlich unterschiedliche Channels je Node) gleich konfiguriert.
3.) Die VLANs sind auf den Portchannels allowed
4.) Alle Nodes haben die gleiche Firmware und Netzwerkkarten Treiber Version.

Zur Umgebung:
- Es werden Switches mit IPL, Portchannels und MLAG benutzt
- Wir nutzen CEPH und SDN als Proxmox Features
- Es handelt sich um einen 3-Node Cluster auf Intel M50CYP Basis mit Intel 810 100GBE OCP3.0 Modulen


Sollte es für das Problem keine Lösung geben, wäre ein Workarround wie man den Node, unter Berücksichtigung der Clusterkonfiguration (inkl. Ceph und SDN) sauber aus dem Cluster entfernt, neu installiert und wieder integriert hilfreich. Da das System Live ist, sind wir für jeden konstruktiven Ansatz dankbar.

EDIT:
Wir haben nun alle Nodes auf Version 5.15.83 gestartet und unter vmbr0 können sich alle Nodes erreichen (ping-test) auf den VLANs vmbr0.100 und vmbr0.101 können sich nur Node 2 + 3 sehen. Node 1 kann auf diesen VLAN-Interfaces weder erreicht werden, noch die anderen Nodes erreichen. Unter vmbr0 ist das allerdings kein Problem.
Ich habe die VLAN Interfaces gelöscht und neu erstellt, leider ohne erfolg. Es schein daran zu liegen. Wir werden morgen die VLAN Interfaces löschen und prüfen, ob der Node dann mit der neuen Version startet.

LG

 

[Falk R.]

Hi,
ihr habt da ganz komische MTU Einstellungen. Außerdem ist die Netzwerkkonfiguration nicht wirklich empfohlen. Der eine Bond ist keine richtige Redundanz. Ich nutze bei den Intel Server immer die onboard 25GBit Adapter für LAN und Corosync. Dann 100GBit für Ceph und second Corosync. Das erklärt noch nicht das Phänomen, aber ich würde einmal mit einer vernünftigen MTU Konfiguration (9000) testen und notfalls je einen Uplink des Bond deaktivieren. Ich habe schon ganz komische Phänomene in Verbindung mit MLAG gesehen und das würde ich gern ausschließen.

 

[Falk R.]

Ich sehe gerade im Post von Fab, dass ihr die 100GBit OCP nutzt. Ich würde für Produktiv schon noch die 250€ pro Server für eine 25GBit Karte investieren.

 

[Fab1984]

Danke für den Tipp mit den deaktivieren der Netzwerkkarten. Das hat die Lösung gebracht!

Wenn ich nur ens259f0 im bond lasse, läuft auf einmal super. Bei ens259f1 only im bond geht nichts. Wieder zurück auf ens259f0 geht alles sofort wieder. Entweder haben wir in der Switch Konfiguration einen Fehler (eigentlich schon geprüft) oder vielleicht ist ja auch ein DAC Kabel defekt.

Auf jeden Fall vielen Dank für die super schnelle und kompetente Rückmeldung. Mit den Verbesserungsvorschlägen zur Topologie werden wir uns gerne nach der Fehlerbehebung befassen und dir nochmal ein Feedback geben.

 

[Falk R.]

Hi, das liegt vermutlich am MLAG. Sind das ganz zufällig DELL Switches?

 

[Falk R.]

Das Phänomen kenne ich von Dell mit MLAG und Cisco mit VPC. Für mich nix neues, nur die Ursache kenne ich auch noch nicht. Da bin ich mit mehreren Kunden dran. Betrifft auch ganz oft ESXi.

 

[Fab1984]

Wir nutzen Arista DCS-7170-64C Switches und haben dort insgesamt 15 Proxmox Nodes und Proxmox Backup Server dran. Alles mit der gleichen Portchannel/MLAG Konstellation. Bei uns trat das Phänomen heute zum ersten mal auf. Dennoch werden wir morgen alles einmal prüfen und geben dir eine Rückmeldung woran es bei uns lag und wie wir es final gelöst haben.

 

[Falk R.]

Bitte prüft die Verbindung auch bei den anderen Knoten. Ich habe schon große vSphere Cluster gesehen, die nur durch Zufall richtig liefen, bis der Fehler bei einem Host auftrat. Alle Server an den gleichen Switches hatten den gleichen Effekt, wenn der falsche Uplink deaktiviert wurde.

 

[Fab1984]

Wir haben den Fehler in der Switch Konfiguration gefunden und behoben. Komisch, dass das so lange fehlerfrei lief.

Nun läuft der Cluster auf der alten PVE Version im Allgemeinen stabil, aber der PVE Update Fehler ist nach wie vor vorhanden. Viel schwerwigender ist jedoch, das wir keine VMs mehr starten können die Qemu64 CPU Emulation haben. Eine Umstellung auf Host CPU Emulation blieb erfolglos bzw. das TPM Modul könnte eingreifen. Hier ein Beispiel:
ask viewer: VM 172 - Start

AusgabeStatus

Stopp

Herunterladen
/dev/rbd2
swtpm_setup: Not overwriting existing state file.
kvm: tpm-emulator: TPM result for CMD_INIT: 0x101 operation failed
stopping swtpm instance (pid 509100) due to QEMU startup error
TASK ERROR: start failed: QEMU exited with code 1


Kann es sein, dass das Laufwerk beschädigt wurde bei der ganzen CEPH Neusynchronisierung und es Zufall ist, dass nur VMs mit QEMU64 CPU-Emulation betroffen sind?
Wir hätten sonst Verdacht, dass durch das Update irgendetwas an der QEMU Server Version geändert wurde was nun Probleme macht. Deshalb würden wir die VMs gerne auf Host CPU umstellen, aber bekommen da eventuell das TPM Problem?

Wie immer wäre ich für Rat dankbar ;-)

 

[Falk R.]

Könnt ihr mir sagen was der Fehler auf dem Switch war?
Bei den aktuellen Updates, waren auch Updates für qemu dabei. Habt ihr Bitlocker in der VM, oder warum benötigt ihr den TPM?

 

[Fab1984]

Die Portchannel auf dem zweiten Switch haben Ihre allowed VLANs verloren. Ich bin mir sicher, das gestern nach den ersten Problemen mit dem Update geprüft zu haben, aber letztendlich lag es daran.
Das letzte Problem konnten wir auch lösen indem wir das Storage für TPM entfernt und für die VM ein Neues erstellt haben.

 

[Neobin]

seit dem letzten Reboot bleibt einer unserer Nodes beim Bootvorgang stehen. Grund dafür ist offenbar die Initialisierung der Netzwerkkarte und/oder Bonds.

In dem Status bleibt der Node auch über Stunden stehen.

Das Booten in Version 5.15.83 ist erfolgreich, aber sobald ich 5.15.102 benutze, wiederholt sich das Problem.

Siehe auch:

• https://bugzilla.proxmox.com/show_bug.cgi?id=4604
• https://forum.proxmox.com/threads/g...ng-and-2-active-interfaces.124326/post-541945

Speziell den Kommentar von @Stoiko Ivanov: [1].

Am besten auch (in Englisch) in dem Bugzilla-Ticket antworten und deine/eure komplette Situation, zusammen mit den von @fabian angefragten Infos: [2] schildern.

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=4604#c2
[2] https://forum.proxmox.com/threads/g...ng-and-2-active-interfaces.124326/post-542000

 

[Stoiko Ivanov]

pve-kernel-5.15.104-1-pve ist auf dem pvetest repository verfügbar und sollte einen potentiell fix enthalten - sind über feedback dankbar!

 

[castes]

Bin möglicherweise auf das gleiche Problem beim Aufsetzen neuer Nodes gestoßen: Der aktuelle ISO Installer proxmox-ve_7.4-1.iso enthält ebenfalls Kernel 5.15.102-1-pve. Wenn man nach der Installation versucht einen Linux Bond anzulegen, hängt der Server:



Mit ISO Installer proxmox-ve_7.3-1.iso lief der Rollout neuer Nodes mit Bonds problemlos.

Freue mich schon auf einen neuen ISO Installer mit aktualisiertem Kernel...

Auch folgender Thread dürfte auf das gleiche Problem mit Bonds in Kernel 5.15.102-1-pve gestoßen sein:
https://forum.proxmox.com/threads/problem-with-bond-after-upgrade-to-7-4.124862/