none
Hyper-V cluster: Unable to fail VM over to secondary host RRS feed

  • Question

  • I am working on a Server 2012 Hyper-V Cluster. I am unable to fail my VMs from one node to the other using either LIVE or Quick migration.

    A force shutdown of VMHost01 will force a migration to VMHost02. And once we are on VMHost02 we can migrate back to VMHost01, but once that is done we can't move the VMs back to VMHost02 without a force shutdown.

    The following error pops up:

    Event ID: 21502 The Virtual Machine Management Service failed to establish a connection for a Virtual machine migration with host.... The connection attempt failed because the connected party did not properly respond after a period of time, or the established connection failed because connected host has failed to respond (0X8007274C)

    Here's what I noticed:

    VMMS.exe is running on VMHost02 however it is not listening on Port 6600. Confirmed this after a reboot by running netstat -a. We have tried setting this service to a delayed start.

    I have checked Firewall rules and Anti-Virus exclusions, and they are correct. I have not run the cluster validation test yet, because I'll need to schedule a period of downtime to do so.

    We can start/stop the VMMS.exe service just fine and without errors, but I am puzzled as to why it will not listen on Port 6600 anywhere. Anyone have any suggestions on how to troubleshoot this particular issue? 

    Thanks,

    Tho H. Le


    • Edited by Tho Le Friday, April 26, 2013 8:03 PM
    Friday, April 26, 2013 7:50 PM

Answers

  • Issue resolved: Some sort of GPO corruption occurred. We noticed that we could not launch gpedit.msc from VMHost02. Copied Group Policy Folder from VMHost01, and gpupdate /force.  Now VMMS.exe shows up and is listening on Port 6600, VM migrations work as well.
    • Marked as answer by Tho Le Friday, April 26, 2013 11:27 PM
    Friday, April 26, 2013 11:27 PM

All replies

  • Ran the Cluster validation test, and there were no issues. In the process of updating NIC drivers as well, but I not sure if it will have an impact.
    Friday, April 26, 2013 9:57 PM
  • Thos is pointing in the right direction.  The reported problem is very often related to some sort of network configuration issue.  Cluster validation wizard will point out the obvious ones.  You can run the validation wizard and select your own tests, ignoring the storage, so you don't get all the errors on that.

    Another thing I like to do is ensure that my Live Migration and CSV NICs are not registered in DNS.  Once in a while I have had issues when there are multiple DNS entries for a server.  You can remove the automatic registration from the Advanced button on the NIC's properties.  Also ensure that the cluster-access network is first in your binding order.


    .:|:.:|:. tim

    Friday, April 26, 2013 10:29 PM
  • Issue resolved: Some sort of GPO corruption occurred. We noticed that we could not launch gpedit.msc from VMHost02. Copied Group Policy Folder from VMHost01, and gpupdate /force.  Now VMMS.exe shows up and is listening on Port 6600, VM migrations work as well.
    • Marked as answer by Tho Le Friday, April 26, 2013 11:27 PM
    Friday, April 26, 2013 11:27 PM
  • Hi Tho H. Le,


    Glad to hear that the issue has been resolved. If you have further questions, please do not hesitate to post in our forum. It is always our pleasure to be of assistance.


    Cheers!


    Jeremy Wu
    TechNet Community Support

    Monday, April 29, 2013 8:50 AM
    Moderator
  • Just ran into the same issue in a 16-node cluster being managed by VMM. When trying to live migrate VMs using the VMM console the migration would fail with the following: Error 10698. Failover Cluster manager would report the following error code: Error (0x8007274C).

     

    + Validated Live Migration and Cluster networks. Everything checked out.

    + Looking in Hyper-V manager and migrations are enabled and correct networks displayed.

    + Found this particular Blog that mentions that the Virtual Machine Management service is not listening to port 6600

    http://blogs.technet.com/b/roplatforms/archive/2012/10/16/shared-nothing-migration-fails-0x8007274c.aspx

    • Ran the following from an elivated command line:

    Netstat -ano | findstr 6600

    • Node 2 did not return anything
    • Node 1 returned correct output:

    TCP

    10.xxx.251.xxx:6600

    0.0.0.0:0

    LISTENING

    4540

    TCP

    10.xxx.252.xxx:6600

    0.0.0.0:0

    LISTENING

    4560

    1. Set Hyper-V Virtual Machine Service to delayed start.
    2. Restarted the service; no change.
    1. Checked the Event Logs for Hyper-V VMMS and noted the following events - VMMS Listener started for Live Migration networks, and then shortly after listener stopped.
    1. Removed the system from the cluster and restarted - No change
    1. Checked this host by running gpedit.msc - could not open console: Permission Error
    1. Tried to run a GPO refresh (gpupdate /force), but error returned that LocalGPO could not apply registry settings. Group Policy processing would not continue until this was resolved.
    1. Checked the local group policy folder on node 2 and it was corrupt:

    C:\Windows\System32\GroupPolicy\Machine\reg.pol showed 0K for the size.

    1. Copied local policy folders from Node 1 to 2, and then was able to refresh the GPOs.
    1. Restarting the VMMS service did not change the status of the ports.
    1. Restarted Server, added Live Migration networks back into Hyper-V manager and now netstat output reports that VMMS service is listening on 6600.
    Thursday, March 27, 2014 6:07 PM
  • Thank you very much! I had the same issue, but was looking at the error messages on the sending node rather than receiving. The error messages on the sending side looked like this: Event ID 21024 "Virtual machine migration operation for 'xyz' failed at migration source 'HVhostX'.

    After copying the C:\Windows\System32\GroupPolicy\Machine\Registry.pol file from a working machine, I ran GPUpdate /force, then restarted the Hyper-V Management Service. Live migration was once again working! 

    Thank you!

    Sunday, October 20, 2019 7:36 AM