[SOLVED] HyperV-Fehler nach Migration / VM bootet nicht

R

rothkraut

New Member
Nov 25, 2025
28
3
3
Hallo zusammen,

ich beiße mir jetzt schon seit Stunden die Zähne an folgendem Problem aus:


Ich habe eine VM von VMWare (Esx 8) zu Proxmox (9.2) migriert.

Auf dieser VM ist Hyper V installiert und es laufen zwei VMs darauf. Leider bekomme ich nun nachdem ich die VMs starten will folgenden Fehler:

1780573334311.png


Ich weiß für nested virtualisation soll man als CPU "host" auswählen. Leider bootet die VM dann nicht! Windows Icon kurz zu sehen danach geht er direkt in die OS-Reparatur.

Die VM läuft mit dem default [x86-64-AES] ohne Probleme, aber dann geht die Virtualisierung eben nicht.


Die CPU meines Servers ist ein 64 x Intel(R) Xeon(R) Gold 6444Y (2 Sockets).

Auf dem Vorherigen System (vor Migration) war es ein Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz


Ich habe schon versucht den CPU-Type auf SapphireRapids (Intel) mit dem nested Virtualisation flag zu setzen. Habe hier verschieden Versionen probiert. Leider kommt immer eine QEMU-Warnung bezüglich fehlender Features (hle, rtm).

Machine Typ von Default (i440fx) auf q35 brachte auch keine Besserung.

Nested virtualisation ist aktiviert:

cat /sys/module/kvm_intel/parameters/nested
Y

CPU auf host mit nested-virt bringt auch nichts, bootet ebenfalls nur ins Windows Repair.

Hat noch jemand eine Idee? Mir fällt nichts mehr ein.

Hier noch die aktuelle Konfig:


bios: seabios
boot: order=scsi0;scsi1;ide2
cores: 4
cpu: x86-64-v2-AES
hotplug: disk,network,usb
machine: pc-i440fx-11.0
memory: 24576
meta: creation-qemu=11.0.0,ctime=1780549481
name: server
net0: virtio=XX:XX:XX:XX:XX:XX,bridge=VLAN1
numa: 0
ostype: win11
 
Last edited:
An der Stelle wäre mal die ESXi-Config interessant.

Bist du sicher, dass die Maschine im MBR-Mode lief? Kein UEFI?

Und pc-i440fx ist ein asbach-alter Standard - q35 wäre sicher sinnvoller.
 
Last edited:
@boisbleu

1780575379885.png

1780575394572.png

Welche Konfig macht Sinn? Bin in ESXi nicht so fit und habe die Umgebung auch nur "geerbt" habe die VM selbst nicht aufgesetzt.
 
Last edited:
Kannst du bitte mal die gesamte Config des Hyper-V Servers posten (in Codeblöcken)? Oder endet die Config tatsächlich mit ostype: win11?
 
Code: 
bios: seabios
boot: order=scsi0;scsi1;ide2
cores: 4
cpu: x86-64-v2-AES
hotplug: disk,network,usb
machine: pc-i440fx-11.0
memory: 24576
meta: creation-qemu=11.0.0,ctime=1780549481
name: server
net0: virtio=xx:xx:xx:xx:xx:xx,bridge=VLAN1
numa: 0
ostype: win11
parent: Working_040626
scsi0: storage:vm-2622-disk-0,size=65G
scsi1: storage:vm-2622-disk-1,size=900G
scsihw: virtio-scsi-single
smbios1: uuid=42088065-1fe4-6c3d-9ccd-661b1a72e184
sockets: 2
vmgenid: 544f9e8d-985a-449b-bae5-678817da65bb
 
boisbleu said:
Passt soweit, auch wenn ich die Kombi seabios und win11 schräg finde.

Wie hast du die Maschine migriert?
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE

Hast du die VirtIO Treiber installiert und aktiviert?
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#VirtIO_Guest_Drivers
Click to expand...

Habe die VM über den normalen Importer vom ESX-Host auf den PVE-Host migriert.

Habe jetzt schon über 400 VMs von VMWare zu PVE migriert. Dieses Verhalten hatte ich bis jetzt noch nicht.

Habe auch auf dem gleichen Host eine andere VM, auf welcher Hyper-V ohne Probleme läuft. Habe bei der Migration nichts anders gemacht. Einzige Konfiguration, die anders ist, NUMA ist aktiviert. Hab ich zum testen auch mal aktiviert. Macht aber keinen Unterschied.

VirtIO-Treiber habe ich vor der Migration installiert. Allerdings die Version 1.271 Ich versuch es mal mit einem Update auf die Version 1.285.
 
Last edited:
ThoSo said:
Was spricht dagegen, die Im HyperV laufenden VMs direkt nach Proxmox zu migrieren und den Overhead zu reduzieren?
Click to expand...
Ist eine historisch gewachsene Sonderlocke, welche ich nicht implementiert habe, aber mit welcher ich nun leben muss.
Leider muss der Zustand vorerst beibehalten werden.
 
ThoSo said:
Was spricht dagegen, die Im HyperV laufenden VMs direkt nach Proxmox zu migrieren und den Overhead zu reduzieren?
Click to expand...
Da wäre tatsächlich die schlaueste Variante. Sind die Gründe, die dagegen sprechen lizenzrechtlicher Natur?

PS: bleib lieber bei den .271 Treibern - das sind aktuell die stabilsten.
 
boisbleu said:
Da wäre tatsächlich die schlaueste Variante. Sind die Gründe, die dagegen sprechen lizenzrechtlicher Natur?

PS: bleib lieber bei den .271 Treibern - das sind aktuell die stabilsten.
Click to expand...

Auch. Die Thematik hat vor meiner Zeit begonnen und der damalige Hauptverantwortliche ist nicht mehr im Team. Daher kann ich leider nicht so viel dazu sagen. Besonders aus Zeitgründen muss ich vorerst bei dieser Lösung bleiben.

P.S. danke für den Hinweis mit den Treibern ^^
 
Auffallen tut, dass die VM mit x86-64-v2-AES läuft, mit Host aber nicht. ABER, genau hier könnte dein Problem liegen. Die alte CPU hatte 18C/36T, die neue hat Kerne mit hoher und niedriger Priorität. Könnte hier die Ursache sein? Was ist das denn für eine Windows Version?

Nachtrag: wie wäre es, den Hyper-V auf PVE neu zu installieren und dann die VMs vom alten Hyper-V auf den neuen zu migrieren?
 
Last edited:
OK jetzt geht es.

Ich habe nochmal final auf Host + nested-virt-flag gesetzt. Und auf einmal hat es funktioniert. Aus dem nichts. Habe es den ganzen Tag mehrmals mit genau dieser Config getestet.

Kann leider wirklich nicht sagen, was jetzt auf einmal anders war. Habe die VM noch mehrmals rebootet kam immer sauber hoch und die VMs liefen auch sauber an. Danke für die Unterstützung!
 
Schön, wenn es jetzt für den Moment mal funktioniert. Aber darauf verlassen kannst du dich nach deiner Odyssee meiner Meinung nach nicht.
Diese altertümlichen, geerbten Lösungen sind meistens Langzeitbeständig und ein Klotz am Bein.
Beim nächsten Reboot oder Update kann es das schon wieder gewesen sein - halte dir die ESXi-Variante mal fest für alle Fälle. GGf. Reicht auch eine VmWare Workstation um das am Leben zu erhalten. ODer gleich einen Windows Server mit HyperV direkt auf einer Kiste installieren und die VMs aus der ESXi Windows Gast Lösung herausnehmen.

Evtl. kannst bei der CPU auch statt "Host" oder der "x86-64-Vxx" Variante auf eine der Physischen CPU nahe gehenden Variante gehen. Mal im Hinterkopf behalten.
 
Last edited:
  • Like
Reactions: Johannes S and rothkraut
ThoSo said:
Schön, wenn es jetzt für den Moment mal funktioniert. Aber darauf verlassen kannst du dich nach deiner Odyssee meiner Meinung nach nicht.
Diese altertümlichen, geerbten Lösungen sind meistens Langzeitbeständig und ein Klotz am Bein.
Beim nächsten Reboot oder Update kann es das schon wieder gewesen sein - halte dir die ESXi-Variante mal fest für alle Fälle. GGf. Reicht auch eine VmWare Workstation um das am Leben zu erhalten. ODer gleich einen Windows Server mit HyperV direkt auf einer Kiste installieren und die VMs aus der ESXi Windows Gast Lösung herausnehmen.

Evtl. kannst bei der CPU auch statt "Host" oder der "x86-64-Vxx" Variante auf eine der Physischen CPU nahe gehenden Variante gehen. Mal im Hinterkopf behalten.
Click to expand...
Danke für den Hinweis. Werde es mir bei Gelegenheit nochmal genauer anschauen, aber für den Augenblick muss es erstmal so laufen.
 
Was dir auf alle Fälle eher früher als später (womöglich schon jetzt) auf die Füsse fallen wird, sind deine VMs selbst. Wenn es tatsächlich Win11 ist, war die letzte Version 23H2, die mit seabios/i440fx lief. Danach eine Zeit lang noch mit Tricks. Du wirst aber nicht darum herumkommen, diese auf UEFI umzustellen, falls du ohne Kopfschmerzen und unliebsamen Überraschungen leben willst. Dabei spielt der verwendete Hypervisor auch kaum eine Rolle.
 
Last edited:
  • Like
Reactions: Johannes S and boisbleu
You must log in or register to reply here.
Top Bottom
Back