Windows Server 2025 Hyper-V: What It Really Adds for Cluster Operators

Windows Server 2025 has been generally available since November 2024, and in 2026 we see at CloudLabs that customers are seriously picking up upgrade planning. Not because Windows Server 2022 disappears tomorrow, but because 2025 brings a number of Hyper-V improvements that genuinely matter for cluster operators working with heterogeneous hardware, mixed-generation CPUs, and GPU workloads.

This article looks at the Hyper-V additions that actually matter for failover clusters, not the marketing list. What improves your operations? What is a good reason to bring the upgrade forward? And which pitfalls open up for existing clusters during the transition?

1. The four Hyper-V changes that actually matter

Windows Server 2025 brings dozens of improvements. The four we treat as material in cluster Health Checks and pre-upgrade assessments:

• Dynamic CPU compatibility for Live Migration. Live Migration between hosts with different CPU generations without VM shutdown or CPU compatibility mode.
• GPU-P (GPU Partitioning) for production. Splitting a physical GPU across multiple VMs, now mature enough for production workloads, no longer lab only.
• vTPM 2.0 by default. Trusted Platform Module for VMs ships by default, with implications for backup, replication, and DR.
• Hot-patching for Hyper-V hosts. Certain patches without reboot, limited scope but enough to noticeably shorten patch windows.

Beyond these four, there are improvements to SDN, AKS on Hyper-V integration, and storage replica, but those are secondary for most customers until Azure Local enters the conversation. We deliver a separate readiness assessment for that.

2. Dynamic CPU compatibility for Live Migration

This is the feature operators in existing heterogeneous clusters notice the most.

The old problem:

A cluster with nodes from different CPU generations (for example Intel Xeon Skylake and Ice Lake, or Sapphire Rapids and Emerald Rapids mixed) could only do Live Migration between those nodes with CPU compatibility mode enabled on the VM. That limited the CPU features the VM saw to what the oldest generation supported, and manual per-VM configuration was required. Live Migration between nodes with different AMD and Intel generations was outright impossible without VM shutdown.

In practice this meant after every hardware refresh, either the entire cluster had to be replaced at once, or part of the VMs stayed pinned to older nodes. Both options are expensive.

What 2025 changes:

Dynamic CPU compatibility adjusts the presented CPU feature set live during the migration, based on what the target host supports. At the source host the VM sees the full feature set, at the target host it sees the set both hosts support, and the transition happens without VM restart and without manual compatibility mode configuration.

Practical impact:

Hardware refreshes can happen rolling over months, without VM pinning. A cluster can run a mix of CPU generations without operational limits on Live Migration. That lowers the threshold to keep existing hardware running alongside new acquisitions, and makes CapEx planning more flexible.

Verify on your cluster:

# Check whether the feature is active on the host
Get-VMHost | Select-Object Name, EnhancedSessionMode,
    SupportedVmVersions, HostNumaTopology

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

What remains a limit:

Cross-vendor migration (Intel to AMD or vice versa) still does not work, not even with dynamic compatibility. For that scenario the solution remains VM shutdown or a quick migration with state save.

3. GPU-P for production workloads

GPU Partitioning was already available in 2022 but in lab state. In 2025 it is mature enough for production, and for customers with VDI workloads or AI-adjacent applications this is interesting.

What GPU-P does:

A physical GPU (NVIDIA T4, A10, A40, H100, or equivalent AMD/Intel) is split into multiple virtual GPUs. Each vGPU gets assigned to a VM and presents itself to the guest as a real GPU with its own vRAM and compute budget. Unlike DDA (Discrete Device Assignment) where one VM gets the whole GPU, GPU-P shares the GPU across multiple VMs.

For which workloads:

VDI with graphics acceleration, where users need a fraction of GPU capacity (CAD viewers, video editing, certain Office-accelerated rendering features). AI inference where multiple models run simultaneously without each needing a whole GPU. Remote desktop hosts for developers needing GPU acceleration for specific tools.

Not for: heavy AI training, where you want the full GPU and DDA remains the right choice. And not for scenarios where you need real hardware isolation between tenants for compliance reasons.

Cluster implications:

GPU-P currently does not work across Live Migration. A VM with a vGPU is pinned to the host with the physical GPU. Plan that into cluster design: GPU hosts are a dedicated subset, not mixed with general workloads, and you accept that GPU VMs need to come down for host maintenance.

High-level configuration:

# Inventory GPUs suitable for GPU-P
Get-VMHostPartitionableGpu

# Create a GPU-P assignment to a VM
Add-VMGpuPartitionAdapter -VMName 'VDI-Pool-01'
Set-VMGpuPartitionAdapter -VMName 'VDI-Pool-01' `
    -MinPartitionVRAM 2147483648 `
    -MaxPartitionVRAM 8589934592 `
    -OptimalPartitionVRAM 4294967296

For customers seriously planning GPU-P use, we recommend a dedicated assessment. Which GPU models are supported, the driver versions on host and guest, and license terms (NVIDIA vGPU requires separate vGPU licenses) make it a topic worth its own attention.

4. vTPM 2.0 by default, and what that means for backup and DR

Virtual TPM 2.0 was opt-in in earlier versions. In 2025 it is default for Generation 2 VMs created on Windows Server 2025 hosts. That sounds harmless, but it has implications.

What changes:

New Gen 2 VMs are created with vTPM, and that vTPM contains keys unique per VM instance. For the VM itself this makes Secure Boot and BitLocker-style features available, which is good.

Backup and DR implications:

vTPM state must travel with the VM on restore. Most modern backup products handle this correctly, but older Veeam versions (pre-12.1) and some scripts leaning on Export-VM plus Import-VM can lose the vTPM state during restore. Result: the VM starts, but BitLocker is off, Secure Boot is broken, and anything depending on TPM-attested cryptography must be re-provisioned.

Hyper-V Replica with vTPM:

Works, provided both sides are on Windows Server 2025 and the host guardian service (HGS) configuration is consistent. For stretched clusters or cross-site replica this is an additional prerequisite to document in pre-migration assessments and DR runbooks.

What we check during a Health Check:

Which VMs have vTPM and which do not, whether the backup product correctly backs up and restores vTPM state, and whether host guardian service configuration is consistent across all nodes when shielded VMs are in scope.

# Inventory vTPM state 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 for Hyper-V hosts

Hot-patching has been available since Windows Server 2022 for specific scenarios, and in 2025 the scope is extended. It is still not for every patch, but enough to noticeably shorten patch windows.

What it does:

Certain patches are applied without reboot. The Cluster Service stays up, VMs keep running, and the patch is immediately active. For cumulative updates that are hot-patch eligible, this means a Cluster Aware Updating run that previously took four hours (a drain per node, a reboot per node, a rebalance afterwards) comes back to a fraction of that.

What it does not do:

Not every patch is hot-patchable. Kernel updates, some driver updates, and firmware-level patches still require a reboot. In practice we see roughly 60 to 70% of monthly CU content is hot-patchable, with the rest landing in quarterly reboot windows.

Cluster impact:

For customers running CAU, the runbook structure stays the same. Hot-patchable updates run through faster, non-hot-patchable updates still trigger a traditional drain-reboot-rejoin cycle. Main difference: monthly patch windows get shorter and less disruptive, with larger quarterly reboot windows for the rest.

Prerequisite:

Azure Arc enablement on the Hyper-V hosts. Hot-patching is tied to Azure Update Manager for coordination. For customers without Azure connectivity, hot-patching is not an option.

6. The Windows Server 2012 R2 and 2016 guest pitfall

This is the biggest practical problem we encounter with customers considering Windows Server 2025 Hyper-V.

The problem:

Windows Server 2012 R2 and 2016 guest VMs are not supported on Windows Server 2025 Hyper-V. In some cases they do not boot, in others they hit unexpected behaviour in integration services, in still others they appear to work but without Microsoft support.

The cause lies in ACPI table changes and modified VMBus device IDs in Hyper-V 2025. A 2012 R2 guest expects specific device identifiers that no longer exist, and falls back to an inaccessible boot device error.

What makes it workable (temporarily):

For customers who must keep 2012 R2 VMs running temporarily on a 2025 cluster, there is a manual registry trick to alias the old device IDs. Didier Van Hoye has written an excellent article explaining the offline registry edit procedure. It is a workaround, not a solution.

The right fix:

Plan the OS upgrade of legacy guests before or alongside the Hyper-V host upgrade. For customers migrating from VMware to Hyper-V, this means a significant share of VMs first needs a Windows Server version upgrade, not just a hypervisor migration. We model this as standard in pre-migration assessments and in upgrade planning.

What does work:

Windows Server 2019, 2022, and 2025 guest VMs run on Windows Server 2025 Hyper-V without issues. Modern Linux distributions with kernel 4.x or newer work as well. The pain sits specifically with 2012 R2 and (to a lesser degree) 2016 guests.

7. What has NOT drastically changed

Equally important to know what stayed the same, because much marketing material claims 2025 is fundamentally different. For most cluster operators that is overstated.

• Failover Clustering core. Quorum models, witness types, CSV mechanics, Cluster Aware Updating: nearly identical to 2022. Existing knowledge and runbooks remain valid.
• SET and networking. Switch Embedded Teaming, virtual switches, VLAN tagging, RDMA over RoCEv2 and iWARP: unchanged in mechanics. Network ATC remains the recommended automation layer, with several added validation features.
• Storage Spaces Direct. S2D is largely unchanged, with strategic emphasis shifted toward Azure Local for new hyperconverged deployments. S2D on Windows Server 2025 stays supported but receives less feature investment.
• PowerShell and management. The core cmdlets for Hyper-V and clustering are backwards compatible. Existing scripts keep working. Windows Admin Center remains the recommended GUI, now with a "Virtualization Mode" (vMode) preview for scale management of multiple clusters.
• System Center VMM. SCVMM 2025 supports Windows Server 2025 hosts. Existing VMM deployments can be updated, and the upgrade is less disruptive than earlier major-version jumps.

8. Upgrade strategy for existing clusters

For customers with an existing Hyper-V cluster on Windows Server 2019 or 2022, we recommend the following order:

Step 1, assessment. Inventory guest OS versions, identify 2012 R2 and 2016 VMs that need OS upgrade, verify backup product versions for vTPM support, and check GPU models against GPU-P compatibility lists.

Step 2, guest OS upgrades. Address the 2012 R2 and 2016 VMs. Upgrade to 2019 or 2022 (not directly to 2025, because OS in-place upgrade skipping multiple versions rarely goes smoothly), or replace with new builds. This is usually the longest part of the trajectory.

Step 3, backup stack update. Verify that Veeam, Commvault, or whichever product is in use is vTPM aware on the version used. Upgrade where needed before the host upgrade.

Step 4, cluster rolling upgrade. Windows Server 2025 supports cluster rolling upgrade from both 2019 and 2022. One node at a time is upgraded, the cluster keeps running, and the Cluster Functional Level is explicitly raised at the end with Update-ClusterFunctionalLevel. Plan one or two nodes per maintenance window, depending on VM evacuation time.

Step 5, post-upgrade validation. Full Test-Cluster run, validation of Live Migration paths, check that GPU-P (if in use) works correctly, and re-verification of time service configuration. That last one because we regularly see a major-version upgrade subtly affecting w32time configuration.

Step 6, activate new features. Only when the cluster is stable on the new version, activate Dynamic CPU compatibility features on heterogeneous clusters, plan GPU-P deployment, and connect hosts to Azure Arc for hot-patching. All step by step, not all at once.

The CloudLabs approach to Windows Server 2025 upgrade

We treat a Windows Server 2025 upgrade for an existing Hyper-V cluster as a two-phase engagement. An assessment phase of three to five working days that maps all dependencies, delivers a go/no-go recommendation, and produces a phased upgrade plan. Then an execution phase that is either done by the customer team using our runbook, or by us in close coordination with the customer team.

For customers considering whether a Hyper-V upgrade still makes sense versus a jump to Azure Local, we deliver a comparative assessment weighing both options against cost, operational impact, and strategic fit.

Schedule a Windows Server 2025 Hyper-V assessment →

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

Windows Server 2025 is sinds november 2024 algemeen beschikbaar, en in 2026 zien wij bij CloudLabs steeds vaker dat klanten upgrade-planning serieus oppakken. Niet omdat Windows Server 2022 morgen ophoudt, maar omdat 2025 een aantal Hyper-V verbeteringen brengt die het verschil maken voor cluster-operators die met heterogene hardware, mixed-generation CPU's, en GPU-workloads werken.

Dit artikel kijkt naar de Hyper-V toevoegingen die er werkelijk toe doen voor failover clusters, niet de marketing-lijst. Wat verbetert je operatie? Wat is een goede reden om de upgrade voor te trekken? En welke valkuilen ontstaan er voor bestaande clusters bij de overstap?

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

Windows Server 2025 brengt tientallen verbeteringen. De vier die wij in cluster Health Checks 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 Health Check 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 in kwartaalse reboot-windows.

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 kwartaalse reboot-vensters 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 CloudLabs aanpak voor Windows Server 2025 upgrade

Wij behandelen een Windows Server 2025 upgrade voor een bestaand Hyper-V cluster als een opdracht in twee fasen. Een assessment-fase van drie tot vijf werkdagen die alle afhankelijkheden in kaart brengt, een go/no-go-advies geeft en een gefaseerd upgrade-plan oplevert. Daarna een uitvoering-fase die ofwel door het klantteam wordt gedaan met ons runbook, ofwel door ons gedaan in nauwe samenwerking met het klantteam.

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 →