Windows Server 2022 - Das System wurde unerwartet heruntergefahren

anjo · May 17, 2022

Hallo

Ich habe ein Problem mit Windows Server 2022 Standard. Es gibt 3 davon. Jedes dieser Systeme schaltet sich über den Tag weg mindestens 2 Mal ab. Und zwar so, dass das System einfach aus geht, ohne herunterzufahren. In der Ereignisanzeige steht nur, dass das System zuvor unerwartet heruntergefahren wurde. Das System ist ein Produktivsystem. Ich habe die deutsche iso benutzt mit pc-q35-5.1. 6.2 funktionieren die Netzwerkadapter nicht, was hier im Forum schon oft besprochen wurde. Ich habe nur den Guest Agent installiert aus virtio win 0215. Hardware Einstellungen und Optionen in Anlage. Ich benutze V7.2.3. Was mir noch aufgefallen war, dass die Systeme zuvor ca. über 4 Wochen stabil gelaufen sind, mit den gleichen Einstellungen, danach ging es dann los mit den unerwarteten Ereignissen, dass die Systeme sich einfach abschalten.

Ich weiss mir jetzt bald nicht mehr zu helfen. Bei Server 2019, Win10 oder Win11 habe ich diese Problematiken nicht. Die laufen stabil.

Gibt es jemand, der weiss was man einstellen oder noch konfigurieren muss?
Wie müssen die Bios Einstellungen aussehen?

Danke

mayli · May 17, 2022

Hallo, ich habe leider das selbe Problem. Mindestens einmal in 24 Stunden schaltet sich die VM einfach ab.
Hätte da auch gerne Hilfe benötigt.
Lg.

L1243 · May 17, 2022

Bitte mal ein paar mehr Infos zum Host selbst.
Wieviel RAM, wieviel ist zugewiesen? Was steht im Proxmox Log, wenn die VM aus geht?

Falk R. · May 18, 2022

Ich benutze bei 2022 nur noch virtio 0217. Die 0215 hatte bei mir Probleme gemacht, aber keine Abstürze, nur ab und zu ein paar hänger.

Das VMs aus gehen liegt meistens am vollem RAM oder Storage Problemen.

anjo · May 19, 2022

Die physische CPU ist eine XEON Silver 4210 (1 Socket derzeit - Supermicro Mainboard 2 Socket). Das physische RAM ist zu 80 Prozent ausgelastet, wovon ca. 12 GB RAM vom ZFS in Beschlag sind (MIN 4 GB - MAX 12 GB. Das Dateisystem ist ZFS auf einem Adaptec RAID 1. Ich habe aus Performancegründen den Controller nicht in den HBA Mode gesetzt, sondern den Controller den Raid machen lassen und dem ZFS als Raid 0 verkauft. Die Best Practics sollen ja sein, dass HBA genommen werden soll und dem ZFS das zu überlassen. Das habe ich bei einem anderen Kunden, wo aber die Performance ziemlich drunter leidet. Die physischen Disks sind 18 TB im Raid 1, wovon derzeit ca. nur 12 Prozent belegt sind.

Der erste Windows Server 2022 dient als virtueller AP für 2 Personen, die auch von extern arbeiten. Die AP hat ca. 3 Monate perfekt gelaufen, erst als ich auf 7.2.3 geupdatet hatte, hat es da auch mit angefangen. Dieser hat 10 GB RAM und 10 vCPU, v 500 GB Disk. Der zweite Windows 2022 Server ist ein AD, dieser hat 8vCPU und 10 GB RAM, und 2 TB v Disk. Der dritte Windows Server ist ein RDP Server (Terminal). Auf diesem gibt es 11 Profile, wovon 8 immer benötigt werden. Dieser hat 30 GB RAM und 20 vCPU und 500 GB vDIsk. Der RDP hat bei voller Auslastung nur ca. 50 Prozent des RAM belegt. und die anderen beiden sind auch nur zu ca. 30 Prozent vom RAM belegt. Die vDisk sind alle nur zu ca. 30 Prozent voll.

Alle 3 haben als Cache=writethrough und discard=on

Ich habe die 0215 genommen, da 0217 bei mir wegen den Ethernet Adaptern Problematiken gemacht hat. Werde aber am WE noch einmal versuchen. Unterdessen habe ich auch Microsoft kontaktiert. Die konnten mir wie immer nicht helfen, da es bei den Abstürzen keinerlei Fehler Meldung gibt. Am Sonntag hatte ich den Guest Agenten rausgenommen (bei allen 3). Hat aber auch nichts gebracht. 2 Systeme sind gestern Abend wieder ausgegangen. Es passiert komischerweise nur dann, wenn das System nicht ausgelastet ist, resp. niemand mehr arbeitet. Tagsüber laufen die 3 Systeme. Die Lizenzen hatte ich auch noch einmal überprüft, da ist aber alles korrekt.

Die LOG ist in Anlage. Ich habe heute morgen gesehen, dass kurz vor dem Absturz der WMI - Leistungsadapter als ausgeführt stand.

itNGO · May 19, 2022

Schaut mal bitte ob zu dem Zeitpunkt im SYSLOG ein Backup gelogged wird.
Kann zum Beispiel so aussehen....


May 19 05:01:34 RZA-APVE1 pvescheduler[3548469]: INFO: Starting Backup of VM 255033004 (qemu)
May 19 05:01:34 RZA-APVE1 kernel:  rbd30: p1 p2 p3 p4 p5
May 19 05:01:34 RZA-APVE1 kernel: rbd: rbd30: capacity 136365211648 features 0x3d
May 19 05:01:34 RZA-APVE1 kernel: rbd: rbd31: capacity 1048576 features 0x3d
May 19 05:01:37 RZA-APVE1 pvescheduler[3548469]: VM 255033004 qmp command failed - VM 255033004 qmp command 'guest-ping' failed - got timeout
May 19 05:04:12 RZA-APVE1 pvescheduler[3548469]: INFO: Finished Backup of VM 255033004 (00:02:38)
May 19 05:04:12 RZA-APVE1 pvescheduler[3548469]: INFO: Starting Backup of VM 255042002 (qemu)

Falk R. · May 19, 2022

Hi, bitte schraube mal die vCPUs runter. Du hast 10 Physikalische Kerne und benutzt 38vCPUs. Außerdem eine VM mit 20 vCPUs auf einem 10 Kerner laufen zu lassen ist mega übel. Hyperthreading kann man ja nutzen, sollte aber nie komplett eingeplant werden.
Meine DCs bekommen z.B. nur 1 vCPU und wenn da mehr Dienste drauf kommen, mal 2vCPUs.
Wenn du deine CPU so ans Limit fährst und dann Prozesse kommen (wie z.B Backup) die den Host auch noch auslasten, dann sind Probleme vorprogrammiert.

hec · May 19, 2022

Laufen da noch andere VMs drauf außer den Windows VMs?

Ich denke da mal an RAM Problem wenn das bei allen VMs gleichzeitig aufgetreten ist. Alternativ könnte das auch ein Windows Update sein.

Hätte bei mir jedoch mit Windows 2022 dieses Verhalten nicht feststellen können.

anjo · May 19, 2022

Vielen Dank für die Antworten. Die Antwort von SkyDiver79 ist nicht von der Hand zu weisen, zumal es sich mit den Backups des Daten Contents deckt. Immer wenn diese laufen, sind die Windows 2022 Server abgeschmiert (nicht alle 3 sondern nur einer oder 2 davon), oder zumindest habe ich das von gestern geprüft. Um 21 Uhr lief Inkrem-Backup und um 21.02 schmierten 2 Windows 2022 Server ab. Und zwischen 1 Uhr nachts und 5 Uhr morgen laufen Kopien an einen anderen Ort. Auch da gab es immer wieder diese Ausfälle in dieser Zeit, jedoch nur bei den 2022 er Systemen. Es läuft noch ein 2019 Server, ein Windows 11, 2 CentOS und 2 virtuelle FireWall Systeme. Da gibt es keine Probleme mit. Ich habe das jedoch über Mittag so angepasst, dass ich mich innerhalb der 20 Threads bewege. DC habe ich 1 CPU gegeben und sieht gut aus. Solch eine CPU kommt mit Overprovisioning zurecht. Ich habe das bei noch keiner anderen Installation gehabt. Da habe ich bei allen das Verhältnis zum Teil x 4. Und nirgends gab es Probleme, auch nicht während der Backups. Zum Teil habe ich dort auch nur E3-1275 im Einsatz. Hier ist nun mal eine RDP Umgebung mit dazugekommen, die vorher nicht geplant war. Kann aber immer noch 2. CPU dazu bauen. Wichtig ist, dass das abschmieren aufhört.

Wegen des Syslog: Backups als vzdump werden einmal die Woche gesichert, immer Sonntags alle vm auf separate Backup Disk.

Ich werde jetzt die nächsten 2 - 3 Tage schauen, ob sich das bessert und mich dann wieder melden, und danke vielmals für euren Input

bluepeeb · May 20, 2022

ich habe einen neuen Server mit Version 7.2-4 und nur eine VM mit Windows Server 2022 (Virt-IO .217) testweise installiert. Storage und RAM sind ausreichen zur Verfügung und ich habe ebenfalls den Fall, dass die VM einfach aus geht und im Gastsystem "unerwartet Beendet" erscheint.

Ich konnte im syslog folgenden Eintrag finden:

Code:

May 20 03:05:35 pve kernel: [55776.831746] set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.
May 20 03:05:35 pve QEMU[530520]: KVM: entry failed, hardware error 0x80000021
May 20 03:05:35 pve QEMU[530520]: If you're running a guest on an Intel machine without unrestricted mode
May 20 03:05:35 pve QEMU[530520]: support, the failure can be most likely due to the guest entering an invalid
May 20 03:05:35 pve QEMU[530520]: state for Intel VT. For example, the guest maybe running in big real mode
May 20 03:05:35 pve QEMU[530520]: which is not supported on less recent Intel processors.
May 20 03:05:35 pve QEMU[530520]: EAX=000a5afe EBX=60ceb180 ECX=00000000 EDX=00000000
May 20 03:05:35 pve QEMU[530520]: ESI=6313fb80 EDI=83190080 EBP=28a3e230 ESP=28a3e050
May 20 03:05:35 pve QEMU[530520]: EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0
May 20 03:05:35 pve QEMU[530520]: ES =0000 00000000 ffffffff 00809300
May 20 03:05:35 pve QEMU[530520]: CS =be00 7ffbe000 ffffffff 00809300
May 20 03:05:35 pve QEMU[530520]: SS =0000 00000000 ffffffff 00809300
May 20 03:05:35 pve QEMU[530520]: DS =0000 00000000 ffffffff 00809300
May 20 03:05:35 pve QEMU[530520]: FS =0000 00000000 ffffffff 00809300
May 20 03:05:35 pve QEMU[530520]: GS =0000 00000000 ffffffff 00809300
May 20 03:05:35 pve QEMU[530520]: LDT=0000 00000000 000fffff 00000000
May 20 03:05:35 pve QEMU[530520]: TR =0040 60d58000 00000067 00008b00
May 20 03:05:35 pve QEMU[530520]: GDT=     60d59fb0 00000057
May 20 03:05:35 pve QEMU[530520]: IDT=     00000000 00000000
May 20 03:05:35 pve QEMU[530520]: CR0=00050032 CR2=6cce1228 CR3=64e36000 CR4=00000000
May 20 03:05:35 pve QEMU[530520]: DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
May 20 03:05:35 pve QEMU[530520]: DR6=00000000ffff0ff0 DR7=0000000000000400
May 20 03:05:35 pve QEMU[530520]: EFER=0000000000000000
May 20 03:05:35 pve QEMU[530520]: Code=kvm: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed.
May 20 03:05:35 pve kernel: [55776.926132]  zd48: p1 p2
May 20 03:05:35 pve kernel: [55776.936100] vmbr1: port 3(tap101i0) entered disabled state
May 20 03:05:35 pve kernel: [55776.936342] vmbr1: port 3(tap101i0) entered disabled state
May 20 03:05:35 pve kernel: [55776.937396]  zd32: p1 p2 p3 p4
May 20 03:05:36 pve systemd[1]: 101.scope: Succeeded.
May 20 03:05:36 pve systemd[1]: 101.scope: Consumed 28min 51.628s CPU time.
May 20 03:05:36 pve qmeventd[1920429]: Starting cleanup for 101
May 20 03:05:36 pve qmeventd[1920429]: Finished cleanup for 101

Hat dies evtl. damit zu tun ?

Gruß
Christian

anjo · May 20, 2022

May 20 03:05:36 pve qmeventd[1920429]: Starting cleanup for 101
May 20 03:05:36 pve qmeventd[1920429]: Finished cleanup for 101

Diesen Eintrag habe ich auch, da hatte ich jedoch gelesen, dass nachdem das System ausgegangen ist, eine Bereinigung durchführt wird.

Die oberen Log sind bei mir ebenfalls identisch

itNGO · May 20, 2022

Evtl. ist das der gleiche Fehler wie hier?
https://forum.proxmox.com/threads/vm-shutdown-kvm-entry-failed-hardware-error-0x80000021.109410/

anjo · May 20, 2022

ja ist er

bei Red Hat sieht es so aus -> https://access.redhat.com/solutions/5749121

++++++

May 18 21:07:22 Server QEMU[2320314]: KVM: entry failed, hardware error 0x80000021
May 18 21:07:22 Server kernel: [887246.661968] set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.
May 18 21:07:22 Server QEMU[2320314]: If you're running a guest on an Intel machine without unrestricted mode
May 18 21:07:22 Server QEMU[2320314]: support, the failure can be most likely due to the guest entering an invalid
May 18 21:07:22 Server QEMU[2320314]: state for Intel VT. For example, the guest maybe running in big real mode
May 18 21:07:22 Server QEMU[2320314]: which is not supported on less recent Intel processors.
May 18 21:07:22 Server QEMU[2320314]: EAX=007be552 EBX=6431a180 ECX=00000001 EDX=00000000
May 18 21:07:22 Server QEMU[2320314]: ESI=cf5da080 EDI=cead1080 EBP=9db64e60 ESP=9db64c60
May 18 21:07:22 Server QEMU[2320314]: EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0
May 18 21:07:22 Server QEMU[2320314]: ES =0000 00000000 ffffffff 00809300
May 18 21:07:22 Server QEMU[2320314]: CS =bc00 7ffbc000 ffffffff 00809300
May 18 21:07:22 Server QEMU[2320314]: SS =0000 00000000 ffffffff 00809300
May 18 21:07:22 Server QEMU[2320314]: DS =0000 00000000 ffffffff 00809300
May 18 21:07:22 Server QEMU[2320314]: FS =0000 00000000 ffffffff 00809300
May 18 21:07:22 Server QEMU[2320314]: GS =0000 00000000 ffffffff 00809300
May 18 21:07:22 Server QEMU[2320314]: LDT=0000 00000000 000fffff 00000000
May 18 21:07:22 Server QEMU[2320314]: TR =0040 6432a000 00000067 00008b00
May 18 21:07:22 Server QEMU[2320314]: GDT= 6432bfb0 00000057
May 18 21:07:22 Server QEMU[2320314]: IDT= 00000000 00000000
May 18 21:07:22 Server QEMU[2320314]: CR0=00050032 CR2=61960088 CR3=85382000 CR4=00000000
May 18 21:07:22 Server QEMU[2320314]: DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
May 18 21:07:22 Server QEMU[2320314]: DR6=00000000ffff0ff0 DR7=0000000000000400
May 18 21:07:22 Server QEMU[2320314]: EFER=0000000000000000
May 18 21:07:22 Server QEMU[2320314]: Code=kvm: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed.
May 18 21:07:24 Server kernel: [887249.115788] fwbr105i0: port 2(tap105i0) entered disabled state
May 18 21:07:24 Server kernel: [887249.115892] fwbr105i0: port 2(tap105i0) entered disabled state
May 18 21:07:24 Server kernel: [887249.177101] zd32: p1 p2 p3 p4
May 18 21:07:24 Server kernel: [887249.235598] fwbr105i1: port 2(tap105i1) entered disabled state
May 18 21:07:24 Server kernel: [887249.235792] fwbr105i1: port 2(tap105i1) entered disabled state
May 18 21:07:24 Server kernel: [887249.293289] fwbr105i2: port 2(tap105i2) entered disabled state
May 18 21:07:24 Server kernel: [887249.293389] fwbr105i2: port 2(tap105i2) entered disabled state
May 18 21:07:25 Server kernel: [887249.353252] fwbr105i3: port 2(tap105i3) entered disabled state
May 18 21:07:25 Server kernel: [887249.353412] fwbr105i3: port 2(tap105i3) entered disabled state
May 18 21:07:25 Server kernel: [887249.425230] fwbr105i4: port 2(tap105i4) entered disabled state
May 18 21:07:25 Server kernel: [887249.425329] fwbr105i4: port 2(tap105i4) entered disabled state
May 18 21:07:25 Server systemd[1]: 105.scope: Succeeded.
May 18 21:07:25 Server systemd[1]: 105.scope: Consumed 1d 8h 14min 30.254s CPU time.
May 18 21:07:25 Server qmeventd[1916254]: Starting cleanup for 105

itNGO · May 20, 2022

Im PVETEST gibt es eine korrigierte Version der pve-qemu-kvm
Vielleicht hilft das auch in diesem Fall..... könnte ich mir zumindest vorstellen....

fokustech · May 20, 2022

Ich habe das gleiche Problem, bisher ist aber nur einer der beiden Windows Server gecrashed.
Hat einer schon die neue Kernelversion 5.15.35-3 getestet. Der Absturz war bei mir unter 5.15.35-1 und im englischen Forum wird davon ausgegangen, dass das mit der Kernelversion zu tun hat.

mira · May 20, 2022

itNGO said:
Im PVETEST gibt es eine korrigierte Version der pve-qemu-kvm
Vielleicht hilft das auch in diesem Fall..... könnte ich mir zumindest vorstellen....

Dies reverted nur eine Änderung in einem unserer Backup Patches. Sollte also nichts diesbezüglich verbessern.

Ich habe das gleiche Problem, bisher ist aber nur einer der beiden Windows Server gecrashed.
Hat einer schon die neue Kernelversion 5.15.35-3 getestet. Der Absturz war bei mir unter 5.15.35-1 und im englischen Forum wird davon ausgegangen, dass das mit der Kernelversion zu tun hat.

Im englischen Teil des Forums [0] kam jetzt auf, dass alle mit diesem Problem pre-enrolled-keys verwenden.
Wir versuchen es derzeit damit zu reproduzieren.

[0] https://forum.proxmox.com/threads/vm-shutdown-kvm-entry-failed-hardware-error-0x80000021.109410/

itNGO · May 21, 2022

Kann bestätigen, seit gestern nacht legt es auch einen unserer Windows 2022 Server (EN) nieder mit folgendem Syslog-Eintrag.

PVE 7.2-4 Kernel aktuell gestartet: Linux 5.15.30-2-pve #1 SMP PVE 5.15.30-3 (Fri, 22 Apr 2022 18:08:27 +0200)
Pending Reboot für Kernel: 5.15.35-1-pve


May 21 06:01:11 RZA-APVE1 QEMU[603030]: KVM: entry failed, hardware error 0x80000021
May 21 06:01:11 RZA-APVE1 QEMU[603030]: If you're running a guest on an Intel machine without unrestricted mode
May 21 06:01:11 RZA-APVE1 QEMU[603030]: support, the failure can be most likely due to the guest entering an invalid
May 21 06:01:11 RZA-APVE1 QEMU[603030]: state for Intel VT. For example, the guest maybe running in big real mode
May 21 06:01:11 RZA-APVE1 QEMU[603030]: which is not supported on less recent Intel processors.
May 21 06:01:11 RZA-APVE1 kernel: set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.
May 21 06:01:11 RZA-APVE1 QEMU[603030]: EAX=ffffffff EBX=01c77a83 ECX=1943e180 EDX=00000000
May 21 06:01:11 RZA-APVE1 QEMU[603030]: ESI=00000001 EDI=1943e180 EBP=01c77a83 ESP=194c4700
May 21 06:01:11 RZA-APVE1 QEMU[603030]: EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0
May 21 06:01:11 RZA-APVE1 QEMU[603030]: ES =0000 00000000 ffffffff 00809300
May 21 06:01:11 RZA-APVE1 QEMU[603030]: CS =be00 7ffbe000 ffffffff 00809300
May 21 06:01:11 RZA-APVE1 QEMU[603030]: SS =0000 00000000 ffffffff 00809300
May 21 06:01:11 RZA-APVE1 QEMU[603030]: DS =0000 00000000 ffffffff 00809300
May 21 06:01:11 RZA-APVE1 QEMU[603030]: FS =0000 00000000 ffffffff 00809300
May 21 06:01:11 RZA-APVE1 QEMU[603030]: GS =0000 00000000 ffffffff 00809300
May 21 06:01:11 RZA-APVE1 QEMU[603030]: LDT=0000 00000000 000fffff 00000000
May 21 06:01:11 RZA-APVE1 QEMU[603030]: TR =0040 194ab000 00000067 00008b00
May 21 06:01:11 RZA-APVE1 QEMU[603030]: GDT=     194acfb0 00000057
May 21 06:01:11 RZA-APVE1 QEMU[603030]: IDT=     00000000 00000000
May 21 06:01:11 RZA-APVE1 QEMU[603030]: CR0=00050032 CR2=4e7fd000 CR3=24529002 CR4=00000000
May 21 06:01:11 RZA-APVE1 QEMU[603030]: DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
May 21 06:01:11 RZA-APVE1 QEMU[603030]: DR6=00000000ffff0ff0 DR7=0000000000000400
May 21 06:01:11 RZA-APVE1 QEMU[603030]: EFER=0000000000000000
May 21 06:01:11 RZA-APVE1 QEMU[603030]: Code=kvm: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed.
May 21 06:01:12 RZA-APVE1 kernel: vmbr0: port 11(tap255014030i0) entered disabled state
May 21 06:01:12 RZA-APVE1 kernel: vmbr0: port 11(tap255014030i0) entered disabled state
May 21 06:01:12 RZA-APVE1 systemd[1]: 255014030.scope: Succeeded.
May 21 06:01:12 RZA-APVE1 systemd[1]: 255014030.scope: Consumed 1d 12h 39min 46.561s CPU time.
May 21 06:01:13 RZA-APVE1 qmeventd[2430350]: Starting cleanup for 255014030
May 21 06:01:14 RZA-APVE1 qmeventd[2430350]: Finished cleanup for 255014030

fokustech · May 21, 2022

Interessanterweise ist bei mir bisher nur einer der zwei Server gecrashed. Der bisher stabile Server hat die Mai Updates von Microsoft noch nicht.
Kann da ein Zusammenhang bestehen, bzw. kann jemand bestätigen, dass die Server auch mit alten Patchständen crashen?

itNGO · May 21, 2022

fokustech said:
Interessanterweise ist bei mir bisher nur einer der zwei Server gecrashed. Der bisher stabile Server hat die Mai Updates von Microsoft noch nicht.
Kann da ein Zusammenhang bestehen, bzw. kann jemand bestätigen, dass die Server auch mit alten Patchständen crashen?

Tatsächlich habe ich hier einen 2022(en) mit pending reboot für das Update 05/22 der also aktuell noch mit 04/22 Updatestand läuft und seit 8 Tagen online ist.... Ich würde jetzt vermuten der müsste dann nach dem Neustart das Problem zeigen. Ist aber der RZ-Zentrale File-Server... da kann ich zur Zeit nicht "zwischen"....

fokustech · May 22, 2022

Letzte Nacht wieder. Die VM mit den Updates war weg, die andere läuft weiter stabil. Ich bin jetzt mal auf den alten Kernel gewechselt, wie im englischen Forum vorgeschlagen und schau mal, was passiert.

Windows Server 2022 - Das System wurde unerwartet heruntergefahren

Member

Attachments

New Member

Active Member

Distinguished Member

Member

Attachments

Renowned Member

Distinguished Member

Renowned Member

Member

New Member

Member

Renowned Member

Member

Renowned Member

Member

Proxmox Staff Member

Renowned Member

Member

Renowned Member

Member