Windows Server 2022 - Das System wurde unerwartet heruntergefahren

[fokustech]

Ich habe vor 16 Tagen die Updates in meiner Testumgebung gemacht um zu testen. Bin da auch auf den damals aktuellen Kernel gegangen und bin zu Testzwecken bei "options kvm tdp_mmu=Y" geblieben. Es ging 15 Tage gut. Dann ist mitten am Nachmittag ein Win Server 2022 stehen geblieben. Der Andere und eine Win11 Enterprise Maschine laufen bisher.
Ich werde jetzt "options kvm tdp_mmu=N" einstellen und dann wieder schauen, was passiert.

 

[mira]

Es gibt mittlerweile einen neueren Kernel pve-kernel-5.15.39-3-pve der einen Fix beinhaltet.
Diese Version befindet sich derzeit auf dem pvetest Repository.

 

[IT-MCSE]

Heute habe ich das System hochgezogen. Schauen wir mal ob es funzt. Ich bleibe am Ball.

 

[fmtech]

Hallo Kollegen

mit dem neuem Kernel läuft nun eine kritische SQL-VM beim Kunden seit 4 Tagen durch, ist sonst alle 8-12h abgestürzt, gute Arbeit des Poxmox-Teams
schöne Grüße und viel Erfolg

 

[fokustech]

Von mir auch nochmal eine kurze Rückmeldung. Mit dem Kernel 5.15.39-3 und "options kvm tdp_mmu=N" läuft das Testsystem nun seit 20 Tagen ohne Crash. Es sieht gut aus. ich traue mich damit jetzt an die Produktivsysteme.

 

[tesme13]

Hi
wenn ich das richtig sehe nutzt Ihr ZFS als filesystem. Mit dem hatte ich richtig Stress bei hoher IO Last.
Könnte einer der Betroffenen mal schauen ob das Verhalten durch eine hohe IO Last provoziert werden kann. Nich auf einem Produktivsystem natürlich.
Ich habe dazu unter Windows den ATTO Diskbench genommen um den Absturz zu provzieren.

Wenn der durchläuft wäre es interessant für das betreffende System die ZFS Parameter zu bekommen.

 

[fokustech]

Hi
wenn ich das richtig sehe nutzt Ihr ZFS als filesystem. Mit dem hatte ich richtig Stress bei hoher IO Last.
Könnte einer der Betroffenen mal schauen ob das Verhalten durch eine hohe IO Last provoziert werden kann. Nich auf einem Produktivsystem natürlich.
Ich habe dazu unter Windows den ATTO Diskbench genommen um den Absturz zu provzieren.

Wenn der durchläuft wäre es interessant für das betreffende System die ZFS Parameter zu bekommen.

Ich hatte die Probleme auch auf einem "normalen" System ohne ZFS. Ich denke, daran kann man das nicht unbedingt festmachen. Mag sein, dass das eine Rolle spielen kann, aber hauptursächlich ist es nicht.

 

[ITT]

Habt ihr schon die neue qemu-v7 am testen?

 

[tesme13]

Hi

Ich hatte die Probleme auch auf einem "normalen" System ohne ZFS. Ich denke, daran kann man das nicht unbedingt festmachen. Mag sein, dass das eine Rolle spielen kann, aber hauptursächlich ist es nicht.

Hi
danke für die Info. Könnte aber trotzdem sein das eine IO Last der Trigger für den Stillstand/Absturz der VMs ist.
Da ja seit meinen letzten Tests und jetzt schon die eine oder andere Verbesserung in den Kernel und ZFS geflossen ist schaue ich aber mal ob das nun stabiler ist.
Denn ZFS nutze ich seit 2008 und finde es in vielen Belangen für meine Zwecke ideal.

Gruss

 

[fokustech]

Hi

Hi
danke für die Info. Könnte aber trotzdem sein das eine IO Last der Trigger für den Stillstand/Absturz der VMs ist.
Da ja seit meinen letzten Tests und jetzt schon die eine oder andere Verbesserung in den Kernel und ZFS geflossen ist schaue ich aber mal ob das nun stabiler ist.
Denn ZFS nutze ich seit 2008 und finde es in vielen Belangen für meine Zwecke ideal.

Gruss

Ich habe auch ein Produktivsystem mit ZFS. Da ist allerdings immer der DC abgeraucht und das Nachts um 4 Uhr. Zu der Zeit liefen keine Backups oder sonstiges. Der ERP Server mit Last auf einer PostgreSQL Datenbank ist nie abgeraucht. Eben das sind ja die verwunderlichen Dinge, die dieses Problem mit sich bringt (gebracht hat).

 

[IT-MCSE]

Ich habe nach dem Update auf Kernel 5.15.39-3 keine Abstürze mehr feststellen können. Schließe mich @fmtech an, gute Arbeit vom PROXMOX Team. Das neueste Update mit qemu-v7 habe ich noch nicht ausprobiert, update damit erstmal die Testmaschine. Bei Auffälligkeiten melde ich mich wieder.

ZFS halte ich als Fehlerquelle als nicht sehr wahrscheinlich, da alle Maschinen damit laufen ( auch LINUX VM´s mit zeitweiser I/O Last-SQL DB ). Keine LINUX Maschine ist jemals zum Stillstand gekommen , also eher eine WINDOWS Thema.

Schöne Restwoche

 

[tesme13]

Ich habe auch ein Produktivsystem mit ZFS. Da ist allerdings immer der DC abgeraucht und das Nachts um 4 Uhr. Zu der Zeit liefen keine Backups oder sonstiges. Der ERP Server mit Last auf einer PostgreSQL Datenbank ist nie abgeraucht. Eben das sind ja die verwunderlichen Dinge, die dieses Problem mit sich bringt (gebracht hat).

Hi,

mmh immer Nachts ? Hört sich nach nem CRON Job an. Könnte ja sein dass der eine unglückliche Art und weise ein IO Muster erzeugt was zu Problemen führt. Wobei mein Gefühl bei ZFS und Linux immer noch nicht so gut ist wie auf anderen Plattformen.
Habe die Tage noch mal 2 Windows VM auf 2 Neu augesetzten ProxMox 7.2 (kernel: Linux 5.15.39-4-pve) getestet.


System 1: Xeon E3-1240L , 32 GB
System 2: Xeon X3440 , 16GB

Windows 1: W10 4 GB
Windows 2: W2022 Server, 8 GB

Bei System 1 ist es kein Problem wenn beide ne Menge IO Last haben. Der Speicher geht auf 90% und das ist es. Keine Last auf der PLltte selbst , wird halt alles gepuffert.
Bei System 2 habe ich nur mal eine VM Last erzeugen lassen (W2022) und dann schlägt der OOM bei dem System zu welches nix macht und beendet es.

Und an der Stelle gibt es zumindest eine Verbesserung zu meinen alten Tests. Vor ein paar Monaten ist nämlich der Proxmox selbst im Nirvana verschwunden.

Jetzt kann man sagen wieso nimmt man so ein schwaches System, aber das ist hier nicht das Thema. Als Betreiber erwarte ich dass das System nur weil es meint puffern zu wollen nicht einfach VMS runterfährt.

Interessanterweise läuft mit ext4 alles ohne Probleme.

Was für mich heist ZFS on linux in einem produktivsystem stellt ein Risiko dar. Unter SunOS/Solaris gab es am Anfang auch Probleme , mal sehen wann das unter Linux auch ruhiger wird.

 

[Pifouney]

hello,

I take the liberty of reminding you that MS products are enormously IO consumer. So, what does your VMs do if you offload the disk IOs to the threads of your procos? (configure iothread in your virtual disk declarations)
Ideally, depending on your configuration, MS Windows works best with a writeback disk cache.

Cordially

 

[tesme13]

hello,

I take the liberty of reminding you that MS products are enormously IO consumer. So, what does your VMs do if you offload the disk IOs to the threads of your procos? (configure iothread in your virtual disk declarations)
Ideally, depending on your configuration, MS Windows works best with a writeback disk cache.

Cordially

Hi
i forgot to mention that i had writeback configured for the Windows VMs.

 

[fokustech]

Hi,

mmh immer Nachts ? Hört sich nach nem CRON Job an. Könnte ja sein dass der eine unglückliche Art und weise ein IO Muster erzeugt was zu Problemen führt. Wobei mein Gefühl bei ZFS und Linux immer noch nicht so gut ist wie auf anderen Plattformen.
Habe die Tage noch mal 2 Windows VM auf 2 Neu augesetzten ProxMox 7.2 (kernel: Linux 5.15.39-4-pve) getestet.


System 1: Xeon E3-1240L , 32 GB
System 2: Xeon X3440 , 16GB

Windows 1: W10 4 GB
Windows 2: W2022 Server, 8 GB

Bei System 1 ist es kein Problem wenn beide ne Menge IO Last haben. Der Speicher geht auf 90% und das ist es. Keine Last auf der PLltte selbst , wird halt alles gepuffert.
Bei System 2 habe ich nur mal eine VM Last erzeugen lassen (W2022) und dann schlägt der OOM bei dem System zu welches nix macht und beendet es.

Und an der Stelle gibt es zumindest eine Verbesserung zu meinen alten Tests. Vor ein paar Monaten ist nämlich der Proxmox selbst im Nirvana verschwunden.

Jetzt kann man sagen wieso nimmt man so ein schwaches System, aber das ist hier nicht das Thema. Als Betreiber erwarte ich dass das System nur weil es meint puffern zu wollen nicht einfach VMS runterfährt.

Interessanterweise läuft mit ext4 alles ohne Probleme.

Was für mich heist ZFS on linux in einem produktivsystem stellt ein Risiko dar. Unter SunOS/Solaris gab es am Anfang auch Probleme , mal sehen wann das unter Linux auch ruhiger wird.

Puh, das ist schon ne Zeit her, aber ich möchte zu deinen Aussagen noch kurz eine Anmeerkung machen. Es hört sich nämlich sehr nach einer Sache an, über die ich gefallen bin.
Standardmäßig ist im Windows die turnusmäßige Defragmentierung aktiviert. Das ist im ZFS aber nicht nötig bzw. sogar kritisch, da es hier zu enormen IO kommt und bei den Maschinen dann den Arbeitspeicher auslastet. Das führt dann zu einem Bluescreen inkl. Neustart. Aber eben Neustart und nicht zu einem Crash bei dem die Maschine aus bleibt.
Ansonsten kann man ZFS sehr genau konfigurieren und es läuft auch sehr stabil. Das Thema hier war sicherlich nicht am Thema ZFS festzumachen.

 

[hec]

Puh, das ist schon ne Zeit her, aber ich möchte zu deinen Aussagen noch kurz eine Anmeerkung machen. Es hört sich nämlich sehr nach einer Sache an, über die ich gefallen bin.
Standardmäßig ist im Windows die turnusmäßige Defragmentierung aktiviert. Das ist im ZFS aber nicht nötig bzw. sogar kritisch, da es hier zu enormen IO kommt und bei den Maschinen dann den Arbeitspeicher auslastet. Das führt dann zu einem Bluescreen inkl. Neustart. Aber eben Neustart und nicht zu einem Crash bei dem die Maschine aus bleibt.
Ansonsten kann man ZFS sehr genau konfigurieren und es läuft auch sehr stabil. Das Thema hier war sicherlich nicht am Thema ZFS festzumachen.

Selbst wenn da IO Load erzeugt wird darf sowas doch nicht zu Bluescreens oder sonst was führen. Die IO Load für Defragementierung sollte noch immer wesentlich geringer sein als ein SAP oder bei einem Datenbankenserver.