In most IT environments, there are different types of networks, different ways the networks are used, and different types of connectivity for the different hosts. System Center Virtual Machine Manager (VMM) 2012 R2 provides the various architectural components (e.g., port profiles, logical networks, logical switches, virtual networks) to enable even highly complex network environments to be configured, which simplifies future administration. However, the initial networking configuration can be confusing. So, I’ll walk you through all the VMM networking architectural components and how to use them. This walkthrough assumes that you’re already familiar with Hyper-V networking basics, such as the types of virtual switches.
Most organizations have different types of networks such as a corporate network, management network, demilitarized zone (DMZ), Internet network, backup network, and testing network. The different networks might be separated physically or separated using networking concepts such as Virtual LAN (VLAN), Private VLAN (PVLAN), and network virtualization. Each of these networks is defined inside VMM as a logical network, which is the primary building block to help model your physical network infrastructure and connectivity.
In addition, an organization might have different physical locations or data centers. In this situation, VMM lets you define a logical network that includes details about the sites it exists at, along with the configuration required at each site. For example, suppose an organization has a management network at its Dallas and Houston locations. In Dallas, the management network uses the 10.1.1.0/24 subnet with VLAN 10, whereas in Houston, the management network uses the 10.1.2.0/24 subnet with VLAN 20. This information can be modeled in VMM using network sites, which are linked to a VMM host group and contained within a logical network. This setup enables VMM to assign not only the correct IP address to virtual machines (VMs) based on location and network but also the correct VLAN or PVLAN. This is a key point. The logical network is modeling the physical network, so it’s important your objects match the physical topology such as the correct IP and VLAN configuration. A network site in a logical network doesn’t have to reflect an actual physical location but rather a specific set of network configurations.
A network site can be configured with just an IP subnet, just a VLAN, or an IP subnet/VLAN pair. You only need to configure IP subnets for a site if VMM will be statically assigning IP addresses to VMs created within the site. If DHCP is present, no IP subnet configuration is required. If VLANs aren’t being used, you don’t need to configure a VLAN. If DHCP is used in the network and VLANs aren’t used, you don’t have to create any network sites.
After the network sites are defined within a logical network, you can add IP pools to the defined IP address subnet, which enables VMM to configure VMs with static IP addresses as the VMs are deployed. If DHCP is used in the network, there’s no need to configure IP pools in VMM or even specify the IP subnet as part of the site configuration. DHCP would be leveraged for the IP assignment. However, if you don’t have DHCP, creating the IP pool allows VMM to handle the IP assignment for you. When a VM is deleted, VMM reclaims the IP address for its pool. Even when DHCP is primarily used in the network, if you’re using features such as load balancing as part of a service, VMM has to be able to allocate and track that IP address, which will require the configuration of an IP pool. If no IP pool is created for a network site, VMM configures the VMs to use DHCP for address allocation.
When using VMM, you should try to minimize the number of logical networks to keep the configuration as simple as possible. You should create them only when you need them. For example, as Figure 1 shows, I have several logical networks defined: a corporate network that has its own DHCP, an Internet network, a private network, two lab networks that use VLANs to separate communication (VMM allocates the IP addresses in these lab networks), and a network virtualization–enabled network that has an IP pool used for the Hyper-V host communications.
The goal for virtualization is to separate and abstract the logical networks from the VMs. This abstraction is achieved through the use of VM networks, which is another networking architectural component in VMM. When you use VM networks, the VMs have no idea of the underlying technology (e.g., VLANs, network virtualization) used by the logical network. A VM’s virtual network adapter can only be connected to a VM network. When network virtualization is used, the Customer Address (CA) space (i.e., the IP addresses given to the VMs) is defined as part of the VM network. This allows specific VM subnets to be created as needed within the VM network, completely separate from the logical network IP configuration.
There are some scenarios in which the isolation provided by VM networks isn’t required. For example, you don’t need isolation when direct access to the infrastructure is required, such as when the VMM server is running on a VM. In these instances, you can create a no-isolation pass-through VM network that directly passes communication through to the logical network. The VM network is present only because a VM’s virtual network adapter needs to connect to a VM network. If a logical network has multiple network sites defined, when you deploy a VM, it will automatically pick the correct IP subnet and VLAN configuration based on the location to which you’re deploying the VM. Users of self-service type portals are exposed to VM networks but not the details of the underlying logical networks.
Although logical networks are defined as part of the networking fabric view within the Fabric workspace, VM networks are defined within the VMs and Services workspace. When creating a VM network, you need to specify which logical network and specific site it relates to.
Port Profiles and Port Classifications
There are two types of port profiles: virtual port profiles and uplink port profiles. With virtual port profiles, you can configure settings that will be applied to virtual network adapters attached to VMs or virtual network adapters used by the management host OS. The settings can include:
- Offload settings such as those used to configure virtual machine queue (VMQ), IPsec task offloading, and single root I/O virtualization (SR-IOV)
- Security settings such as those used to configure DHCP guard
- Guest teaming settings
- Quality of Service (QoS) settings such as minimum and maximum bandwidth settings
VMM provides a number of built-in virtual port profiles for common network adapter uses, many of which are aimed at virtual network adapters used by the host OS. After a virtual port profile is used within a logical switch and the logical switch is deployed to a host, the host will be flagged as noncompliant if the virtual port profile configuration is changed because the host’s configuration no longer matches that of the virtual port profile. To fix this problem, you can easily remediate the servers to apply the updated configuration.
An uplink port profile defines the connectivity of the virtual switch to the logical networks. You need a separate uplink port profile for each set of hosts that require the same physical connectivity. (Remember that the logical networks define the physical network.) Conversely, anytime you need to restrict a logical network to specific hosts in the same location or need custom connectivity, you need a different uplink port profile. In the uplink port profile, you can select the logical networks that will be available as part of the logical network and the NIC teaming configuration when used on hosts. No preconfigured uplink port profiles are supplied, as their primary purpose is to model the logical networks that can be connected and, by default, there are no logical networks. If a change is made to the uplink port profile definition (e.g., a new VLAN is added), VMM will use a logical switch to automatically update all the virtual switches on the Hyper-V hosts that use the uplink port profile.
Port classifications are also available. They’re containers for port profile settings. You can think of port classifications as storage classifications, where you might create a gold storage classification that uses a top-of-the-line SAN and a bronze storage classification that uses a much lower tier of storage. Or you might create a high bandwidth classification and low bandwidth classification.
The benefit of the port classification is that it acts a layer of abstraction between the port profiles assigned to the logical switches. Because of this abstraction layer, you can assign a port classification to a VM template, but have a VM’s logical switch determine the port profile to be used.
VMM includes a number of port classifications that correlate to the provided virtual port profiles. Port classifications are linked to virtual port profiles as part of the logical switch creation process. Like VM networks, port classifications are exposed to users through self-service portals and not the underlying port profiles.
Although it’s possible to manually perform virtual switch configurations on a server-by-server basis, it can lead to inconsistencies. In addition, it inhibits the automatic deployment of new Hyper-V hosts.
Fortunately, VMM has the logical switch component, which acts as a container for all virtual switch settings. It also ensures a consistent deployment of switch configurations across all servers. Automatic configuration with the logical switch is useful for not only deployments but also compliance tracking and enforcement. After a host is deployed using the logical switch component, VMM will continue to track the host’s configuration and compare it to the logical switch’s configuration. If the host’s configuration deviates from that of the logical switch, this configuration will be flagged as noncompliant, which you can then resolve through the administrative interface. If the logical switch is updated (e.g., a new extension is added), all the Hyper-V hosts using the logical switch will automatically be updated.
When configuring the logical switch, you can specify:
- The Hyper-V virtual switch extensions that should be deployed to the hosts.
- The uplink port profiles that relate to the switch.
- The port classifications for the various types of virtual ports. For each port classification, you can select a specific virtual port profile to be used for the logical switch, as Figure 2 shows.
As part of the logical switch component deployment, you can have VMM automatically configure NIC teaming on the Hyper-V hosts. You just need to select multiple network adapters on the host when applying the logical switch to the host. This means that you don’t need to make any networking configurations on the actual Hyper-V host. You do everything in VMM.
How to Design and Implement a Network
Before you design and implement your network in VMM, you must first disable VMM’s Create logical networks automatically option. This option is enabled by default, which means that if you add a Hyper-V host to VMM for management purposes, VMM will automatically create a logical network for it if no suitable existing match is found. Here’s how to disable this option:
- Open VMM.
- Open the Settings workspace.
- Select the General navigation node.
- Double-click Network Settings in the details pane.
- In the Network Settings dialog box, clear the Create logical networks automatically check box and click OK.
Now you can safely design and implement your network in VMM. Here are the steps:
- Create the logical networks that relate to your physical networks. (You can also create logical networks for communication isolation purposes.) Create IP pools for the sites you defined in the logical network.
- Create the VM networks that relate to sites within the logical networks. Where network virtualization is used, you can create IP pools for the VM subnets to be used for assignment to VMs connected to the virtual networks.
- Create the uplink port profiles. As mentioned previously, they describe the connectivity between a specific port (which will be assigned later on) and the logical networks. Essentially, this will tell VMM which networks a specific NIC on a host can connect to.
- Create custom virtual port profiles if needed. VMM provides many virtual port profiles for the various types of traffic, but you can create additional virtual port profiles if needed.
- Create custom port classifications if needed. Port classifications typically reflect the virtual port profiles. Therefore, if you created additional virtual port profiles, you’ll likely need to create additional port classifications.
- Create a logical switch. Specify the type of teaming to use, the uplink port profile, the port classifications, and the virtual port profile that relates to each port classification.
- Apply the logical switch to a host and select the network adapters on the host to be bound to the logical switch, as shown in Figure 3. You can create additional virtual network adapters for use by the host OS within the possible port classifications that you assigned to the logical switch.
When you apply the logical switch to the Hyper-V host, all the networking configurations will be automatically made. Afterward, you’ll be able to view the server, any NIC teams created, the virtual switches, and the virtual network adapters related to the logical switch in VMM. Figure 4 illustrates all the relationships among the various VMM architectural components in a sample network.
Not As Bad As It Initially Seems
Initially, the number of architectural components related to Hyper-V networking in VMM can seem intimidating, but the reality is once you understand what they actually do, it’s really not that bad. After you finish the main work of defining the networks and creating the logical switches, the ongoing maintenance is very light.