Proxmox VMs - No Route to Host

[keytrickz]

Hallo,

wir haben aktuell Probleme mit der Netzwerkverbindung zu den VMs unter Proxmox 7.2-4.
Dies betrifft ein Cluster mit zwei Nodes auf den die VMs betrieben werden.

Fehlerbild:
Sporadisch sind die VMs nicht erreichbar, sobald diese auf den anderen Nodes migriert werden, kann eine Verbindung (ssh, monitoring etc.) wieder aufgebaut werden.
In diesem Zeitraum ist der jeweilige Node dennoch voll erreichbar, lediglich die darauf liegenden VMs nicht.
Die Fehlermeldung bei "nicht-erreichbarkeit":
No route to host

Temporäre Abhilfe kann durch einen Neustart des Nodes behoben werden, jedoch ist dies nicht sinn und zweck des Proxmox-Clusters.

Die Netzwerk-Konfiguration der Nodes ist schlicht gehalten:

auto lo
iface lo inet loopback

iface enp0s31f6 inet manual

auto enp3s0
iface enp3s0 inet static
        address 10.0.30.2/28
        gateway 10.0.30.1
auto vmbr0
iface vmbr0 inet manual
        bridge-ports enp0s31f6
        bridge-stp off
        bridge-fd 0

Hatte jemand bereits ein ähnliches Fehlerbild oder einen Einsatz zum Debugging?
mfg

 

[shrdlicka]

Servus,

kannst du vielleicht den corosync log posten journalctl -u corosync.service?

 

[oguz]

hi,

einen Einsatz zum Debugging?

man kann waehrend einer migration auf beiden nodes die kommandos dmesg -w und journalctl -f am separaten fenster ausfuehren und schauen was fuer fehlermeldungen auftauchen.

In diesem Zeitraum ist der jeweilige Node dennoch voll erreichbar, lediglich die darauf liegenden VMs nicht.
Die Fehlermeldung bei "nicht-erreichbarkeit":
No route to host

sind alle VMs auf den nodes nicht erreichbar? oder nur die migrierende VM?

 

[keytrickz]

Servus,

kannst du vielleicht den corosync log posten journalctl -u corosync.service?

Moin!

Folgend die Logeinträge seit dem letzten Neustart.

Jun 02 09:39:28 HOST02 systemd[1]: Started Corosync Cluster Engine.
Jun 02 09:39:33 HOST02 corosync[1809]:   [KNET  ] rx: host: 1 link: 0 is up
Jun 02 09:39:33 HOST02 corosync[1809]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Jun 02 09:39:33 HOST02 corosync[1809]:   [KNET  ] pmtud: Global data MTU changed to: 469
Jun 02 09:39:33 HOST02 corosync[1809]:   [QUORUM] Sync members[2]: 1 2
Jun 02 09:39:33 HOST02 corosync[1809]:   [QUORUM] Sync joined[1]: 1
Jun 02 09:39:33 HOST02 corosync[1809]:   [TOTEM ] A new membership (1.11c6) was formed. Members joined: 1
Jun 02 09:39:33 HOST02 corosync[1809]:   [QUORUM] This node is within the primary component and will provide service.
Jun 02 09:39:33 HOST02 corosync[1809]:   [QUORUM] Members[2]: 1 2
Jun 02 09:39:33 HOST02 corosync[1809]:   [MAIN  ] Completed service synchronization, ready to provide service.
Jun 02 09:39:49 HOST02 corosync[1809]:   [KNET  ] pmtud: PMTUD link change for host: 1 link: 0 from 469 to 1397
Jun 02 09:39:49 HOST02 corosync[1809]:   [KNET  ] pmtud: Global data MTU changed to: 1397
Jun 02 09:44:37 HOST02 corosync[1809]:   [CFG   ] Node 1 was shut down by sysadmin
Jun 02 09:44:37 HOST02 corosync[1809]:   [QUORUM] Sync members[1]: 2
Jun 02 09:44:37 HOST02 corosync[1809]:   [QUORUM] Sync left[1]: 1
Jun 02 09:44:37 HOST02 corosync[1809]:   [TOTEM ] A new membership (2.11ca) was formed. Members left: 1
Jun 02 09:44:37 HOST02 corosync[1809]:   [QUORUM] This node is within the non-primary component and will NOT provide any services.
Jun 02 09:44:37 HOST02 corosync[1809]:   [QUORUM] Members[1]: 2
Jun 02 09:44:37 HOST02 corosync[1809]:   [MAIN  ] Completed service synchronization, ready to provide service.
Jun 02 09:44:38 HOST02 corosync[1809]:   [KNET  ] link: host: 1 link: 0 is down
Jun 02 09:44:38 HOST02 corosync[1809]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Jun 02 09:44:38 HOST02 corosync[1809]:   [KNET  ] host: host: 1 has no active links
Jun 02 09:45:33 HOST02 corosync[1809]:   [KNET  ] rx: host: 1 link: 0 is up
Jun 02 09:45:33 HOST02 corosync[1809]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Jun 02 09:45:33 HOST02 corosync[1809]:   [QUORUM] Sync members[2]: 1 2
Jun 02 09:45:33 HOST02 corosync[1809]:   [QUORUM] Sync joined[1]: 1
Jun 02 09:45:33 HOST02 corosync[1809]:   [TOTEM ] A new membership (1.11cf) was formed. Members joined: 1
Jun 02 09:45:33 HOST02 corosync[1809]:   [QUORUM] This node is within the primary component and will provide service.
Jun 02 09:45:33 HOST02 corosync[1809]:   [QUORUM] Members[2]: 1 2
Jun 02 09:45:33 HOST02 corosync[1809]:   [MAIN  ] Completed service synchronization, ready to provide service.
Jun 02 19:00:05 HOST02 corosync[1809]:   [KNET  ] link: host: 1 link: 0 is down
Jun 02 19:00:05 HOST02 corosync[1809]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Jun 02 19:00:05 HOST02 corosync[1809]:   [KNET  ] host: host: 1 has no active links
Jun 02 19:00:07 HOST02 corosync[1809]:   [KNET  ] rx: host: 1 link: 0 is up
Jun 02 19:00:07 HOST02 corosync[1809]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)

 

[keytrickz]

hi,


man kann waehrend einer migration auf beiden nodes die kommandos dmesg -w und journalctl -f am separaten fenster ausfuehren und schauen was fuer fehlermeldungen auftauchen.


sind alle VMs auf den nodes nicht erreichbar? oder nur die migrierende VM?

Hallo Oguz,

das betrifft sämtliche VMs auf einem Node. Sobald ich eine/alle VMs auf den anderen Node migriere, sind diese wieder erreichbar.
Das ist aktuell die Abhilfe:
Problem taucht auf (VM nicht erreichbar) → VM auf anderen Node migrieren → Fehlerbehafteten Node neustarten → VM zurück migrieren.

 

[shrdlicka]

Heißt vielleicht nichts, aber laut corosync ist der link um 19:00:05 einmal weg gewesen für kurze Zeit. Geht crosync über enp3s0?

GIbt es einen Unterschied zwischen den beiden Netztwerk Ports enp3s0 und enp0s31f6?

 

[keytrickz]

Heißt vielleicht nichts, aber laut corosync ist der link um 19:00:05 einmal weg gewesen für kurze Zeit. Geht crosync über enp3s0?

GIbt es einen Unterschied zwischen den beiden Netztwerk Ports enp3s0 und enp0s31f6?

Ja, läuft über enp3s0. Einen Unterschied zu den beiden Ports gibt es keinen.

 

[shrdlicka]

Mein Vorschlag wäre den Port ( enp0s31f6 ) zu überwachen, ob der die gesamte Zeit UP ist. Also entweder den Link Status oder wenn möglich dem vmbr0 Interface eine IP geben und von einem anderen Server pingen.

 

[oguz]

Sporadisch sind die VMs nicht erreichbar

* was fuer eine netzwerkkarte hast du? ich wuerde die ausgabe von ip a schauen und lspci -v | grep Ethernet -C 2 gibt dir den treibernamen (Kernel modules)

wie @shrdlicka gemeint hat, den port ueberwachen und in den journal oder syslog nach enp0s31f6 greppen waere auch hilfreich:

grep enp0s31f6 /var/log/syslog -C 5 > syslog-grep.txt
journalctl | grep enp0s31f6 -C 5 > journal-grep.txt

danach die zwei resultierenden dateien schauen/hier uploaden

edit: fix interface name

 

[keytrickz]

@shrdlicka @oguz
Da das Problem zuletzt vor 5 Tagen aufgetreten ist, habe ich den aktuell betroffenden Node neugestartet und die VMs verteilt.
Ich werde dies noch einmal beobachten und sobald das Problem erneut auftritt, hier die aktuellen Logfiles reinposten, um auch entsprechend einen genauen Zeitpunkt mitteilen zu können.

 

[keytrickz]

* was fuer eine netzwerkkarte hast du? ich wuerde die ausgabe von ip a schauen und lspci -v | grep Ethernet -C 2 gibt dir den treibernamen (Kernel modules)

wie @shrdlicka gemeint hat, den port ueberwachen und in den journal oder syslog nach enp0s31f6 greppen waere auch hilfreich:

grep enp0s31f6 /var/log/syslog -C 5 > syslog-grep.txt
journalctl | grep enp0s31f6 -C 5 > journal-grep.txt

danach die zwei resultierenden dateien schauen/hier uploaden

edit: fix interface name

Hallo Oguz,

das Problem tauchte erneut am 11. um 19:50 Uhr zuletzt auf.

# lspci -v | grep Ethernet -C 2
Kernel modules: i2c_i801

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM (rev 31)
Subsystem: Intel Corporation Ethernet Connection (2) I219-LM
Flags: bus master, fast devsel, latency 0, IRQ 131, IOMMU group 9
Memory at df100000 (32-bit, non-prefetchable) [size=128K]
--
Kernel modules: e1000e

03:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
Subsystem: Intel Corporation I211 Gigabit Network Connection
Flags: bus master, fast devsel, latency 0, IRQ 17, IOMMU group 10


Im Anhang die beiden Logfiles.

 

[oguz]

Hallo Oguz,

das Problem tauchte erneut am 11. um 19:50 Uhr zuletzt auf.

# lspci -v | grep Ethernet -C 2
Kernel modules: i2c_i801

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM (rev 31)
Subsystem: Intel Corporation Ethernet Connection (2) I219-LM
Flags: bus master, fast devsel, latency 0, IRQ 131, IOMMU group 9
Memory at df100000 (32-bit, non-prefetchable) [size=128K]
--
Kernel modules: e1000e

03:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
Subsystem: Intel Corporation I211 Gigabit Network Connection
Flags: bus master, fast devsel, latency 0, IRQ 17, IOMMU group 10


Im Anhang die beiden Logfiles.

danke fuer die logs

es sieht nach einem bekannten bug mit e1000 driver aus [0]

kannst du bitte dieses workaround probieren:

apt install ethtool
ethtool -K enp0s31f6 gso off gro off tso off tx off rx off

und schauen ob das workaround dir weiterhilft?

danach solltest du die kernel trace in den logs nicht mehr sehen.

wenn ja, kann man auch permanent in /etc/network/interfaces eine post-up fuer das interface hinschreiben:

iface enp0s31f6 inet manual
    # other configuration options here
    # post-up goes below
    post-up ethtool -K enp0s31f6 tso off gso off

[0]: https://forum.proxmox.com/threads/e1000-driver-hang.58284/

 

[keytrickz]

danke fuer die logs

es sieht nach einem bekannten bug mit e1000 driver aus [0]

kannst du bitte dieses workaround probieren:

apt install ethtool
ethtool -K enp0s31f6 gso off gro off tso off tx off rx off

und schauen ob das workaround dir weiterhilft?

danach solltest du die kernel trace in den logs nicht mehr sehen.

wenn ja, kann man auch permanent in /etc/network/interfaces eine post-up fuer das interface hinschreiben:

iface enp0s31f6 inet manual
    # other configuration options here
    # post-up goes below
    post-up ethtool -K enp0s31f6 tso off gso off

[0]: https://forum.proxmox.com/threads/e1000-driver-hang.58284/

Hallo nochmal,

danke für die Rückmeldung! Leider hat dies keine Abhilfe geschaffen und die VM ist weiterhin nicht erreichbar. Von den Logeinträgen bleibt es unverändert.
Aktuell wird folgender Kernel genutzt, falls das weiterhilft: 5.15.35-1-pve

Hättest du weitere Ideen/Ansätze, die ich hierbei probieren könnte?

 

[oguz]

Leider hat dies keine Abhilfe geschaffen und die VM ist weiterhin nicht erreichbar. Von den Logeinträgen bleibt es unverändert.

siehst du immer noch im journal/syslog die e1000 eintraege mit einem trace?

kannst du bitte das ganze trace aus den logs hier posten?

Aktuell wird folgender Kernel genutzt, falls das weiterhilft: 5.15.35-1-pve

was bekommst du mit pveversion -v?

 

[keytrickz]

siehst du immer noch im journal/syslog die e1000 eintraege mit einem trace?

kannst du bitte das ganze trace aus den logs hier posten?


was bekommst du mit pveversion -v?

hier die letzten Einträge aus dem Journal.

Jun 13 14:25:26 HOST02 kernel: e1000e 0000:00:1f.6 enp0s31f6: Reset adapter unexpectedly
Jun 13 14:25:26 HOST02 kernel: vmbr0: port 1(enp0s31f6) entered disabled state
Jun 13 14:25:26 HOST02 kernel: vmbr0v31: port 1(enp0s31f6.31) entered disabled state
Jun 13 14:25:29 HOST02 ntpd[1526]: Deleting interface #10873 vmbr0, fe80::485f:34ff:fef1:86a5%4#123, interface stats: received=0, sent=0, dropped=0, active_time=11 secs
Jun 13 14:25:30 HOST02 kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Jun 13 14:25:30 HOST02 kernel: vmbr0: port 1(enp0s31f6) entered blocking state
Jun 13 14:25:30 HOST02 kernel: vmbr0: port 1(enp0s31f6) entered forwarding state
Jun 13 14:25:30 HOST02 kernel: vmbr0v31: port 1(enp0s31f6.31) entered blocking state
Jun 13 14:25:30 HOST02 kernel: vmbr0v31: port 1(enp0s31f6.31) entered forwarding state
Jun 13 14:25:32 HOST02 ntpd[1526]: Listen normally on 10874 vmbr0 [fe80::485f:34ff:fef1:86a5%4]:123
Jun 13 14:25:32 HOST02 ntpd[1526]: new interface(s) found: waking up resolver
Jun 13 14:25:32 HOST02 kernel: e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
                                        TDH                  <0>
                                        TDT                  <3>
                                        next_to_use          <3>
                                        next_to_clean        <0>
                                      buffer_info[next_to_clean]:
--
                                      MAC Status             <80083>
                                      PHY Status             <796d>
                                      PHY 1000BASE-T Status  <3800>
                                      PHY Extended Status    <3000>
                                      PCI Status             <10>
Jun 13 14:25:34 HOST02 kernel: e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
                                        TDH                  <0>
                                        TDT                  <3>
                                        next_to_use          <3>
                                        next_to_clean        <0>
                                      buffer_info[next_to_clean]:
--
                                      MAC Status             <80083>
                                      PHY Status             <796d>
                                      PHY 1000BASE-T Status  <3800>
                                      PHY Extended Status    <3000>
                                      PCI Status             <10>
Jun 13 14:25:36 HOST02 kernel: e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
                                        TDH                  <0>
                                        TDT                  <3>
                                        next_to_use          <3>
                                        next_to_clean        <0>
                                      buffer_info[next_to_clean]:
--
                                      MAC Status             <80083>
                                      PHY Status             <796d>
                                      PHY 1000BASE-T Status  <3800>
                                      PHY Extended Status    <3000>
                                      PCI Status             <10>
Jun 13 14:25:38 HOST02 kernel: e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
                                        TDH                  <0>
                                        TDT                  <3>
                                        next_to_use          <3>
                                        next_to_clean        <0>
                                      buffer_info[next_to_clean]:

Zwecks pveversion:

# pveversion -v
proxmox-ve: 7.2-1 (running kernel: 5.15.35-1-pve)
pve-manager: 7.2-4 (running version: 7.2-4/ca9d43cc)
pve-kernel-5.15: 7.2-3
pve-kernel-helper: 7.2-3
pve-kernel-5.4: 6.4-16
pve-kernel-5.3: 6.1-6
pve-kernel-5.0: 6.0-11
pve-kernel-5.15.35-1-pve: 5.15.35-3
pve-kernel-5.4.178-1-pve: 5.4.178-1
pve-kernel-5.4.60-1-pve: 5.4.60-2
pve-kernel-5.3.18-3-pve: 5.3.18-3
pve-kernel-5.0.21-5-pve: 5.0.21-10
pve-kernel-5.0.15-1-pve: 5.0.15-1
ceph-fuse: 14.2.21-1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: 0.8.36+pve1
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.2-1
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-2
libpve-guest-common-perl: 4.1-2
libpve-http-server-perl: 4.1-2
libpve-storage-perl: 7.2-4
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.12-1
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.2.1-1
proxmox-backup-file-restore: 2.2.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.5.1
pve-cluster: 7.2-1
pve-container: 4.2-1
pve-docs: 7.2-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.4-2
pve-ha-manager: 3.3-4
pve-i18n: 2.7-2
pve-qemu-kvm: 6.2.0-8
pve-xtermjs: 4.16.0-1
qemu-server: 7.2-3
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.4-pve1

 

[oguz]

koenntest du bitte das ganze journal von beiden nodes posten? journalctl -b0 > journal-node1.txt

Zwecks pveversion:

stimmen die versionen ueberein bei beiden nodes?

 

[keytrickz]

koenntest du bitte das ganze journal von beiden nodes posten? journalctl -b0 > journal-node1.txt


stimmen die versionen ueberein bei beiden nodes?

Hallo Oguz,

vom anderen Node(host01), wo aktuell das Problem nicht vorliegt, das Journal im Anhang.
Vom problembehafteten Node(host02) ist die Datei leider zu groß zum Anhängen (gezippt 3MB), wäre eine Unterteilung in einzelnen Dateien für dich in Ordnung?

Die Versionen von beiden Nodes sind 1:1 identisch.

 

[oguz]

vom anderen Node(host01), wo aktuell das Problem nicht vorliegt, das Journal im Anhang.

danke.
ja, man sieht dass seit juni 7 die e1000 error bei diesem node HOST01 nicht mehr auftaucht.

Vom problembehafteten Node(host02) ist die Datei leider zu groß zum Anhängen (gezippt 3MB), wäre eine Unterteilung in einzelnen Dateien für dich in Ordnung?

du kannst die journal file splitten: split -n 4 journal-node2.txt, dann haettest du kleinere files.

hast du uebrigens das workaround auf beiden nodes getan?

 

[keytrickz]

danke.
ja, man sieht dass seit juni 7 die e1000 error bei diesem node HOST01 nicht mehr auftaucht.


du kannst die journal file splitten: split -n 4 journal-node2.txt, dann haettest du kleinere files.

hast du uebrigens das workaround auf beiden nodes getan?

Im Anhang die Logfiles.

Den Workaround hatte ich auf den Node02 probiert, da aktuell das Problem vorliegt, um gleich zu sehen ob das Problem behoben wird - auf dem Node01 ist das Problem in den letzten Wochen nicht erneut aufgetreten.

 

[keytrickz]

@oguz hättest du hierbei noch Ideen?