More on Hyper-V and NIC Teaming
Published on 23 Jun 2008 · Filed in Rant · 396 words (estimated 2 minutes to read)My original article on Hyper-V’s issues with NIC teaming has gotten a fair amount of attention.
First Keith Ward over at Virtualization Review blogged about this issue. In his initial post, Keith basically pointed out the issue and then asked the readers for feedback: is this really as big of an issue as it seemed? The readers who responded were split; one blasted Hyper-V and the other wasn’t too concerned.
Keith followed that up with another post in which he provides a response from Microsoft regarding this issue:
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.
Keith’s second article was then also picked up by DABCC.
While Microsoft is sticking to the “this is a device driver issue” mantra, I’m not so sure I agree. I can see their position to a point. In Keith’s second post, analyst Chris Wolf brings up storage drivers. This is similar in that Microsoft relies upon the storage vendors to provide device-specific modules (DSMs) that provide the multipathing functionality. So, like with the NIC teaming, Microsoft is pushing the functionality back to the device drivers and vendors who write them.
But that’s as far as this comparison can be taken. Microsoft officially supports storage multipathing; they don’t officially support NIC teaming. (See this KB article or this KB article.) In addition, Microsoft provides an official framework in which the storage vendors can operate: the MPIO framework. There is no such framework for network redundancy. In fact, if such a framework existed then much of the dissatisfaction with Microsoft over this issue would be alleviated, in my opinion.
Instead, there is no framework to provide official NIC redundancy for any Microsoft product running on Windows Server, and Windows itself doesn’t provide that functionality. Users are forced to adopt unsupported means to provide NIC redundancy. Why shouldn’t they be upset?
By the way, since publishing the first article I’ve been contacted by one of the presenters of the VIR358 session during this which issue came to light, but he has not yet been able to provide any additional information. As soon as more information is available, I’ll be sure to let everyone know here.