Bootloop in Windows 11 VM nach Update auf PVE 9.2.2

[DrNoname]

Nach Update meines pve auf 9.2.2 hatte eine meiner Windows 11 pro VMs einen Bootloop. Der ließ sich dadurch beheben, dass ich den OS-Typs von (fäschlich) Windows 10 auf (korrekt) Window 11 umgestellt habe. Merkwürdig ist nur, dass diese falsche Einstellung des guest-OS mehr als ein Jahr keinerlei Probleme gemacht hat.
Wolle das nur berichten, falls jemand ähnliche Probleme hat...

 

[mariol]

Danke @DrNoname für diese Info. Der Bootloop, war der rein auf BIOS Ebene oder schon auf Windows Ebene. Bitte poste uns auch zur Vollständigkeit deine VMconfig.

qm config <vmid>

 

[DrNoname]

Der Bootloop war vermutlich auf BIOS-Ebene: nach dem Start der VM erschien auf der Proxmox-Konsole das Proxmox-Logo, am Unterrand der Start-Fortschrittsbalken, der aber (statt wie normal einmal) dreimal durchlief, anschließend kam eine Meldung, der Computer sei defekt müsse repariert werden und man müsse die Bitlocker Entsperrung starten. Die Eingabe der Entsperrcodes führte aber -eben im loop- zu einem erneuten Startversuch, der wieder in der Bitlocker Maske endete. Der Windows "Startkringel" tauchte nicht auf; deswegen gehe ich von einem BIOS-Bootloop aus.

Hier noch die VM-Konfig:

agent: 1
bios: ovmf
boot: order=scsi0
cores: 4
cpu: x86-64-v2
efidisk0: local-lvm:vm-404-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=4M
machine: pc-q35-9.2+pve1
memory: 8192
meta: creation-qemu=9.2.0,ctime=1749562195
name: W11-REMOTE-2
net0: virtio=00:0c:29:af:ee:a1,bridge=vmbr0
numa: 0
onboot: 1
ostype: win11
scsi0: local-lvm:vm-404-disk-1,iothread=1,size=70G
scsihw: virtio-scsi-single
smbios1: uuid=564dc356-0582-d9a2-66c1-e2de8bafeea1
sockets: 1
startup: order=4
tpmstate0: local-lvm:vm-404-disk-2,size=4M,version=v2.0
vmgenid: 1ac88b7a-50f1-4b8d-a3e4-bda936b960b1

 

[Falk R.]

Der Bootloop war vermutlich auf BIOS-Ebene: nach dem Start der VM erschien auf der Proxmox-Konsole das Proxmox-Logo, am Unterrand der Start-Fortschrittsbalken, der aber (statt wie normal einmal) dreimal durchlief, anschließend kam eine Meldung, der Computer sei defekt müsse repariert werden und man müsse die Bitlocker Entsperrung starten. Die Eingabe der Entsperrcodes führte aber -eben im loop- zu einem erneuten Startversuch, der wieder in der Bitlocker Maske endete. Der Windows "Startkringel" tauchte nicht auf; deswegen gehe ich von einem BIOS-Bootloop aus.

Hier noch die VM-Konfig:

agent: 1
bios: ovmf
boot: order=scsi0
cores: 4
cpu: x86-64-v2
efidisk0: local-lvm:vm-404-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=4M
machine: pc-q35-9.2+pve1
memory: 8192
meta: creation-qemu=9.2.0,ctime=1749562195
name: W11-REMOTE-2
net0: virtio=00:0c:29:af:ee:a1,bridge=vmbr0
numa: 0
onboot: 1
ostype: win11
scsi0: local-lvm:vm-404-disk-1,iothread=1,size=70G
scsihw: virtio-scsi-single
smbios1: uuid=564dc356-0582-d9a2-66c1-e2de8bafeea1
sockets: 1
startup: order=4
tpmstate0: local-lvm:vm-404-disk-2,size=4M,version=v2.0
vmgenid: 1ac88b7a-50f1-4b8d-a3e4-bda936b960b1

Eventuell stört sich Win11 auch an der limitierten CPU. Laut MS Doku muss ein System für Win11 mindestens die x86-64-v3 Features unterstützen.

 

[mariol]

Danke für die VMconfig. Ich habe es versucht im LAB zu reproduzieren. Startete hier aber immer normal. Da meine TestVMs hier nicht mit Bitlocker arbeiten, könnte es vielleicht eine Kombination sein.

 

[GMBauer]

Eventuell stört sich Win11 auch an der limitierten CPU. Laut MS Doku muss ein System für Win11 mindestens die x86-64-v3 Features unterstützen.

Au contraire, mon Capitan.

Die ganz normale x86-64-v2-AES betreibt bei mir Win11Pro ganz vorzüglich.

btw: Was wird alles umgestellt, wenn man in einem aktuellen PVE den OS-Type von Win10 auf Win11 ändert?

 

[mariol]

btw: Was wird alles umgestellt, wenn man in einem aktuellen PVE den OS-Type von Win10 auf Win11 ändert?

Es ändert sich das Startverhalten, also mit welchen Commandos und Optionen eine VM im Backend gestartet wird. "This is used to enable special optimization/features for specific operating systems."

Alle Optionen und Commandos sieht man mit:

qm showcmd <vmid>

Die ganz normale x86-64-v2-AES betreibt bei mir Win11Pro ganz vorzüglich.

Ja, hier auch.

 

[Falk R.]

Au contraire, mon Capitan.

Die ganz normale x86-64-v2-AES betreibt bei mir Win11Pro ganz vorzüglich.

btw: Was wird alles umgestellt, wenn man in einem aktuellen PVE den OS-Type von Win10 auf Win11 ändert?

Microsoft schreibt das einfach nur in die Doku. Wenn etwas nicht wie gewollt funktioniert berufen die sich immer auf die Doku.
Bei Redhat 10 wird der x86-64-v3 sogar erzwungen, sonst startet das System nicht. Der V3 Standard ist jetzt auch nicht so Taufrisch und das wird demnächst noch öfters Mindestvoraussetzung werden.

 

[GMBauer]

Microsoft schreibt das einfach nur in die Doku. Wenn etwas nicht wie gewollt funktioniert berufen die sich immer auf die Doku.

So kann man es sich einfach machen.

"Die Lampe ist kaputt."
"Haben Sie auch linksdrehenden Strom? Das steht so in den Dokus. Wenn Sie den nicht haben, sind Sie selbst schuld."

 

[Falk R.]

So kann man es sich einfach machen.

"Die Lampe ist kaputt."
"Haben Sie auch linksdrehenden Strom? Das steht so in den Dokus. Wenn Sie den nicht haben, sind Sie selbst schuld."

Jetzt lass mal die Kirche im Dorf. Sei doch froh das Microsoft das nicht komplett blockt wie bei Redhat. Übrigens gibt es den Standard x86-64-v3 schon seit 2013 und die meisten CPUs aus der Zeit unterstützen auch alle Features dafür. Da kann man schon mal sowas zum Standard definieren.