Hyper-V has had the ability to use virtual switch extensions for quite some time, but this capability is often...
overlooked. Even so, virtual switch extensions do have their place. This article will discuss what Hyper-V virtual switch extensions are and how they can be used.
Before I talk about what virtual switch extensions are used for, I want to take a moment to show you how they are exposed through the operating system. Windows Server 2012 R2 includes three built-in virtual switch extensions, two of which are enabled by default. You can access the virtual switch extensions by opening the Hyper-V Manager, right clicking on a Hyper-V server, and selecting the Virtual Switch Manager command from the shortcut menu. When the Virtual Switch Manager opens, expand the container representing your virtual switch and then click on the underlying Extensions container. Upon doing so, you will see the available extensions for the selected virtual switch, as shown in Figure A.
As you can see in the figure above, the Virtual Switch Manager can be used to enable or disable virtual switch extensions on a per host per virtual switch basis. You might also notice in the figure that there is no option to add additional virtual switch extensions. In order to understand why this is the case, you need to know a little bit about what virtual switch extensions do.
As you might have already guessed, virtual switch extensions allow you to augment a virtual switch's capabilities by adding modules -- extensions -- that add functionality to the virtual switch. This probably isn't something you would do yourself, but there are many software vendors which use virtual switch extensions as a way of enabling functionality within their products.
Reasons for extending a virtual switch
So why extend the virtual switch? Why not just replace the default virtual switch with a vendor supplied virtual switch? There are at least three good reasons why it is better to use virtual switch extensions than to use vendor specific virtual switches.
The first reason has to do with general supportability. Imagine, for a moment, that you begin experiencing some sort of problem with your Hyper-V server, so you call Microsoft for technical assistance. If the server were running some sort of third-party product that replaces the Hyper-V virtual switch with a vendor specific virtual switch, then it is conceivable that Microsoft could blame the problem on the virtual switch without providing any sort of real solution to the problem. After all, from Microsoft's perspective, replacing the Hyper-V virtual switch with a third-party virtual switch puts the server into an unsupported state. Even if no problems ever occur, you should never operate a production hypervisor in an unsupported state.
Looking at this issue another way, imagine that you experience problems with a Hyper-V server that contains a third-party virtual switch extension. Having the extension installed on your server means, like replacing the virtual switch with a third-party virtual switch, you will have third-party code running on your hypervisor. From a troubleshooting standpoint, the advantage to using virtual switch extensions rather than third-party virtual switches is that virtual switch extensions can be enabled or disabled on an as needed basis. This should make the troubleshooting process easier.
Another reason why it is a good idea to use virtual switch extensions rather than third-party virtual switches is because using third-party virtual switches can cause complications with clustered Hyper-V deployments. In order for Hyper-V servers to function in a cluster, each host server must contain an identical virtual switch. Depending on how a third-party product implements a custom virtual switch, it may or may not be cluster compliant. Conversely, host servers using virtual switch extensions continue to use the native Hyper-V virtual switch, which is guaranteed to be compatible with the Windows Failover Clustering Feature.
The third, and most important, reason why it is better to use virtual switch extensions than to use third-party virtual switches is because you may need to run multiple third-party products that each have virtual switch requirements. Since each virtual network connection is limited to using a single virtual switch, there is no easy way to use multiple vendors' virtual switches on a single host. Virtual switch extensions solve this problem nicely. As you saw in the figure, multiple extensions can be associated with a single virtual switch.
Virtual switch extensions make it easy for vendors to extend the functionality of a virtual switch. Perhaps the best thing about virtual switch extensions is they allow an organization to add virtual switch intelligence without requiring major architectural changes to the existing virtual switch topology.
Security options for Hyper-V virtual switches
Create a virtual switch strategy for your network
Using virtual switching to integrate networks