PVE 7.1 - Restored Windows VM friert beim Start ein

[Devian242]

Hallo zusammen,

ich habe heute direkt auf PVE 7.1 aktualisiert und stehe nun vor einem Problem:

Via PBS habe ich eine Testmaschine (die ich öfters mal komplett lösche und wiederherstelle) auf PVE zurückgeholt. Die Maschine versucht zu booten (Windows), friert aber kurz nach dem Start ein. Da ich diese Maschine schon öfters restored habe, vermute ich hier ein PVE 7.1 "Problem".

Kann das jemand bestätigen oder widerlegen?

Viele Grüße
Christian

 

[ag1]

Hallo Christian,

wir hatten auch das Problem nach dem Update auf 7.1 mit Windows 2019 Servern. Sind nach dem Reboot einfach beim Booten hängen geblieben. Wir haben das Problem mal so gelöst, dass wir mit dem alten Kernel hochgefahren sind und dann sind auch die Windows 2019 Server wieder hochgekommen.

Entweder ist was im Kernel was sich nicht mit den Windows Servern verträgt oder man muss ggf. Einstellungen in der VM nachziehen.

Viele Grüße
Rene

 

[Devian242]

Hallo Christian,

wir hatten auch das Problem nach dem Update auf 7.1 mit Windows 2019 Servern. Sind nach dem Reboot einfach beim Booten hängen geblieben. Wir haben das Problem mal so gelöst, dass wir mit dem alten Kernel hochgefahren sind und dann sind auch die Windows 2019 Server wieder hochgekommen.

Entweder ist was im Kernel was sich nicht mit den Windows Servern verträgt oder man muss ggf. Einstellungen in der VM nachziehen.

Viele Grüße
Rene

Hallo Rene,

kann ich von meiner Seite her bestätigen. Mit dem 5.11.xxx Kernel starten die Maschinen wieder problemlos, wobei es sich um Win2016 Maschinen handelt.

Scheint wirklich eine Kernelsache zu sein...

Viele Grüße und vielen Dank für den Workaround

Christian

 

[t.lamprecht]

Hi,

welche CPU ist bei euch im Einsatz und wie schaut die VM config aus (qm config VMID)?

 

[Devian242]

Hallo

Ich hab hier eine "etwas ältere" CPU im Einsatz:
Intel(R) Xeon(R) CPU E3-1245 v6 @ 3.70GHz

Und hier die entsprechende Config:
root@pve:~# qm config 400
agent: 1
boot: order=ide2;sata0;net0
cores: 6
description: Exchange 2016 CU20
ide2: none,media=cdrom
machine: pc-i440fx-6.1
memory: 16384
name: W2016-EXCH
net0: virtio=BA:36:48:44:60:B9,bridge=vmbr0,tag=8
numa: 0
onboot: 1
ostype: win10
rng0: source=/dev/urandom
sata0: RAID6:400/vm-400-disk-0.raw,cache=writeback,size=1200G
scsihw: virtio-scsi-pci
smbios1: uuid=e8debd6a-60fb-4b37-bcfe-27c6df583130
sockets: 1
startup: up=60
vmgenid: 262b7fa4-34f5-434e-8ef5-8e21337b2951

Viele Grüße
Christian

 

[t.lamprecht]

Danke für die Details.

Die CPU ist zwar nicht die neueste aber wir haben auch ältere (etwa Xeon v2/v3) in unseren Testlab bei denen Windows grundsätzlich i.O ist, also an "zu alt" dürfte es wohl nicht liegen.

Sind im Journal vom vorherigen Boot, also wo der 5.13 Kernel verwendet wurde, irgendwelche Fehler im Log?
Also zum Zeitpunkt wo die VM Probleme gemacht hat?

 

[pete13]

Ich habe das gleiche Problem CPU Ryzen 9 5900X. Habe das in Proxmox 7.1 Upgrade Issues auch schon mit VM Config geposted. Im Anhang der Log-Ausschnitt vom Start de Windows 10 VM. Ja, es sind Fehlermeldungen im Log zu sehen.Hinweis zum Fehlerbild: am Anfang lässt sich der Mauszeiger im Startbildschirm von Windows noch einige Zeit bewegen, aber weder auf Klicks noch auf Tastendrücke auf der angeschlossenen Tastatur erfolgt eine Reaktion (2 Tastaturen angeschlossen, eine direkt am USB Port des Host, eine über KVM-Switch)

 

[noch_einer]

Hallo zusammen,
habe gleiches Problem, CPU ist auch etwas älter: Xeon CPU E3-1240 v3 @ 3.40GHz
betroffen sind alle VMs auch Linux wie z.B. ZorinOS16
einzige Ausnahme ist der Windows Server 2000, der einzige der brav weiter läuft.
Noch eine Beobachtung, als ich bei einem Server 2012 im abgesicherten Modus die QEmu-Treiber gestoppt habe lief auch der normal weiter.
Hoffe das hilft Euch
Gruß Werner

 

[boscolab]

Hallo zusammen,
auch ich beobachte das gleiche verhalten! Meine CPU ist eine 2x Xeon E5-2670 v2 20 Kerne.
Eine Windows 10 VM läuft, die andere bleibt bei booten hängen.

 

[pny]

Hatte das selbe Problem mit

Habe von Poxmox Version 7.1-5 auf 7.0-14+1 einen Rollback via apt gemacht und das hat das Problem behoben.

 

[t.lamprecht]

FYI: die meisten hier melden, dass das Booten des vorherige 5.11 Kernel genug ist, dafür muss man keine Pakete mit apt o.ä. zurückrollen, der alte Kernel kann beim Booten ausgewählt werden.

 

[pny]

FYI: die meisten hier melden, dass das Booten des vorherige 5.11 Kernel genug ist, dafür muss man keine Pakete mit apt o.ä. zurückrollen, der alte Kernel kann beim Booten ausgewählt werden.

Alles klar. Hab den Server remote gehostet und habe keinen Konsolenzugriff und wolle nicht manuell am grub.conf rumfummeln.

Deshalb habe ich das via apt gemacht.

Danke für den Hinweis, t.lamprecht

 

[ag1]

FYI: die meisten hier melden, dass das Booten des vorherige 5.11 Kernel genug ist, dafür muss man keine Pakete mit apt o.ä. zurückrollen, der alte Kernel kann beim Booten ausgewählt werden.

Hallo,

es dürfte nur Windows Clients oder Server treffen. Auch auch nur die neueren Versionen. Bei uns waren es die Windows 2019 Server.. Aber wir haben einen älteren Windows.2012R2 auch noch und der hatte kein Problem. Die ganzen Linux-Server sind ohne Probleme hochgekommen.

Ich denke nicht, dass es am CPU liegt.

BR Rene

 

[t.lamprecht]

es dürfte nur Windows Clients oder Server treffen. Auch auch nur die neueren Versionen. Bei uns waren es die Windows 2019 Server.. Aber wir haben einen älteren Windows.2012R2 auch noch und der hatte kein Problem. Die ganzen Linux-Server sind ohne Probleme hochgekommen.

Ok, um configs vom betroffenen VMs und Details wie welcher Storage o.ä. wäre ich Dankbar, da unsere Windows tests alle OK laufen sollte es schon ein Detail geben welches anders sein muss um das Problem auszulösen.

Ich denke nicht, dass es am CPU liegt.

Glaube ich langsam auch nicht mehr, zu viele verschiedene Modelle.

 

[ag1]

Ok, um configs vom betroffenen VMs und Details wie welcher Storage o.ä. wäre ich Dankbar, da unsere Windows tests alle OK laufen sollte es schon ein Detail geben welches anders sein muss um das Problem auszulösen.


Glaube ich langsam auch nicht mehr, zu viele verschiedene Modelle.

Hallo,

anbei im Textfile die Config der zwei W 2019 Server. An sich nichts spezielles.

BR Rene

 

[t.lamprecht]

Recht normal.. Was etwas auffällt, die Disk ist mit SATA angebunden, das war bei Devian242 oben auch der Fall:

sata0: RAID6:400/vm-400-disk-0.raw,cache=writeback,size=1200G

Würd ich bei dem Problem jetzt normal nicht sofort verdächtigen aber es ist mir halt leicht Suspekt, dass hier zwei Leute mit Problemen SATA haben und persönlich habe ich SATA auch schon etwas länger nicht mehr getestet (VirtioBlock, (VirtIO-)SCSI, und IDE (für CDROM) sind da etwas gängier).

Wir empfehlen generell ja immer SCSI mit VirtIO als SCSI-controller und den Windows VirtIO Treibern
https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers

Werde mal probieren das nachzustellen...

 

[t.lamprecht]

Ok, hängt hier auch mit SATA als Disk Bus bald nach Beginn der Installation...

Aber, es scheint nicht (nur) an SATA zu liegen, sondern am IO Framework, also an io_uring vom 5.13 kernel.

Sobald ich das bei der auf threads (für cache = write back/through) bzw. native (für cache = off, none oder direct sync) wechsele klappt es wieder.

Kann man pro Disk unter Advanced bei Async IO Einstellen:

 

[t.lamprecht]

Gegencheck: Mit VirtIO-SCSI klappt es hier auch mit io_uring und dem 5.13 Kernel Problemlos.

Für betroffene mit SATA ist es aber trotzdem wohl einfacher den Async IO modus zu wechseln, denn das kriegt das Gastbetriebsystem nicht als HW Änderung mit (Windows muckt hier ja gerne bei jeglicher Änderungen rum..).

Für neue VMs würde ich aber wie bereits geschrieben generell VirtIO-SCSI empfehlen.

 

[ag1]

Gegencheck: Mit VirtIO-SCSI klappt es hier auch mit io_uring und dem 5.13 Kernel Problemlos.

Für betroffene mit SATA ist es aber trotzdem wohl einfacher den Async IO modus zu wechseln, denn das kriegt das Gastbetriebsystem nicht als HW Änderung mit (Windows muckt hier ja gerne bei jeglicher Änderungen rum..).

Für neue VMs würde ich aber wie bereits geschrieben generell VirtIO-SCSI empfehlen.

Danke, kann ich soweit bestätigen. Ich habe die W 2019 Server umgestellt und sie laufen jetzt auch unter Kernel 5.13.

BR Rene

 

[pete13]

Gegencheck: Mit VirtIO-SCSI klappt es hier auch mit io_uring und dem 5.13 Kernel Problemlos.

Für betroffene mit SATA ist es aber trotzdem wohl einfacher den Async IO modus zu wechseln, denn das kriegt das Gastbetriebsystem nicht als HW Änderung mit (Windows muckt hier ja gerne bei jeglicher Änderungen rum..).

Für neue VMs würde ich aber wie bereits geschrieben generell VirtIO-SCSI empfehlen.

Funktioniert so auch bei mir wieder. Danke