If you would like to read the other parts in this article series please go to:
Introduction
In my first article in this series I started out talking about some of the more common problems that you are likely to encounter when working with Hyper-V. My original intention was to spend this article talking about some more of Microsoft’s top Hyper-V support issues. However, I decided to save that for Part three because I ran into some Hyper-V problems because I ran into some Hyper-V problems of my own this week, and I wanted to talk about how I fixed those problems for the benefit of anyone else who might run into a similar situation.
My problems started when the system board on one of my Hyper-V lab servers was damaged by a power surge during a recent storm. The server was a couple of years old and I was unable to find the exact system board that I needed to replace the damaged one. That being the case, I ordered an updated system board, a processor with more cores than what my previous system board could support, and some faster memory.
The way that my server had been set up was that it acted solely as a host server, and was not even a domain member. It was essentially running a default Windows Server 2008 R2 deployment with Hyper-V. All of my virtual servers resided on an external storage array that was not affected by the power surge.
Since I was going to be using a different CPU architecture I knew that I was asking for trouble if I tried to reuse my existing Windows Server instance. That being the case, my plan was to repair the hardware, reinstall Windows from scratch, install the Hyper-V role, and then connect the server to the virtual machines on the storage array.
At first my plan seemed to work without a hitch. However, I soon realized that I was having intermittent network connectivity issues. For example, I was sometimes unable to connect to network drives. I also had problems with Remote Desktop connectivity. Sometimes Remote Desktop were not connected all, and other times the connection will work fine for a little while and then drop.
It didn’t take me long to discover that the reason for my network problems was that Windows Server 2008 R2 had misidentified my primary network adapter. Even though I was using a Netgear card, Windows had identified it as a Realtek card. Needless to say, I downloaded the correct driver and installed it onto the system.
I would have thought that installing the correct driver would have been an easy fix, but fixing the driver actually led to a chain reaction of other problems. The first of these problems was that once I fixed the network driver, none of my virtual machines were able to access the network. The reason why this happened was because the only software component that is bound to the physical Nic is the Microsoft Virtual Switch Protocol. The host partition and all of the virtual machines rely on virtual network adapters which tie into the physical network adapter as if the physical network adapter were a network switch. Changing the driver for my network card ended up breaking the virtual switch linkage.
The easiest way to fix this problem was to simply remove the Hyper-V role and then reinstall it. I knew from past experience that when you remove the Hyper-V role, all of the virtual machines remain on the system. If you later decide to reinstall the Hyper-V role, all of the virtual machines will still be intact.
Removing and reinstalling the Hyper-V role did fix the virtual network switch linkage problem. After Hyper-V was reinstalled the host operating system was immediately able to access the network. However, my virtual machines were still inaccessible from across the network.
In an effort to resolve the problem, I shut down one of the virtual machines and then I took a look at the settings for that virtual machine. What I found was that the virtual machine was still looking for my old virtual network (which existed by way of the old virtual switch). When I removed and reinstalled Hyper-V, I connected it to the correct network driver, which in turn created a new virtual switch and a new corresponding virtual network. Because my guest machines were configured to connect to a virtual network that no longer existed, the settings for the virtual machine actually showed that the virtual machine was configured to connect to an unknown network.
This problem was easy enough to fix. All I had to do was to shut down all of my virtual machines, and then adjust the network settings for each virtual machine so that the virtual machine would be connected to the correct virtual network.
Once I had tied all of my virtual machines into the correct virtual network, I powered all of the virtual machines backup. Imagine my surprise when I was still unable to access the network from any of my virtual machines.
The reason why network connectivity failed from within the virtual machines was because connecting the virtual machines to a different virtual network has the same effect as replacing a network card with a different model of network card in a physical machine. Windows treats the new network card as a new piece of hardware and does not apply your network settings to the new network card.
In the case of virtual hardware things work basically the same way. Because I had connected all of my virtual machines to a different virtual network, the virtual machines lost their network configurations. In my particular case with this meant was that I had to manually reassign IP addresses to each of the virtual servers.
I will be the first to admit that this step may not always be necessary. Most networks are configured to dynamically assign IP addresses to machines as they come onto the network. In my case though, all of the virtual servers that were running on this particular Hyper-V host had previously been configured with static IP addresses. In fact, all of my lab hosts are connected to an isolated network segment that does not even have access to a DHCP server. Once I had reapplied the static IP addresses to each virtual machine, network connectivity was reestablished and all was right with the world.
Conclusion
Being that Windows Server 2008 R2 is a mature product, it seems strange to me that the operating system can still misidentify physical network adapters. Apparently the lesson to learn here is that when setting up a new host server is a good idea to take a moment and make sure that Windows has correctly identified all of your server hardware. Taking a few minutes upfront to do a quick hardware check can save you quite a bit of time later on.
In Part 3 of this series, I plan to talk about several more common issues that you may run into in a Hyper-V environment.
If you would like to read the other parts in this article series please go to:
