In-Depth

Hyper-V Private vs. Internal Virtual Switches: Which to Choose?

Here's how to choose the right switch type for your environment.

If you have ever had to create a virtual switch for Hyper-V that is not an external switch, you may have had to stop and think about it. Do you want to go Private or do you want to go Internal? Let's summarize the differences here so you know the pros and cons of each type, and if you ever need to do anything more; that you don't lock yourself in too much. This section of the new virtual switch wizard can cause some guesswork, as well as some misconfigurations, shown below:

[Click on image for larger view.]  Figure 1.  Internal or Private, that is the question!

By way of definition, the Hyper-V Private switch allows VMs to communicate to each other ONLY when they are on the same host. The Private virtual switch cannot communicate to any network outside of the host either. If you select a Private virtual switch, it still allows you to give it a name; I wish it would just call it "Private Virtual Switch for (Computername)" -- or maybe "Private Virtual Switch 1 for (Computername)". If I add a name to the switch, I run the risk of getting confused later on, so that request is somewhat self-serving.  My own forgetfulness aside, it is important to note the Private virtual switch can communicate to other VMs on one host only. They can't connect to any outside network unless the VM(s) in question are connected to additional virtual switches (such as one Private and one external). A host can have multiple Private switches and the same Private switch name can exist on multiple hosts, not to confuse you or anything.

The Hyper-V Internal switch is a bit different in that the VMs on the switch can communicate to each other, but additionally can communicate to the Hyper-V host itself. This can commonly be used as a file exchange mechanism. The internal switch for the most part functions the same as the Private switch, with the added ability to communicate directly to the Hyper-V host.

It is important to note that both the Internal and Private switch types are not bound to a physical network interface. As such, there is "authoritative" network addressing scheme that is set by the host. In the case of the Private virtual switch, the host has no real concern what happens on the virtual switch. This means that the networking (IP addressing) needs to be set by the VMs on the Private network.

The Internal network is slightly different however. Because there is communication with the Hyper-V host, a network interface is added to the host. I added an Internal network called "TEST-InternalPrivateNetwork" to a Windows Server 2012 Hyper-V host. Once that that step was completed, you can see a new interface is added to the host below:

[Click on image for larger view.]  Figure 2. Each internal virtual switch would create it's own host interface; and networking

Note that with the Internal virtual switch, that interface has its own IP and DNS configuration.

So back to the question, which one should I use? Well, if you need isolated VM connectivity, the Internal switch type has slightly more flexibility. But you run the risk of networking going awry. I'm a purist in the sense that I want host networking rock solid. I'm slightly worried of having an Internal Private switch and then the associated host networking go awry (Or event DNS/default gateway) then all management traffic may not function as expected. See the concern here?

If you need a recommendation, I'd point you down the Private virtual switch route; and if you need limited interaction use .ISO file mounts or an additional VM with multiple network interfaces (including one on an external switch).

How do you do isolated networking with the hosts? Private, external, or neither? Share your comments below.

About the Author

Rick Vanover (vExpert, VCP, MCITP) is a product strategy specialist for Veeam Software based in Columbus, Ohio. Rick is a popular blogger, podcaster and active member of the virtualization community. Rick's IT experience includes system administration and IT management; with virtualization being the central theme of his career recently. Follow Rick on Twitter @RickVanover.

comments powered by Disqus

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.