Kevin Remde's IT Pro Weblog
At a TechNet Event a couple of months ago, Ken W. asked :
“If I'm running many guest VMs, do you recommend NIC teaming additional NICs for guest traffic? Or just adding them and keeping them separate and control per guest settings?”
For those of you not familiar with the idea, NIC Teaming is a capability of making many physical Network Interface Cards (NICs – not always a card these days, but still representing physical plugs or paths for network traffic) as if they are one. Prior to Windows Server 2012, NIC teaming in Windows was the job of the NIC vendors to provide. However, in the next version of the server, NIC teaming is also a capability that Windows Server provides.
NIC Teaming provides two main benefits:
So, you have the opportunity to get better throughput, and also maintain connectivity in the event that one of the network paths fail.
You can team NICs on the physical AND the virtual machines; provided you’re running Windows Server 2012, of course. In a virtual machine you could define virtual NICs that connect to different physical NICs (or even teams that are presented as physical NICs) in order to create a team. (You could also connect a virtual machines virtual NICs all to the same virtual switch and then create a team, but you wouldn’t gain anything by doing that. It makes for a good demonstration, but nothing more.)
On your physical server running Windows Server 2012, it’s really up to you how you want to divide the workload and traffic among your guests, plus other important network traffic types as needed:
“But what do you recommend?”
I have to say it really all depends on how you want to manage it. If you want to do all of your teaming on the physical host, and present teams as individual NICs to your VMs, then that’s great. And even your guest operating systems that don’t otherwise support NIC teaming can use a single NIC that in reality is a high-performing, reliable team. But if you have some reason to do the teaming of NICs within your Server 2012 VM, then you can do that, too. Consider the role your physical server plays (cluster node?), the roles your machines play, and the kind of performance and/or reliability you need them to have. Also consider carefully your network definitions and assigned NICs when configuring nodes in a cluster. The machines need to see the same-named virtual switches when they move between cluster nodes.
NOTE: There may be other considerations having to do with the new Network Virtualization capabilities with Hyper-V in Windows Server 2012. I haven’t looked into it enough yet to know what impact that will have (if any) in making these choices.
Here are some more useful resources about NIC Teaming:
and I really enjoyed David Ziembicki’s blog post about it:
Are you excited about native, build-in, easy-to-use NIC teaming in Windows Server 2012? Give us your feedback in the comments.