Configuring Hyper-V virtual networks

Configuring virtual networks in Hyper-V can be achieved using virtual local area network (VLAN) trunks.

Rick VancouverRick Vancouver

In any virtualization environment, networking considerations are one of the most critical aspects and, as a result, require a great deal of planning and testing. If you choose to implement Microsoft's Hyper-V technology, you can use either Hyper-V Manager or Microsoft System Center Virtual Machine Manager (MSCVMM) to manage the Hyper-V host and guest networking.

This article explains how to configure a virtual network for a Hyper-V environment using virtual local area network (VLAN) trunks. I focus partly on the R2 beta release of Windows Server 2008 because some of its native features will appear in the final R2 release of the technology that will ship by late 2009 or 2010.

Virtual network mapping with VLAN trunks

As you plan networks in a virtual environment, the first consideration is which networks will be available to virtual machines (VMs). For Hyper-V, the key to this discussion is the virtual networks that map out the interfaces to provide connectivity to guest VMs. The requisite virtual networks can be configured directly on the host or configured remotely through Hyper-V manager or MSCVMM. Figure 1 shows the network configuration I have constructed:

Figure 1: Click image to enlarge

Hyper-V Manager's primary tool is Virtual Network Manager. In the example in Figure 1, I have named the new virtual network BRIDGE. BRIDGE has been provisioned so it can interact with the guest VMs on the external network that's hosted on the Broadcom interface. The virtual network you create can be configured as an internal network or a private Network Address Translation (NAT) network. The networking configuration is represented as well on the guest VMs. During their provisioning process, guests can select from your created virtual networks.

The configuration of virtual networks identifies the mapping of physical interfaces to the name of a virtual network but doesn't necessarily identify the address space. In all virtual environments, 802.1Q tagged ports, or trunks, are needed to provide access to different networks. A VLAN trunk on the physical switch, such as a Cisco switch, makes multiple networks available through protocols like the VLAN Trunking Protocol (VTP). Doing so identifies various networks simply as numbers.

Hyper-V offers flexibility in assigning VLANs to virtual networks. If you use Hyper-V Manager, the same virtual network can be assigned to multiple VLAN trunks per virtual machine. If you use MSCVMM, the entire virtual network can be provisioned to share the same VLAN trunk. Figure 2 shows a host's interface being prepared to have a network tag (or trunk) assigned to it for all guest connections:

Figure 2: Click image to enlarge

With either management tool, Hyper-V allows the management OS traffic to be stacked on the same interface as the guest VM traffic, while a separate VLAN is assigned to the host OS.

Configuring interfaces with VLAN trunks 

Compared with other virtualization platforms, mapping interfaces to roles in Hyper-V isn't much different; the general approach is the more interfaces the better. Table 1 shows a sample mapping of interfaces and their configurations for a sample Hyper-V environment with VLAN trunks in use:

Interface Speed Role
Local Area Connection 1 1000 Mbps Teamed for host operating systems
Local Area Connection 2 1000 Mbps Teamed for host operating systems
Local Area Connection 3 1000 Mbps Teamed for guests, enable trunks
Local Area Connection 4 1000 Mbps Teamed for guests, enable trunks

Table 1

This is a relatively simple configuration that illustrates that, when possible, guest traffic should be provisioned on separate interfaces rather than on the host operating system. Unique networks, such as a demilitarized zone (or DMZ), however, may require a different approach.

One strategy is to build a dedicated host for VMs on these networks so that they are isolated from the hypervisor. These sensitive networks can also be provisioned as dedicated interfaces not to be shared with other VLAN trunks. This drives the interface count higher but is usually more cost-effective than additional host hardware. Hyper-V also permits guest VM traffic and the host OS to share the same interface, which may be suitable for small environments or those with low consolidation ratios.

Using Hyper-V Integration Services for driver support

Windows Server 2008 has native Hyper-V driver support. Other OSes will need to install Integration Services on the guest OS. For systems managed by MSCVMM, this same functionality is achieved through Virtual Guest Services. Without this driver set, other guest VMs with default configurations cannot view the Hyper-V network.

Hyper-V permits a guest to be assigned to a virtual interface that works with all supported OSes. Hyper-V Manager calls this type of network interface a legacy network adapter, while MSCVMM calls it an emulated network adapter. Both management tools give the same connectivity options provided by virtual networks. Assuming the OS is updated with Virtual Guest Services, the preferred network interface in the guest VM's inventory is the standard networking adapter. MSCVMM refers to this as the synthetic network adapter.

Provisioning guest networks with MAC addresses

When provisioning guest networks, the guest VM is assigned a legacy or emulated virtual interface, depending on whether you use Hyper-V Manager or MSCVMM. Previously, I mentioned that a guest can be assigned to a VLAN trunk for a network as opposed to the entire virtual network being assigned a trunk in MSCVMM. This is particularly true for small implementations where a small number of Hyper-V hosts are involved. In this situation, MSCVMM would be overkill.

In Hyper-V Manager, however, a guest can be assigned to a VLAN and have a Media Access Control (MAC) address configured to it. Figure 3 shows a guest being assigned to a VLAN and accepting the default MAC address configuration:

Figure 3: Click image to enlarge

I would not recommend entering MAC addresses on Hyper-V -- or on any other platform, for that matter -- and using the default network configuration. The default network configuration creates a MAC address that makes the system easily identifiable as a Hyper-V virtual machine. In some physical-to-virtual (P2V) or virtual-to-virtual (V2V) conversion situations, the MAC address may need to be changed, so exercise caution with this practice.

I also mentioned that Windows Server 2008 can function in the native network mode and not use legacy or emulated interfaces. Other OSes such as Windows Server 2003, XP and Vista need a certain patch level before permitting the installation of Integration Services or Virtual Guest Services. Generally the latest major service pack is required for the installation to succeed and allow the guest to access the network without using legacy or emulated adapters.

Resources on configuring Hyper-V virtual networks

With Hyper-V, planning a virtual network becomes tricky when you consider MSCVMM and Hyper-V Manager's corresponding differences and overall functionality within Hyper-V. Luckily, Microsoft has several resources to get you started, such as the Solution Accelerator site on Microsoft TechNet.

Overall, Hyper-V's networking features stack up well against other platforms and can accommodate the majority of environments.

About the author:
Rick Vanover (MCITP, MCTS, MCSA) is a systems administrator for Safelite AutoGlass in Columbus, Ohio. Vanover has more than 12 years of IT experience and focuses on virtualization, Windows-based server administration and system hardware.

And check out our Server Virtualization blog.

Dig Deeper on Microsoft Hyper-V and Virtual Server