Proxmox stürzt ab. Gibt es irgendwo ein Log ?

[RudiP]

In letzter Zeit stürzt mein Proxmox so ein bis zweimal am Tag ab. Das Äußert sich dadurch, das sämtliche VM's nicht mehr erreichbar sind und auch Proxmox selbst nicht mehr reagiert.
Die Eingabeaufforderung auf dem Rechner, auf dem Proxmox läuft, ist aber noch da und auch nutzbar. Ein "reboot" Kommando funktioniert da und danach ist dann auch alles wieder da, bis zum nächsten Absturz.
Ich kann es leider an nichts festmachen, da es zu unterschiedlichen Zeiten passiert. Tagsüber, nachts, eigentlich immer irgendwann mal.

Was habe ich seit dem geändert ?
Ich hatte eine I3 CPU verbaut und wollte eine Grafikkarte an eine VM durchreichen. Dazu muß aber VT-d bzw. VT-x im BIOS aktiviert sein und die CPU muß das können.
Die I3 konnte das aber nicht, also habe ich ne I5 verbaut.
Die Abstürze kamen aber auch schon mit der I3 kurz nachdem ich die Versuche mit dem weiterleiten eines PCI Gerät versucht hatte.
Im BIOS finde ich aber nichts, wo ich den Fehler dran festmachen würde.
Frage ist, da ich an die Console ja noch dran komme, ob es irgendein Log gibt, das man aufrufen könnte.
Die Logs in Proxmox helfen nicht, da steht nur der Neustart drin, aber nichts zum Absturz.

 

[blurrrr]

Hi,

In letzter Zeit stürzt mein Proxmox so ein bis zweimal am Tag ab. Das Äußert sich dadurch, das sämtliche VM's nicht mehr erreichbar sind und auch Proxmox selbst nicht mehr reagiert.
Die Eingabeaufforderung auf dem Rechner, auf dem Proxmox läuft, ist aber noch da und auch nutzbar

"und auch Proxmox selbst nicht mehr reagiert"... damit meinst Du vermutlich das Webinterface? Das auf die Netzwerk-Funktionalität schliessen lassen. Wenn sowas wieder vorkommt, schau doch bitte mal, wie es sich mit einem "ping <Deine Router-IP>" verhält. Die IP vom PVE-Host sollte standardmässig auf vmbr0 laufen (sofern Du da nichts anderweitig konfiguriert hast). Schau dann auch mal mittels "ip a", ob das Interface auch "UP" ist.

Logs findest Du unter /var/log, da könntest Du ggf. mal in messages und syslog nachschauen. Sofern Du es direkt via Shell machst (z.B. via cat /var/log/messages), kannst Du mittels z.B. grep auch noch filtern:

cat /var/log/messages | grep -i vmbr0 (-i ignoriert die Groß- und Kleinschreibung)

Alternativ kannst Du auch direkt nach mehreren Dingen filtern ("oder") mittels:

cat /var/log/messages | grep -i -E "eth0|vmbr0"

Falls noch ein Bond-Interface dabei ist, dann halt z.B. so:

cat /var/log/messages | grep -i -E "eth0|vmbr0|bond0"

Das ist jetzt natürlich nur in Bezug auf die Netzwerk-Interfaces (ich vermute einfach mal, dass da netzwerktechnisch etwas im argen ist). Sei's drum, nach Fehlern kann man auch direkt suchen, z.B. in so einer Form:

cat messages |grep -E "err|fail"

Vielleicht findest Du auf diesem Wege ja etwas entsprechendes

 

[Confluencer]

Ich würde hier vermuten, dass das weiterreichen des PCI(e)-Geräts das Problem verursacht.

Gerade, wenn IOMMU im Bios nicht aktiviert ist, kann beim Durchreichen von PCI-Geräten etwas schief gehen.
Nach einem Mainboard-Tausch hatte ich das Problem, dass sobald eine VM mit durchgerichtem Storage-Controller lief, plötzlich PVE nicht mehr über das Netzwerk erreichbar war. Bei mir lag es am deaktivierten IOMMU (Achtung: danach nochmal die Addresse des durchgereichten PCI(e)-Geräts anpassen!)

Hier nochmal der Link zur Anleitung was alles gemacht werden muss: https://pve.proxmox.com/wiki/PCI(e)_Passthrough

 

[RudiP]

Au man. Das da einfach nur die LAN Verbindung weg sein könnte, kam mir nicht in den Sinn. Aber ja, kann natürlich sein, werde ich testen.

Das IOMMU das Problem ist, klar, denkbar, auch wenn ich es aktuell nicht nutze, die Einträge in diversen Config Dateien sind natürlich noch drin.
Schaue ich mir auch beim nächsten Absturz an.

Danke euch beiden für die Tipps.

 

[RudiP]

So, irgendwann mal diese Nacht zwischen 02:00 Uhr und 09:00 Uhr ist mein Proxmox mal wieder Offline gegangen.
PING auf die IP zeigt, das er nicht mehr erreichbar ist.
Dann bin ich an die Console und habe "IP a" eingegeben und er zeigt mir die Netzwerkverbindung an.
Ich habe jetzt testweise im BIOS mal den Multi Monitor Betrieb abgeschaltet, das war so eine Funktion, die ich beim Einbau einer Grafikkarte aktiviert hatte.
Wenn das nicht hilft, werde ich noch versuche, alle Einträge betreffend IOMMU wieder rückgängig zu machen.

Die Grafikkarte ist übrigens wieder raus, an der kann es also nicht liegen.
Was ich in letzter Zeit noch geändert hatte, der Router ist ein anderer.
Ich hatte hier so ja so extra dusselige Installation, weil ich Glasfaser bekommen hatte, DSL aber noch ne weile lief und darüber eben auch das Telefon.
Also hatte ich noch die alte Fritzbox 7590, dazu den Speedport zwecks Glasfaser. Das lief ja soweit auch alles, AVM war der Master, hat also die IP's vergeben.
Nachdem nun DSL weg ist, mußte ich den Speedport zum Master machen. Klappte auch alles, außer, das ein paar WLAN Geräte nun ne neue IP haben, was aber nicht das Problem ist. Der Proxmox hat ne feste IP.

 

[blurrrr]

Klappte auch alles, außer, das ein paar WLAN Geräte nun ne neue IP haben, was aber nicht das Problem ist. Der Proxmox hat ne feste IP.

IP-Adresse vom PVE-Host liegt auch ausserhalb des DHCP-Pools des Speedport?

 

[RudiP]

Nein, das nicht. Aber die Gültigkeitsdauer der IP im Speedport für den PVE ist auf 3 Wochen gesetzt. Eigentlich dürfte der Router diese IP doch gar nicht anderweitig vergeben, so lange diese in Benutzung ist, also das Gerät sich da anmeldet und selbst 2 Wochen nach der letzten Anmeldung dürfte der Router die nicht neu vergeben.
Aber ich habe ja gelernt, blurrr hat von nix Ahnung, aber man tut am besten mal, was er sagt.
Also darf der Speedport IP's jetzt erst eine Adresse später vergeben.

 

[blurrrr]

Eigentlich dürfte der Router diese IP doch gar nicht anderweitig vergeben, so lange diese in Benutzung ist

Das ist soweit richtig. Allerdings - ich mag mich hier irren - vergibt man doch bei der PVE-Installation sowieso schon statische Netz-Informationen:



Ist zumindestens mein Stand, von daher frage ich mich schon ein wenig, wie Du auf DHCP kommst? Es mutet auch etwas merkwürdig an, dass ein Gerät - welches Dienste im Netz anbietet - mit einer dynamischen IP versorgt wird. Um es mal ganz banal zu sagen: Dein Backofen ist ja auch in der "Küche" und das "fix" und nicht heute mal im Wohnzimmer und morgen im Schlafzimmer. Ebenso bleibt der Backofen auch dort, selbst wenn Du die Haustür auswechselst, die Wände neu streichst, oder gar umziehst. Der Backofen bleibt wo er ist. Ebenso sollte es sich für alle anderweitigen Geräte - welche Dienste im Netzwerk anbieten - verhalten. Du tauscht den Router? Kein Problem, aber nicht die Geräte sind an den neuen Router anzupassen, der neue Router wird an die eigene Umgebung angepasst. So vermeidet man auch den ganzen unnötigen Aufwand, alle betroffenen Geräte erneut bzgl. der Netzinformationen zu konfigurieren.

DHCP-Reservierungen sind ja eine "nette" Sache, fällt der Router aber mal aus, ist sofort Chaos im Netz. Kommt ein neuer Router dazu, ist auch erstmal Chaos im Netz (da die Reservierungen noch nicht vorhanden sind). Hier ist alles - was Dienste in irgendeiner Form im Netz bereitstellt - statisch eingerichtet. Alles Client-artige wird via DHCP versorgt (abgesehen von meiner Workstation). Somit kann ich dann auch - selbst bei DHCP-Ausfall (z.B. Firewall fällt aus) noch weiterhin auf alle internen Dienste zugreifen.

Für die Clients ist es i.d.R. sowieso egal, was für eine IP sie bekommen, da sie nie direkt angesprochen werden (ganz im Gegensatz zu internen Diensten). Man könnte sich sicherlich auch - bei Ausfall - an seiner Workstation noch kurzerhand selbst eine IP vergeben, da aber auch div. Firewall-Regeln an die Workstation gebunden sind, ist das hier halt so wie es ist.

DHCP läuft hier ja auch (keine Frage), aber DHCP hat hier nichts mit irgendwelchen Geräten zu tun, welche Dienste bereitstellen. Oftmals fängt so ein DHCP-Bereich ja bei 100 aufwärts an (Fritz!Box war - meine ich - ab 20 aufwärts), also ist zwischen dem Router (i.d.R. ".1") und dem Anfang des DHCP-Pools ja noch Platz. Diesen Platz kann man dann halt für seine statisch konfigurierten Geräte nutzen.

Ich habe hier jetzt nicht soviel laufen, aber mein DHCP-Pool beginnt ab 100 und der Teil davor wird halt für die statischen Dinge genutzt (managed Switche, WLAN-Accesspoints, NAS, IP-Cams, etc.).

Die Sache mit dem DHCP ist auch nur solange "nett", solange die entsprechende Namensauflösung funktioniert. Sollte es da mal irgendein Problem geben, ist man auch sofort aufgeschmissen, da man die IPs der gewünschten Geräte (mit Diensten) dann auch erstmal beim Router raussuchen darf. Diesbezüglich sei ggf. auch noch erwähnt, dass ich auf sowas intern auch komplett verzichte (mag laufen, interessiert mich aber nicht), da ich die Geräte dann normalerweise einfach direkt via IP anspreche (was natürlich umso leichter ist, wenn diese - egal was kommt - immer die ihre statische IP haben).

Aber ich habe ja gelernt, blurrr hat von nix Ahnung, aber man tut am besten mal, was er sagt.

Das würde ich so definitiv nicht unterstreichen Es gibt viele Meinungen und sicherlich auch viele Lösungen. Schlussendlich muss es jede Person für sich entscheiden. Es mag sicherlich Wege geben, welche - je nach Sicht - angenehmer sind, aber ebenso Wege, welche mitunter auch weniger fehleranfällig sind (dafür ggf. aber auch nicht so bequem). Da kann man eigentlich auch nur sagen: "Jeder ist seines eigenen Glückes Schmied", klingt zwar ziemlich abgedroschen, ist aber so...

Also darf der Speedport IP's jetzt erst eine Adresse später vergeben.

Ähm... das beisst sich jetzt aber ganz gewaltig mit:

Aber die Gültigkeitsdauer der IP im Speedport für den PVE ist auf 3 Wochen gesetzt.

Hat der PVE dann doch eine statische IP (am PVE-Host eingetragene) und Du hast einfach nur noch "zusätzlich" eine DHCP-Reservierung vorgenommen? Die "Gültigkeitsdauer" hat auch nichts mit einer Reservierung zu tun. Bzgl. der Lease-Time schau Dir doch mal den DHCP-Wikipedia-Artikel an bzw. konkreter dort den Block "DHCP-Refresh (nur bei dynamischer Zuordnung)".

Aber so oder so... statisch konfigurierte Dinge haben nichts im Bereich des DHCP-Pools zu suchen. Die "Lösung" den DHCP-Pool jetzt um eine IP zu verschieben...fragwürdig. Sinnvoller wäre es wohl gewesen, hätte man dem PVE-Host eine neue IP zugewiesen, aber jut... hauptsache Du weisst "irgendwann" noch, was Du da gemacht hast

Wer nix von "Problemen" lesen will, hört hier bitte auf zu lesen

Kommt dann ggf. irgendwann ein neuer Speedport, hat der erstmal seinen regulären DHCP-Pool-Bereich, irgendein Client wird sich die erste verfügbare IP schnappen und dann wird es direkt Trouble mit dem PVE-Host geben. Dummerweise nutzt es dann auch nix, wenn man den Router neustartet, da der Client ja mit seiner "Ewig-und-3-Tage"-Leasetime ja nun auch erstmal "etwas länger" der Meinung ist, dass die IP nun seine ist. Entweder wartet man nun (extrem) geduldig darauf, dass der Client die IP irgendwann wieder frei gibt, oder man startet den diebischen Client einfach neu. Natürlich muss man diesen dazu auch erstmal ausfindig machen und da man MAC-Adresse und/oder Hostnamen im Router sieht, "könnte" man den Client vielleicht sogar schnell ausfindig machen. Vielleicht aber auch nicht, je nach Situation halt.

Das ist dann so ein Punkt, wo ich persönlich sagen muss: Hätte ich ja mal so gar keine Lust zu... Sowas lässt sich durchaus vermeiden, aber es gibt Lösungen und Lösungen. Die Verschieberei des DHCP-Pools erinnert mich doch sehr stark an folgendes Szenario: Netzwerkverkabelung. Es gibt eine Doku, welches Kabel vom Patchfeld an welchen Port eines Switches geht. Der Switch ist via VLAN noch logisch in mehrere Netze aufgeteilt. Nun möchte jemand ein Gerät von Netzwerk A in Netzwerk B verfrachten. Der "korrekte" Weg wäre nun entsprechendes auf dem Switch abzuändern. Oftmals geht man aber einfach hin und steckt am Switch einfach solange um, bis es passt. Die Doku wird dabei natürlich nicht aktualisiert. Das führt dann in Folge dazu, dass die Doku - nach einiger Zeit - einfach komplett unbrauchbar wird.

Ich erwähne das jetzt auch nur, weil so ein Chaos mit diesen "mal eben"-Kleinigkeiten anfängt. Weisst Du denn in 5 Jahren noch, dass Dein DHCP-Pool nicht bei X, sondern bei X+1 anfängt? Hast Du es Dir irgendwo niedergeschrieben, falls es mal "Pöff" macht und nur noch ein kleines Rauchwölkchen aus dem Router aufsteigt?

Ja ich weiss... ist immer wieder ein Kreuz mit diesen blöden Bedenkenträgern, wird schon schief gehen, ist ja bisher auch nix passiert...

Es bleibt wie es ist: Jeder ist seines eigenes Glückes Schmied und damit ist das Thema eigentlich auch durch. Ich wollte mit dieser etwas längeren Passage auch nur dazu verleiten, dass man sein eigenes Konstrukt ggf. doch nochmal überdenkt. Wenn es für einen selbst passt, alles gut, falls man doch noch Zweifel hat, kann man an diesem Text ja ggf. einen kleinen Anstoss nehmen

 

[RudiP]

Das ist soweit richtig. Allerdings - ich mag mich hier irren - vergibt man doch bei der PVE-Installation sowieso schon statische Netz-Informationen:

Ist zu lange her, kann ich nicht mehr sagen.

Ist zumindestens mein Stand, von daher frage ich mich schon ein wenig, wie Du auf DHCP kommst? Es mutet auch etwas merkwürdig an, dass ein Gerät - welches Dienste im Netz anbietet - mit einer dynamischen IP versorgt wird.

Ähm, weil ich sehr viele WLAN Geräte habe, unmöglich den Überblick behalten kann, welche IP schon vergeben ist und da einfach den Weg des geringsten Widerstand gegangen bin ?

Um es mal ganz banal zu sagen: Dein Backofen ist ja auch in der "Küche" und das "fix" und nicht heute mal im Wohnzimmer und morgen im Schlafzimmer. Ebenso bleibt der Backofen auch dort, selbst wenn Du die Haustür auswechselst, die Wände neu streichst, oder gar umziehst. Der Backofen bleibt wo er ist. Ebenso sollte es sich für alle anderweitigen Geräte - welche Dienste im Netzwerk anbieten - verhalten. Du tauscht den Router? Kein Problem, aber nicht die Geräte sind an den neuen Router anzupassen, der neue Router wird an die eigene Umgebung angepasst. So vermeidet man auch den ganzen unnötigen Aufwand, alle betroffenen Geräte erneut bzgl. der Netzinformationen zu konfigurieren.

Mag sein, aber mal eben 130 Geräte neu Einrichten ist halt extrem aufwendig und da ist DHCP einfach der einfachere Weg. Hat ja soweit auch prima geklappt. Und der Proxmox Server hat ja ne feste IP, sollte also hier nicht das Problem sein.

DHCP-Reservierungen sind ja eine "nette" Sache, fällt der Router aber mal aus, ist sofort Chaos im Netz.

Wenn der ausfällt, habe ich eh kein Netz mehr. So what

Kommt ein neuer Router dazu, ist auch erstmal Chaos im Netz (da die Reservierungen noch nicht vorhanden sind).

Nein, keineswegs. Die wirklich wichtigen Geräte haben eine feste IP. Kommt ein neuer Router, fragen die doch bei dem an, ob die bitte ihre IP wieder haben können. Ist die frei, bekommen die diese ja auch. Und wenn nicht, muß ich ein bisschen nachhelfen, aber eben keine 130 Geräte neu einrichten.

DHCP läuft hier ja auch (keine Frage), aber DHCP hat hier nichts mit irgendwelchen Geräten zu tun, welche Dienste bereitstellen. Oftmals fängt so ein DHCP-Bereich ja bei 100 aufwärts an (Fritz!Box war - meine ich - ab 20 aufwärts), also ist zwischen dem Router (i.d.R. ".1") und dem Anfang des DHCP-Pools ja noch Platz. Diesen Platz kann man dann halt für seine statisch konfigurierten Geräte nutzen.

Sehe ich ja nicht anders. Die wirklich wichtigen Geräte haben alle eine IP < 20 und auch feste IP's.

Hat der PVE dann doch eine statische IP (am PVE-Host eingetragene) und Du hast einfach nur noch "zusätzlich" eine DHCP-Reservierung vorgenommen? Die "Gültigkeitsdauer" hat auch nichts mit einer Reservierung zu tun. Bzgl. der Lease-Time schau Dir doch mal den DHCP-Wikipedia-Artikel an bzw. konkreter dort den Block "DHCP-Refresh (nur bei dynamischer Zuordnung)".

Keine Ahnung, ob der ne feste IP eingetragen hat. Ist halt ne weile her, das ich den mal aufgesetzt hatte und seit dem lief er ja Problemlos.
Was das Lease Time angeht. Ich kenne das so, das der Router diese IP erst dann wieder neu vergeben darf, wenn sich das Gerät, dem diese IP zugeordnet war, 3 Wochen nicht mehr angemeldet hat. Da der Proxmox aber ständig angemeldet ist, kann dessen IP also nicht an jemand anderen vergeben werden.
Aber selbst wenn diese IP neu vergeben worden wäre, müßte der PING mir ja eine Antwort geben, was aber ja nicht geschehen ist.

Kommt dann ggf. irgendwann ein neuer Speedport, hat der erstmal seinen regulären DHCP-Pool-Bereich, irgendein Client wird sich die erste verfügbare IP schnappen und dann wird es direkt Trouble mit dem PVE-Host geben. Dummerweise nutzt es dann auch nix, wenn man den Router neustartet, da der Client ja mit seiner "Ewig-und-3-Tage"-Leasetime ja nun auch erstmal "etwas länger" der Meinung ist, dass die IP nun seine ist.

Und ? So war es ja auch, nachdem ich die FritzBox raus nehmen mußte und der Speedport alles übernimmt. Nein, der Proxmox hat seine alte IP wieder bekommen, ein paar andere Geräte aber nicht. Aber das ist ja nun kein Akt. 2 Stunden Arbeit und alles läuft wieder.

Entweder wartet man nun (extrem) geduldig darauf, dass der Client die IP irgendwann wieder frei gibt, oder man startet den diebischen Client einfach neu. Natürlich muss man diesen dazu auch erstmal ausfindig machen und da man MAC-Adresse und/oder Hostnamen im Router sieht, "könnte" man den Client vielleicht sogar schnell ausfindig machen. Vielleicht aber auch nicht, je nach Situation halt.

Dafür gibt es pi.Alert und das läuft bei mir und wird auch möglichst gepflegt.

Ich erwähne das jetzt auch nur, weil so ein Chaos mit diesen "mal eben"-Kleinigkeiten anfängt. Weisst Du denn in 5 Jahren noch, dass Dein DHCP-Pool nicht bei X, sondern bei X+1 anfängt? Hast Du es Dir irgendwo niedergeschrieben, falls es mal "Pöff" macht und nur noch ein kleines Rauchwölkchen aus dem Router aufsteigt?

Nein, habe ich nicht notiert, sehe ich aber auch nicht als sooooo dramatisch an. Wie gesagt. Einige Geräte haben feste IP's, die kenne ich auswendig und die liegen alle außerhalb des DHCP Pools. Von daher also kein Akt, auch in 5 Jahren einen neuen Router einzubinden.

Ja ich weiss... ist immer wieder ein Kreuz mit diesen blöden Bedenkenträgern, wird schon schief gehen, ist ja bisher auch nix passiert...

Nein, ich sehe es eher hier als kleines Netzwerk im privaten zu Hause und kein Firmennetzwerk, wo gleich mal alles zusammen bricht. wenn was gewaltig schief läuft.

Gerade gemerkt. Trotz verschieben des DHCP Pool hat sich Proxmox gerade eben wieder verabschiedet.
Hab aber gerade auch gesehen, das da noch die weiterleitung der Grafikkarte eingetragen war, die aber ja gar nicht mehr eingebaut ist.
Habs gelöscht, schauen wir mal, obs nun geht.

 

[blurrrr]

Wie ich schon sagte, muss jede Person für sich wissen, von daher - alles easy

Die wirklich wichtigen Geräte haben alle eine IP < 20 und auch feste IP's.

Der PVE-Host gehört da (noch) nicht zu?

2 Stunden Arbeit und alles läuft wieder.

Aus meiner Sicht unnötig, aber... s. den ersten Satz in diesem Post

Mag sein, aber mal eben 130 Geräte neu Einrichten ist halt extrem aufwendig und da ist DHCP einfach der einfachere Weg.

Naja, kommt auch immer darauf an, was es nun eigentlich genau ist. Bei 130x Smarthome-Gedöns hätte ich da sicherlich auch keine Lust drauf, wenn es denn auch anderweitig geht, die Namensauflösung soweit funktioniert und die Geräte auch via Name angesprochen werden. Ist aber auch schon ein dezenter Unterschied, ob nun der PVE-Host oder der HA-Host nicht funktionieren, oder ob es irgendwas von dem Smarthome-Zeugs ist (da ich davon keine Ahnung habe, sage ich jetzt einfach mal "sowas wie eine schaltbare Steckdose").

Gerade gemerkt. Trotz verschieben des DHCP Pool hat sich Proxmox gerade eben wieder verabschiedet.

Wenn Du den Wikipedia-Artikel bzw. den Teilabschnitt gelesen hast, solltest Du wissen, dass das sehr wahrscheinlich "jetzt" sowieso keine Auswirkung hat (sofern es zeitlich nicht dort erwähnte Zeiträume fällt), denn....

Aber die Gültigkeitsdauer der IP im Speedport für den PVE ist auf 3 Wochen gesetzt.

Das gilt normalerweise - sofern keine anderweitigen DHCP-Optionen konfiguriert sind - für alle und nicht nur für den PVE-Host. Das aber nur mal am Rande. Wenn eine DHCP-Reservierung vorhanden ist (mit der MAC-Adresse des PVE-Hosts) sollte die IP sowieso nicht doppelt vergeben werden.

Btw... wenn das Problem auftritt und Dein Client nicht mehr an den PVE-Host kommt, könntest Du in der Eingabeaufforderung auch mal hingehen und den Befehl arp -a ausführen. Das listet Dir alle - dem Client bekannten - Zuordnungen zwischen MAC- und IP-Adresse auf. Stimmt dort bei der PVE-Host-IP die MAC-Adresse nicht mit der MAC-Adresse des PVE-Host überein, wird es ein Problem in diese Richtung sein. Andernfalls sollte diesbezüglich soweit alles in Ordnung sein.

Hab aber gerade auch gesehen, das da noch die weiterleitung der Grafikkarte eingetragen war, die aber ja gar nicht mehr eingebaut ist.
Habs gelöscht, schauen wir mal, obs nun geht.

Die Weiterleitung einer Grafikkarte sollte "eigentlich"(!) nichts damit zu tun haben, dass das Netzwerk nicht mehr funktioniert. Interessant wäre halt noch - Du Du ja versuchst hast den PVE-Host zu pingen - ob der PVE-Host seinerseits noch irgendwas im Netz pingen/erreichen kann. Selbst wenn es da irgendwelche Kausalitäten gibt... merkwürdig ist doch definitiv, dass es eher sporadisch ist, also nicht, wenn Du eine VM ein- oder ausschaltest, oder dergleichen.

Was mich noch interessieren würde: Der PVE-Host legt per default eine Bridge an (vmbr0). Sofern Du da nichts anderweitiges konfiguriert hast, ist das PVE-Webinterface über die IP erreichbar, welche der Bridge zugeteilt wurde. Die VMs auf dem PVE-Host - sofern nicht anderweitig konfiguriert - sollten ja ebenfalls über diese Bridge laufen (per default). Sind die VMs denn dann auch nicht erreichbar (was für mich jetzt erstmal logisch wäre), oder ist es "nur" der PVE-Host selbst?

Dazu noch folgende Überlegung - ist jetzt nicht ganz so hübsch, aber wer weiss... - Du hattest doch vor einiger Zeit die Firewall auf dem PVE-Host eingerichtet. Hast Du diese ggf. testweise mal abgeschaltet? Das wäre insbesondere interessant, wenn die VMs alle noch erreichbar sind, ein Client nicht mehr an den PVE-Host kommt, der PVE-Host selbst aber noch im Netzwerk agieren kann (ping <IP>, curl <URL>, etc.).