VM resettet sich

H6G · Jul 23rd 2021

Quote from Proctrap

Wie stehts jetzt ? Immer noch alles sauber ?

Sieht gut aus.

Momentane Uptime: 14 Tage und 15 Stunden.

Ente-Dank · Aug 5th 2021

Quote from H6G

Momentane Uptime: 14 Tage und 15 Stunden.

Na dann hoffe ich mal sieht das noch immer so aus Noch warte ich dass debian endlich den neuen stable released. Möchte ungern auf'n unstable im freeze wechseln..

H6G · Sep 23rd 2021

Ich glaube es geht schon wieder los.

Ich habe wieder resets, trotz neuerem Kernel...

Ente-Dank · Sep 26th 2021

Also ich habe mal versucht die Maschine auf Debian11/PVE 7 hoch zu ziehen.

Allerdings kommt dann keine VM weiter als bis zum ersten kernel-init, danach gibts sofort 'n hangup. Reproduzierbar sobald eine VM bootet, es liegt also definitiv am VMX support. Auch eine neue VM mit Debian 11 in Proxmox hat das Problem nicht gelöst, es liegt also nicht an komischen Guests o.ä. (Host shutdown ist dann natürlich auch blockiert.)

Leider ist damit die Lösung für mich einfach weiterhin Debian 10 + Proxmox 6 und ein restart-bot auf'm VPS für dieses System. Laut NC wird das VMX Flag auch nicht mehr angeboten seit diesem Jahr (und Support beendet) und ein womöglicher Fix durch ein Upgrade des HVS wird i-wann nächstes Jahr stattfinden. Bis dahin also durchhalten - ich hoffe mein Setup fängt bis dahin nicht an die gleichen Symptome zu haben wie ein PVE 7. Ein Crash per Woche ist ok, aber wenn es nimmer bootet wäre halt nix mehr zu machen.

H6G · Sep 27th 2021

Kann ich leider bestätigen - hatte ich bei einem Kunden auch. Habe es aber auf den alten Gast geschoben.

Unter Kernel 5.4 bootete der Gast, unter 5.10 hatte der Gast seine Probleme.

H6G · Sep 27th 2021

Ich verstehe es halt nicht. Hier mal ein Diff zwischen einer Kernel Config von Ubuntu (LXD läuft hier ja) und Proxmox (Netcup Server resettet sich ohne Gäste):

Compiler kann es auch nicht sein, da PVE 7 wieder mit GCC 10 kompiliert wird, und da gibt es auch Haufen Probleme.

Code

3c3
< # Linux/x86_64 5.4.86 Kernel Configuration
---
> # Linux/x86 5.4.140-1-pve Kernel Configuration
7c7
< # Compiler: gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
---
> # Compiler: gcc (Debian 8.3.0-6) 8.3.0
10c10
< CONFIG_GCC_VERSION=90300
---
> CONFIG_GCC_VERSION=80300
153c153
< # CONFIG_MEMCG_SWAP_ENABLED is not set
---
> CONFIG_MEMCG_SWAP_ENABLED=y
857c857,858
< # CONFIG_MODVERSIONS is not set
---
> CONFIG_MODVERSIONS=y
> CONFIG_ASM_MODVERSIONS=y
859,867c860
< CONFIG_MODULE_SIG=y
< # CONFIG_MODULE_SIG_FORCE is not set
< CONFIG_MODULE_SIG_ALL=y
< # CONFIG_MODULE_SIG_SHA1 is not set
< # CONFIG_MODULE_SIG_SHA224 is not set
< # CONFIG_MODULE_SIG_SHA256 is not set
< # CONFIG_MODULE_SIG_SHA384 is not set
< CONFIG_MODULE_SIG_SHA512=y
< CONFIG_MODULE_SIG_HASH="sha512"
---
> # CONFIG_MODULE_SIG is not set
1156c1149
< CONFIG_BRIDGE_NETFILTER=m
---
> CONFIG_BRIDGE_NETFILTER=y
1560c1553
< CONFIG_STP=m
---
> CONFIG_STP=y
1563c1556
< CONFIG_BRIDGE=m
---
> CONFIG_BRIDGE=y
1586c1579
< CONFIG_LLC=m
---
> CONFIG_LLC=y
2434,2435c2427,2428
< CONFIG_NVME_CORE=m
< CONFIG_BLK_DEV_NVME=m
---
> CONFIG_NVME_CORE=y
> CONFIG_BLK_DEV_NVME=y
3859c3852
< CONFIG_INPUT_EVBUG=m
---
> # CONFIG_INPUT_EVBUG is not set
6497c6490
< CONFIG_SND_PCSP=m
---
> # CONFIG_SND_PCSP is not set
7167c7160
< CONFIG_USB_XHCI_HCD=y
---
> CONFIG_USB_XHCI_HCD=m
7169c7162
< CONFIG_USB_XHCI_PCI=y
---
> CONFIG_USB_XHCI_PCI=m
7171c7164
< CONFIG_USB_EHCI_HCD=y
---
> CONFIG_USB_EHCI_HCD=m
7174c7167
< CONFIG_USB_EHCI_PCI=y
---
> CONFIG_USB_EHCI_PCI=m
7176c7169
< CONFIG_USB_EHCI_HCD_PLATFORM=y
---
> CONFIG_USB_EHCI_HCD_PLATFORM=m
7181,7184c7174,7178
< CONFIG_USB_OHCI_HCD=y
< CONFIG_USB_OHCI_HCD_PCI=y
< CONFIG_USB_OHCI_HCD_PLATFORM=y
< CONFIG_USB_UHCI_HCD=y
---
> CONFIG_USB_OHCI_HCD=m
> CONFIG_USB_OHCI_HCD_PCI=m
> # CONFIG_USB_OHCI_HCD_SSB is not set
> CONFIG_USB_OHCI_HCD_PLATFORM=m
> CONFIG_USB_UHCI_HCD=m
7187c7181
< CONFIG_USB_SL811_HCD_ISO=y
---
> # CONFIG_USB_SL811_HCD_ISO is not set
7417d7410
< CONFIG_USB_BDC_PCI=m
7930,7932c7923,7925
< CONFIG_VFIO_IOMMU_TYPE1=y
< CONFIG_VFIO_VIRQFD=y
< CONFIG_VFIO=y
---
> CONFIG_VFIO_IOMMU_TYPE1=m
> CONFIG_VFIO_VIRQFD=m
> CONFIG_VFIO=m
7934c7927
< CONFIG_VFIO_PCI=y
---
> CONFIG_VFIO_PCI=m
7941c7934
< CONFIG_IRQ_BYPASS_MANAGER=y
---
> CONFIG_IRQ_BYPASS_MANAGER=m
7957c7950
< CONFIG_HYPERV=m
---
> CONFIG_HYPERV=y
9281d9273
< CONFIG_UBUNTU_ODM_DRIVERS=y
9612c9604
< # CONFIG_CIFS_SMB_DIRECT is not set
---
> CONFIG_CIFS_SMB_DIRECT=y
9649c9641
< CONFIG_NLS_ISO8859_1=m
---
> CONFIG_NLS_ISO8859_1=y
9732,9737c9724
< CONFIG_SECURITY_LOCKDOWN_LSM=y
< CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
< CONFIG_LOCK_DOWN_IN_SECURE_BOOT=y
< CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
< # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set
< # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set
---
> # CONFIG_SECURITY_LOCKDOWN_LSM is not set
9777c9764
< CONFIG_LSM="lockdown,yama,integrity,apparmor"
---
> CONFIG_LSM="yama,integrity,apparmor"
10026d10012
< CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
10033a10020
> CONFIG_SYSTEM_REVOCATION_LIST=y
10479c10466

Display More

m_ueberall · Sep 27th 2021

Quote from H6G

Unter Kernel 5.4 bootete der Gast, unter 5.10 hatte der Gast seine Probleme.

Bei Kernel 5.10 scheint leider mit/nach v5.10.8 der Wurm 'drin zu sein, was Virtualisierung anbelangt… Auch mit LXD ließen sich auf arm64/aarch64-Hosts aufgrund von Änderungen keine VMs mehr starten. Wurde bei v5.10.56 auch nicht besser, sodass ich für diese Architektur nun leider auf Nicht-LTS-Kernel angewiesen bin (v5.13.16 läuft zusammen mit einem wenige Tage alten Patch). Auf v5.10.7 oder früher mag ich allerdings auch nicht zurückgehen, da das ja den LTS (langfristige Updates) konterkariert – ggf. wäre ein "früher v5.10-Kernel" allerdings hier eine Option für Proxmox, wenn noch älteren Kernel bestimmte Eigenschaften fehlen?

lulatsch66 · Sep 28th 2021

Quote from H6G

Ich glaube es geht schon wieder los.

Ich habe wieder resets, trotz neuerem Kernel...

Hallo zusammen,

nachdem ich immer mit Hoffnung auf Lösung auch schon eine Weile mitgelesen habe, hier mal meine Erfahrungen zum Thema.
Vielleicht finden wir ja doch irgendwann einen Zusammenhang ...

Ich betreue z.Z. 2 Cluster mit jeweils 3 Nodes mit Proxmox 6.4, ich nenn die jetzt mal "soft" und "netz" zur Unterscheidung.
Verbunden sind die jeweils per cloudVlan M und CloudVlan free.
Da ich nur container brauche, hab ich auch kein vmx Flag dazu gebucht. HA-setup mit Failover-IPs, was unterm Strich
nicht viel Sinn macht, wenn jetzt mehr Reboots auftreten als bei normaler Nutzung (auch wenn's trotzdem flexibler ist).

Bei "netz" sind 2x RS4000 G9 und ein VPS 100 -> da gab es bis zum 20.9. keine unvorhergesehenen Reboots. Gar keine.
Bei "soft" sind 2x RS4000 G9 und ein RS2000 G8 (auch der hat sich, obwohl Intel, schon mal alleine rebootet).

Hinzugekommen ist jetzt noch ein RS Superuser vom 21.9., dort hab ich Proxmox 7 aktuell vom iso installiert. Da ging es mit
Reboots am 26.9. und 28.9. los - bin dort allerdings noch innerhalb der 30 Tage, würde den gern als PBS mit nur 1-2 container nutzen.

Fragen:

hat jemand schon mal mit dem Hochsetzen von 'kernel.watchdog_thresh' per sysctl experimentiert?
das o.g. Script zum Ausschalten per CCP bzw. SCP/API ... was genau bringt das? Längere Uptime, weil dann nicht so schnell wieder ein Reboot passiert?

kann sich jemand erklären, warum bei dem "netz" Cluster s.o. die Reboots erst jetzt angefangen haben (nach 3 Monaten)? Bei m.E. gleicher Konfiguration.

Hat jemand Aussagen zum Support dazu (außer "Proxmox wird nicht unterstützt"), also z.B. "passiert nur mit zfs" oder "Debian 10 + proxmox manuell installieren"?
Ideen, wie man an die Kernel-Ausschriften kommt, rsyslog z.B. o.ä.?

Vielen Dank schon mal für eure Antworten.

Falko

H6G · Sep 28th 2021

Quote from lulatsch66

Hat jemand Aussagen zum Support dazu (außer "Proxmox wird nicht unterstützt"), also z.B. "passiert nur mit zfs" oder "Debian 10 + proxmox manuell installieren"?

Keine Aussage vom Support, aber eigene Erfahrung.

Alle meine Proxmox Kisten sind Debian + Proxmox manuell installiert. Spielt also keine Rolle.

Auch ZFS hatte ich schon auf den gleichen Systemen mit Ubuntu und LXD im Einsatz, ohne Probleme.

Quote from lulatsch66

Ideen, wie man an die Kernel-Ausschriften kommt, rsyslog z.B. o.ä.?

Persistentes systemd journal auf die Festplatte schreiben. Das ganze führt aber zu nichts, weil der Kernel über den Absturz keinen Log schreibt. Es gibt auch keine Kernelpanik. Du kannst auch eine SSH Sitzung auflassen die dir dann wegbricht, wenn er abstürzt, mit den letzten Meldungen noch im Terminal.

Ente-Dank · Sep 29th 2021

Quote from lulatsch66

das o.g. Script zum Ausschalten per CCP bzw. SCP/API ... was genau bringt das? Längere Uptime, weil dann nicht so schnell wieder ein Reboot passiert?

Mit VMX Flag unter RS4000 G9 hast du keinen Reset, der betroffene CPU-"Kern" hängt sich vollständig auf, den siehst du nie wieder, auch der Host verliert diesen Kern (und alle darauf laufenden Prozess + VMs) vollständig. Es ist also völlig random ob du 1 bis alle CPU Kerne verlierst, früher oder später alle. In meinem Fall ist das Skript einfach nur dazu da den Host hart zu resetten sobald gewisse relevante Dienste nicht mehr verfügbar sind, ihm aber die Chance zu lassen andere Daten weg zu schreiben, da vielleicht nur diese VM betroffen ist, die restlichen Systeme also noch herunter fahren könnten.

lulatsch66 · Sep 29th 2021

Ok, verstehe, vielen Dank für eure Antworten.

Bleibt für mich die Theorie, dass bei meinem "netz" Cluster bisher alle nodes auf neueren Hostsystemen waren/sind, und dann nur die eine Maschine auf einen älteren/anderen Host verschoben wurde, der die Reboots (= Ryzen-Bug?) hat ... Die anderen vom "soft" Cluster und der RS Superuser mit pve7 könnten entsprechend alle auf älteren sein. Klingt das plausibel? Wenn ja, müsste der Support das doch eigentlich zuordnen können ...

Kernel sind bei mir alles 5.4.x, auf pve7 ist 5.11.22 - entsprechend aktuell. Demnach bringt upgrade auf 5.11 bei pve6 auch nix. Nur Wechsel auf G8 ... und den RS Superuser wieder zurückgeben, da noch innerhalb 30 Tage. Den nutze ich im Moment nur zum pve7-Experimentieren, weil ich dort das private network mit lxc noch nicht hinbekommen habe - anderes Thema.

tauceti · Oct 4th 2021

So melde mich hier auch, da ich das gleiche Problem habe und auch im Proxmox Forum erst gemeldet hatte:

https://forum.proxmox.com/thre…f-node.96503/#post-421128

Seitdem ich den VPS 1337 21 neu hab und manuell neuestes proxmox mit bullseye und 5 lxc containern mit bullseye installiert hatte, habe ich einfach resets ohne dass im ccp was steht bzw. in den logs. (siehe proxmox thread)

Mit meinem vorherigen VPS Ostern XL 21 hatte ich das Problem nicht auch mit proxmox bullseye aber buster lxc containern.

Dateisystem jeweils ZFS

Es ist wirklich nervig und ich weiß nicht was man machen kann. Einmal hatte ich sogar 9 Tage lang nichts, doch jetzt wieder alle paar Stunden plötzliche reboots/resets

Update: Im kernel log steht nur: Poweron or device reset occurred

Linux proxmox 5.11.22-4-pve #1 SMP PVE 5.11.22-9 (Wed, 22 Sep 2021 10:11:11 +0200)

Nutze kein Luks

Ente-Dank · Nov 26th 2021

Weil ich es hier jetzt nicht nochmal explizit gelesen hatte: Aussage vom Support war nochmal dass man vil. nächstes Jahr was macht. Vorerst sei VMX nicht mehr buchbar.

MeisterYoda · Nov 27th 2021

Quote from Ente-Dank

Weil ich es hier jetzt nicht nochmal explizit gelesen hatte: Aussage vom Support war nochmal dass man vil. nächstes Jahr was macht. Vorerst sei VMX nicht mehr buchbar.

Hmm, also ich bin ja wirklich gespannt, ob auch Proxmox mit reinen Containern, sprich KEIN nested KVM und auch KEIN VMX flag betroffen ist. Denn sollte das der Fall sein wäre das für mich ein außerordentlicher Kündigungsgrund. Ohne Containervirtualisierung kann ich die Kiste leider nicht brauchen; wäre dann auch nicht bugfree seitens Netcup.

Falls nur VMX + eigenes nested KVM betroffen ist, ist es natürlich in Ordnung wenn der Support da nix (rechtzeitig) macht, da es auch offiziell nicht angeboten wird.

m_ueberall · Nov 27th 2021

Quote from MeisterYoda

Hmm, also ich bin ja wirklich gespannt, ob auch Proxmox mit reinen Containern, sprich KEIN nested KVM und auch KEIN VMX flag betroffen ist.

Nein, LXC/LXD benötigen definitiv kein VMX-Flag.

Ente-Dank · Nov 27th 2021

Quote from m_ueberall

benötigen definitiv kein VMX-Flag

das nicht aber andere hatten ja ihre resets dann mit proxmox

MeisterYoda · Nov 27th 2021

Quote from Ente-Dank

das nicht aber andere hatten ja ihre resets dann mit proxmox

genau darum gings mir. Wenn das mit der aktuellen Proxmox VE 7.1-4 und kernel 5.13.19+ immer noch der Fall sein sollte und nicht als Problem seitens Support angesehen wird, werde ich wohl beim zuletzt gebuchten Server die Zufriedenheitsgarantie nutzen und den anderen einfach kündigen und zu einem anderen Hoster umziehen müssen, wo entsprechende Patches / Kernel updates eingespielt werden.

voja · Nov 28th 2021

Quote from MeisterYoda

genau darum gings mir. Wenn das mit der aktuellen Proxmox VE 7.1-4 und kernel 5.13.19+ immer noch der Fall sein sollte

Ich habe gestern meinen Node mit Proxmox 7 auf den Kernel 5.13.19-1-pve upgedated. Heute Morgen kam es wieder zu dem Reboot Problem. Das System läuft laut SCP seit über 200 Tagen. Es ist ein KVM Update ausstehend. Ich werde jetzt erstmal die Kiste runterfahren, damit das KVM Update sicher greift und dann nochmal beobachten. Ich habe das Reboot Problem nur auf dem Proxmox 7 Node, der Proxmox 6 Node läuft ohne Probleme.

MeisterYoda · Nov 28th 2021

Quote from voja

Es ist ein KVM Update ausstehend. Ich werde jetzt erstmal die Kiste runterfahren, damit das KVM Update sicher greift und dann nochmal beobachten.

Welches KVM Update meinst du? Eins seitens Netcup? Gibt es da offizielle Neuigkeiten, dass die ein Update machen?

Ente-Dank · Nov 28th 2021

Voja wird einfach nur die Benachrichtigung im CCP meinen, das hat nix mit dem Problem zu tun. Eher wie wenn dein linux dich auffordert mal neu zu starten weils ja kernel updates gab und du glaubst damit dein GPU treiber problem zufällig zu lösen.