Mental Ward

Blog archive

NIC Bonding Not in Hyper-V

I recently blogged about the issue of "NIC teaming", also known as "NIC bonding", and the fact that it's allegedly missing from Hyper-V. Virtualization blogger Scott Lowe originally reported this, and we have confirmed that it is not a feature of Microsoft's new hypervisor. Here's the response, from Microsoft's Robb Mapp:

"NIC Teaming is a capability provided by our hardware partners such Intel and Broadcom. Microsoft supports our partners who provide this capability. This is true whether the customer is running Windows, Exchange, SQL Hyper-V, etc. We'll have a detailed KB article about this coming out soon."

So Hyper-V doesn't do it, but you can buy products that do it -- although not all of them do. I went back to my go-to virtualization analyst, Chris Wolf, for his take on how this could affect the market for Hyper-V. Here's what he said:

"This is a pretty big issue, and one that I've been raising with Microsoft for months. NIC teaming is a requirement in virtualization deployments, in my opinion, as there should be no single points of failure that could potentially disrupt access to several VMs.

Now if you think about it, the need for teaming is nothing new to Microsoft. I've been deploying Microsoft clusters with teamed NICs for years. The NIC vendors would support their own teamed configuration and that was good enough for me. So basically, it's the same issue with Hyper-V. Microsoft may not officially support the teamed configuration, but the vendor that provides the NIC driver will. Microsoft even has a KB article about this.

Compare this to storage and there are a lot of similarities. Microsoft officially supports multipath storage drivers, and when it comes to troubleshooting low-level storage issues, the storage HBA vendor will get involved. It should be the same process with network interface vendors.

Comparing VMware to Microsoft, I can team any two NICs using VMware ESX, so I don't need to go out and buy specific NICs that include a teaming driver. The Microsoft implementation would require a pair of NICs and a teamed driver, so the NIC teaming would be managed independently of the hypervisor.

At the end of the day, I can achieve the same level of network availability in both hypervisors (ESX and Hyper-V). However, Microsoft can do more in this area. Since I can still achieve teaming in Hyper-V, I don't see the issue as a deal breaker. I'm sure Microsoft will do more with teaming down the road, but Hyper-V is a first generation product, so it's fair to expect Microsoft to take some time to develop such features. In the meantime, the features are there, but just implemented differently."

My take: NIC teaming should be included in the base hypervisor, period. If Hyper-V truly wants to compete with ESX -- and more competition for VMware is something everyone should want -- this needs to be added as a feature.

Posted by Keith Ward on 06/18/2008 at 10:27 AM


Reader Comments:

Wed, Feb 25, 2009 Lee Atlanta

Amazing! Everyone is a "guru". I love how the "guru" said that NIC teaming is a "requirement" in virtualization deployments. Really? And let's see, Microsoft show expend the cost and effort to develop drivers for another vendor's product, hunh? As if they don't have enough development costs.

Fri, Feb 13, 2009 Anonymous Anonymous

mwzio roypxnjfc ipasf upcaileo rlkomhc pasrkuq lamjvr

Wed, Dec 3, 2008 Justin

As stated already NIC teaming is a function of the parent partition by the manufacture utility. The problem is that the manufacture driver’s don’t expect random MAC addresses to be sourced/destined to the parent. The result is that frames from/to the guests end up being dropped by the NIC driver. SO it’s not MS Hyper-V that is the cause of the problem, but rather the NIC vendors teaming software.

Once Intel/Broadcom release a version of their drivers that support Hyper-V you will be able to create a NIC team in the parent partition, and then connect your virtual switch to the team, and everything will work.

Microsoft should really be getting on the NIC vendors to release an update to support Hyper-V, and NIC teaming though.

Wed, Jul 23, 2008 Paul Welsh UK

Well my dl380 g5 crashed while trying to apply the hyper-v update. I had HP's teaming installed. Reading this I imagine the teaming is the problem. Back to the drawing board!

Fri, Jun 27, 2008 Brian

I am still confused. In Windows, when I team NIC's, it is obviously done at the OS level with either the Intel or Broadcom management utilities. Will these utilities exist at the hypervisor level?

Where exactly do the drivers live in the Hyper-V architecture? How will I configure them? Would Intel and Broadcom have to build plugins into MS System Center in order to manage and configure these sorts of configurations?

Thu, Jun 19, 2008

On a positive side for MS, their nic teaming will probably (depending on the HW) support true load balancing whereas ESX only supports psuedo random load balancing. On VMwares side you are able to team nics from different vendors ie team onboard broadcom nics with added intel nics.

Thu, Jun 19, 2008 Shawn

Doesn't the difference lie in the architecture?
Hyper-V relies on the parent partition (Win2008) for network I/O and because its Windows, NIC redundancy or teaming are provided as a function of the OS. Therefore you must install compatible physical NICs and their respective teaming drivers.
As long as the Hyper-V hypervisor relies on the VMbus/parent partition architecture, this will be the case.

Wed, Jun 18, 2008 Keith Ward

Please click around on other entries, and you'll see that we have positive and negative comments about all the big vendors. We're not "pro" or "anti" anything, other than being "pro" reader.

Wed, Jun 18, 2008

Interesting. Another anti-MS blog. Even though your guru says it's a non-issue, you rephrase it in a negative way. Should I be surprised? After all, your blog is surrounded (top, side, and bottom) by VM Ware ads.
How about you just call it vmwarereview.com instead?

Add Your Comment:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above