Server 2022 Hyper-V Cluster Setup Fails

Question

Hope someone can help with an issue I'm having. When creating a Server 2022 Failover Cluster, I continue to timeout issues when joining the cluster. I'll list what I have tried and the setup below.

Setup is 2 identical servers. I have run the validation, and it passes without any errors. I can successfully create the Cluster using Server 2016 and Server 2019 both Core and GUI based. I had been trying this on an in place production cluster using the standard cluster aware updating. I had moved the cluster from 2016 to 2019 without issue. When I started having major problems moving to 2022, I moved to nodes out and created a new cluster to try and fix the issue.

Initially I tried to create a 2 node Server 2022 cluster, which failed. The validation passed, and it failed creating the cluster with timeout issues. I then created a 2019 cluster using the same setup without any problems. I then following the steps for cluster aware server update, upgrading one of the nodes to 2022. It failed with the same errors.

The main issue it seems to me is the cluster service on server 2022 fails to come online when joining. I'm not sure why that would be...

As far as event logs, when joining I see lots of networking back and forth. I'll a messaging stating the nodes can communicate, followed by a warning they can't communicate, then back again. These nodes work fine in Server 2019, so I assure you they can communicate.

Long post, thanks!

Answer 1

Hey,

Have you tried going through the following guide? https://learn.microsoft.com/en-us/troubleshoot/windows-server/high-availability/troubleshoot-cluster-service-fails-to-start

It covers the troubleshooting steps.

It could be related with some driver issues of your NICs on 2022. You can try installing up-to-date drivers for you NICs.

In addition, you can try using alternative shared storage. StarWind VSAN as an example. https://www.starwindsoftware.com/starwind-virtual-san

Cheers,  
Alex Bykovskyi  
StarWind Software  
Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

Answer 2

For those that come upon this later or are interested. I finally figured out the issue.

Standard practice when setting up multiple segmented networks is to use a default gateway on only the one (the local server outside connection). The other vlans have no default gateway as they aren't going outside the network and are all internal. MS marks these networks as "public" instead of private. You need to move these networks to "private" and then the cluster can communicate normally. You could also create firewall rules on the public network for also, but I thought it made more sense to move these to private.

This is only as issue with Server 2022. I had no problems not making this change in Server 2019 and 2025. I would argue these should be defined as private networks though and have made the change across the board on our systems.