Save to My DOJO
Table of contents
In the previous part of this series, we looked at poorly performing virtual switches. In this part, we’ll look at ways to troubleshoot virtual switches that don’t work at all.
Usually, a switch that doesn’t work at all is the result of a configuration error. The number one way to cause switch failure at creation is to use Hyper-V Manager from a remote computer to create a switch on the same physical adapter that the Hyper-V host is using to connect to the network (2008 R2 and prior). This causes a network disconnect that prevents the tool from finishing the creation process, leaving it in a state in which the switch isn’t created but the host can no longer use it is as a regular network connection, either.
The Easy Way
If possible, use Hyper-V Manager to remove the switch and start over. On 2012, try the Remove-VMSwitch cmdlet. Sometimes, it’s just that easy.
The Hard Way
On a GUI system, you’ll find that the physical adapter is bound to an item called the “Hyper-V Extensible Virtual Switch” and that this item cannot be unchecked. The system will allow it to be uninstalled. If you choose this approach, you can re-add it by clicking “Install” and choosing “Protocol”. This will also remove any switches, including any invalid ones.
NVSPBind
On a non-GUI system, repairing the switch will require a little more effort. Fortunately, there are some tools to help out. First among these is NVSPBIND. This tool gives you access to the bindings in a similar fashion to the GUI tool. It’s not an installable tool; the file you download is a self-extracting archive. When you run it, you’ll give it a target folder. Among the three extracted files is “nvspbind.exe”, which is the tool you’re looking for.
If you run just NVSPIND.EXE with no switches, it will dump a list of all adapters and the protocols that are bound to them. We’re not here for a list, though. We’re here to fix an adapter. You can scroll through the entire list looking for the adapter in question, or you can narrow it down to only the ones with the virtual switch bound to it. What you want first is the actual name of the adapter you’re working on. To find it quickly:
nvspbind /o * vms_pp
A sample output follows:
C:\temp\nvspbind>nvspbind /o * vms_pp Hyper-V Network VSP Bind Application 6.1.7725.0. Copyright (c) Microsoft Corporation. All rights reserved. Protocols: {D593BAC8-3585-4CFF-AFC5-C179BEF3AC3A} "vms_pp" "Hyper-V Extensible Virtual Switch": disabled: Ethernet 2 disabled: Local Area Connection* 9 enabled: Ethernet cleaning up...finished (0)
From the above, “Ethernet” is the name of the adapter we need. Now, we need that adapter’s GUID. Feed it back through NVSPBIND with the /n switch:
nvspbind /n "Ethernet"
The quotes in the above aren’t strictly necessary since it’s only one word, but you’ll need those quotes if your adapter has more. The output has the ID we need:
C:\temp\nvspbind>nvspbind /n "Ethernet" Hyper-V Network VSP Bind Application 6.1.7725.0. Copyright (c) Microsoft Corporation. All rights reserved. Adapters: {E868A1F0-A435-4421-BB97-AB506F336419} "pci\ven_8086&dev_10d3" "Intel(R) 82574L Gigabit Network Connection" "Ethernet": cleaning up...finished (0)
Our adapter’s ID is {E868A1F0-A435-4421-BB97-AB506F336419}. Just feed it back into NVSPBIND with the /u switch:
NVSPBIND.EXE /u {E868A1F0-A435-4421-BB97-AB506F336419}
If all is well, the virtual switch protocol will be disabled and all others will be enabled. You should now be able to use the adapter as desired.
NVSPSCRUB
If the above did not clear your issue, the next tool available to you is NVSPSCRUB. (February 18, 2015: Microsoft has removed the archive. The link now points to a personal blog for someone that has copied the contents and made it available online). There is an Unblock button on its properties sheet in Windows Explorer, or you can use the Unblock-File PowerShell cmdlet. This utility is much easier to use than NVSPBIND. If you’re trying to fix a broken switch and NVSPIND didn’t help, run:
CSCRIPT NVSPSCRUB.JS /P
You can also use it with /V if you want to clean out any virtual adapters that are no longer functional. The difference between this tool and NVSPBIND is that NVSPBIND will return the adapter to the condition it was in prior to the virtual switch being bound to it, which generally means that it will rebind it to TCP/IP and the Microsoft networking services. NVSPSCRUB will leave it unbound from everything.
NETCFG
NETCFG.EXE is a generic tool built-in to Windows. Its purpose is the installation and uninstallation of protocols, services, and clients on adapters. Start with the uninstallation:
NETCFG -u vms_pp
Restart the system.
After it reboots, enter the following, depending on the system:
2008 R2 RTM:
NETCFG –L C:\Windows\winsxs\amd64_wvms_pp.inf_31bf3856ad364e35_6.1.7600.16385_none_beda85050b13680c\wvms_pp.inf -C P -I vms_pp
2008 R2 SP1:
NETCFG –L C:\Windows\winsxs\amd64_wvms_pp.inf_31bf3856ad364e35_6.1.7601.17514_none_c10b98cd0801eba6\wvms_pp.inf -C P -I vms_pp
2012 and Windows 8:
NETCFG –L C:\Windows\winsxs\amd64_wvms_pp.inf_31bf3856ad364e35_6.2.9200.16384_none_bbaf3ac27b26975c\wvms_pp.inf -C P -I vms_pp
2012 R2 and Windows 8.1
Note: These operating systems have multiple folders with the wvms_pp.inf driver. The text below references the most current version as of December 18th, 2014. When typing this line, press [TAB] after C:\Windows\winsxs\amd64_wvms_pp.inf and cycle through until you find the folder with the highest version number. Proceed from there.
NETCFG –L C:\Windows\winsxs\amd64_wvms_pp.inf_31bf3856ad364e35_6.3.9600.17136_none_53dbe904c52f2e25\wvms_pp.inf -C P -I vms_pp
Restart the system again, and the protocol will have been removed from all adapters.
Follow-Up
All of the above has been intended to reset the system so that you can try to create a functional switch. Make sure you understand how the switch works. If you’re going to create it on the primary adapter for the host, you must use the “Share” option or the host will be unable to communicate. If the host has another primary connection, do not use the “Share” option.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
16 thoughts on "Troubleshooting the Hyper-V Virtual Switch – Part 2"
Hi Eric,
Great content but I’ve got something different I’m hoping you can help me with. I have a virtual switch on a host that has lost it’s NIC altogether. I’m unable to remove the virtual switch either from VMM or Powershell. Have you any ideas how I can remove it. Below is the powershell output:
Remove-VSwitch : Failed while removing virtual Ethernet switch.
Failed to connect Ethernet switch port (switch name =
’19C995FD-3E13-4ACB-967C-4B77D3DF8935′, port name =
‘359B5EEC-6279-4EB4-86F0-94736F93E289’, adapter GUID =
‘{01DA4A52-CC56-4785-A436-828AB3F3807D}’): The system cannot find file specified. (0x80070002).
Ethernet port ‘{01DA4A52-CC56-4785-A436-828AB3F3807D}’ unbind failed: No more data available. (0x80070103).
Also and aside from the above, when I check Hardware | Network Adapters, I still have a NIC with it’s logical network associated to a now deleted uplink port profile! How do I disassociated it?
Any help clearing either or both of these two issue would be appreciated.
Thanks.
Nigel
Hi Nigel,
Have you tried the above? The information in this post is specifically intended to provide assistance when PowerShell and Hyper-V Manager do not work.
Hi Eric,
The problem I have isn’t that I have a NIC that needs to be unbound. I have a vswitch on a host without a NIC that I can’t remove. Any ideas?
I understand that. But even switches that aren’t bound to a physical adapter still have to follow all these rules. I expect that NVSPBIND won’t do a lot for you, but the other two might. But, they might not. If I could duplicate your issue I’d try it.
Hi Eric,
I bow to your superior knowledge. The javascript did the job with the /p. Thanks.
Ha! No bowing, please. It gives me fathead disease.
Glad you got it fixed!
Ok, nearly there. I still have an uplink port profile set that is associated to a NIC that I can’t unassociate, as the profile has previously been removed. Any idea how I might unassociate the NIC from the now deleted port profile?
I’m still at minimal competence level in SCVMM 2012. Usually I have to fix stuff like that by dipping into the database. How’s your SQL?
Very rusty, but I get by. I used to be software developer so I can man handle T-SQL. Any idea where to start. Have you a schema for the DB?
I usually just drop right into it. Of course, I always make a backup and work on that. Well, usually. OK, occasionally.
I’m looking at these tables:
[VirtualManagerDB].[dbo].[tbl_NetMan_UplinkPortProfile]
[VirtualManagerDB].[dbo].[tbl_ADHC_HostNetworkAdapter]
[VirtualManagerDB].[dbo].[tbl_NetMan_LogicalSwitch]
Maybe:
[VirtualManagerDB].[dbo].[tbl_NetMan_VirtualNicPortProfile]
The foreign keys can usually help you track back to what you need.
Thanks the info. The wife’s giving me THAT look now as I promised her I’d take he out. I’ll take a look over the weekend. Thanks again for your time on this.
I was having a similar problem as the one in this article. My problem was that I was trying to add a NIC to a team. However, because the “Hyper-V Extensible Switch” protocol couldn’t be disabled I was unable to do that. This particular NIC was previously disabled, so I know it wasn’t being used. It also wasn’t attached to any virtual switches. I just uninstalled the faulty NIC in the device manager, and reinstalled it. After that I was able to add the NIC to the team like I was initially trying to.
I think the problem with the Manager (10.0.1) is that it has the switch seperate from the configuration then after you use the switch the network does appear in the config. The reason this is an issue is that if you remove the adapter using the switch manager and it messes up like mine did then you end up with nothing in the switch manager but there is still a reference to the network in the settings but as you did not make it there you may not think to look there.
Anyway. I had the error stating that the VM could not be started as the network adaptor ‘myVMNetworkAdapter’ was missing. I had just deleted it so I panicked and thought I had well and truly messed it up and when I tried to make a new adaptor using the Switch Manager, this issue still existed. Eventually I went in to settigns and found the network section that is there and opening it I could see the configuration error. As I had created a new adaptor in Switch manager I was able to select it.
If I had not already created the new adaptor in Switch Manager then I might have been even more confused as in the setting.network section I would not have had the option to switch to a new network adaptor. There is another option in there which is “No network” and that might have helped to get the machine running – i don’t know because I didn’t do that.
So the fix is to delete the Switch, create a new Switch and use that but its not clear that you need to use settings.network to do this.
Thankfully your excellent and informative post did help point me in the right direction.
Thanks
David
If you have a virtual adapter on a virtual machine that was connected to a virtual switch that was deleted while the VM’s virtual network adapter was still attached, the problem is that the virtual adapter’s referenced connecting object is gone. This will be true even if you recreate a virtual switch with the same name as the deleted switch. Just setting the VM’s virtual adapter to Disconnected will clear the missing reference object and allow the VM to start. Virtual adapters for VMs cannot be managed in Switch Manager because they are part of the VM, not the host or the switch.
Excellent post. I lost connectivity so I connected directly to the server remote console.
I ran the PowerShell cmdlet:
Get-VMSwitch
Remove-VMSwitch “Name of Switch”
1 of them was in use so I had to stop running VMs:
Get-VM
then Get-VM | Stop-VM
Some could not be stopped for some reason so I then typed:
Get-VM | Stop-VM -Force
This worked for me on Hyper-V Server 2019 and when i had the issue on Hyper-V Server 2016 in the last i did the same thing but also had to follow the NVSPBIND process described above.