Jonathan's Virtual Blog : Cluster

‘Unsupported Cluster Configuration’ - Virtual Networks

Jonathan — Fri, 07 Aug 2009 21:23:00 GMT

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: http://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! (http://blogs.technet.com/askperf)

Creating Virtual Networks on Clustered Hosts leaves some binding work to be done

Jonathan — Tue, 02 Jun 2009 01:52:00 GMT

If you ever happen to set up a new virtual network on a Cluster node/Host you may find that your work is not entirely done. First, the Host that you added the VN to will in fact have networking set up correctly. What may appear odd is that the other Hosts in the cluster (nodes) will also show the new virtual network name correctly, but the virtual network bindings are not set up?! What’s going on here?

Simply, the requirement that all Hosts in a Cluster have matching network names is met as it should be. The problem is that although the name of the virtual network is created on the other nodes, there are no network bindings. The reason for this is simple: VMM has no way of knowing which network is the correct one to bind to. Left unchecked, it might bind to the wrong external network, or even an iSCSI network if you have one set up, and then where would your Cluster be? Wrecked. So, following a successful virtual network creation and binding on the initial node, you must manually bind the new virtual network to the correct network on each Host. There will be an error in the initial Host job in fact prompting you to do so. With this done, your new virtual network will be up and running correctly on all nodes. I hope this helps those of you who have run across this.

…

Recommended hotfixes for System Center Virtual Machine Manager 2008

Jonathan — Wed, 11 Feb 2009 20:59:00 GMT

Here it is. We have a new KB that details updates and hotfixes required for SCVMM, Hyper-V and Clustering. Read the article here.

I've commented on the hotfixes inline below, providing a Support Engineer's perspective.

________________________________________________

Required hotfixes for Hyper-V servers

Install these. No question.

956589 (http://support.microsoft.com/kb/956589/ ) Description of the Hyper-V update for issues that may occur when you manage the Hyper-V role on the 64-bit editions of Windows Server 2008 by using SCVMM
956774 (http://support.microsoft.com/kb/956774/ ) A Background Intelligent Transfer Service (BITS) client cannot handle files that have paths that contain the volume GUID in Windows Server 2008 or in Windows Vista
950050 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;950050/ ) Description of the update for the release version of the Hyper-V technology for Windows Server 2008

Note If these hotfixes are missing from a Hyper-V server, the System Center Virtual Machine Manager 2008 Admin Console lists the server status as Needs Attention. Hotfix 956774 should be installed on the Hyper-V servers and on System Center Virtual Machine Manager 2008 Server.

Back to the top

Recommended hotfixes for System Center Virtual Machine Manager 2008 Server

I would change this from 'Recommended' to 'Required' based on experience.

958124 (http://support.microsoft.com/kb/958124/ ) A wmiprvse.exe process may leak memory when a WMI notification query is used heavily on a Windows Server 2008-based or Windows Vista-based computer
954563 (http://support.microsoft.com/kb/954563/ ) Memory corruption may occur with the Windows Management Instrumentation (WMI) service on a computer that is running Windows Server 2008 or Windows Vista Service Pack 1
955805 (http://support.microsoft.com/kb/955805/ ) Certain applications become very slow on a Windows Server 2008-based or Windows Vista S955805-based computer when a certificate with SIA extension is installed
959596 (http://support.microsoft.com/kb/959596/ ) Description of the System Center Virtual Machine Manager 2008 update to address physical to virtual (P2V) issues

Back to the top

Recommended hotfixes for the Hyper-V servers

Install ALL hotfixes on ALL Hyper-V servers, whether SCVMM is involved or not. This is more than a recommendation based on cases I have worked.

957967 (http://support.microsoft.com/kb/957967/ ) Stop error message on a Windows Server 2008-based computer that has the Hyper-V role installed: "STOP 0x0000001A"
958124 (http://support.microsoft.com/kb/958124/ ) A wmiprvse.exe process may leak memory when a WMI notification query is used heavily on a Windows Server 2008-based or Windows Vista-based computer
954563 (http://support.microsoft.com/kb/954563/ ) Memory corruption may occur with the Windows Management Instrumentation (WMI) service on a computer that is running Windows Server 2008 or Windows Vista Service Pack 1
955805 (http://support.microsoft.com/kb/955805/ ) Certain applications become very slow on a Windows Server 2008-based or Windows Vista S955805-based computer when a certificate with SIA extension is installed

Back to the top

Recommended hotfixes for Hyper-V failover clusters

957311 (http://support.microsoft.com/kb/957311/ ) Recommended hotfixes for Windows Server 2008-based server clusters