A couple of weeks ago, I blogged about running Windows from a flash drive – specifically running Hyper-V Server 2008 R2. One thing I hadn’t got around to at that time though was injecting the necessary drivers to provide network access to/from the server – which is pretty critical for a virtualisation host! Under network settings, the Hyper-V Server Configuration (sconfig.vbs
) showed that there were no active network adapters found but I knew this should be pretty easy to fix.
One of the strengths of the Hyper-V architecture is that it uses the standard Windows device driver model. This is in stark contrast to the monolithic model used for VMware ESX (and ESXi) and is the reason that I can’t do something similar with ESXi. In fact, adding network drivers to Hyper-V Server (or for that matter Windows Server 2008 running in server core mode, or even for command line administration of a full Windows Server 2008 installation) is pretty straightforward.
The network card I needed to support is a Marvell Yukon 88E8055 PCI-E Gigabit Ethernet Controller and, even though Windows 7 recognised the hardware and installed the appropriate drivers at installation time, I couldn’t find the drivers in the install.wim file on the DVD. That was no problem – Marvell’s download site had x64 drivers for Windows 7 available and these are also be suitable for Windows Server 2008 R2 and Hyper-V Server 2008 R2. Armed with the appropriate driver (yk62x64.sys v11.10.7.3), I ran pnputil -i -a yk62x64.inf
on my Hyper-V Server:
Microsoft PnP Utility
Processing inf : yk62x64.inf
Successfully installed the driver on a device on the system.
Driver package added successfully.
Published name : oem0.inf
Total attempted: 1
Number successfully imported: 1
(oem0.inf and an associated oem0.pnf file were created in the %windir%\inf\ folder)
With drivers loaded, I restarted the server (probably not necessary but I wanted to ensure that all services were running) and Hyper-V Server recognised the network card, allowing me to make configuration changes if required.
To validate the configuration, I ran pnputil -e
, to which the response was:
Microsoft PnP Utility
Published name : oem0.inf
Driver package provider : Marvell
Class : Network adapters
Driver date and version : 07/20/2009 11.10.7.3
Signer name : Microsoft Windows Hardware Compatibility Publisher
So, that’s installing network drivers on Hyper-V Server, what about removing them? Here, I was less successful. I tried removing the plug and play package with pnputil -f -d oem0.inf
and this removed the package from %windir%\inf but, after a reboot, my network settings persisted. I also used devcon.exe
, the command line equivalent to the Windows Device Manager (making sure I had the amd86 version, not i386 or ia64) to successfully remove the PnP package (devcon -f dp_delete oem0.inf
) as well as the network interface (devcon remove "PCI\VEN_11AB&DEV_4363"
) but this still left several copies of yk62x64.sys available in various Windows system folders. Again, after a reboot the network card was re-enabled. Uninstalling network drivers is not a very likely scenario in most cases but, with a bootable flash device potentially roaming between hardware platforms, it would be good to work out how to do this. Of course, my work is based on the release candidate – the RTM version of Hyper-V Server 2008 R2 is yet to be released to web.
Remember if you’re using the Marvell network card to turn off large send offload. Otherwise network perf sucks. Best alternative is to use a decent network card (not an option in the case of my demo machine :( )
@Stu – nice tip, thanks for that.
Hi Mark
I didn’t need a network driver, but the same method allowed me to inject a display driver to allow Hyper V to operate at the appropriate machine/display resolution.
Garry Martin just tipped me off that the reason I couldn’t find my network driver in the Hyper-V Server install.wim was because it has a different name: anyone else looking for the Marvell Yukon drivers I needed might want to check out c:\windows\inf\netmyk00.inf but the principles are the same whatever the NIC (or, as Peter pointed out in his comment, for other devices too).
@Stu
YOU JUST MADE MY DAY!! Consider yourself smiled at. :-)
I built a couple hyper-v servers for experimentation using ASUS p5k pro motherboards with 8 gigs of ram and a quad core Q6600 processor. (Great bang for your buck/pound/euro/pickyourcurrency :-) ) Anyway, they have marvell 1-Gig network cards plus I have other PCI-e Marval NICs too. Now they all work like they should have.
God did a good thing when he brought your consciousness into this world.
“I also used devcon.exe, the command line equivalent to the Windows Device Manager (making sure I had the amd86 version, not i386 or ia64) to successfully remove the PnP package (devcon -f dp_delete oem0.inf) as well as the network interface (devcon remove “PCI\VEN_11AB&DEV_4363″) but this still left several copies of yk62×64.sys available in various Windows system folders. Again, after a reboot the network card was re-enabled.”
Mark,
> devcon -f dp_delete oem.inf
removes the driver package from the Driver Store and %windir%\inf\oem.?nf + oem.cat.
> devcon remove “device/hardware/compatibleId”
removes the device devnode.
If the device was being reinstalled after a reboot, perhaps you also needed to remove the service?
> sc delete
This would delete HKLM\System\CurrentControlSet\Services\
where =
Also need to have the physical network cable plugged it for Hyper-V to pick up the card.
Tried this first and it didn’t look like it worked – then plugged in a network to my router and it picked up the card!
Pete, two years on I hope you’re still reading this. Your advice helped me out so much! I was about to snap my network drivers CD in two, because I thought the drivers were dodgy and causing the system not to “recognise” the network card. Plugged a cable in and everything was fine!
You’d think they’d have put a clearer error message in…
Anyway, thanks.
Also as indicated above by Pete, the NIC needs to be plugged in or Hyper-V won’t see it.