Most Hyper-V VM problems trace back to a setting chosen at creation time. Generation is permanent — there’s no conversion path. Config version is a one-way door. Secure Boot state determines whether a Linux VM boots at all. The New VM wizard moves fast and defaults to reasonable values, but “reasonable” and “correct for this workload” aren’t always the same thing.
This is the Hyper-V VM configuration reference for operators deploying on Windows Server 2022 and 2025 — what each Hyper-V VM configuration setting controls, what breaks when it’s wrong, and what can’t be changed later. Hyper-V VM configuration decisions made at creation time have consequences that range from recoverable to permanent.
- Generation is permanent — no conversion path exists; choose before creating the VM
- Linux on Gen 2: set Secure Boot template to
MicrosoftUEFICertificateAuthorityor get a black screen at boot - Dynamic Memory harms SQL Server — balloon driver conflicts with SQL’s memory manager; use static memory
- vCPU overprovisioning is more common than underprovisioning — start at 2–4 and monitor
- Disable Time Synchronization integration service on Domain Controllers — it disrupts Kerberos
- Config version upgrade is irreversible — the VM can no longer run on older hosts afterward
- Production checkpoints are the default for a reason — Standard checkpoints leave databases inconsistent. For checkpoint recovery when something goes wrong, see the Hyper-V Checkpoint & AVHDX Troubleshooting guide.
What Cannot Be Changed After VM Creation
Before the settings themselves — the Hyper-V VM configuration decisions that are permanent or nearly so:
| Setting | Changeable after creation? |
|---|---|
| Generation | No — permanent |
| Config version upgrade | One-way only — cannot downgrade |
| Secure Boot state | Yes — while VM is off |
| Memory type (Static / Dynamic) | Yes — requires VM off |
| vCPU count | Yes — can change while running on Server 2025 |
| Checkpoint type | Yes — anytime |
| Integration services (per-service) | Yes — anytime |
Generation and config version are where operators get burned. Everything else is recoverable.
Generation 1 vs Generation 2 — The Decision You Can’t Undo
Hyper-V VM configuration starts with generation selection. Generation 1 uses BIOS emulation with legacy IDE controllers and a PXE-capable emulated NIC. Generation 2 uses UEFI firmware, SCSI synthetic controllers, and Secure Boot. The difference is not cosmetic — it affects which guest OS versions work, how the VM boots, and what storage and network performance looks like — covered in detail in the Hyper-V Storage guide.
What actually differs between generations
| Feature | Generation 1 | Generation 2 |
|---|---|---|
| Firmware | BIOS (legacy) | UEFI |
| Boot disk controller | IDE (emulated) | SCSI (synthetic) |
| Network adapter | Legacy + Synthetic | Synthetic only |
| Secure Boot | No | Yes (optional) |
| Hot-add network adapter | No | Yes |
| Max boot disk size | 2 TB (MBR) | 64 TB (GPT) |
| Windows support | All versions | Server 2012+, Win 8+ |
| Linux support | All distributions | Most modern distros |
The boot disk controller difference matters for performance. Generation 1 VMs boot from an emulated IDE controller — synthetic SCSI isn’t available for the boot disk. Generation 2 uses synthetic SCSI throughout, which removes emulation overhead on every disk I/O. In environments with heavy VM storage I/O, that overhead is measurable.
When to use Generation 1
Generation 1 is the right choice when the guest OS doesn’t support UEFI, when you’re running a 32-bit OS, or when migrating an existing VM from a platform that used BIOS firmware without wanting to convert the disk partition layout. Practically: Windows Server 2008 R2 and earlier, older Linux distributions without UEFI support, and any 32-bit guest.
If you’re deploying new workloads on modern OS versions, there’s no reason to use Generation 1.
When to use Generation 2
Any Windows Server 2012 or newer, Windows 8 or newer, and most Linux distributions released after 2014 work correctly as Generation 2 VMs. The SCSI boot controller, hot-add networking, and larger boot disk support are worth having. Secure Boot adds a meaningful layer of boot integrity enforcement.
The exception that trips people up: Linux on Generation 2 with Secure Boot enabled using the wrong template. If a Generation 2 Linux VM won’t start and shows a black screen before shutting down, that’s the first place to look — covered in the next section. Generation mismatch is also one of the most common root causes documented in Hyper-V VM won’t start scenarios.
Generation decision by guest OS
| Guest OS | Recommended generation |
|---|---|
| Windows Server 2025 / 2022 / 2019 / 2016 | Gen 2 |
| Windows Server 2012 R2 / 2012 | Gen 2 |
| Windows Server 2008 R2 and earlier | Gen 1 |
| Windows 11 / 10 / 8.1 | Gen 2 |
| Windows 7 and earlier | Gen 1 |
| Ubuntu 18.04+ / Debian 10+ / RHEL 8+ | Gen 2 |
| Older Linux (pre-2014 distros) | Gen 1 |
| 32-bit OS (any) | Gen 1 |
| Unknown / legacy appliance | Gen 1 |
Secure Boot and Virtual TPM
Secure Boot and virtual TPM are Generation 2 features. Both are available on Generation 2 VMs running Windows Server 2016 and newer.
Secure Boot — templates and Linux failures
Secure Boot validates the bootloader against a certificate database. Hyper-V ships with two templates: Microsoft Windows and Microsoft UEFI Certificate Authority. The Windows template contains only Microsoft’s signing keys. The UEFI CA template adds third-party signing certificates — necessary for Linux distributions that don’t use Microsoft-signed bootloaders.
The most common Generation 2 Linux boot failure looks like this:
VM starts → black screen → VM shuts down after ~30 secondsCause: Secure Boot enabled with the Windows template, Linux bootloader not signed by Microsoft. This is the Secure Boot template mismatch — and it’s silent. No helpful error message, just a VM that won’t stay running. If a Generation 2 Linux VM won’t start after creation, this is the first thing to check before investigating deeper. The Hyper-V VM won’t start troubleshooting guide covers this and other Generation 2 boot failures in the diagnostic workflow.
Fix:
# Change to the correct Secure Boot template for Linux
Set-VMFirmware -VMName "YourLinuxVM" -SecureBootTemplate "MicrosoftUEFICertificateAuthority"
# Or disable Secure Boot entirely (acceptable for internal lab VMs)
Set-VMFirmware -VMName "YourLinuxVM" -EnableSecureBoot OffUbuntu, RHEL/CentOS 8+, Debian 10+, and SLES all work with the UEFI CA template. Some older or niche distributions still require Secure Boot disabled entirely — check the distribution’s Hyper-V documentation if the UEFI CA template doesn’t resolve the boot failure.
For Windows VMs, leave Secure Boot enabled with the Microsoft Windows template. Disabling it for Windows guests removes a meaningful integrity control with no operational benefit.
Virtual TPM
Generation 2 VMs support virtual TPM (vTPM), which provides a software-emulated TPM 2.0 chip to the guest. vTPM enables BitLocker with a TPM protector inside the guest, is required for Windows 11 guest VMs, and supports measured boot for shielded VM scenarios. Details on vTPM requirements and configuration are documented in Microsoft’s Generation 2 security settings reference.
Check and configure vTPM state:
Get-VMSecurity -VMName "YourVMName"Migration note: a VM with vTPM and BitLocker active inside the guest requires the host’s Key Protector to be available on the destination host before live migration succeeds. For clustered environments, this is handled automatically through the cluster’s Host Guardian configuration. For standalone-to-standalone migration, export the Key Protector before moving the VM. For full live migration diagnostic workflow, see the Hyper-V Cluster & Live Migration Troubleshooting guide.
Hyper-V VM Configuration — vCPU Settings
How Hyper-V schedules vCPUs
Each vCPU assigned to a VM is scheduled as a virtual processor on the host’s physical cores. The Hyper-V Core Scheduler (default since Windows Server 2019) assigns vCPU pairs to physical core pairs, keeping sibling vCPUs on the same physical core’s hyperthreads. This matters for side-channel isolation and for latency between vCPUs that need to communicate — co-scheduled vCPU pairs have lower inter-processor latency than pairs running on separate physical cores.
How many vCPUs to assign
The instinct to assign as many vCPUs as possible is wrong. A VM with more vCPUs than it regularly uses creates scheduling overhead — the scheduler coordinates more virtual processors even when most are idle. More vCPUs also increases the chance of NUMA boundary crossing.
| Workload | Starting point | Notes |
|---|---|---|
| Domain Controller | 2 vCPU | Rarely needs more unless handling 5000+ objects/sec |
| File server | 2–4 vCPU | I/O-bound, not compute-bound |
| SQL Server | Match physical NUMA node | Never cross NUMA boundary — see below |
| Web server (IIS) | 4 vCPU | Scale out rather than up |
| Linux app server | 2–4 vCPU | Depends heavily on workload profile |
| Build server / CI | 4–8 vCPU | CPU-bound, benefits from more cores |
Start conservative. Adding vCPUs later takes seconds. Overprovisioned VMs cause host-level scheduler pressure that degrades every VM on the host — not just the overprovisioned one.
NUMA topology — the overcommit trap
NUMA (Non-Uniform Memory Access) matters when a VM’s vCPU count spans multiple physical NUMA nodes. A host with two 16-core CPUs has two NUMA nodes, each with its own local memory bank. A VM that crosses NUMA boundaries has vCPUs on both nodes — memory accesses from one node’s vCPUs to the other node’s memory incur measurably higher latency.
# Check host NUMA topology
Get-VMHostNumaNode
# Verify VM NUMA assignment
Get-VMProcessor -VMName "YourVMName" | Select-Object Count, MaximumCountPerNumaNode, MaximumCountPerNumaSocketFor SQL Server and latency-sensitive workloads: assign vCPUs that fit within a single NUMA node. On a host with 16-core NUMA nodes, a VM with 20 vCPUs will span both nodes regardless of intent. 16 vCPUs maximum keeps the VM within one node.
Network-heavy workloads have an additional consideration: Virtual Machine Queue (VMQ) assigns receive queues to specific vCPUs. A VM with too few vCPUs relative to its network throughput may exhaust VMQ capacity. The Hyper-V networking guide covers VMQ configuration and virtual switch performance settings in detail.
Hyper-V VM Configuration — Memory Settings
Static memory
Static memory allocates a fixed amount of RAM at VM startup and holds it for the VM’s lifetime regardless of actual usage. The VM always has exactly what it was configured with, and the host always has exactly that amount reserved.
Use static memory for: SQL Server, any in-memory database or caching workload (Redis, Elasticsearch, Memcached), Domain Controllers, and any production workload where predictable memory availability matters. The overhead of the balloon driver — the mechanism Dynamic Memory uses — doesn’t exist with static allocation.
Dynamic Memory — how it works and where it fails
Dynamic Memory uses a balloon driver inside the guest (delivered via integration services) to reclaim or allocate RAM dynamically based on host pressure and guest demand signals. The guest OS reports how much memory it actually needs, and Hyper-V adjusts allocation between the configured minimum and maximum.
Dynamic Memory works well for dev/test VMs, stateless web servers, and lightly loaded application VMs where memory usage is variable and low. It fails badly for specific workloads:
- SQL Server — SQL allocates a large buffer pool at startup based on available RAM. The balloon driver reclaims memory from that pool, forcing SQL to repeatedly re-evaluate its buffer pool size. In practice: intermittent query slowdowns and increased disk I/O as SQL flushes buffer pool pages to free memory. Forum reports consistently document this pattern on SQL Server VMs with Dynamic Memory enabled.
- In-memory caches — Redis, Memcached, and similar workloads pre-allocate memory for performance. The balloon driver fights them for the same memory.
- VMs in Saved state — a VM saved with Dynamic Memory may fail to resume if host memory conditions changed while it was saved.
- Real-time or low-latency workloads — balloon driver activity introduces latency spikes at unpredictable intervals.
Startup RAM, Minimum RAM, Maximum RAM
| Parameter | What it controls |
|---|---|
| Startup RAM | How much RAM Hyper-V allocates at VM boot — must be available on the host at start time |
| Minimum RAM | Lower floor — Hyper-V will not reclaim below this value |
| Maximum RAM | Upper ceiling — Hyper-V will not allocate above this regardless of guest demand |
The common misconfiguration: Startup RAM set high “for safety” while Minimum RAM stays at the Hyper-V default of 512 MB. The VM boots needing 8 GB but the host can reclaim down to 512 MB under pressure. The guest then runs with 512 MB RAM. Set Minimum RAM to a realistic floor for the workload under low load.
Memory weight
Memory weight (1–10000) controls priority when the host is under memory pressure. Higher weight means higher priority. For Domain Controllers and infrastructure VMs, raise memory weight above the default of 5000. For dev/test VMs, lower it.
# Check current memory config
Get-VMMemory -VMName "YourVMName"
# Set static memory
Set-VMMemory -VMName "YourVMName" -DynamicMemoryEnabled $false -StartupBytes 8GB
# Configure Dynamic Memory with realistic floor
Set-VMMemory -VMName "YourVMName" -DynamicMemoryEnabled $true `
-MinimumBytes 2GB -StartupBytes 4GB -MaximumBytes 16GB -Priority 6000Checkpoints — Standard vs Production
Checkpoints save VM state for rollback. The checkpoint type determines what state is saved and whether it’s application-consistent.
Standard checkpoints
Standard checkpoints save the complete VM state including memory contents. The checkpoint captures everything — disk, memory, running processes, in-flight transactions. Rolling back to a Standard checkpoint restores the VM to exactly the running state, including RAM contents.
The problem: in-flight database transactions are captured mid-flight. Rolling back to a Standard checkpoint on a VM running SQL Server, Exchange, or Active Directory leaves the database in an inconsistent state. Standard checkpoints are also the source of AVHDX chains that accumulate on disk until merged — a common contributor to storage exhaustion. The Hyper-V backup guide covers checkpoint lifecycle management and the interaction between VSS backups and checkpoint chains in detail.
Use Standard checkpoints for: dev/test VMs without active database workloads, and situations where you specifically need to restore to a running state including memory contents.
Production checkpoints
Production checkpoints use VSS (Volume Shadow Copy Service) inside the guest to create an application-consistent snapshot. The guest OS quiesces I/O, flushes transactions, and signals Hyper-V that the checkpoint is ready. No memory state is saved — the VM resumes from a cold-boot-like state.
Production checkpoints require the Hyper-V VSS integration service running in the guest. If VSS fails, Hyper-V falls back to a Standard checkpoint by default — configurable to fail instead:
# Check current checkpoint type
Get-VM -VMName "YourVMName" | Select-Object Name, CheckpointType
# Set Production only — fail rather than fall back to Standard if VSS fails
Set-VM -VMName "YourVMName" -CheckpointType ProductionOnlyProductionOnly prevents silent fallback to an inconsistent Standard checkpoint when VSS fails. For any VM running database workloads, this is the safer setting — you get a visible error instead of a checkpoint that looks successful but can’t be safely restored.
A production VM running SQL Server had checkpoint type set to Production (not ProductionOnly). The VSS writer for SQL Server was in a degraded state after an incomplete cumulative update. Nightly checkpoints were silently falling back to Standard for three weeks before anyone noticed. When a restore was attempted, the checkpoint was inconsistent — the SQL databases required manual recovery. The fix was straightforward once identified, but the silent fallback had been creating an illusion of consistent backups for weeks.
Integration Services — What Each Service Does
Integration services are drivers and components installed in the guest OS that enable Hyper-V-specific functionality. On modern Windows guests (Server 2016+), they’re delivered through Windows Update rather than requiring a separate installation.
The six integration services
| Service | What it does | Required? |
|---|---|---|
| Hyper-V Guest Service Interface | File copy between host and guest without network | Optional |
| Hyper-V Heartbeat Service | Host monitors guest alive status — triggers recovery actions if heartbeat stops | Yes for production |
| Hyper-V Data Exchange | Reads guest OS info from host (OS version, IP, hostname via KVP) | Recommended |
| Hyper-V Time Synchronization | Synchronizes guest clock with host — conflicts with domain time sync | Conditional |
| Hyper-V VSS | Enables Production checkpoints and host-initiated VSS backups | Yes for backups |
| Hyper-V Remote Desktop Virtualization | Enhanced session mode — clipboard, USB, audio redirection | Desktop VMs only |
Time synchronization — the Domain Controller conflict
Time Synchronization must be disabled on Domain Controllers. A DC is the authoritative time source for the domain — Hyper-V overriding its clock from the host disrupts Kerberos authentication. Kerberos requires clocks within 5 minutes of each other domain-wide; a DC with a drifting clock that gets periodically corrected by the hypervisor creates intermittent authentication failures that are painful to diagnose.
Disable-VMIntegrationService -VMName "YourDCName" -Name "Time Synchronization"The DC should sync time via NTP hierarchy — PDC emulator to an external NTP source, all other DCs and domain members to the PDC emulator. For all non-DC VMs, Time Synchronization is fine to leave enabled.
Linux integration services
Linux integration services are built into the kernel for distributions running kernel 4.x and newer. RHEL 7+, Ubuntu 16.04+, SLES 12 SP2+, and Debian 9+ include Hyper-V drivers natively — no separate installation needed. For older distributions, Microsoft provided a Linux Integration Services ISO that is now largely legacy.
Check integration service status from the host:
Get-VMIntegrationService -VMName "YourVMName" | Select-Object Name, Enabled, PrimaryOperationalStatusPrimaryOperationalStatus of OK means the service is running and communicating. NoContact or LostCommunication means the guest-side component isn’t responding — usually the service is disabled in the guest, or integration services aren’t installed. Missing integration services is a documented root cause for several VM management failures, including backup failures and heartbeat-triggered VM restarts. The Hyper-V VM won’t start troubleshooting guide covers integration service failures as a diagnostic path.
VM Configuration Version
Configuration version is a number tied to the Hyper-V host version — 9.0 for Server 2019, 10.0 for Server 2022, 11.0 for Server 2025. It determines which features the VM can use and, critically, which hosts it can run on.
What it controls
A VM on config version 9.0 can live migrate to Server 2019 or newer. A VM on version 10.0 can only move to Server 2022 or newer. Upgrading config version unlocks new features but permanently restricts which hosts the VM can run on. For Failover Cluster environments running a rolling OS upgrade — where some nodes are Server 2019 and others are Server 2022 — upgrading config version before all nodes are on the newer OS version breaks live migration back to the older nodes. The Hyper-V Failover Clustering guide covers cluster functional levels and the correct upgrade sequence in detail.
When to upgrade — and when not to
Upgrade config version when you’ve permanently moved the VM to a higher-version host with no need to fail back, when the VM needs a feature only available in a newer version, or when decommissioning older hosts from a cluster. Do not upgrade during a rolling cluster upgrade, when fail-back to an older host is possible, or when the current version already supports everything the VM needs.
# Check current version
Get-VM -VMName "YourVMName" | Select-Object Name, Version
# Check what version this host supports
Get-VMHostSupportedVersion
# Upgrade (irreversible — run Get-VMHostSupportedVersion first)
Update-VMVersion -VMName "YourVMName"The upgrade is silent and fast. There’s no confirmation prompt and no warning that it’s irreversible. Run Get-VMHostSupportedVersion first to understand the target version, and confirm the VM won’t need to run on older hosts before running Update-VMVersion.
- Verify all cluster nodes are on the target OS version before upgrading any VM config versions:
Get-ClusterNode | Select-Object Name, NodeHighestVersion - If a VM was already upgraded: check current version with
Get-VM -Name "VMName" | Select-Object Version - If the VM version exceeds what older nodes support, the VM cannot migrate to those nodes — live migration attempts will fail with a config version mismatch error
- Resolution: complete the cluster OS upgrade on all remaining nodes before attempting migration
Default Hyper-V VM Configuration by Workload
| Workload | Generation | Memory | Dynamic Memory | Checkpoints | Notes |
|---|---|---|---|---|---|
| Domain Controller | Gen 2 | Static | No | Production | Disable Time Synchronization integration service |
| SQL Server | Gen 2 | Static | No | ProductionOnly | Size vCPU within single NUMA node |
| File Server | Gen 2 | Static | Optional | Production | Static preferred for Hyper-V hosts under memory pressure |
| Web Server (IIS) | Gen 2 | Dynamic | Yes | Production | Scale out rather than up |
| Linux Server | Gen 2 | Static | Usually No | Production | Set UEFI CA Secure Boot template |
| Dev/Test VM | Gen 2 | Dynamic | Yes | Standard | Standard checkpoint acceptable for non-DB dev VMs |
| Windows 11 guest | Gen 2 | Static | No | Production | vTPM required for TPM 2.0 requirement |
| Legacy OS (pre-2012) | Gen 1 | Static | Conditional | Standard | Verify guest OS support matrix before deploying |
Configuration Verification Reference
Run this after creating any VM and before moving it to production:
$vm = "YourVMName"
# Generation and config version
Get-VM $vm | Select-Object Name, Generation, Version
# Processor
Get-VMProcessor $vm | Select-Object Count, MaximumCountPerNumaNode
# Memory
Get-VMMemory $vm | Select-Object DynamicMemoryEnabled, Startup, Minimum, Maximum, Priority
# Firmware (Secure Boot template)
Get-VMFirmware $vm | Select-Object SecureBoot, SecureBootTemplate
# Security (vTPM)
Get-VMSecurity $vm
# Integration services — verify all expected services are OK
Get-VMIntegrationService $vm | Select-Object Name, Enabled, PrimaryOperationalStatus
# Checkpoint type
Get-VM $vm | Select-Object CheckpointType
# Disk controllers and paths
Get-VMHardDiskDrive $vm | Select-Object ControllerType, ControllerNumber, ControllerLocation, PathThe output covers every Hyper-V VM configuration setting that matters for operational stability. For Hyper-V installation prerequisites and host-level configuration before creating VMs, see the Hyper-V installation guide and post-install checklist.
For the full list of supported guest operating systems and their Hyper-V VM configuration requirements, see Microsoft’s supported Windows guest OS list and supported Linux and FreeBSD VMs for Hyper-V.
Frequently Asked Questions
What is the correct Hyper-V VM configuration for a new VM?
Start with Generation 2 for any modern OS, static memory for production workloads, Production checkpoints, and integration services verified as OK. The exact Hyper-V VM configuration depends on workload — see the recommendations table above for DC, SQL Server, Linux, and web server defaults.
Should I use Generation 1 or Generation 2 for a new Hyper-V VM?
Generation 2 for any modern OS — Windows Server 2012 or newer, Windows 8 or newer, and most Linux distributions from 2014 onward. Generation 1 only for legacy operating systems, 32-bit guests, or when migrating an existing BIOS-based VM. There’s no conversion path between generations, so the choice at creation time is permanent.
Can I change a Hyper-V VM from Generation 1 to Generation 2?
No. Generation is permanent and cannot be changed after creation. The only path is to create a new Generation 2 VM and migrate the workload — which also requires converting the disk from MBR to GPT for Windows guests. Plan the generation correctly before deploying.
Is Hyper-V Dynamic Memory safe to use in production?
Depends on the workload. Safe for stateless web servers, lightly loaded application VMs, and dev/test environments. Actively harmful for SQL Server, in-memory databases, and any workload that pre-allocates memory for performance. The balloon driver conflicts with SQL Server’s memory manager and causes intermittent performance degradation. When in doubt, use static memory — it’s predictable and has no overhead.
How many vCPUs should I assign to a Hyper-V VM?
Start at 2–4 for most workloads and monitor under real load. Overprovisioning vCPUs is more common than underprovisioning, and it creates host-level scheduling overhead that affects all VMs. For SQL Server, stay within one physical NUMA node. Adding vCPUs later is a live operation on Server 2025 — starting conservative costs nothing.
What are Hyper-V Integration Services and do I need them?
Integration services are guest drivers enabling Hyper-V-specific functionality — heartbeat monitoring, VSS-consistent backups, clock sync, and data exchange. On modern Windows guests they’re delivered via Windows Update. Heartbeat and VSS integration services are required for production VMs. Time Synchronization must be disabled on Domain Controllers to avoid Kerberos authentication failures.
Why won’t my Linux VM boot on Hyper-V Generation 2?
Most likely cause: Secure Boot is enabled with the Microsoft Windows template, which doesn’t include Linux signing certificates. Fix with Set-VMFirmware -VMName "VMName" -SecureBootTemplate "MicrosoftUEFICertificateAuthority". If the UEFI CA template doesn’t resolve it, disable Secure Boot entirely for the VM. The symptom is a black screen followed by VM shutdown — no helpful error message.
Does Hyper-V support virtual TPM?
Yes — Generation 2 VMs on Windows Server 2016 and newer support virtual TPM (vTPM). vTPM enables BitLocker with a TPM protector inside the guest and is required for Windows 11 guest VMs. For live migration of vTPM-enabled VMs with BitLocker active, the destination host must have the correct Key Protector configured.
What is Hyper-V VM configuration version and when should I update it?
Configuration version determines which host OS versions the VM can run on. Upgrading is irreversible — a VM on version 10.0 (Server 2022) can no longer run on Server 2019 hosts. Don’t upgrade during a rolling cluster upgrade until all nodes are on the target OS version. Use Get-VMHostSupportedVersion to check the target version before running Update-VMVersion.
Hyper-V Series
12 articles — Windows Server 2025 · Networking · Storage · Backup · Clustering