• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1301
  • Last Modified:

Hyper V Network Issue

Hi Experts!  I have a Hyper-V machine with one VM that - regardless of what I try - cannot seem to see the physical network.  I have installed (and re-installed) Hyper-V Tools, to no avail.  I have created a second Network entity, bound to the first (instead of the second) NIC, also to no avail.  I think I've covered most of the obvious bases, yet the machine still fails to "reach out" to the physical network: DHCP doesn't work, and I have only a few clues as to what might be happening.  It seems to show a Local Connection 8, DCHP-Enabled, Autoconfig Enabled, no IP or Subnet Mask, and then a "stub" for the VPN tunnel, which we're not using yet (anyway).  I think it has somehow - mo matter how I configure the Hyper V Network Settings - set upon the unused IP tunnel (or some other fictitious interface) as its Net Source, instead of NIC2 (Local Area Connection 5) to which it should be connecting.

Both NICs are connected to the switch, so we're not bound to an inactive NIC.  

I'm confused, and getting a little frustrated.  Is there some way to simplify this mess and make it work?

Thanks in Advance,

- LongFist
  • 7
  • 4
1 Solution
Hi LongFist, let's start it over.
In hyperv, you can dedicate or share a nic to be connected to a virtual switch

Let's choose the dedicated methode. First make sure there is no NIC teaming or trunk configured on the switch.

Let's say Nic1 is for physical host and management purpose
Nic2 should be used to create a Virtual External Network called 'Virtual Switch' for example. You want to uncheck 'Interact with os' checkbox when creating this switch. No vlan configuration so far.
Then, once applied, you browse you vm network settings and under Network configuration, you choose Virtual Switch in the dropdown list. Vlan should not be set as well.

On the host side, in NIC2 property, IPv4 and other protocol should be automatically unchecked.

The VM starts, and if VMBus drivers are correctly installed on the guest, you should have a plugged and activated network connection.

Once you're there we can go on trying to fix your problem.
LongFistAuthor Commented:
Okay.  Starting from scratch.  I like this.  This way I can figure out what I'm missing - and I'm pretty sure it's something I'm missing.

Host machine has 2 NICs.

Network Connections:
NIC1: Client for Networks, File and Printer Sharing, IPV6, IPV4, Link-Layer Topo Discovery Mapper, and Link-Layer Topo Discovery Responder have been checked/selected.
NIC2: Microsoft Virtual Network Switch Protocol has been checked/selected.

Virtual Networks:
Created a single network [VirConn], selecting [External] and binding it to NIC2.  Nothing else selected, no VLANs enabled/in use.

You mentioned "Interact with os" - this is an option have not yet encountered.  Is there another place where this gets set up?

LongFistAuthor Commented:
Or have I mis-configured things yet again?  So far, I've only looked at Network Connections, HyperV Manager, and HyperV Virtual Network Manager on the Host machine, and File-->Settings-->Network Adapter on the Virtual Machine.  Is there another utility/application/interface that I should pay attention to?

Or am I as hopelessly lost as I think I am?

Thanks again!
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

Interact with os, I meant "allow management operating system to share this network adapter" (see image)

you should not check/uncheck protocols and services bound to the interface, Hyperv will do it for you automatically.

Are we working on 2008 or 2008r2 version of Hyperv ?

There is no other utility, its :
1- create a switch
2- set vm settings to be connected on this switch
3- configure host with good parameters.

You might have an issue with vmbus drivers and your hardware. Now we will add a Legacy emulated NIC in your VM
Shut the VM down, click ADD Driver and select 3rd choice : legacy adapter if my memory is correct.
Connect this adapter to VirConn switch.

Windows Hosted VM will show 2 nics, disable the 1st one and configure the second one. Try to use it and give us feedback if it works better.

LongFistAuthor Commented:
I'm going to assume that I've got 2008 [Hyper-V Manager Ver, 6.0.6002.18005] based on the fact that I don't have the "Allow management operating system to share this network adapter" checkbox on my HyperV Virtual Network Manager.

Okay, I shut down the VM.  In the Network Manager, I added the Legacy Network Adapter, connected it to my [VirConn] connection, then Removed the prior Network Adapter.  Restarted the VM.

Everything seems to start up all right.  Log into the VM.  At the bottom right (SysTray) the Network icon pops up, gives me the "Status: Acquiring network address" mouseover message (and animation), then just continues to "acquire network address" in perpetuity.

So, it would seem that creating a Legacy Network Adapter wasn't the answer.

I realize that this should be pretty straightforward.  I'm not sure what to think, because I was only informed of this issue after it occurred.  Of note: this only started after a disaster recovery operation - this machine was recovered from backup.  Would that cause some issues?  Does Hyper-V networking "break" when restored from a backup?  I mean, it sounds possible, but not very probable.  It's been ten minutes now, and that machine is still fishing for an IP address.  Dunno what to think about this.

The host machine can see the 'net just fine - it recognizes all of the (other) connected machines, and can even access the internet.
Afaik, Hyperv doesnt break anything after a restore. There can still be hidden old devices in the registry, and some might already have an IP configuration
To see these devices and clean the system check here :

There are 2 *obvious* possibilities:

Your physical network isnt registering any mac address to the switch, so your mainboard / nic has a problem.
Your 2008 is an old one and is refusing to acquire an ip from a public network, or there is a firewall policy that blocks dhcp request... anyway turn it down this way:
netsh firewall set opmode disable
netsh firewall set opmode mode=disable profile=all

At last, if you wanna deep farther, you can install wireshark on the Hosted VM and analyze the incoming and outgoing packets. there might be a clue hidden there

LongFistAuthor Commented:
Okay, the problem with the first obvious possibility is that if the NIC had a problem, it wouldn't connect to the network for the host machine.  Since we see that it does, that's right out.  The firewall has never been set up - this particular server doesn't use it because it gets in the way: if we really feel the need, we'll install ZoneAlarm to protect the server, but later.

I have also opted to change the Virtual Switch definition from the second NIC to the first, just to see if it was a hardware issue.  Since each NIC behaved in the same manner as the other - and both serve the host machine perfectly - I can only assume that the hardware is functional.  And I have even performed the Legacy NIC test, with no success.  Bound to either NIC.  So, I'm going to check for hidden old devices in registry, that sort of thing, in accordance with <http://support.microsoft.com/kb/315539/en-us> to see if there might be some cruft hiding out in the registry.

The scary thing about this is that the interfaces are really simple, and yet I seem to have managed to mess something up - I'm not exactly sure how or why - and now my Hyper-V system is deaf/mute.

Thanks for your time and attention: I'm going to go give this a look: I'll report back (either way) with results.
LongFistAuthor Commented:
All right, I'm back, and nothing appears to have changed.

When I go to device manager, as per <http://support.microsoft.com/kb/315539/en-us>, I see nothing that isn't already there.  Maybe this problem lies somewhere outside the Hyper-V strata: I'm not sure what to think.

I gave this machine a thorough once-over, to make sure that everything appeared functional.  And it does, it does.  But - for reasons beyond my explanation, I note that (in the "Network and Sharing Center", the second link appears broken:

     [SERVER] -----> [Network] --X--> [Internet]

...when I click on the red X that appears in the second pathway to diagnose the possible issue, Windows tells me there is nothing wrong.  The machine can see the network, the various and sundry other machines connected to the network, and even the Internet itself, although browsing from a server is totally against Microsoft's best practices.  Windows Firewall is not running, so that's not an issue in this case.

But that's about as far as I can see with this aberrant behavior: The apparent "X" in the link between [Network] and [Internet], and the fact that my VMs cannot see/hear/taste the network at all!  Is there a link between the problems?  I have no idea.  The host machine interfaces to the network without a flaw, so I'm really puzzled, here.

Sharing and Discovery:
     Network Discovery       [GREEN LIGHT] Custom
     File Sharing                   [GREEN LIGHT] On
     Public Folder Sharing    [GREY LIGHT]  Off
     Printer Sharing              [GREY LIGHT] Off (No printers installed)

----- I always thought Network Discovery was either "On" or "Off".  What is this "Custom", and why is there no radio button for such when the drop-down is activated?  Come to think of it, I've never seen this type of behavior before.  In the drop-down, it tells me that "when network discovery is on, this computer can see other network computers and devices and is visible to other network computers", and the radio button to "Turn on network discovery" is un-greyed and available, while the radio button to "Turn off network discovery" is greyed out, with an attention triangle explaining that "To turn off network discovery, you must first enable the Windows Firewall Service".

Could this be the culprit?  Or am I spinning my wheels here?  It just seems that - by Occam's Razor - while my problem may manifest at the Hyper-V/VM/Network Connectivity layer, that the problem may actually exist/persist in a layer "outside" where the actual problem 'becomes' visible.

What do you think?
LongFistAuthor Commented:
Endgame: Updated the hardware drivers to the latest version, and re-defined virtual network settings (because when we removed and replaced the drivers our existing virtual bindings were removed).  The DHCP still failed, but assigning the VM an IP address allowed it to connect properly - so we're not sure if DHCP wouldn't have worked had we given it the DHCP server IP.  But for sure it wasn't performing DHCP IP acquisition correctly.

Technically this was like peeling an onion from the inside.  We started with the VM, reached out to the Virtual Network, then ended up looking at the actual (hardware) NIC for possible solutions.  Now all is resolved, even though it introduces a little more network maintenance down the road (that's why we're trying to keep it all running DHCP).

Well, the CRM server is back up and running, and now we know a lot more than we did before.  Thanks for your help!
Updated the hardware drivers to the latest version,

Indeed, I should have guided you in this direction too, It might be easy to say it now, but for future readers :
Before troubleshooting Hyperv Network issues, Upgrade Drivers, NIC firmwares and network teaming utility.

LongFistAuthor Commented:
Before troubleshooting Hyperv Network issues, Upgrade Drivers, NIC firmwares and network teaming utility.  It'll save a lot of time and headaches.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 7
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now