Windows Server 2025 und Nested-Hyper-V

[ollibraun]

Hallo,

ich starte gerade nochmal den Versuch, Hyper-V unter PVE virtualisiert einzusetzen. Ich habe das schon einmal erfolglos versucht (damals mit Windows Server 2022: https://forum.proxmox.com/threads/hyper-v-unter-proxmox-ve.151919/), nun also auf ein Neues.

Ich wollte nun von Windows Server 2025 Standard inkl. Desktopdarstellung starten, und meine ersten Versuche waren nicht nur ferfolglos, sondern erinnerten mich auch an den damaligen Hyper-V-Versuch. Mal schauen.

Ich lege hier los:

• pve-manager/8.2.8
• Linux 6.11.0-1-pve
• 48 x Intel(R) Xeon(R) Gold 5412U (1 Socket)

Bei ersten Versuchen konnte ich mich zunächst anmelden, irgendwann nach ersten Neustarts kam ich dann in die gleiche Situation wie damals beim Hyper-V-versuch. Allerdings hatte ich jetzt noch keine Hyper-V-Rolle hinzugefügt.

Ich hatte jeweils die VirtIO-treiber hinzugefügt, Windows Updates installiert. Dann kam nach Neustarts nur noch kurz das Proxmox-Logo, und die Maschine startete immer wieder neu. Im Abgesicherten Modus mit Netzwerktreibern funktionierte das System.

Jetzt also systematisch. Zuerst: Hat hier schon jemand einen Windows Server 2025 unter PVE virtualisiert?

Ups... jetzt startet das frische System schon nicht mehr, nachdem ich nur den Hostnamen geändert habe. Letzte Woche trat dieser Effekt erst nach mehreren Neustarts auf, während derer ich die VirtIO-treiber hinzugefügt und für Internetverbindung gesorgt hatte. Habe ich jetzt alles noch nicht gemacht. Abgesicherter Modus mit Netzwerk funktioniert.

 

[ThoSo]

Wie ist den die VM konfiguriert?
Der Server 2025 ist ja "baugleich" mit dem Windows 24H2 - das läuft bei mir in Proxmox sauber.
Hier waren die Treiber entscheidend, da die Kiste beim erstenBooten immer mit schwarzem Bild ins "leere" lief.
Siehe Thread hier : https://forum.proxmox.com/threads/gelöst-windows-11-gast-bootet-nicht-mehr-nach-inplace-upgrade-von-23h2-auf-24h2.153814/

Hat der exKurs "HyperV" unter Proxmox einen besonderen Grund oder nur Just-for-Fun ?

 

[ollibraun]

Ja, mit W11 24H2 habe ich auch keine Probleme. Treiber sind hier virtio-win-0.1.262.iso.

Was meinst Du mit der Nachfrage wegen Hyper-V? Ich möchte einerseits diverse einfache Windows Server-VMs durch die Version 2025 ersetzen, andererseits dann aber auch nochmal einen Versuch mit Nested-Hyper-V starten. Dass ich das jetzt schon erwähne, liegt daran, dass das Fehlerbild ähnlich ist.

 

[ThoSo]

Ich habe gerade mal einen Server 2025 installiert (bin aber bei VE 8.2.7 / Kernel 6.8.12-2)
Unterschiede : beim Speicher Ballooning, als CPU nicht HOST sondern [x86-64-v2-AES) -> also die Standardwerte sozusagen,
Installation mit Treibern, QEMU Agent 0.1.262-1, läuft erstmal.
Muss mir das mit dem HyperV mal ansehen

 

[ThoSo]

So, ich habe den CPU Typ auf HOST Umgestellt und HyperV installiert.
Reboot ok, Hyper-V geöffnet und eine VM erzeugt und gestartet




Sieht gut aus!

 

[ollibraun]

Ja. Bei Dir.

Ich werde die Tage nochmal in BIOS gehen und mir die Einstellungen ansehen. VT-d ist aktiviert, aber vielleicht finde ich noch was. Ist ein Hetzner EX130-R mit Intel Xeon Gold 5412U.

Denn das Bild bei mir ist sehr uneinheitlich:

• W11 23H2 und 24H2 macht keine Probleme mit dem CPU-Typ "HOST".
• Die Windows Server 2022 funktionieren auch als "HOST" (starteten aber nicht mehr nach dem hinzufügen der Hyper-V-Rolle, alter Thread).
• Der Windows Server 2025 letzte Woche funktionierte zunächst "HOST", aber irgendwann dann nicht mehr nach dem Ändern des Hostnamens, der VirtIO-Treiber, der ersten Windows-Updates - ich konnte die Ursache nicht eingrenzen, diverse Neuinstallationen und anschließend die genannten Änderungen und nach irgendeinem Neustart dann nicht mehr.

Jetzt mit ein paar PVE-Updates und neuerdings mit Kernel 6.11 statt vorher 6.8:

• Der Windows Server 2025 funktionierte nicht als "HOST", nach dem Umschalten auf "x86-64-v2-AES" funktioniert er zwar gerade, lässt aber wegen fehlender CPU-Features jetzt die Hyper-V-Rolle nicht hinzufügen.

Wenn ich alle VMs mal aus habe und ins BIOS komme, mache ich diesmal Screenshots.

 

[ThoSo]

Deswegen habe ich den auch auf HOSt umgestellt, da Hyper-V ja etwas „fehlt“.
Teste es doch bitte einmal mit einem 6.8er Kernel - vielleicht liegt es ja am 6.11er Kernel, das da der Hase im Pfeffer liegt und es knatscht im Getriebe.

Könnte aber auch an den MS Updates liegen - so ausgereift ist der 24er noch nicht, da er noch viel zu wenig Produktiv eingesetzt wird - der kann m.Erachtens noch ein halbes Jahr reifen und abhängen, bis man den wirklich loslassen kann.

 

[Falk R.]

Ich habe für tests schon öfters Win2022 mit HyperV genutzt. Habe noch nie Probleme gehabt, aber ich nutze die virtio Tools 0.1.262 nicht. Da sind mir zu viele Bugs drin.
Für Server 2022 nutze ich 0.1.248. 2025 ist aber nur in der 262 gelistet, aber die 2022 Treiber tun es auch im 2025.
Deine VM Konfiguration sieht OK aus, VT-D sollte aber unbedingt an sein.

 

[ollibraun]

Irgendwie dachte ich schon mal, das System käme eingach nur mit den Startlaufwerken durcheinander. Gerade fiel mir dies auf:




Weiß jemand, wie es zu der unterschiedlichen Nummerierung kommt?

 

[ollibraun]

Deswegen habe ich den auch auf HOSt umgestellt, da Hyper-V ja etwas „fehlt“.
Teste es doch bitte einmal mit einem 6.8er Kernel - vielleicht liegt es ja am 6.11er Kernel, das da der Hase im Pfeffer liegt und es knatscht im Getriebe.

Mit Kernel 6.8 ändert sich am Verhalten leider nichts. Spannend finde ich, dass ich bei "x86-64-v2-AES" die Hyper-V-Rolle nicht aktivieren kann. Ich hätte gedacht, dass durch die zusätzliche Virtualiserung der Host-Typ hier nicht durchgereicht wird... irgendwo muss man das noch beeinflussen können.

 

[Falk R.]

Mit Kernel 6.8 ändert sich am Verhalten leider nichts. Spannend finde ich, dass ich bei "x86-64-v2-AES" die Hyper-V-Rolle nicht aktivieren kann.

Das ist ja normal, das x86-64-v2-AES CPU Layout reicht nur grundlegende CPU Feature durch, unter anderem auch das Virtualisierungsflag wird maskiert. Mit CPU Typ host geht das, wenn du das Feature im Bios aktiviert hast.

Ich hätte gedacht, dass durch die zusätzliche Virtualiserung der Host-Typ hier nicht durchgereicht wird... irgendwo muss man das noch beeinflussen können.

 

[Falk R.]

Irgendwie dachte ich schon mal, das System käme eingach nur mit den Startlaufwerken durcheinander. Gerade fiel mir dies auf:

View attachment 77931
View attachment 77932

Weiß jemand, wie es zu der unterschiedlichen Nummerierung kommt?

Das ist auch ganz normal, Windows sortiert das bei jedem boot neu. In der Regel wer sich zuerst meldet kommt zuerst. Da gibt es keine festen Regeln.

 

[ollibraun]

Verstehe. Deshalb hatte @ThoSo hatte vor dem Hinzufügen der Rolle auf HOST umgestellt. Das Flag scheint mir aktiviert:

root@proxmox:~# lscpu

Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        52 bits physical, 57 bits virtual
Byte Order:                           Little Endian
CPU(s):                               48
On-line CPU(s) list:                  0-47
Vendor ID:                            GenuineIntel
BIOS Vendor ID:                       Intel(R) Corporation
Model name:                           Intel(R) Xeon(R) Gold 5412U
BIOS Model name:                      Intel(R) Xeon(R) Gold 5412U  CPU @ 2.1GHz
BIOS CPU family:                      179
CPU family:                           6
Model:                                143
Thread(s) per core:                   2
Core(s) per socket:                   24
Socket(s):                            1
Stepping:                             8
CPU(s) scaling MHz:                   59%
CPU max MHz:                          3900.0000
CPU min MHz:                          800.0000
BogoMIPS:                             4200.00
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cat_l2 cdp_l3 intel_ppin cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect user_shstk avx_vnni avx512_bf16 wbnoinvd dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req vnmi avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxldtrk pconfig arch_lbr ibt amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

Virtualization:                       VT-x

L1d cache:                            1.1 MiB (24 instances)
L1i cache:                            768 KiB (24 instances)
L2 cache:                             48 MiB (24 instances)
L3 cache:                             45 MiB (1 instance)
NUMA node(s):                         1
NUMA node0 CPU(s):                    0-47
Vulnerability Gather data sampling:   Not affected
Vulnerability Itlb multihit:          Not affected
Vulnerability L1tf:                   Not affected
Vulnerability Mds:                    Not affected
Vulnerability Meltdown:               Not affected
Vulnerability Mmio stale data:        Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   Not affected
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

 

[ThoSo]

Verstehe. Deshalb hatte @ThoSo hatte vor dem Hinzufügen der Rolle auf HOST umgestellt. Das Flag scheint mir aktiviert:

Richtig, ich hatte den auch erst einmal mit der Standardeinstellung erzeugt und gestartet.
Ich war gestern Abend auch noch ein bisschen zum Thema unterwegs und habe folgende Infos gefunden, die aber eventuell nicht wirklich dein Problem lösen werden - aber lese es mal quer - vielleicht hast ja doch eine Idee:

https://brentk.io/thoughts/qemu-and-kvm/making-sense-of-qemu-cpu-types.html

https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html

https://www.qemu.org/docs/master/system/i386/hyperv.html

Im Prinzip ist der "x86-64-v2-AES CPU" also eine "Westmere-v2 - Maschine"
Auf meiner Testkiste läuft noch physisch ein Xeon E3-1220v2 (IvyBridge-v2).
Was ich mir jetzt nicht vorstellen kann, ist das dein Gold-Xeon für Windows Hyper-V zu "gut" ist.

Du kannst ja statt HOST auch noch anderen Modelle (x86-64-v3, x86-64-v4) auswählen, auch passend zur Deiner CPU (SapphireRapids) und als Option das FLAG hv-evcms aktivieren und das mal testen. Wobei das bei mir nur mit "HOST" geklappt hat.
Drücke die Daumen!

 

[ollibraun]

SapphireRapids und SapphireRapids-v2 funktionieren leider nicht, PVE lässt den Start gar nicht erst zu:

swtpm_setup: Not overwriting existing state file.
kvm: warning: host doesn't support requested feature: CPUID.07H:EBX.hle [bit 4]
kvm: warning: host doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11]
kvm: warning: host doesn't support requested feature: MSR(10AH).taa-no [bit 8]
kvm: Host doesn't support requested features
stopping swtpm instance (pid 1079445) due to QEMU startup error
TASK ERROR: start failed: QEMU exited with code 1

In den verschiedenen x86-64-v# bootet die VM, aber Hyper-V lässt sich nicht aktivieren mangels Prozessorfunktionen. Ich arbeite mich am Wochenende mal hier durch: https://www.reddit.com/r/Proxmox/comments/gu73cj/nested_virtualization_not_working/

 

[Falk R.]

Warum machst du dir das Leben schwer?
Mit CPU Typ host geht es immer. Habe ich selbst ganz oft genutzt für verschiedene Hypervisoren. Wenn das mit dem Typ Host nicht funktioniert, fehlt entweder eine Einstellung im BIOS oder bei manchen Intel Desktop CPUs geht die Nested Virtualisierung nicht. Serverprozessoren können das immer.

P.S.
Ist neben VT-D auch iommu aktiviert im BIOS?

 

[ThoSo]

@Falk - er hat 48 x Intel(R) Xeon(R) Gold 5412U (1 Socket) - keine DesktopCPU.
Kann aber sein, das da irgendwas im BIOS in den Einstellungen fehlt. Vielleicht gibt es dafür auch ein Update ?
Da Windows bei Ihm mit der CPU HOST nicht willig ist, war es eine Idee mit den anderen CPU Typen - ich habe keine Doku gefunden was die einzelnen CPUs durchreichen und was nicht.

 

[Falk R.]

@Falk - er hat 48 x Intel(R) Xeon(R) Gold 5412U (1 Socket) - keine DesktopCPU.

Deshalb, Server CPUs können das immer.

Kann aber sein, das da irgendwas im BIOS in den Einstellungen fehlt. Vielleicht gibt es dafür auch ein Update ?
Da Windows bei Ihm mit der CPU HOST nicht willig ist, war es eine Idee mit den anderen CPU Typen - ich habe keine Doku gefunden was die einzelnen CPUs durchreichen und was nicht.

Mit der Einstellung host wird nichts maskiert sondern die CPU wird genau so genutzt wie Sie im Hypervisor ankommt. In der Regel liegt es immer an Bioseinstellungen.
Ich kann den Fehler nicht nachstellen, da mein Server mit Xeon der rumliegt sowie meine Testumgebung mit Ryzen funktioniert das Nesting immer. Ich habe damit schon ganz viele Sachen getestet.