I’ve been struggling on and off with what I thought was a bug in Hyper-V on my production desktop since the end of February. That’s when I cut over from my old production PC to a new one, built around an Asrock Extreme7+ mobo. So far, that system’s been great. It’s faster, more stable, and runs significantly cooler than the system it replaced. There has been one chronic issue, however. Until yesterday, I’d been unable to get a virtual switch set up and working with Hyper-V on that machine. All along, I was convinced I was fighting a Hyper-V bug of some kind. But now I know that this apparent Hyper-V vSwitch set-up snafu was entirely of my own making. Let me explain…
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Symptoms for My Hyper-V vSwitch Set-up Snafu
Now that I understand what I was doing wrong, I can see everything I always needed to know in the Network Connections screen from Control Panel. It shows that Ethernet2 is unplugged. That’s absolutely accurate and correct, because the Asrock Extreme7+ includes not one, but two built-in GbE Ethernet ports. One is for an Intel I211 devices, the other is for an Intel I219-V device. On my PC, I’ve only got one port connected to my office (physical) switch — namely, the I211.
The red X’s indicate that the I219 is unplugged, and so is the “Broken Switch.” Turns out they’re directly connected…or not!
Until I tackled the excellent Hyper-V Tutorial by my co-author and occasional collaborator Kari the Finn at TenForums, I didn’t snap to what was going on with my vSwitch set-up. It seems that virtual switch set-up in Hyper-V Manager picks the network interface to use for the “External Network” setting according to some logic of its own. I can tell that logic is neither the ASCII collating sequence (where I211 comes ahead of I219) or “connected vs. disconnected” (where I211 is attached to a network, and I219 is not).
For whatever reason, the “wrong” — that is, disconnected — NIC shows up in the top position in the pick list for the external network connection. I simply hadn’t paid close enough attention to realize I needed to scroll down to the second (but invisible) entry in the two-item pick list to make the proper selection. And of course, any virtual switch that gets bound to a disconnected NIC can’t help but be disconnected as well. Doh!
Fixing My Hyper-V vSwitch Set-up Snafu
And of course, once I systematically worked through the tutorial, I also looked more closely at all the set-up and configuration screens. That’s when I saw that my problem stemmed from my erroneous selection of the disconnected NIC instead of the other, connected one. As soon as I made the proper selection, everything worked like a charm. Ever since, I’ve been setting up and using a couple of new Windows 10 CU VMs. One is for playing with and experimenting, so I can protect myself from unwanted side-effects of grabbing and using all kinds of random software and utilities. The other is a licensed Windows 10 development environment VM that includes a raft of features documented in the Windows Dev Center’s “VM Downloads” page.
It just goes to show you that little things, like my oversight, can stymie progress just as effectively as problems that genuinely come from bugs. I now understand that my earlier experience with Hyper-V had always been on PCs with a single Ethernet NIC, so I was insulated from paying attention to picking the right one. When there’s only one NIC, it can’t help but be the right NIC to get you to your LAN. But when there’s more than one to choose from, you MUST pick one that’s connected. Sigh.