• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 620
  • Last Modified:

How do I configure virtual machine networks as a highly available resource in a Hyper-V failover cluster?

Greetings -

I have created a Hyper-V failover cluster and I have a question about virtual machine networks and ensuring the cluster fails over the VMs to another node when a network connection for a VM network goes down.

My experience tells me that if I rip out a network cable from a NIC designated as a virtual machine network, the cluster does not fail over the VMs.  Rather, the cluster maintains its current status and the VM just goes offline.  I find this strange and don't understand the design decision behind it.  I would think networks dedicated to VM traffic would be cluster resources and cause the cluster to failover if they go down.

How do I set things up such that if a physicial adapter devoted to VM traffic goes "down", the vms fail to another cluster node?  By default, when you use SCVMM to configure a virtual machine network and attach it to a physical nic, that network doesn't appear as a cluster resource.

I suppose a way to ensure redundancy would be to attach each VM to two virtual machine networks and use the bridging functionality within the VM itself but that seems a bit cheesy and not quite enterprise-class.

Any input on this would be helpful.
  • 3
  • 2
1 Solution

a way to ensure redundancy would be to attach each VM to two virtual machine networks and use the bridging functionality within the VM itself but that seems a bit cheesy and not quite enterprise-class.

The proper method of achieving network redundancy is to trunk multiple physical NICs into the virtual machine network. In the case of Hyper-V you'd team the physical NICs on the host server using whatever flavor utility matches the NIC vendor.
amendalaAuthor Commented:
Interesting input and I understand what you're driving at.  It's a good idea if I can get it to work stably.  The confusion for me comes from the fact that most of the best practice and Hyper-V config docs I've read from Premier and Technet urge you *avoid* teaming whenever possible due to the notorious reliability issues that have been endemic to a lot of OEM teaming code - especially with Broadcom adapters.

Though it appears Microsoft has substantially softened their stance on teaming and its ability to be used with Failover Clustering.  I will keep this in mind.

If anyone else has any input, please share.

Thanks BDoellefeld.
The virtual network should appear as a cluster resource if it has been defined in Hyper-v manager on every host in the cluster.

I haven't tried the cable pull test to see if that gets detected as a failure that will cause a VM to migrate or failover to another host. I imagine that SCVMM with SCOM and the PRO integration would do a better job or detecting situations where VMs should be moved around, but I haven't setup SCOM yet.

To put things into perspective, I don't think that I've ever had a single link failure in my 5 years here. I have pulled a power cable, and I've had the power supply is a switch go out, but I've never had a complete failure in a single NIC, switchport, or cable. I monitor all of my servers, and I will know soon enough if something goes down. If the Hyper-V host dies for some reason, everything does get restarted on other nodes in the cluster.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

amendalaAuthor Commented:
kevinhsieh - Thanks for the input but I'm experiencing things differently.  The networks I have defined in my cluster are configured through SCVMM which essentially fires Powershell scripts at the hosts.  If I enter the Hyper-V manager MMC, I do see all my networks defined but they are not shown in the Failover Cluster Manager as a cluster resource.

This depends on whether or not one checks the "Host Access" box in SCVMM when setting up a virtual network.  If you check "Host Access", a physical adapter will be left availalbe for host-IP configuration in your "Network Connections" under Network & Sharing Center.  This will allow both virtual machines and the parent partition to communicate out the NIC.  In my environment, our security standards mandate that NICs be dedicated to VM traffic or host traffic, not both.  Therefore, we don't check "Host Access" and the NIC ends up being taken over by the "Microsoft Virtual Network Switch" and as a result, they do not appear as a cluster resource.  This design decision intrigues me.

We have SCOM with PRO integration running in my enterprise but this won't really help with failure / fault-tolerance.  PRO is much more targeted at ensuring that the load across hosts is balanced and it ends there.

I appreciate that you haven't had a failure in your environment but for the systems I'm configuring within a public-safety organization, I cannot afford even seconds of downtime or lives are put at risk.  Therefore, pulling every single cable whether network, power, fibre channel, etc. is required as part of fault-tolerance testing.  If any one cable causes a service to become unavailable, you have a single point of failure.  I'd also like to point out that fault-tolerance testing needs to include human-error.  If a network admin makes a VLAN change and mistakenly transposes two numbers in a core switch, the cluster needs to be able to fail and tolerate that.  It isn't only about hardware failure.  I'm sure you agree.

Thanks again for the input.
I checked my cluster and I have a cluster resource for my networks that are on all of the hosts, even networks where host access has been cleared. It seems to me that there is something wrong with your configuration that is preventing the cluster from seeing your virtual networks as a clustering resource. It is working for me, so it doesn't appear to be a Microsoft design decision. That certainly seems to be something that needs to be corrected in your cluster. You might need to put each host into maintenance and redo the virtual network configuration on each host.

It may be possible to change the dependencies of the VMs. I haven't had any luck with messing with the dependencies, though, and you would certainly need to get the networking in as a cluster resource.

amendalaAuthor Commented:
The solution to this question is to team the NIC's using HP's network management utilities on the server itself.  This is working beautifully and I've been putting it through faul-tolerance testing over the past few days with remarkable success.

kevinhsieh - I received confirmation from Microsoft Premier Support that when you define a virtual network from with SCVMM (not via the Hyper-V manager) and you do not check the Host Access box, on a Server 2008 R2 failover cluster, the virtual networks do NOT appear as cluster resources.  This is by design.  The recommendation from Microsoft, apparently they've changed their tune as teaming has become more and more reliable, is to team the NICs on the host and leverage the OEM management utilties.  They explicitly support teaming in failover clusters (including Hyper-V implementations) now, whereas before, they decried it.

Thank you all for your help.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Network Scalability - Handle Complex Environments

Monitor your entire network from a single platform. Free 30 Day Trial Now!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now