Hyper-V Live Migration Fails Between Different Intel Xeon CPU Generations

Question

Hyper-V Live Migration Fails Between Different Intel Xeon CPU Generations

Md Rashid 0

Hello Microsoft Support,

We are currently adding an older Hyper-V host to our existing Windows Server 2022 Failover Cluster. Based on the guidance we received, we understand that the older host with an Intel Xeon Gold 6342 processor can be used with our existing hosts running Intel Xeon Gold 6442Y processors.

After adding the older host as Node 3, we are facing issues with Live Migration.

Environment

Windows Server 2022 Hyper-V Failover Cluster

Node 1 and Node 2: Intel Xeon Gold 6442Y

Node 3: Intel Xeon Gold 6342

Same Windows Server 2022 environment

Cluster and shared storage are healthy

All three nodes are cluster owners for the affected VM

Processor Compatibility for Migration is enabled on the affected VM

Issue

Live Migration between the newer CPU nodes and Node 3 is not working consistently.

The affected VM reports the following error when we attempt Live Migration to Node 3:

The virtual machine is using processor-specific features not supported on the physical computer. To allow migration to physical computers with different processors, modify the virtual machine settings to limit the processor features used by the virtual machine.

We have enabled:

CompatibilityForMigrationEnabled : True
CompatibilityForMigrationMode    : MinimumFeatureSet

We also restarted the VM after enabling CPU compatibility.

Migration behavior

We have observed the following:

Live Migration fails with the processor compatibility error.

If we shut down the VM and perform a Quick Migration, the VM can move to Node 3.

After the VM starts successfully on Node 3, Live Migration may work afterward.

However, this behavior is not consistent. In some cases, Live Migration continues to fail.

We also had a case where the VM could not start on Node 3 due to a Key Protector/vTPM error. After addressing that issue, the VM was able to start on Node 3, but Live Migration still reports the processor compatibility error.

Other VMs have shown similar behavior where Quick Migration allows the VM to move, and subsequent Live Migration works.

Additional testing

We confirmed that the processors are different:

Node	Processor
Node 1	Intel Xeon Gold 6442Y
--------	--------
Node 1	Intel Xeon Gold 6442Y
Node 2	Intel Xeon Gold 6442Y
Node 3	Intel Xeon Gold 6342

The affected VM is Generation 2 and has:

VM Version: 10.0
vCPU: 6
CompatibilityForMigrationEnabled: True
CompatibilityForMigrationMode: MinimumFeatureSet

The cluster reports all three nodes as possible owners for the VM.

Assistance requested

Since Microsoft guidance indicated that this mixed CPU configuration is supported, we would like Microsoft to help us determine why Live Migration is still failing even after enabling Processor Compatibility for Migration.

Specifically, we would like to confirm:

Whether Intel Xeon Gold 6342 and Intel Xeon Gold 6442Y are fully supported for Live Migration within the same Windows Server 2022 Hyper-V cluster.

Whether there are any CPU feature differences between these processors that Processor Compatibility Mode cannot mask.

Whether there are additional Hyper-V or cluster settings required for this specific mixed CPU configuration.

Why Quick Migration can succeed while Live Migration fails.

Why Live Migration sometimes starts working after a Quick Migration.

Whether the Key Protector/vTPM issue we encountered is related to the processor compatibility issue or is a separate issue.

What Microsoft recommends to make Live Migration work reliably between Node 3 and Nodes 1/2.

Our goal is to use the older host as Node 3 in the production cluster while maintaining reliable Live Migration between all three nodes.

We can provide the Hyper-V VMMS, Failover Clustering, and Host Guardian Service event logs if required.

Previous Question Reference:
https://learn.microsoft.com/en-us/answers/questions/5954524/adding-a-new-hyper-v-host-to-an-existing-windows-s

0 comments

2 answers

Your answer

Answer 1

The behavior points to CPU feature exposure differences between the hosts, not a cluster ownership problem.

Supported facts for this scenario:

The error itself matches a known Hyper-V live migration issue caused by processor-specific features not supported on the destination host.
The documented fix is to enable Migrate to a physical computer with a different processor version in the VM processor settings, which maps to CompatibilityForMigrationEnabled = True.
Hyper-V guidance also recommends starting VMs for the first time on the oldest / least capable CPU host.
If hosts differ in BIOS settings, firmware, patch level, or speculation-control-related CPU feature exposure, live migration can still fail.
Microsoft documents that Spectre/Meltdown mitigations and microcode differences can expose different CPU features and block migration.
Microsoft also documents a Windows Server 2019 issue where speculation control reporting differences can block migration, and states that this specific issue is resolved in Windows Server 2022.
A vTPM/key protector failure is documented as a separate migration issue category tied to certificate or Shielded VM configuration, not CPU compatibility.

For this environment, the recommended checks are:

In Hyper-V Manager on the affected VM, verify Virtual Machine Settings > Processor > Processor Compatibility is enabled.
Verify the host BIOS settings are the same across Node 1, Node 2, and Node 3.
Verify all nodes are at the same patch and firmware level.
Run Get-SpeculationControlSettings on all three nodes and compare the results. The results should be the same on all nodes.
If possible, boot the affected VM on Node 3 first, then test live migration from Node 3 to Nodes 1/2.
As a workaround for mixed microcode environments, migrate VMs from older to newer microcode rather than from newer to older.

Why Quick Migration can work while Live Migration fails:

Microsoft documents quick migration as a way to align VM state with the new host when CPU compatibility is involved.
The accepted Microsoft Q&A explanation is consistent with this: compatibility mode does not retroactively remove CPU features from a VM that is already running. After compatibility is enabled, the VM must be shut down and started so it boots with the masked feature set.
That also explains why migration may work after a quick migration and restart on Node 3: the VM starts there with the destination-compatible feature set.

Why it can still be inconsistent:

If BIOS, firmware, microcode, or speculation-control settings differ between nodes, the exposed CPU feature set can still differ enough to block live migration.
Microsoft specifically calls out post-update failures and advises ensuring all nodes are updated and that speculation settings match.

What can be concluded from the available guidance:

Mixed CPU generations can work only when the exposed processor feature set is compatible.
Processor compatibility mode does not guarantee masking of every difference if host configuration, microcode, or mitigation state is inconsistent.
The vTPM/key protector problem should be treated as a separate issue from the processor compatibility error.

If the issue continues after the checks above, collect data from both source and destination nodes:

Run the TSS trace on both nodes:
```
   TSS rOn VML:verbose
```
Reproduce the migration failure.

Run psSDP on both nodes:

   .\GetpsSDP.ps1 HyperV -localNodeOnly

Collect Hyper-V VMMS, Failover Clustering, and related logs from both nodes for escalation.

References:

Answer 2

Hello,

The Xeon Gold 6342 and Xeon Gold 6442Y are supported together in a Windows Server 2022 Failover Cluster, but Live Migration issues arise because the newer CPU exposes instruction sets that the older CPU cannot mask, even with Processor Compatibility Mode enabled. Quick Migration works because it saves and restores VM state, bypassing CPU feature checks, while Live Migration requires real-time CPU feature alignment.

The key point is that Processor Compatibility Mode only masks certain advanced instructions (e.g., AVX, AVX2, AVX-512), but not all differences between CPU generations. The 6442Y (Sapphire Rapids) supports newer extensions that the 6342 (Ice Lake) does not. When a VM is running on the newer node, it may actively use instructions unavailable on the older node, which causes Live Migration to fail. Quick Migration succeeds because the VM is shut down and restarted, allowing it to initialize against the older CPU’s baseline feature set.

To make Live Migration reliable, you need to ensure the following:

Cluster Functional Level must be set to 11 (Windows Server 2022 native). This ensures uniform handling of CPU compatibility across nodes.

BIOS and microcode updates must be identical across all nodes. Intel microcode patches affect exposed CPU features, and mismatched firmware can cause inconsistent migration behavior.

Processor Compatibility Mode must be enabled while the VM is powered off. Use PowerShell:

powershell

Set-VMProcessor -VMName <VMName> -CompatibilityForMigrationEnabled $true

Restart the VM afterward.

Understand limitations: Compatibility Mode masks most but not all instructions. If the VM workload uses features unique to Sapphire Rapids (e.g., AVX-512 variants), Live Migration will fail regardless. This explains why migration sometimes works after Quick Migration but not consistently.

vTPM/Key Protector errors are unrelated to CPU compatibility. They stem from Host Guardian Service or VM security settings. Once resolved, they should not affect CPU migration behavior.

In short, Microsoft supports mixed CPU generations in clusters, but Live Migration reliability depends on the common denominator of CPU features across nodes. If workloads use instructions unavailable on the 6342, Live Migration will fail even with compatibility enabled. The only way to guarantee consistent migration is to standardize CPU generations across all nodes or accept Quick Migration as the fallback method when moving VMs to Node 3.

I recommend validating with Test-Cluster after BIOS and microcode updates, and if Live Migration continues to fail, you may need to restrict workloads requiring newer CPU instructions to Nodes 1 and 2. Node 3 can still host VMs, but migration will be limited.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HP.