Unsolved
1 Rookie
•
3 Posts
0
4130
Live migraton failed between R440 R430
Hello,
I have a problem about hyper-v failover cluster live migration. Originally i have a Windows Server 2012R2 hyper-v failover cluster with 3 node members (2xR420 1XR430). The live migration works perfect between the nodes. Our company buy 2 R440 server and a new storage and we bulid a new Windows Server 2019 hyper-v failover cluster. After migrate VM's to the new cluster we destroyed the old cluster and reinstall the R430 to Windows Server 2019. Next step we add the R430 to the new cluster.
node1 (R440): Intel® Xeon® Silver 4116 Processor
node 2 (R440): Intel® Xeon® Silver 4116 Processor
node3 (R430): Intel® Xeon® Processor E5-2640 v2
If I try live migraton from node 1 or node 2 to node 3 live migration failed:
Event 21502
Live migration of 'VMNAME' failed.
Virtual machine migration operation for 'VMNAME' failed at migration destination 'NODE03'. (Virtual machine ID 63AFF93A-13F7-40B9-8C4A-32B9E6801448)
The virtual machine 'VMNAME' is using processor-specific features not supported on physical computer 'NODE03'. To allow for migration of this virtual machine to physical computers with different processors, modify the virtual machine settings to limit the processor features used by the virtual machine. (Virtual machine ID 63AFF93A-13F7-40B9-8C4A-32B9E6801448)
Processor compatibility is already turned on every VM!!
If I turned off VM I can migrate to node3. After offline migration I turend on VM on node3 (R430) I can move the VM between all nodes but if I restart VM node1 or node2 live migration to node3 fail again.
All nodes is updated with SUU and the OS is up to date.
RobKinetek
4 Posts
0
August 1st, 2020 15:00
Did you ever fix this?
tonislow
1 Rookie
1 Rookie
•
3 Posts
0
August 1st, 2020 23:00
Hello,
Problem is solved but I don't know how.
I just install windows updates every month and SUU if Dell released a new version.
Live migration working now between R440 R430.
RachelGomez
162 Posts
0
September 6th, 2022 22:00
To work around this problem, use the output of the gpresult command to identify the Group Policy Object (GPO) that modifies user rights settings. Then, use one of the following methods to correct the issue:
Method 1
Place the computer account for the Hyper-V Host in an Organizational Unit (OU) that doesn't have any policies applied, that manage user rights, and then run gpupdate /force command or reboot the computer. It should remove the user rights applied by policy and allow user rights defined in the local security policy to take effect.
Method 2
Take the following steps on the Hyper-V host machine:
Sign in to the machine as a Domain Administrator.
Install the Group Policy Management feature from the Server Manager console.
After installation, open the GPMC MMC snap-in and browse to the policy that manages User Rights.
Edit the policy to include NT Virtual Machine\Virtual Machines in the entries for Log on as a service.
Close the policy editor.
Run gpupdate /force on the Hyper-V host computer to refresh policy. You may need to wait several minutes for Active Directory replication to occur.
Method 3
Take the following steps on a client computer running Windows 8 that supports the Client Hyper-V feature:
Sign in to the machine as a Domain Administrator.
Install the Client Hyper-V feature.
Install the Windows 8 Remote Server Administration Tools (RSAT).
Open the Group Policy Management console and browse to the policy that manages User Rights.
Edit the policy to include NT Virtual Machine\Virtual Machines on the entries for the Log on as a service user right.
Close the policy editor on the client.
Run gpupdate /force on the Hyper-V host to refresh policy. You may need to wait several minutes for Active Directory replication to occur.
Greeting,
Rachel Gomez