5

I've been reading around Hyper V and how it manages virtual networking & I think I've spotted a problem with a small cluster that has been put together for me by our networks team to host a SharePoint farm.

The servers is question have two NICs - 1 to be used for standard LAN traffic and the other for communication with SAN storage.

On a default installation when the Hyper V role is enabled and a Virtual Network is created for each NIC then as I understand it the following should happen:

  1. Create a virtual switch.
  2. Create a vNIC with the same name as the vSwitch.
  3. Host unbinds itself from the physical NIC and binds itself to the new vNIC.

The result is the host OS uses the same virtual networking route that the child VMs use and any new guest VMs can create their own vNICs against the appropriate vSwitch.

In the case of the servers that I'm looking at I see that on each of the host machines the vNICs have been unbound and the machine has been re-bound back to the physical NICs.

Everything works fine as far as I can tell. The set-up has been replicated across all blades in the cluster so Live Migration etc works fine.

Am I correct in my understanding of Hyper V networking as I've briefly summarised above? (If I'm wrong you can ignore the rest of the post...!)

If so, given the changes that have been made in this set-up are there any potential problems that may arise with the hosts machines bound the physical NICs?

We've have an intermittent issue with network activity freezing on random VMs at random times - the solution is to either re-start the VM or live migrate it to another host. Another intermittent issue is for hosts to BSOD and re-start occassionally - crash dumps seem to indicate a problem within a network driver. So far I've been getting told that the issue is probably just drivers or BIOS settings and various things have been tried without success to stop the problems. I'm wondering if our problems could be related to the hosts binding to the physical NICs when they should be bound to the vNICs instead.

2 Answers 2

2

As far as the bsod's are concerned the following (relevant to your situation) hotfixes will need to be applied.

http://technet.microsoft.com/en-us/library/ff394763(WS.10).aspx

Are you really running with just two nics, are they 10gb's? if not then your clusters not running in a recommended configuration. True it will pass with warnings the cluster validation test but it will be less then optimal.

If you truly have one nic for lm,csv,hb,vms,mgmt then its configured the only way possible and the host must share the nic's with the vm's.

Another issue was this cluster built with hyper-v installed then sysprepped? If so then you have mac collisions.

http://blogs.technet.com/b/jhoward/archive/2008/07/15/hyper-v-mac-address-allocation-and-apparent-network-issues-mac-collisions-can-cause.aspx

2
  • Yep - 2 NICs. The hosts are a set of blades so there's limited resources available. The specific question is what possible problems could arise with the host bound directly to the physical adapter rather than via the vNIC that Hyper V creates for the host at the point that the switch is created through Virtual Network Manger. The default is for the parent to use a vNIC but there's nothing to stop you manually swapping the settings back to the physical adapter which is what appears to have happened here. No sysprep involved here to my knowledge.
    – Chris W
    Jul 20, 2010 at 15:39
  • this "host bound directly to the physical adapter rather than via the Vnic" really has me confused. I'm trying to figure out how the host is bound to a vnic, thats not the default. Do you mean guests not hosts?
    – tony roth
    Jul 20, 2010 at 16:03
2

Not. You are doing it ok. In an Hyper-V team you can bing a real network adapter with the same name to a virtual network in all the nodes. You should do this and this is the recommended by Microsoft.

Altough you are using the NICs for doing a lot of things and that could be genereating your problems. Keep in mind that only use two network adapters for this scenario is not the best option and could have unexpected behavior.

Based on the Microsoft recommendations you should have in all the Hyper-V nodes the following:

  1. A NIC dedicated to Virtual Machines.
  2. A NIC dedicated for management, that means for be use to the host.
  3. A NIC dedicated for iSCSI.
  4. A NIC dedicated for heart beat. This is the internal traffic of the cluster.
  5. If you are planing to use Live Migraton you should dedicated a NIC for that.

Try to have them all. Remeber to rename them exactly on all your nodes.

Remeber that is not supported by Microsoft to have Teaming at NICs in Hyper-V Clusters, that could genereate failures. There is more information at Microsoft KB 968703.

Read this article about network best practice for knowinf what protocols you should enable in whic NIC and about the metric. It's highy recommended to change the metric in each interface.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .