We just received our new server to begin our Hyper-V deployment. It was recommended that we get 4 NICs on the server. The server has 2 onboard BroadCom nics and 2 pci Intel Pro nics.

The Broadcom software will support teaming of both the broadcom and intel nics.

Question, has anyone had great success with teaming in Hyper-V? I have read many stories both ways. If teaming in Hyper-V works (I know MS does not support it), what is the best option to use the Broadcom software and the nic configurations? Load balance? Link Aggregation? Not sure if I should even use teaming?


  • I've never been a fan of NIC teaming except in very specific circumstances. What's your intended goal for teaming? – joeqwerty Feb 16 '11 at 3:01
  • I have never used teaming or load balancing. Being new to the VM world, I was informed that it is beneficial?? Would it be best to leave each phyisical nic for each VM? – user71023 Feb 16 '11 at 17:26
  • Where's it say that MS doesn't support NIC teaming? – Chris S Feb 16 '11 at 18:07
  • @Chris I believe Microsoft just doesn't test teaming - not that they don't support it. Some Hyper-V docs were unclear on that a while back. – Doug Luxem Feb 16 '11 at 18:16

For Great Success! Our Hyper-V Hosts are all configured like this:

  • An iSCSI NIC with iSOE - This NIC has two ports for all but NIC redundancy; MPIO handles redundancy, so no teaming here.
  • Two Dual-Port NICs with TOE - These are teamed, one port from each controller, two teams. One team is for Hyper-V guest traffic. The other is for management and heartbeat traffic (clustered systems).

All are configured for Least Queue Depth sending, failover receiving. Each function is on a separate vlan (all connections go to the same switch stack). All Broadcom chips, nothing against Intel, I just get paranoid about mixing hardware in critical production systems.

If the management and heartbeat teams were separated this would be exactly as MS recommends (according to my sources). Having those two very lightly used functions on separate teams is just overkill in my opinion, so we combine them. If traffic demanded it, I would add additional NICs/Ports to the Hyper-V team. If your switch stack supports InterSwitch Trunking, you should use LACP instead of Least Queue Depth (Round Robin is also an option, though I wouldn't recommend it).

| improve this answer | |
  • We have a similar configuration and it's been online for over 18 months now. Definitely recommend using MPIO for iSCSI SAN connections. We noted that failover clustering does not take into consideration network link failures for connections that are not used for the service, but may be used by clients (i.e. Hyper-V guests). This is where we found NIC teaming to be VERY useful. – newmanth Mar 16 '11 at 21:06

Teaming is probably best used when you've got some shared storage in place.

I like to team two (or more) of the nics back to the storage device, then use 1 nic for hyper-v(or more, depending on your scenario) and a separate nic for management.

In your situation I would probably just want to use 1 nic for hyper-v and 1 for management.

| improve this answer | |
  • 1
    If you're using iSCSI for shared storage Teaming will cause iSCSI to fail in the event of a link failure. MPIO is the way to add redundancy to iSCSI. – Chris S Feb 16 '11 at 18:14

We've got two Dell R410's in a Hyper-V Server 2008 R2 cluster, with two integrated Broadcom NICs for LAN access, and a 4 port Intel NIC for iscsi storage network.

The Intel NICs are configured independantly of each other, on separate subnets to be used for MPIO with our SAN.

The two Broadcom NICs are teamed together using the BACS utility with the LACP configuration. On the switch side, we have a 3COM 3848 providing the other side of the LACP config.

This setup has been running since December 26th, 2010 and have had zero issues so far.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.