Hyper-V Private Cloud Networking for Beginners – Virtual Networks

Introduction

Just in case you didn’t get the memo: Microsoft is “all in” when it comes to cloud computing. I’ve written a bit about cloud computing before on this site and will do so more in the future. Most analysts think Microsoft has made the right decision to go “all in” with the cloud, in part because the nature of the service delivery business is changing from an IT driven one to a consumer driven one. Add to that what we’re seeing in terms of trends toward “ubiquitous” computing, and the writing on the wall becomes clear; the PC revolution is winding to an end and it’s time to introduce yourself to the new boss.

While that day is certainly coming, it isn’t all going to happen this week. The journey to the cloud is going to take time. And before we all become consumers of “utility computing” in the public cloud, there are going to be plenty of private clouds floating around out there. In fact, the vision of “computing utilities” (of which Microsoft hopes to be a major provider) will likely never be complete because our laws, regulations, corporate policies and personal peccadillos will prevent everyone from going “all in” with a public cloud.

Private clouds are actually pretty cool. They provide you with most of the benefits you get from a public cloud with a big difference: you control the solution from layer 1 (physical) to layer 8 (political or psychiatric – the “human factor”). While there are a number of elements that define a private cloud, one thing that is common to all private cloud deployments is virtualization. That means if you want in on the private cloud, you’re going to need to have some knowledge of virtualization, and if you want to get on top of the Microsoft private cloud, that means you’ll need to know something about Hyper-V.

Tom and I cut our virtualization teeth on VMware products. Thus, in the beginning I was somewhat skeptical of Hyper-V. Sure, I had heard good things about it, and some of my friends said they actually preferred it to VMware. I found that hard to believe, but I’m an open minded kind of gal so I thought I’d give Hyper-V a chance. Well, it turned out that my friends were right, and willingness to try new things paid off! I love Hyper-V now and consider myself a convert. Not that VMware is a slouch – because it’s not. I just find that I like working with Hyper-V more. I especially like its interface, the Hyper-V Manager.

For the most part I found Hyper-V to be pretty intuitive and didn’t experience much of a learning curve. However, one thing I didn’t grok immediately was how Hyper-V virtual networks worked. I was accustomed to the VMware approach to virtual networking, and so making the transition to the way that Microsoft does it took a little rethinking. It’s not hard to understand, but if you’re coming from a VMware world, you need to know a couple of things to get up and running.

Varieties of Hyper-V Virtual Networks and NICs

First the good news: Hyper-V virtual networks are virtual “switches”, which is very similar to the way VMware handles virtual networking. There are three types of virtual networking you can create with Hyper-V:

• External Virtual Networks. External virtual networks can be connected to the live production network. Virtual machines that are connected to an external virtual network can contact each other and the host operating system if they are all connected to the same physical network through one or more External virtual networks.
• Internal Virtual Networks. An Internal virtual network enables virtual machines to communicate with each other and with the host operating system. You can use these when you want to isolate the virtual machines from a production network, such as when you’re doing testing, or when you want to allow controlled access to the live network, such as when you put a virtual firewall in, which has a leg in the Internal virtual network and a leg on an External virtual network. The VMs can also communicate with the host operating system, which allows you to transfer files between the host operating system and the virtual machines.
• Private Virtual Networks. A Private virtual network is similar to an Internal virtual network, except that the virtual machines cannot communicate with the host operating system and the host operating system cannot communicate with the virtual machines. Use Private virtual networks when you want to make sure that no VM can “break out” of the virtual environment and communicate with other machines on the network, including the host operating system. If you want to transfer files to the VMs on a Private virtual network, you’ll need to find an alternative method, such as creating and mounting an .iso file, or use a multi-homed virtual machine that enables the virtual machines on the Private virtual network to contact hosts on an External network (i.e., hosts on a production or “live” network).

Note that Hyper-V doesn’t support wireless networks, which sort of sucks. I’m hoping this will be fixed at some point in the future.

There are also two types of virtual adapters that you can create:

• A “normal” NIC. I have to note here that this isn’t the official term for this type of virtual NIC. I could have called it “the non-legacy” NIC. This is the higher performing of the two types of virtual NICs that you can create. This NIC is available to operating systems that support Hyper-V integration services, which means only Microsoft operating systems.
• A “legacy” NIC. A legacy NIC is lower performing than the non-legacy NIC, but it will work for any operating system, or even when there is no operating system, such as when you want to perform a PXE boot.

And although it’s annoying that you can’t use wireless networking with Hyper-V virtual networks, you can assign your External virtual networks VLAN IDs. In fact, you should only assign VLAN IDs to virtual NICs and not to your physical NICs.

How External Networks Give the Impression that Your NICs are Horked

I remember the first time I installed the Hyper-V role on a Windows 2008 computer. After the role was installed, I opened up the Network Connections folder and couldn’t figure out what had happened to my NICs! The NIC I thought I was using to connect to the network had all of its IP addressing information removed, and there was a new NIC there with a new name and I couldn’t figure out how that new NIC got there and what it was doing there.

What happens is that when you install the Hyper-V role, a virtual NIC is created on the host operating system. Then Hyper-V binds all the typical services you’re used to seeing on a physical NIC to the virtual NIC, which is configured as an External network adapter. Then it changes the physical NIC by removing all the services bound to that NIC, except for the Virtual Network Service Protocol.

You can see an example of what happens in Figure 1 below. The NIC labeled Intel P1 is a physical NIC. After installing the Hyper-V role on this server, a new NIC was created, which had the name Local Area Connection 5. Notice in the description of the virtual NIC that it takes the name you give it when you configure the External Network in the Hyper-V console.

Figure 1

In Figure 2 below, you can see that the original NIC has had all the services unbound from the NIC except for the Microsoft Virtual Network Switch Protocol.

Figure 2

In Figure 3, you can see that all the services that were previously bound to the physical NIC are now bound to the new External virtual network adapter.

Figure 3

If you open the Virtual Network Manager from the Hyper-V console, you can see that the External virtual network adapter’s description, as seen in the Network Connections window, is taken from whatever you entered in the Name text box for that virtual network, as seen in Figure 4.

Figure 4

It’s a good idea to have at least two NICs in a Hyper-V server. You need one that can be used by the virtual machines to connect to the live network  and one that you can use to connect to the host operating system. While you can connect to the host operating system through the External virtual network adapter from anywhere on a live or production network, those communications are going through the virtual switch, along with all the traffic to and from the VMs that might be using that virtual switch.

Using Virtual Networks with Virtual Machines

Assigning a virtual machine to a virtual NIC/network is very easy. Open the Hyper-V manager and then right click the virtual machine you want to connect to a specific network and click Settings. You’ll see the Settings for dialog box/page, as seen in Figure 5. On the left side of the dialog box, click the Network Adapter entry. On the right side of the page, you’ll see a Network drop down list box. Click the down arrow and you’ll see the list of virtual networks you’ve created on the Hyper-V server. Just click on the virtual network to which you want to attach the virtual machine, and it will connect to that network. The behavior of the virtual machine is similar to what you would see on a physical machine that is unplugged from a network and then plugged into a new one.

Figure 5

Also note, as seen in Figure 6, that you can choose between Dynamic  andStatic MAC addresses. The default configuration is to use a Dynamic MAC address. The Dynamic addresses are obtained from a pool of MAC addresses that were created when the Hyper-V role was installed. You can find the starting and ending MAC addresses created in the Registry at HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization. The keys are MinimumMacAddress and MaximumMacAddress.

Note that if you change the MAC addresses in the pool, it will not change the MAC addresses that are currently assigned to the existing virtual machines.

Figure 6

Also, if you just want to change the range, you don’t have to go into the Registry. Open the Virtual Network Manager from the Hyper-V console and click the MAC Address Range entry on the bottom left of the dialog box, as seen in Figure 7. There you can adjust your MAC address pool, which by default contains 256 entries.

Figure 7

Summary

In this article, we began with a short discussion about cloud computing and how the path to the public cloud will probably include a visit to the private cloud first (if you don’t end up staying there). We then went over the types of virtual networks and virtual adapters that are available with Hyper-V, then talked about what happens to your physical NIC configuration when you install the Hyper-V role. We then finished up by demonstrating how you bind a virtual network to a particular virtual machine. In the second part of this series, we’ll look at some of the details of how to configure virtual networks and examine some scenarios where you would use different types of virtual networks, and we’ll discuss how virtual networking should be approach in the private cloud.