Why does Live Migration fail for specific VMs despite Processor Compatibility being enabled?

Question

Why does Live Migration fail for specific VMs despite Processor Compatibility being enabled?

Pradeep Singh Arora 20

Hi everyone, I’m encountering a bit of a strange issue with our Hyper-V cluster and I'm quite confused. Some VMs migrate perfectly between hosts during Live Migration, but others fail immediately with the error: "The virtual machine is using processor-specific features not supported on physical computer…"

I have already tried enabling "Processor Compatibility" in the VM settings, but it still doesn't work. What's puzzling is that other VMs with similar configurations are migrating without any issues. Does anyone know why this CPU feature error persists even after enabling compatibility mode? I feel like I might be missing something small. Thanks!

0 comments

Answer accepted by question author

1 additional answer

Your answer

Answer 1

Harry Phan 17,045 Independent Advisor

Hi Pradeep,

Per my experience, that error sticks around because compatibility mode doesn’t retroactively strip CPU features from a VM that’s already running. If the VM was started before you enabled compatibility, it will still expose the advanced instructions it picked up from the source host, and migration fails when the target CPU doesn’t support them. The reason some VMs move fine is they were either created or rebooted after compatibility was turned on, so they never saw those unsupported features. The best way to fix it, well make sure all hosts are on the same CPU family and BIOS/firmware level, then shut down and restart the affected VMs after enabling compatibility. Once they come back up, the migration should work the same way as the others.

I hope it provides you some useful information. Please give it a thump up or accept the answer if you find this helpful. Have a nice day ahead :)

Harry.

Pradeep Singh Arora 20 Reputation points

2026-03-17T14:16:33.1233333+00:00

Thanks, that makes sense. If the affected VMs were already running before compatibility mode was enabled, is there a way to confirm which CPU features they’re still exposing, and do I need a full shutdown/power-on cycle or would a simple reboot be enough for the compatibility mask to apply correctly?
Harry Phan 17,045 Reputation points Independent Advisor

2026-03-17T14:21:10.9166667+00:00

Hi P, a standard guest OS reboot usually isn’t enough, because the virtual CPU presented to the VM is typically defined when the VM powers on, not when the OS restarts inside the guest. To make sure the compatibility mask is applied, you should do a full power off of the VM and then power it back on. You can confirm this by checking the VM’s processor compatibility settings and then testing migration again after the cold start, since Hyper-V doesn’t always expose a simple live view of exactly which CPU instructions the guest is still seeing. If the VM still fails after a full power cycle, then the issue is more likely a true host-level mismatch such as CPU generation, microcode, BIOS/firmware, or inconsistent virtualization settings across nodes.

Answer 2

The error persists because processor compatibility mode only hides newer CPU instruction sets; it does not fix all types of CPU/firmware/patch mismatches or configuration/version issues between hosts. Several other CPU-related and VM-related factors can still block Live Migration even when compatibility is enabled.

Key reasons this can happen and what to check:

CPU/firmware/patch differences between hosts

Live migration can fail if the VM is running on a host that exposes CPU features (for example, side‑channel mitigation features like Spectre/Meltdown) that are not present on the destination host.
When a VM boots, the guest OS makes decisions based on the CPU features it sees. If those features are missing on the target host, migration is blocked to avoid exposing the VM to side‑channel attacks.
This is especially common when:
- Some hosts have newer microcode (uCode) or different speculation control settings.
- Some hosts have different Spectre/Meltdown patches or BIOS settings.

What to do:

Prefer migrating VMs from older to newer microcode/patch levels, not the other way around.
Run Get-SpeculationControlSettings on all nodes and ensure the results (especially speculation/SSBD-related flags) match.
Ensure all hosts have consistent BIOS/firmware and CPU security settings (Spectre/Meltdown options, virtualization features).

Processor compatibility mode limitations

Processor compatibility mode:
- Must be enabled per VM; it is not global.
- Hides newer instruction sets so the VM sees only a common subset of features.
- Does not allow migration between different CPU manufacturers (Intel ↔ AMD) even when enabled.
Some CPU feature mismatches (especially around security mitigations and microcode) can still block migration even if compatibility is turned on.

What to do:

Confirm that compatibility is enabled on the specific failing VMs:
- Hyper‑V Manager → VM → Settings → Processor → Processor Compatibility → “Migrate to a physical computer with a different processor version”.
Verify that all hosts use the same CPU vendor and compatible CPU families.

VM configuration version mismatch

If a VM’s configuration version is upgraded on a newer host, it may migrate one way (old → new) but not back (new → old).
This can surface as compatibility/CPU‑related errors even though the root cause is the configuration version.

What to do:

On each host, run:
- Get-VM * | Select Name, Version
If a VM has been upgraded to a configuration version that older hosts do not support, it cannot be migrated back. This is by design.

Per‑VM differences and “first boot” host

VMs that were first started on newer, more capable CPUs can “bake in” expectations about available features.
VMs first started on the oldest (least capable) host tend to migrate more reliably across the cluster.

What to do going forward:

Always start new VMs for the first time on the oldest/least capable CPU host.
Standardize CPU, BIOS, firmware, and patch levels across all cluster nodes.

Hardware incompatibility beyond CPU instruction sets

Some failures are reported generically as “processor‑specific features not supported” but are actually broader hardware/cluster compatibility issues.

What to do:

Ensure all hosts:
- Run supported Windows Server versions and are fully patched.
- Have consistent Hyper‑V settings and cluster configuration.

Summary of practical steps:

Confirm processor compatibility is enabled on the specific failing VMs (not just others).
Verify all hosts use the same CPU vendor and compatible CPU families.
Align BIOS/firmware and Spectre/Meltdown/SSBD settings; run Get-SpeculationControlSettings on all nodes and make them match.
Ensure all hosts are patched to the same Windows/firmware level.
Check VM configuration versions; avoid upgrading if the VM must move back to older hosts.
For new VMs, always perform the first boot on the oldest host.

These differences explain why some VMs migrate successfully while others with “similar” settings still fail, even with processor compatibility enabled.

References:

Share via

Why does Live Migration fail for specific VMs despite Processor Compatibility being enabled?

1 additional answer

Your answer