The Network Virtualization Guide with SC 2012 - VMM SP1

Let’s forget about my previously post about this subject, as things have changed in the final bits of SP1 for System Center 2012.

Let’s start off with some clarifications:

-          IP Re-write is not supported in VMM 2012 SP1.

-          NVGRE is the default and only option for network virtualization with VMM 2012 SP1

 This blog post will cover the following: 

·         What the heck is network virtualization – and why do we need it?

·         How does it work?

·         How to prepare our networking fabric for network virtualization

What the heck is network virtualization – and why do we need it?

 Not everyone needs network virtualization, but the industry itself need a better way to meet the requirements for a secure multi-tenant infrastructure. To isolate tenants from each other without purchasing all the network infrastructure in the world.

As you may be aware of, Windows Server 2012 is truly a cloud OS. It’s more than just a server. It’s the private (and public) cloud enabler and the most important ingredient in your infrastructure to design a multi-tenant infrastructure at low cost, in conjunction with other pieces. Like storage for example, but that’s another story (SMB, Storage Pools/Spaces, resource groups ++).

I`ve been working a lot with hosters over the last years and a common challenge is a secure and scalable solution for multi-tenancy. First thing that you might think of in relation to network is to use VLAN`s. Fair enough, that`s a wide adopted technology to separate networks, but it is also complex and not suited to scale. When I say scale, I am thinking of big time scale, for those major hosters.
In these days when cloud computing is all over the place, we are expecting our service providers to provision infrastructure, platform and software as a Service quite rapidly, working together with anything else and without making any changes to our environment. Unfortunately this is very challenging and not practically realistic.
One additional challenge to VLAN`s is that when you need to scale your Fabric with new virtualization hosts, storage and networking, you are in some ways limited to one physical location.
VLAN can’t span multiple logical subnets and will therefore restrict the placement of virtual machines. So how can you get a solution that works for your customers – even when they have already existing solutions that they want to move to the cloud?

By using traditional networking and VLAN`s you will have to reassign IP addresses when moving to the cloud, since mostly of the configuration is relying on the IP configuration on those machines. This will include policies, applications, services and everything else that is used for layer 3 network communications. With the limitations of VLAN`s, the physical location will determine the virtual machine`s IP addresses.

This is where Network Virtualization in Windows Server 2012 – Hyper-V comes to the rescue.

It removes the challenges related to IaaS adoption for customers, and will provide the datacenter administrator an easy an effective way to scale their network fabric for virtual machines.

Network Virtualization will let you run several virtual machines – even with the same identical IP assigned, without letting them see each other, which sounds like the solution for multi-tenancy.

How does it work?

So, let’s explain network virtualization in a nutshell-manner:

You can virtualize any network and run them all on a single physical network fabric.

Just like you would virtualize your servers on one single physical host, where they’re running in their own isolated environment.

Each virtual network adapter in Hyper-V Network Virtualization is associated with two IP addresses.

Customer Address (CA): The CA is the address that’s assigned by the customer based on their subnet, IP range and so on. This address is only visible to the virtual machine and eventually other virtual machines within the same subnet/VM network if you allow routing. However, the important part here is that it’s only visible to the VM and the customer, not the underlying fabric. So think of it as a layer of abstraction. The CA is maintained by the customer’s network topology through the tenant-concept in VMM 2012 SP1.

Note: Tenants in VMM 2012 SP1 is a user role with additional permissions compared to the Self-Service User role.

Provider Address (PA): The PA is the address that is assigned by the server administrator/service provider/virtualization guru, based on their physical network infrastructure. The PA is only visible on the physical network, where the Hyper-V hosts are exchanging packets.

Summary

Each IP address assigned to a VM (CA) is mapped to an IP address on the physical host (PA)

VMs send data packets in the CA space, which are put into an “envelope” with a PA source and a destination pair based on the mapping

The CA-PA mappings must allow the hosts to differentiate packets for different customer virtual machines

The PA is the “ship” and the CA is the “load”.

Prior to the final release of Service Pack 1 for System Center, we had two options when it came to network virtualization.

IP rewrite where the customer IP address (CA) packets were modified on the virtual machine before they were transferred on the physical network fabric, and IP Encapsulation (NVGRE) where the packets were encapsulated with a new header before they were sent on the physical network.

From now on, only IP Encapsulation (NVGRE) is supported.

Network Virtualization with Generic Routing Encapsulation (NVGRE)

If you want to scale, and doesn’t require optimization on your VMs virtual NICs (like VMQ etc), NVGRE is ideal. NVGRE is intended for the majority of datacenters deploying Hyper-V Network Virtualization. The packet is encapsulated inside another packet (think “envelope”), and the header of this new packet has the appropriate source and destination PA IP address in addition to the Virtual Subnet ID, which is stored in the Key field of the GRE header.

 

 

Customer network/VM Networks

Each VM network contains one or more virtual subnets. A VM Network is an isolated network where the virtual machines within a VM network can communicate with each other. Virtual subnets implements the Layer 3 IP subnet semantics for VMs in the same virtual subnet. The Virtual Subnet is similar to a VLAN when it comes to broadcasting, where the Virtual Subnet is a broadcast domain. Each and every virtual subnet belongs a Routing Domain ID (RDID which has a GUID format) to identify the VM Network which is assigned by the virtualization guru with VMM 2012 SP1 and has a universally unique virtual subnet ID (VSID).

The Virtual Subnet ID (included with the GRE header) allows hosts to identify customer’s virtual machines for any given packet. Since this is a “policy driven” solution, the PA’s and the CA’s on the packets may overlap without any problems. This means that all virtual machines on the same host can share a single PA. ß That means scalability!

The less the switches in your infrastructure needs to learn about IP and MAC addresses, the more they smile.

How to prepare your networking fabric for network virtualization

 A good reason to buy System Center 2012 SP1 is management of network virtualization. If you’re not using Virtual Machine Manager, you must brush off your Powershell Ninja capabilities, and it’s really painful to maintain your environment when it scales.

VMM is the key to a successful cloud world, and will work as a policy supervisor on the Hyper-V switches, controlling every VM network, VLID

 If you are not familiar with Network Fabric in VMM, I`ll suggest that you read this blog post http://kristiannese.blogspot.no/2011/05/create-networks-with-vmm-2012.html for a guidance on how to setup Logical Networks, Virtual Networks, IP Pools and more. This is related to PA – Provider Addresses – which is the IP addresses that the Hyper-V hosts will be able to see and use.

VMM 2012 SP1 introduces several new features and capabilities related to networking in the fabric space.

A close look at the Fabric view will summarize that.

The idea behind these new concepts is to create consistently and identical capabilities for network adapters across multiple hosts in your fabric, using profiles and logical switches. Both profiles and logical switches works as containers for properties or capabilities that you want your network adapters to have.

This means you can create a set of profiles, associate them with logical switches and apply the same configuration to all of your hosts. Again, think scalability.

Native port profile for uplinks (Connectivity)

This is a profile that specifies which logical networks can connect through a specific physical network adapter. An uplink port profile can be added to a logical switch, and the logical switch can be applied to a network adapter on the host. If you’re interesting in NIC teaming in Windows Server 2012, this is where you configure it in VMM. You select ‘team’ for the Uplink mode to enable teaming, as well as selecting load-balancing algorithm and teaming mode.

Native port profile for virtual network adapters (Capabilities)

This is a profile for virtual network adapters connected to an extensible virtual switch in Hyper-V. All from offload settings to security settings are managed through this profile. Together with Native port profile for uplinks, you can associate these profiles as well with a logical switch, assuring that the VMs connected to the switch has the right capabilities.

Port classification

Provides a global name for identifying different types of virtual network adapter port profiles and can be used across multiple logical switches. Example is to create one classification named “Bronze” where the customers who pays you the least amount of bucks get slower performance than the “Gold” customers. Traditionally called as SLA.

Logical Switch

Logical switches brings port profiles, classifications and switch extensions together for you to apply a bunch of configuration to multiple hosts at once, streamlined and easy. The logical switch is also responsible to tell the physical network adapter that it should support network virtualization. (Enabling network virtualization filtering driver on the physical NIC on the parent partition).

How to create a Native Port Profile for Uplinks in VMM 2012 SP1

1.       In the Fabric workspace, right click on Native Port Profiles and click ‘Create Native Port Profile’.

2.       Assign the profile a name and a description, and make sure you have enabled ‘Uplink port profile’.

Default, the load balancing algorithm is HyperVPort, and Teaming mode is set to SwitchIndependent.

Choose what you want and click next.

3.       Select the network sites supported by this uplink port profile. This is the logical network you have available in VMM. Since network virtualization requires PA’s to work, you must have an underlying networking fabric to make the magic happen’. Once you have selected the right network sites, check the ‘Enable Windows Network Virtualization’ option at the bottom of the screen – and click next, and finish.

We have now created an uplink profile that will enable network virtualization on our physical network adapters. The next thing we’ll do, is to create a native port profile for virtual network adapters to assure we configure the proper capabilities for your vNICs.

 

How to create a Native Port Profile for Virtual Network Adapters 

1.       Navigate to the networking space in the Fabric Workspace, select Native Port Profiles, right click, and create Native port profiles.

2.       This time, make sure the ‘Virtual network adapter port profile’ is selected, assign the profile a name and a description and click next.

3.       Select the offload settings for the virtual network adapter port profile. VMQ, IPsec task offloading and SR-IOV is available. Select the required configuration and click next.

4.       Next, specify the security settings for this profile. All of these capabilities is a result of the work that has been done in the extensible virtual switch in Hyper-V. Click next once you’re done.

5.       Select the bandwidth settings for the profile. QoS is another feature that’s available directly on the vNICs in Hyper-V, and you can specify those settings here. Click next once you’re done, and finish.

The last thing we’ll do before we go ahead with our Logical switch, is to create a port classification

How to create a Port Classification

 

1.       In the Fabric Workspace, right click Port Classification and create new Port Classification

2.       Assign a name. Based on the previous steps when you created your native port profile for virtual network adapters, name the classification something meaningful to you, as you will use this classification when you’re creating the logical switch. Type a description and click OK.

Also note that VMM ships a bunch of pre-configured classifications, for you to use in your environment. Take a look at them to get a better understanding of their intentions.

We have now configured the required prerequisites for our logical switch.

How to create a Logical Switch

1.       Right click Logical Switches in Fabric workspace, and create logical switch.

2.       Enter a name and a description for the logical switch. Here you can also enable SR-IOV since this is a HW feature on the NIC. Make sure you have adapters that supports SR-IOV prior to this. Click next

3.       Choose the extensions you want to use with this logical switch. If you haven’t added any switch extensions (add on to VMM) you will only have the default switch extensions provided by Hyper-V in this step. Click next once you’re done.

4.       Select the uplink mode (teaming or no teaming), and add the Uplink port profile you created earlier. Click next once you’re done. As you can see, when you created the Uplink port profile, you selected the network sites where the profile should be available. If the host group already has access to this logical network, it will be visible here.

5.       Specify the port classification for virtual ports part of this logical switch. Add your virtual port profile you created earlier in this step along with the port classification.

6.       Click next – and finish.

 

The last thing to do, is to assign the logical switch to a physical network adapter (or team) on your hosts.

Go to a host group, select a host, right click and select properties.

In the Virtual Switches view, click ‘New Virtual Switch’, find your logical switch you created and select your uplink profile.