Hyper-V Error: Error Applying New Virtual Network Changes - Cannot bind to because it is already bound to another virtual network.

Error Applying New Virtual Network Changes

Cannot bind to because it is already bound to another virtual network.

What is this error? What solutions do we have to solve this error in Windows 2008 R2 FULL installation and Core edition?

This error generally means that the “Microsoft Virtual Network Switch Adapter” is selected/in use by the physical NIC that you’re trying to use to configure your new Hyper-V virtual switch (vswitch). There’re many different reasons why this protocol may be selected, the most common are:

1. 
   
   Because in fact you do have and vswitch assigned to that physical card, and before you use that NIC to add a new vswitch you need to unbound it from the existing vswitch to add the new one.
   
   
   
2. 
   
   You manually selected the “Microsoft Virtual Network Switch Adapter” under your NIC properties (Note: do not try to select Microsoft Virtual Network Switch Adapter as an attempt to bind that NIC to a existent vswitch or to create a new one, instead always use the hyper-v management console or the System Center Virtual Machine to create new vswitch, the same is true for existing vswitchs, DO NOT select this protocol on NICs that REPRESENT the VSwitch, remember only the physical NIC that HAS A VSWITCH bound should have this protocol selected).
   
   
   
3. 
   
   You installed software to manage your NICs or Teams and now you’re having weird errors (as described in another post for HP servers) and when you attempt to repeat the process you get this error.
   
   
   

These are the most common ones.

How to solve this problem:

Note: Before proceed I suggest that you do a full backup of the system that you’re trying to repair, some procedures explained here will change configurations and some registry settings that may break other functionalities. Before removing any vswitch, make sure that you don’t have virtual machines assigned to it, if so, you’ll need to reconfigure those VMs to a new vswitch before those VMS be able to get network communications again, also be careful when unbinding the “Microsoft Virtual Network Switch Adapter” from a given physical NIC, if that physical NIC is associated with a vswitch and you remove the “Microsoft Virtual Network Switch Adapter” from it, the vswitch will not be able to function properly.

That said, let’s begin.

Identify if an existing vswitch is bound to the NIC that you’re trying use, if you already have a vswitch assigned to that physical NIC you need to use a different physical NIC to configure the new vswitch or unbound the existing vswitch before configuring the new one.

1 - First let’s identify the NIC GUID that is having problems. Open command prompt and type:

WMIC NICCONFIG GET Description,SettingID

The result will be something similar to this

In my scenario the GUID for the NIC is {F9A4CE20-59D1-4C64-BA39-6487862361A4}.

Note: The GUID will differ in your server.

2 - Using the Hyper-V Manager console (in core editions use the Hyper-V manager console to remotely connect to the physical host): Connect to the host that you’re trying to create the new vswitch, then in the right pane select the option “Virtual Network Manager”, after that a new window appears and will allow you to identify if the physical NIC is already in use by an existing vswitch.

3 - I don’t have any vswitch configured to use the physical NIC but I still get the error: In this scenario check if the “Microsoft Virtual Network Switch Adapter” is selected in the NIC that you’re using to configure your new Hyper-V virtual switch, from cmd type “ncpa.cpl”, this will open the network connections folder, right click in the NIC and check if the “Microsoft Virtual Network Switch Adapter” is selected, if it’s then unselect it and try again.

3.a - Unfortunately this is not an option in Core Installations, in Core installations you’ll need to use a tool called “nvspbind”. Download the tool to “c:\windows\system32” directory and from cmd type

“nvspbind.exe -n”

This will display NIC information, identify the NIC GUID (check step 1) and to remove the Microsoft Virtual Network Switch Adapter from it type “nvspbind.exe –u {GUID}” in this case would be:

“nvspbind.exe -u {F9A4CE20-59D1-4C64-BA39-6487862361A4}”

Ok ENIAC, nice tips but I still have the problem, what to do next??!!!

In some scenarios things can get pretty ugly and the previous tips may not be enough to solve this error, if that is your case take a deep breath and let’s continue…

Let’s try some global cleanup process. (Did you read the Note that I wrote at the beginning of solution process in this post? NO!!!! Now is a good time to go there and read it, it talks about backups and other things that you may want to be aware of).

The first one is to use a tool called “nvspscrub.js”. Download nvspscrub.js then from cmd run: “cscript nvspscrub.js”, this will delete all vswitches, virtual NICs in the parent partition and will unbind the switch protocol from all physical NICs.

Run the tool, reboot the server and try again…

If the “nvspscrub.js” didn't work for you then you can try the last resource tool. The netcfg tool (use this procedure as last resource only). You can use this tool to install/uninstall Network Protocols, services and clients. From cmd type:

netcfg -u vms_pp

This will uninstall switch protocol and will remove it from all your NICs as well.
Reboot the server then from cmd type:

netcfg -l c:\windows\winsxs\amd64_wvms_pp.inf_31bf3856ad364e35_6.1.7600.16385_none_beda85050b13680c\wvms_pp.inf -c p -i vms_pp

This will install the protocol again and make it available to use on the NICs but by default will disabled in all NICs.

Reboot the server and try again…

To end this blog entry, and especially because this can be useful in core installations, I will show you some registry entries that may help you to identify where the NICs are their configuration, vswitches and NICs associated, etc... I suggest that DO NOT use the registry to remove or change any configuration mentioned before, instead use the tools or the cmds provided in the previous steps.

The first one is the:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}

Under this path you can find all your existing NIC adapters, the Microsoft Virtual Network Switch Adapter (vms_mp), etc… Scrolling down to the numbers listed under this path you’ll find the interfaces that exist in your server and some properties associated with it. You can also find some configuration definitions, like bounded protocols, GUIDs, file driver path, etc (Note: these numbers will differ from server to server).

Under 007\ you can find some interesting information about the physical NIC that I repaired in previous steps. Here I can identify some useful information like DriverDescription, Version, InfoPath, GUID, etc…

 Under 007\Linkage, I can find what protocols are bound to this interface:

If the physical NIC had a vswitch associated with it, only “VMSP” would be listed like this.

The next registry path that you may want to know about it is the:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMSMP
and
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMSP

Here you’ll find information about listed physical NICs in use, Virtual Switches and some properties. For example, when you are using a given physical NIC with vswitch, the physical NIC GUID should be listed under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMSP\Linkage\

“Bind” & “Export” & “Route” as the picture shows, additionally that same NIC GUID will also appear in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMSMP\Parameters\NicList\/DEVICE/{GUID}

Also note the difference between how a physical NIC (starts with /DEVICE/{GUID}) is listed under NicList and how a vswitch (starts with GUID) is listed in the same path.

Hopefully this blog entry will help you to resolve the error “Cannot bind to because it is already bound to another virtual network.” and also help you to identify where some connections properties and vswitches definitions are stored using the registry which can useful when using windows core installations.

nvspbind can be found here
nvspscrub can be found here

Have Fun!!!