Windows Server 2025 Hyper-V: wat het werkelijk toevoegt voor cluster operators

1. De vier Hyper-V veranderingen die er werkelijk toe doen

Windows Server 2025 brengt tientallen verbeteringen. De vier die wij in cluster assessments en pre-upgrade assessments als materieel zien:

• Dynamic CPU compatibility voor Live Migration. Live Migration tussen hosts met verschillende CPU-generaties zonder VM-shutdown of CPU compatibility-mode.
• GPU-P (GPU Partitioning) voor productie. Verdeling van een fysieke GPU over meerdere VM's, nu volwassen genoeg voor productie-workloads, niet meer alleen lab.
• vTPM 2.0 standaard. Trusted Platform Module voor VM's wordt standaard meegerold, met implicaties voor backup, replicatie en DR.
• Hot-patching voor Hyper-V hosts. Bepaalde patches zonder reboot, beperkte scope maar genoeg om patch-windows merkbaar in te korten.

Buiten deze vier zijn er verbeteringen aan SDN, AKS on Hyper-V integratie en storage replica, maar die zijn voor de meeste klanten secundair tot Azure Local in beeld komt. Daar leveren we een aparte readiness-assessment voor.

2. Dynamic CPU compatibility voor Live Migration

Dit is de feature waarvan operators in bestaande heterogene clusters het meeste merken.

Het oude probleem:

Een cluster met nodes van verschillende CPU-generaties (bijvoorbeeld Intel Xeon Skylake en Ice Lake, of Sapphire Rapids en Emerald Rapids gemixed) kon alleen Live Migration tussen die nodes doen met CPU compatibility-mode aangezet op de VM. Dat beperkte de CPU-features die de VM zag tot wat de oudste generatie ondersteunde, en handmatige aanpassing per VM was vereist. Live Migration tussen nodes met verschillende AMD- en Intel-generaties was sowieso niet mogelijk zonder VM-shutdown.

In de praktijk betekende dit dat na elke hardware-refresh ofwel het hele cluster in één keer vervangen moest worden, of dat een deel van de VM's vast zat aan oudere nodes. Beide opties zijn duur.

Wat 2025 verandert:

Dynamic CPU compatibility past de gepresenteerde CPU-feature set live aan tijdens de migratie, op basis van wat de doel-host ondersteunt. De VM ziet bij de bron-host de volledige feature set, bij de doel-host de set die beide ondersteunen, en de overgang gebeurt zonder VM-restart en zonder dat handmatige compatibility-mode-configuratie nodig is.

Praktische impact:

Hardware-refreshes kunnen rolling gebeuren over maanden, zonder VM-pinning. Een cluster kan een mengeling van CPU-generaties draaien zonder operationele beperkingen op Live Migration. Dat verlaagt de drempel om bestaande hardware door te laten draaien naast nieuwe aanwinsten, en maakt CapEx-planning flexibeler.

Verifieer op je cluster:

# Controleer of de feature actief is op de host
Get-VMHost | Select-Object Name, EnhancedSessionMode,
    SupportedVmVersions, HostNumaTopology

# CPU compatibility mode per VM (legacy setting, niet meer nodig)
Get-VM | Select-Object Name,
    @{N='CompatMode';E={$_.GetCPUFeatureCompatibilityMode()}}

Wat blijft beperking:

Cross-vendor migration (Intel naar AMD of omgekeerd) werkt nog steeds niet, ook niet met dynamic compatibility. Voor dat scenario blijft de oplossing een VM-shutdown of een quick migration met state-save.

3. GPU-P voor productieworkloads

GPU Partitioning was in 2022 al beschikbaar maar in lab-staat. In 2025 is het volwassen genoeg voor productie, en voor klanten met VDI-workloads of AI-gevoelige applicaties is dit interessant.

Wat GPU-P doet:

Een fysieke GPU (NVIDIA T4, A10, A40, H100, of equivalente AMD/Intel) wordt opgesplitst in meerdere virtuele GPU's. Elke vGPU wordt aan een VM toegewezen en presenteert zich aan de guest als een echte GPU met eigen vRAM en compute-budget. Anders dan DDA (Discrete Device Assignment) waar één VM de hele GPU krijgt, deelt GPU-P de GPU over meerdere VM's.

Voor welke workloads:

VDI met grafische versnelling, waar gebruikers een fractie van GPU-capaciteit nodig hebben (CAD-viewers, video-editing, sommige Office-versnelde rendering-features). AI-inferentie waarbij meerdere modellen tegelijk draaien zonder elk een hele GPU op te eisen. Remote desktop hosts voor ontwikkelaars die GPU-acceleratie nodig hebben voor specifieke tools.

Niet voor: zware AI-training, waar je de volle GPU wilt en DDA de juiste keuze blijft. En niet voor scenario's waar je echte hardware-isolatie tussen tenants nodig hebt om compliance-redenen.

Cluster-implicaties:

GPU-P werkt momenteel niet over Live Migration heen. Een VM met een vGPU is gepind aan de host die de fysieke GPU heeft. Plan dat in cluster-ontwerp: GPU-hosts zijn een dedicated subset, geen mix met algemene workloads, en je accepteert dat GPU-VM's down moeten voor host-onderhoud.

Configuratie hoog niveau:

# Inventariseer GPU's geschikt voor GPU-P
Get-VMHostPartitionableGpu

# Maak een GPU-P toewijzing aan een VM
Add-VMGpuPartitionAdapter -VMName 'VDI-Pool-01'
Set-VMGpuPartitionAdapter -VMName 'VDI-Pool-01' `
    -MinPartitionVRAM 2147483648 `
    -MaxPartitionVRAM 8589934592 `
    -OptimalPartitionVRAM 4294967296

Voor klanten die GPU-P serieus willen inzetten, raden wij een dedicated assessment aan. De GPU-modellen die ondersteund worden, de driver-versies aan host en guest, en de licentievoorwaarden (NVIDIA vGPU vereist aparte vGPU-licenties) maken het een onderwerp dat eigen aandacht verdient.

4. vTPM 2.0 standaard, en wat dat betekent voor backup en DR

Virtual TPM 2.0 was in eerdere versies opt-in. In 2025 is het standaard voor Generation 2 VM's die op Windows Server 2025 hosts worden aangemaakt. Dat klinkt onschuldig, maar het heeft implicaties.

Wat verandert:

Nieuwe Gen 2 VM's worden met vTPM aangemaakt, en die vTPM bevat keys die uniek zijn per VM-instantie. Voor de VM zelf maakt dit Secure Boot en BitLocker-achtige features beschikbaar, wat goed is.

Backup en DR implicaties:

Een vTPM-state moet bij een VM-restore mee. De meeste moderne backup-producten doen dit correct, maar oudere Veeam-versies (vóór 12.1) en sommige scripts die op Export-VM plus Import-VM leunen, kunnen de vTPM-state verliezen tijdens een restore. Resultaat: de VM start, maar BitLocker is uit, Secure Boot is verbroken, en alles wat van TPM-attested cryptografie afhankelijk is moet opnieuw geprovisioneerd worden.

Hyper-V Replica met vTPM:

Werkt, mits beide kanten op Windows Server 2025 staan en de host guardian service-configuratie (HGS) consistent is. Voor stretched clusters of cross-site replica is dit een extra prerequisite die je in pre-migration assessments en in DR-runbooks moet documenteren.

Wat we tijdens een cluster assessment controleren:

Welke VM's hebben vTPM en welke niet, of het backup-product de vTPM-state correct backupt en restored, en of de host guardian service-configuratie consistent is over alle nodes als shielded VMs in scope zijn.

# Inventariseer vTPM-status per VM
Get-VM | Select-Object Name, Generation,
    @{N='vTPM';E={(Get-VMSecurity -VMName $_.Name).TpmEnabled}},
    @{N='SecureBoot';E={(Get-VMFirmware -VMName $_.Name).SecureBoot}}

5. Hot-patching voor Hyper-V hosts

Hot-patching is sinds Windows Server 2022 beschikbaar voor specifieke scenarios, en in 2025 is de scope uitgebreid. Het is nog steeds niet voor alle patches, maar wel voor genoeg om patch-windows merkbaar in te korten.

Wat het doet:

Bepaalde patches worden toegepast zonder reboot. De Cluster Service blijft draaien, VM's blijven draaien, en de patch is direct actief. Voor cumulative updates die hot-patch geschikt zijn, betekent dit dat een Cluster Aware Updating-run die voorheen vier uur kostte (een drain per node, een reboot per node, een rebalance achteraf) terugkomt op een fractie daarvan.

Wat het niet doet:

Niet alle patches zijn hot-patchable. Kernel-updates, sommige driver-updates en firmware-niveau patches vereisen nog steeds een reboot. In de praktijk zien wij dat ongeveer 60 tot 70% van de maandelijkse CU-content hot-patchable is, met de rest via een Server reboot per kwartaal.

Cluster-impact:

Voor klanten die CAU draaien, blijft de runbook-structuur hetzelfde. Hot-patchable updates lopen sneller door, niet-hot-patchable updates triggeren nog steeds een traditionele drain-reboot-rejoin cyclus. Belangrijkste verschil: maandelijkse patch-vensters worden korter en minder disruptief, met grotere reboot-vensters per kwartaal voor de rest.

Pre-requisite:

Azure Arc-enablement op de Hyper-V hosts. Hot-patching is gekoppeld aan Azure Update Manager voor coördinatie. Voor klanten zonder Azure-connectivity is hot-patching geen optie.

6. De Windows Server 2012 R2 en 2016 guest-valkuil

Dit is het belangrijkste praktische probleem dat we tegenkomen bij klanten die overwegen naar Windows Server 2025 Hyper-V te gaan.

Het probleem:

Windows Server 2012 R2 en 2016 guest-VM's worden niet ondersteund op Windows Server 2025 Hyper-V. In sommige gevallen booten ze niet, in andere gevallen lopen ze tegen onverwacht gedrag aan in integration services, in nog andere gevallen lijken ze te werken maar zonder Microsoft-support.

De oorzaak ligt in ACPI table-veranderingen en aangepaste VMBus device IDs in Hyper-V 2025. Een 2012 R2 guest verwacht specifieke device-identifiers die er niet meer zijn, en valt terug op een inaccessible boot device-fout.

Wat het werkbaar maakt (tijdelijk):

Voor klanten die 2012 R2-VM's tijdelijk moeten blijven draaien op een 2025 cluster, bestaat er een handmatige registry-truc om de oude device-IDs te aliasen. Didier Van Hoye heeft hierover een uitstekend artikel geschreven dat de offline registry-edit procedure uitlegt. Het is een workaround, geen oplossing.

De juiste oplossing:

Plan de OS-upgrade van legacy guests vóór of gelijktijdig met de Hyper-V host-upgrade. Voor klanten die VMware naar Hyper-V migreren, betekent dit dat een aanzienlijk deel van de VM's eerst een Windows Server-versie upgrade nodig heeft, niet alleen een hypervisor-migratie. Wij modelleren dit standaard in pre-migration assessments en in upgrade-planning.

Wat wel werkt:

Windows Server 2019, 2022 en 2025 guest-VM's draaien zonder issues op Windows Server 2025 Hyper-V. Moderne Linux-distributies met kernel 4.x of nieuwer werken eveneens. De pijn zit specifiek bij 2012 R2 en (in mindere mate) 2016 guests.

7. Wat NIET drastisch is veranderd

Het is even belangrijk om te weten wat hetzelfde is gebleven, omdat veel marketing-materiaal claimt dat 2025 fundamenteel anders is. Voor de meeste cluster-operators is dat overdreven.

• Failover Clustering kern. Quorum-modellen, witness-types, CSV-mechanica, Cluster Aware Updating: vrijwel identiek aan 2022. Bestaande kennis en runbooks blijven van toepassing.
• SET en netwerken. Switch Embedded Teaming, virtuele switches, VLAN-tagging, RDMA over RoCEv2 en iWARP: ongewijzigd in mechaniek. Network ATC blijft de aanbevolen automatiseringslaag, met enkele toegevoegde validatie-features.
• Storage Spaces Direct. S2D is grotendeels onveranderd, met de strategische nadruk verschoven naar Azure Local voor nieuwe hyperconverged deployments. S2D op Windows Server 2025 blijft ondersteund maar krijgt minder feature-investering.
• PowerShell en management. De kern-cmdlets voor Hyper-V en clustering zijn backwards compatible. Bestaande scripts blijven werken. Windows Admin Center is de aanbevolen GUI, met inmiddels ook een "Virtualization Mode" (vMode) preview voor schaal-management van meerdere clusters.
• System Center VMM. SCVMM 2025 ondersteunt Windows Server 2025 hosts. Bestaande VMM-deployments kunnen geüpdatet worden, en de upgrade is minder disruptief dan eerdere major-versie sprongen.

8. Upgrade-strategie voor bestaande clusters

Voor klanten met een bestaand Hyper-V cluster op Windows Server 2019 of 2022, raden wij de volgende volgorde:

Stap 1, assessment. Inventariseer guest-OS versies, identificeer 2012 R2 en 2016 VM's die OS-upgrade nodig hebben, controleer backup-product-versies op vTPM-support, en check GPU-modellen tegen GPU-P compatibility-lijsten.

Stap 2, guest OS-upgrades. Pak de 2012 R2 en 2016 VM's aan. Upgrade naar 2019 of 2022 (niet direct naar 2025, want een OS-in-place-upgrade die meerdere versies overslaat, verloopt zelden soepel), of vervang met nieuwe builds. Dit is meestal het langste deel van het traject.

Stap 3, backup-stack update. Verifieer dat Veeam, Commvault of welk product ook in gebruik is, vTPM-aware is op de gebruikte versie. Upgrade waar nodig vóór de host-upgrade.

Stap 4, cluster rolling upgrade. Windows Server 2025 ondersteunt cluster rolling upgrade vanuit 2019 en 2022. Een node tegelijk wordt geüpgraded, het cluster blijft draaien, en de Cluster Functional Level wordt aan het eind expliciet verhoogd met Update-ClusterFunctionalLevel. Reken op één tot twee nodes per onderhoudsvenster, afhankelijk van VM-evacuatietijd.

Stap 5, post-upgrade validatie. Volledige Test-Cluster run, validatie van Live Migration-paden, controle of GPU-P (indien in gebruik) correct werkt, en hercontrole van time service-configuratie. Dat laatste, omdat wij regelmatig zien dat een major-version upgrade de w32time-configuratie op subtiele manieren beïnvloedt.

Stap 6, activeer nieuwe features. Pas wanneer het cluster stabiel is op de nieuwe versie, activeer je Dynamic CPU compatibility-features op heterogene clusters, plan je GPU-P deployment, en koppel je hosts aan Azure Arc voor hot-patching. Allemaal stap-voor-stap, niet allemaal tegelijk.

De ClusterTriage aanpak voor Windows Server 2025 upgrade

Wij behandelen een Windows Server 2025 upgrade voor een bestaand Hyper-V cluster in twee stappen. Eerst een cluster assessment dat alle afhankelijkheden in kaart brengt en een go/no-go-advies met een gefaseerd upgrade-plan oplevert. Daarna de uitvoering, ofwel door het klantteam met dat plan als runbook, ofwel samen met ons op basis van nacalculatie.

Voor klanten die overwegen of een Hyper-V upgrade nog wel logisch is versus een sprong naar Azure Local, leveren wij een vergelijkende assessment die beide opties tegen elkaar afzet op kosten, operationele impact, en strategische fit.

Plan een Windows Server 2025 Hyper-V assessment →