by Dan Pilone
This is a somewhat random post to put up here but maybe it will help save someone else time. I’m fascinated by virtualization and cloud technologies and recently virtualized all of Element 84’s infrastructure into an AMD based server running Microsoft’s Hyper-V Server Core 2008 R2. On the whole installation and setup went well with the exception of the built-in Realtek NICs. Realtek is decent at the consumer level but just doesn’t cut it for server class. In particular, Hyper-V has all kinds of networking issues trying to share a Realtek NIC across VMs.
After many hours of banging my head against it I eventually gave up and spent the $30 to buy an Intel based NIC. In short, it works great and addressed the networking issues. However, even though the card is natively supported by Server 2008 R2 that Hyper-V Server is based on, it wasn’t immediately detected when I installed it. The easiest way I found to get the driver to load after initial installation is to use the devcon command line tool included with the Windows Driver Kit. It’s a command line version of Device Manager (since Server Core doesn’t include the device manager and running it remotely only allows read-only access).
First, verify that Hyper-V physically sees the card:
devcon findall =net PCIVEN_10EC&DEV;_8167&SUBSYS;_81671019&REV;_104&35E69562&0&28A4: Realtek PCI GBEnFamily ControllernROOTVMS_MP000 : Microsoft VirtualnNetwork Switch AdapternPCIVEN_8086&DEV;_107C&SUBSYS;_13768086&REV;_054&35E69562&0&00A4: Intel(R) PRO/100n0 GT Desktop AdapternROOTVMS_MP001 : External Networkn4 matching device(s) found.
This should return network interfaces installed in your machine, including the new one. Next, check the status of the card:
devcon status "@
devcon status "@PCIVEN_8086&DEV;_107C&SUBSYS;_13768086&REV;_054&35E69562&0&00A4"
This should tell you that the card exists but has a problem, usually Code 01 if the driver exists but isn’t loaded. Code 31 means the driver it wants it can’t find – in that case you’ll need to download and install the vendor driver using “pnputil -i -a *.inf”.
Next remove the device then scan for PnP changes which will find it again, this time properly starting the driver:
devcon remove "@
"ndevcon rescanndevcon status "@ "
This time it should come back happy and tell you that everything is working properly. The card should now be available in Sysconfig and the Hyper-V remote admin tools. Hope that helps
**There are a number of “tweaks” you can do to try and work around the issues such as disabling all offloading options in both the host and VMs and disabling TCP chimney support, RSS, and window autotuning but those are… “tweaks”… at best. See the technet link above for some suggestions.*