Failover cluster VM not live migrate

Tomas Prodest 0 Reputation points
2025-11-13T20:29:27.82+00:00

Hello,

maybe someone had this problem. Failover cluster stopped live migrate VM's.

I have 3 hosts: 1,2 - HP gen10; 3 - HP gen11. All with the latest firmware.

Between 1-2 everything ok. But from 1-2 can't live migrate to 3 and from 3 to 1-2. If VM turned off, then ok and VM migrating.

Tried with CPU compatibility on/off, validate cluster, remove and add to cluster host - nothing helped.

In log only this info:

Live migration of 'Virtual Machine TESTwin' failed.

Virtual machine migration operation for 'TESTwin' failed at migration destination 'H3'. (Virtual machine ID 2802A32B-6538-4EAB-9CC9-1B51A7AE0664)

Windows for business | Windows Server | Storage high availability | Clustering and high availability
0 comments No comments
{count} votes

3 answers

Sort by: Most helpful
  1. Nam Bui (WICLOUD CORPORATION) 625 Reputation points Microsoft External Staff Moderator
    2025-11-14T09:10:57.0433333+00:00

    Hi Tomas ,

    Welcome to Microsoft Q&A forum. It's my pleasure to help you today.
    Based on my experience, here are the steps that usually resolve this issue:

    1. Enable Processor Compatibility for the VM before restarting:
         Set-VMProcessor "VMName" -CompatibilityForMigrationEnabled $true
      
    2. Shut down the VM and perform an offline migration (Offline migration = move the VM while it is powered off.) Do the following:
      • Shut down the VM
      • Move the VM to the Gen11 host while it is off (Failover Cluster Manager → Move → Best Possible Node or PowerShell Move-ClusterVirtualMachineRole)
      • Power on the VM on the Gen11 host
      When the VM boots on the Gen11 host for the first time, it loads the Gen11 CPU feature set. This resets the VM’s CPU state, allowing future Live Migrations to work in both directions.
    3. Update and synchronize everything across all nodes
      Live Migration is far more sensitive than Quick Migration. Even small mismatches can block memory-state transfer. Please verify:
      • Same Windows Server build/patch level on all hosts
        • Same Hyper-V and Failover Cluster feature versions
          • Same firmware baseline (BIOS/UEFI, NIC firmware, storage firmware)
            • Same NIC driver versions and vSwitch configuration
      A cluster can pass validation even when Live Migration still fails due to subtle CPU/firmware differences.

    Live Migration transfers the CPU execution state. If the VM is running on Gen10 hardware and tries to migrate to Gen11:

    • The CPU feature sets do not align
    • Live Migration fails instantly
    • But Offline Migration works because the VM’s CPU state is recreated from scratch on the new host

    By enabling Processor Compatibility + booting the VM once on the Gen11 host, you synchronize the VM’s CPU state across all hosts.
    Let me know how it goes, and if this answer helps, feel free to hit “Accept Answer” so others can benefit too.

    Titus Bui

    1 person found this answer helpful.

  2. Nam Bui (WICLOUD CORPORATION) 625 Reputation points Microsoft External Staff Moderator
    2025-11-21T06:52:38.6333333+00:00

    Hi Tomas,

    Sorry for the delay, based on the log you provided, here is the analysis:

    Analysis

    From the PowerShell outputs:

    Get-VMSwitch comparison:

    H1/H2 have matching vSwitch names (Finpass_vlan, Mygom_vlan, Fintegry_vlan_switch, Prodest_prod_vlan, External)

    H3 uses different names (Fin_vlan, M_vlan, Fnt_vlan_switch, Prd_prod_vlan)

    → When a VM is attached to Finpass_vlan on H1/H2, H3 does not have a vSwitch with the same name → Live Migration fails.

    Recommendations:
    1. Unify vSwitch names across all nodes

    Rename vSwitches on H3 to match H1/H2:

    Rename-VMSwitch -Name 'Fin_vlan' -NewName 'Finpass_vlan'Rename-VMSwitch -Name 'M_vlan' -NewName 'Mygom_vlan'Rename-VMSwitch -Name 'Fnt_vlan_switch' -NewName 'Fintegry_vlan_switch'
    

    If renaming is not possible, create new vSwitches with correct names and reassign VM NICs.

    2. Verify VLAN and uplink team configuration for consistency across all nodes.

    3. Cluster environment considerations:

    If NIC Teaming or SET Teaming is used, teaming configuration must be identical on every node.

    If needed, you can also standardize SR-IOV/RDMA policies cluster-wide to avoid feature conflicts.

    "We strongly recommend using the same NICs, drivers, and firmware between cluster nodes when the NICs are used for the same types of traffic (compute, storage, and management). For SET to work correctly across all cluster nodes, it's required that the NIC adapters, drivers, and firmware be identical on each node.”

    https://learn.microsoft.com/en-us/windows-server/failover-clustering/clustering-requirements#:~:text=We%20strongly%20recommend,on%20each%20node.

    **
    Summary: The primary blocker is mismatched vSwitch names on H3. Fixing those should resolve the Live Migration issue. After that, review NIC Teaming and optionally align SR-IOV/RDMA policies for long-term stability.

    If you believe this information adds some value, please accept the answer so that your experience with the issue would help contribute to the whole community.

    Best wishes!
    Titus Bui.

    1 person found this answer helpful.

  3. Q&A Assist
    2025-11-13T20:29:52.9+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    It seems like you are experiencing issues with live migration of virtual machines between your hosts in a failover cluster. Here are some potential reasons and troubleshooting steps you can take:

    1. CPU Compatibility: Since you mentioned trying both with CPU compatibility on and off, ensure that the processor features are compatible across the hosts. You can check this in the Hyper-V Manager under the virtual machine settings for processor compatibility.
    2. Network Configuration: Ensure that the cluster network is properly configured and that all nodes can communicate with each other. You can verify this by running the Get-ClusterNetwork PowerShell cmdlet to check the status of the cluster network.
    3. Firewall and Antivirus Settings: Check the firewall settings and ensure that the necessary ports for live migration (typically TCP ports 6600 and 3343) are open and not blocked by any antivirus software.
    4. Cluster Validation: You mentioned validating the cluster, but it’s worth running the cluster validation wizard again to ensure there are no underlying issues that might affect live migration.
    5. Event Logs: Review the event logs for any additional error messages that might provide more insight into why the migration is failing. Look specifically for events related to live migration.
    6. Firmware and Driver Updates: Ensure that all hosts have the latest firmware and drivers, especially for network adapters, as these can affect live migration capabilities.
    7. Cluster Configuration: Check that the cluster configuration allows for live migration. In Hyper-V Manager, go to Settings > Live Migrations and ensure that the appropriate options are selected.

    If the issue persists after checking these areas, consider performing a quick migration as a temporary workaround until the live migration issue is resolved.


    References:


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.