Today I experienced a weird issue after installing the Hyper-V role on a Windows 8 client, during which the network adapter model changed, a phantom NIC appeared,in the Hyper-V UI and my VM failed to connect to the network. There were also issues when trying to create a new Virtual Switch, but thankfully it was something that a quick search on the Intel site turned up a few suggestions.
The system has an Intel DH67CL desktop board installed, and the physical NIC is the Intel 82579V (aka V), but after Hyper-V was installed and configured it started reporting itself as the 82579LM (aka LM), which then meant that the Virtual Switch in Hyper-V wasn’t letting the client connect to the network. The first sign of this was that the VM wasn’t able to pick up an IP address via DHCP, and attempting to disable and enable the NIC did not improve the situation.
Going back into Hyper-V Manager, the Virtual Switch settings gave me a choice of using either the the V or LM NIC, but device manager only showed that I had LM. Uninstalling the hardware through device manager and rescanning made the NIC reappear as the V variant. Hmmm, maybe things weren’t going to be as simple to resolve as I expected. Unfortunately I didn’t get a screenshot until after I had resolved the issue, but here’s how it should look.
Thankfully the Intel site revealed what I was after in the second search screen, which was a utility for resolving this exact issue where the non-volatile memory on the NIC was reporting the wrong hardware, apparently something that is more frequent under Windows 8. This machine has been running Windows 8 for an extended time period without issue, so it really seems enabling Hyper-V was the trigger for this.
I grabbed the download from the Intel site, the utility description was as follows…
This utility resolves an issue where during system resume, the Intel® 82579V Gigabit Ethernet PHY Network Connection erroneously reports the device id as an Intel® 82579LM Gigabit Ethernet Controller Network Connection, resulting in a Windows* Code 10 error and loss of network connection.
Not all systems with the Intel 82579V Network connection will see this problem. Systems using Microsoft Windows* 8 are more susceptible to the issue.
If you experience this error, Intel recommends that you update the non-volatile memory for your network connection by downloading and running the NVM Update Utility.
Three versions of the utility are available to support three different operation systems (Windows 32 bit; Windows 64 bit; DOS).
Steps to run the update tool:
1. Download the utility.
3. Open a command prompt window with administrator privileges
2. Select the utility in the directory or folder based on the operating system installed
a. 32-bit Windows use the utility in the Win32 directory
b. 64-bit Windows use the utility in the Win64e directory
c. DOS use the utility in the DOS directory
4. Run the executable file from the common prompt
5. The NVM image will be updated. Reboot the computer for best results.
Obviously I needed the 64 bit version, how else would I be running Hyper-V! Assuming I needed to run this as an admin, it was time for Windows Key + X to let me launch an elevated command prompt with ease.
Running the command in verbose mode indicated that a machine restart was required, and voila – after a reboot everything worked as planned.
Of course, I wasn’t satisfied, I went back to the Intel site for their update utility after discovering my network drivers were a year old, so why not update them. And the graphics driver. And the audio driver. Now the scary piece of all of this… it’s my long running Media Center machine. If you aren’t familiar with the site, take a look here. For those of you who are Media Center users you know that I’ve broken several of the golden rules in regards to deploying extra roles and updating drivers with disregard to system stability, but that’s what System Restore and backups are for.
In case you were wondering, the VM that I moved over to this machine is for Threat Management Gateway, which I primarily run as a caching solution. There is a bit of hardware juggling going on at home at the moment, which necessitated this move, but I’ll drill into this in a future post.
intunedin.net 