‘Unsupported Cluster Configuration’ - Virtual Networks

There are a number of reasons a Virtual Machine (VM) can fall into a status of ‘Unsupported Cluster Configuration.’ A brief list, pulled from TechNet, shows that storage, networking, and other factors can cause this status. (Source: https://technet.microsoft.com/en-us/library/cc967323.aspx)

• The virtual machine is on a LUN that contains more than one virtual machine.
• The virtual machine is using non-clustered storage.
• One or more virtual network adapters on the virtual machine are not connected to a highly available virtual network.
• An ISO image is attached to highly available virtual machines.
• A VMware HAVM is connected to a port group that does not exist on all nodes of the host cluster.

This article deals with the third bullet, which effectively means, ‘settings are not identical on all virtual network (VN) adapters.’ Here are the TechNet instructions. Next we’ll discuss checking these automatically.

For a virtual network to be considered common by VMM and available to highly available virtual machines on a host cluster, each virtual network in the host cluster must meet the following requirements:

• The virtual network name must be identical on each host in the cluster. Virtual network names are case-sensitive, so the cases of all characters must match.
• The host network adapters to which the virtual network is attached on each host in the cluster must have the same location.
• The virtual network must have the same tag on each host in the cluster.

After you update the virtual network configurations on all nodes, refresh the cluster to ensure that each virtual network is detected as common. Then check the Networks tab in the host cluster properties to verify that the networks have been added to it.

So, check the Network Name, Location and Tag for inconsistencies. Once you have done this for all VNs on each Host in the Host Cluster, corrected any inconsistencies and refreshed the Host Cluster, the VMs will change back to a healthy status. Verifying all of this can take some time, and is prone to human error as these settings are case sensitive and take into account spaces. Instead, why not run a PowerShell script that will report all settings for you? (Scroll to the bottom to download the script).

Here are the three settings that must be consistent on all nodes.

Here’s the PowerShell script we’re going to use.

The script is saved as ‘VMNicInfo.ps1’ in the VMM Library. This way, it can be run from within the Admin console. I’ve created a folder named ‘Scripts’ to place it in. Refresh the library to see it.

Now we run the script by right clicking on it and answering a few prompts. Enter ‘r’ to run the script if prompted. Next, enter the name of your Host Cluster and press Enter. (This script must be run from an Admin console running on the VMM Server. To run it from the Admin console on a different system change ‘localhost’  to the name of your VMM Server and surround it with quotes.)

You see in the image above that the Name and Location are the same. There is no entry for Tag on either VN, so they match as well. In the example below we add a value to Tag on one of the systems.

Now we run the script again and see that the output reflects this change. (If this does not work for you make sure you have refreshed the Host Cluster, in the red box). You will also notice that the VMs running on the Host Cluster change to a state of ‘Unsupported Cluster Configuration.’

Change the Tag back to its previous value (nothing in my case) and perform another refresh to see your VMs change back to a healthy state.

That’s it. I hope this clears up any questions or misconceptions you may have had. Below is the script. Be sure to copy this to Notepad as it will remove all formatting characters. Or, download the script here, then run from a VMM PowerShell prompt.

 

#####################################################################

 

function DisplayNicInfo($VMHostName)

 

{

 

  $yy= get-VirtualNetwork -VMHost $VMHostName;

 

  $yy | ForEach-object {write-host " Name " $_.Name;

 

                        write-host " Locations " $_.Locations;

 

                        write-host " Tag " $_.Tag;

 

                       }

 

}

 

#####################################################################

 

$clusname = read-host "Host Cluster name to check"

 

Write-Host ""

 

$VMMServer = get-vmmserver -computername localhost

 

$Cluster = get-vmhostcluster -name $clusname

 

$VMHosts = get-vmhost -vmhostcluster $Cluster

 

$VMHosts | ForEach-object {Write-Host "VMHost: " $_.Name;

 

  DisplayNicInfo($_.Name);

 

  Write-Host ""}

 

Big thanks to Austin, who reworked the script into a thing of beauty. Go Perf! (https://blogs.technet.com/askperf)

VMNicInfo.ps1

Comments

• Anonymous
  January 01, 2003
  Absolutely. Try a variation of 'Set-VirtualNetwork' options. Help 'Get-Help Set-VirtualNetwork -full'

• Anonymous
  January 01, 2003
  thank you

• Anonymous
  October 08, 2010
  Thats very useful thanks. Can the actual changes also be scripted by powershell?

• Anonymous
  December 31, 2010
  This is a great resource for troubleshooting the "unsupported cluster configuration" status problems.  I've used this many times to resolve this issue.  Thanks Jonathan!