Hardware manufacturers (not Microsoft) have always enabled the ability to team network interfaces. As far back as Windows NT, Microsoft's position on NIC teaming has been that "support for the fault-tolerant technology [the hardware and drivers] is provided by the hardware manufacturer." Focusing solely on Hyper-V, Microsoft released its "Microsoft Support Policy for NIC Teaming with Hyper-V" ,which restated this position. More specifically, it said the following:
Since Network Adapter Teaming is only provided by Hardware Vendors, Microsoft does not provide any support for this technology thru [sic] Microsoft Product Support Services. As a result, Microsoft may ask that you temporarily disable or remove Network Adapter Teaming software when troubleshooting issues where the teaming software is suspect. If the problem is resolved by the removal of Network Adapter Teaming software, then further assistance must be obtained thru [sic] the Hardware Vendor.A previous Microsoft article on network adapter teaming and server clustering, reinforces this position:
Using teaming on the public or client networks is acceptable. However, if problems or issues seem to be related to teaming, Microsoft Product Support Services will require that teaming be disabled. If this resolves the problem or issue, you must seek assistance from the hardware manufacturer.Does Microsoft support NIC teaming?
The wording of these articles is a source of debate. Does Microsoft "support" teaming or not? The answer is rather simple, actually. Microsoft has never written a teaming driver, so it cannot provide support for driver issues. The teaming driver support has always been a function of the hardware vendors that write them. As a result, Microsoft's position isn't that it doesn't support teaming. Its stance is that it isn't responsible for teaming. While confusing, it all boils down to technical support. If you require Microsoft technical support, you may have to disable teaming during the call to prove that the teaming driver isn't at fault. If it is, Microsoft will also require that you work with the driver's manufacturer to resolve the problem. Consider car repairs. Say you purchased a new Toyota and installed a third-party fuel-injection computer that improves horsepower. Later on, the car's horsepower encounters problems. A Toyota dealership will not consider this a warranty repair because the car has been modified. Fixing it will likely require assistance from Toyota and your third-party fuel-injection manufacturer. This is just the way the real world works. The same situation applies when creating a data center infrastructure from multiple IT vendors. Getting support for that infrastructure may involve effort from multiple organizations. To further solidify this point, I approached Microsoft for an additional statement. Here's their official response:
Microsoft understands that NIC teaming is an important technology; however, Microsoft cannot support NIC teaming configurations in general as they are proprietary solutions by the NIC vendor. That said, [Microsoft] has tested several vendors' solutions and found that there are good products that work well to meet our customer needs. Two vendors in particular have recently released updates to their teaming products that are specifically targeted at meeting the needs of Hyper-V installations.So, you can -- and should -- absolutely use network teaming for your Hyper-V hosts. You'll need to confirm that your hardware drivers support Hyper-V teaming, though. Consult your server manufacturer to determine whether drivers are available for your equipment. Stay tuned for part two of this Hyper-V NIC best practices series in which I discuss the ideal scenarios for adding NICs instead of implementing a virtual local area network.