none
Hyper-V Clustering issue

    Question

  • Hello all,

     Getting the below error message when trying to establish a Hyper-V cluster between 2 servers.  I am using Windows Server 2016 Datacenter with Server Core.  The Hyper-V role is installed.  I use another physical server to graphically manage these 2 servers. I have 1 physical NIC being utilized by the operating system and a 2nd physical NIC configured as a vSwitch for virtual machines.  I have more Hyper-V servers that I would like to establish a cluster with but I am limiting complexity right now, so I am only doing these 2 servers because they are on the same physical switch.  On my switch there are ACL's that are configured.  I created an ACL for UDP port 3343 and saved the configuration.  On my 2 servers I disabled the Windows Firewall for domain, public, and private profiles. My network is using a /24 subnet mask on these 2 servers for all NIC's.  There is a VLAN configured at the physical switch for all ports involved and within Hyper-V the same VLAN is configured for the vSwitches.    Both servers appear to be listening on UDP 3343.  I do not have Internet access from the network my Hyper-V servers reside on, so I cannot readily upload logs or error messages.  They have to typed in by hand.  I cannot easily apply patches at the moment.  

    Network interfaces server1.domain.tld – vEthernet (vSwitch) and server2.domain.tld – vEthernet (vSwitch) are on the same cluster network, yet 10.x.x.x is not reachable from 10.x.x.x using UDP on port 3343. 

    Network interfaces server1.domain.tld – vEthernet (vSwitch) and server2.domain.tld – Host are on the same cluster network, yet 10.x.x.x is not reachable from 10.x.x.x using UDP on port 3343. 

    Network interfaces server2.domain.tld – vEthernet (vSwitch) and server1.domain.tld – Host are on the same cluster network, yet 10.x.x.x is not reachable from 10.x.x.x using UDP on port 3343. 

    Network interfaces server2.domain.tld – vEthernet (vSwitch) and server1.domain.tld – vEthernet (vSwitch) are on the same cluster network, yet 10.x.x.x is not reachable from 10.x.x.x using UDP on port 3343.

    I would appreciate any insights from anyone about this problem of mine. 


    • Edited by DBS_1 Tuesday, March 6, 2018 2:30 PM typo
    Tuesday, March 6, 2018 2:15 PM

Answers

  • In my case the problem is related to the virtual switch.  I have since come across other sources of information for the clustering process that state the Hyper-V cluster needs to be create be for the virtual switch is created.  Going on that information, if you disable to virtual switch during the cluster creation process, the cluster will create successfully.  Enabling after allows the virtual machines to continue functioning properly.  

    Essentially, I did not following the correct order of steps to minimize the headaches I experienced to accomplish everything I wanted. 


    • Marked as answer by DBS_1 Wednesday, July 11, 2018 8:25 PM
    Wednesday, July 11, 2018 8:25 PM

All replies

  • "... limiting complexity ... " by setting up ACLs on the switch? Why?

    Simplify. Eliminate all settings on the switch and start from there.

    If there are only two ports on the host then team them then bind the virtual switch to the team. That eliminates a single point of failure (SPoF) which is the goal of a cluster.


    Philip Elder Microsoft High Availability MVP Blog: http://blog.mpecsinc.ca Twitter: @MPECSInc

    • Proposed as answer by Matej Klemencic Wednesday, March 7, 2018 6:21 AM
    • Unproposed as answer by DBS_1 Thursday, March 8, 2018 12:25 AM
    Wednesday, March 7, 2018 6:09 AM
  • I agree with Philip.  You state you are trying to eliminate complexity and then you talk about VLANs, ACLs, playing with the Windows firewall.  That all seems counterintuitive to 'limiting complexity'.

    I also agree that you should team the two NICs at the host level and create all the virtual NICs you would need from that.  While it is technically possible to run a cluster with a single NIC for cluster communication, management, CSV, and Live Migration, it is not recommended. https://www.altaro.com/hyper-v/19-best-practices-hyper-v-cluster/ provides some excellent information about configuring a Hyper-V cluster.


    tim

    Wednesday, March 7, 2018 1:32 PM
  • In my case the problem is related to the virtual switch.  I have since come across other sources of information for the clustering process that state the Hyper-V cluster needs to be create be for the virtual switch is created.  Going on that information, if you disable to virtual switch during the cluster creation process, the cluster will create successfully.  Enabling after allows the virtual machines to continue functioning properly.  

    Essentially, I did not following the correct order of steps to minimize the headaches I experienced to accomplish everything I wanted. 


    • Marked as answer by DBS_1 Wednesday, July 11, 2018 8:25 PM
    Wednesday, July 11, 2018 8:25 PM