Freigeben über

Step-by-Step: Hyper-V Network Virtualization - 31 Days of Favorite Features in #WinServ 2012 ( Part 8 of 31 )

  • Artikel

This article is Part 8 in a series of articles of the "Top 31 Favorite Features in Windows Server 2012" with my fellow IT Pro Technical Evangelists.  Be sure to follow them on Twitter and check out their blogs this month for the other parts of this series:

What is Hyper-V Network Virtualization?

Any Service, Any Server, Any Data Center or Cloud!

True network and virtual machine portability - that's the ultimate goal of Hyper-V Network Virtualization - allowing you, as an IT Pro, to align changing business needs with the best physical resource locations to run your VMs and network services - easily, without the sweeping network, router, switch, firewall and DNS changes with which we'd traditionally be plagued when merely attempting the feat of relocating VMs to a new rack, subnet or data center ... WOW!

Windows Server 2012 and our FREE Hyper-V Server 2012 include a new network virtualization feature that permits the configuration of "software-defined networking (SDN)" within the native Hyper-V hypervisor.  Hyper-V Network Virtualization extends the virtualization benefits we've realized when virtualizing server workloads into the network layer to decouple our physical network infrastructure from logical layer-2 and layer-3 subnets as illustrated below:

Sounds Interesting! But, Why Use Hyper-V Network Virtualization Instead of Traditional VLANs?

Hyper-V Network Virtualization was intended to address the limitations and complexity seen in typical environments using VLANs, such as:

  • Limited scalability - typical network switch configurations permit only 1,000 VLANs out of a maximum of 4,094 VLAN IDs.  In contrast, Hyper-V Network Virtualization can scale to support over 16 million virtualized networks.
     
  • Configuration cost and complexity - environments using many VLANs need to carefully manage VLAN configurations on each switch, host and virtual machine to ensure a consistent experience.  In addition, enterprise VLAN configurations can require network switches with advanced processing capabilities from a single hardware vendor, often times making it difficult to cost effectively expand virtual network capacity.  Hyper-V Network Virtualization can be centrally implemented via network virtualization policies across a diverse network switch infrastructure and does not require special capabilities in the underlying network hardware.
     
  • Constrained to a single subnet - Traditional VLANs are constrained to a single subnet, and although VLANs can be extended across physical sites, they must stretch one subnet at the network layer across those physical locations, which can cause extreme routing challenges - particularly when trying to leverage a combination of private data center resources along with hosted or public cloud resources.  Hyper-V Network Virtualization can present virtualized networks across diverse IP networks that extend across private, hosted and public cloud resources.

By removing these limitations, Hyper-V Network Virtualization extends the value of virtualization features that rely on network configurations.  As a I discuss these capabilities with IT Pros at our IT Camp events, three of the new scenarios that they are really excited about include:

  1. Cross-subnet Live Migration of Virtual Machines - Live migrate running virtual machines to Hyper-V hosts on a different physical network subnet!  Hyper-V Network Virtualization extends virtualized subnets across one or more physical IP subnets, allowing Live Migration to be used across physical subnet boundaries. 
     
    Note:  Cross-subnet Live Migration with Hyper-V Network Virtualization requires the use of Hyper-V over SMB 3.0 to provide shared VM storage to Hyper-V hosts on each physical subnet.  Hyper-V over SMB 3.0 uses cost effective file shares on Windows Server 2012 to provide a shared storage location that each Hyper-V can access for running and live migrating virtual machines.
     
  2. IP Address and VM Portability across subnets and premises -   As business needs change, re-locate VMs to any datacenter, hosting provider or public cloud location WITHOUT changing the existing IP Addresses of the VMs! Today, numerous configuration choices are tied to the IP Address of each virtual machine - physical datacenter locations, firewall rules, router ACLs, directory services roles, etc - and this can make changing the IP Address of a deployed virtual machine a painful process.  As a result, many shops find that it's difficult to move VMs new host locations - such as new datacenter, hosted or public cloud locations - as business needs change, because these moves would generally require IP Address changes - not so with Hyper-V Network Virtualization!
     
  3. Multi-tenancy with Overlapping IP Address ranges - This is a great solution for Hosting Providers, who need to ensure that each customer's collection of virtual machines are completely isolated at a network layer from other customers.  Each virtualized network can also use the customer's native IP addressing scheme, even if it would normally conflict with IP addressing schemes used by other customers.

How Does Hyper-V Network Virtualization Work?

Hyper-V Network Virtualization is implemented in Windows Server 2012 and Hyper-V Server 2012 as a new network driver module, Windows Network Virtualization (aka "ms_netwnv").  This module can be bound to physical NICs on each server and configured with a set of policies to virtualize network addressing and routing rules.  When configuring network virtualization, two different configuration approaches can be used:

  • Generic Routing Encapsulation (NVGRE) - this approach builds GRE (RFC 2784 and 2890) tunnels between Hyper-V hosts to encapsulate virtualized networks using the details outlined  in the NVGRE Draft RFC document that has been submitted to the Internet Engineering Task Force (IETF).  This draft RFC document was assembled by a committee of networking veterans that includes senior engineers from Intel, DELL, HP, Emulex, Broadcom and Microsoft.  NVGRE is the preferred configuration approach for most network virtualization scenarios with Hyper-V hosts.
     
  • IP Address Rewrite (IP Rewrite)  - this approach uses a NAT-like approach at each Hyper-V host to rewrite virtualized network addresses to native network addresses that can be routed across the physical network architecture.  IP Rewrite is intended for scenarios where Virtual Machines require extremely high-performance network bandwidth, such as 10 Gbps Ethernet, since traditional NIC offload mechanisms are supported to increase throughput.

Since NVGRE is the preferred choice for most network virtualization scenarios, we'll be focusing on this approach for the reminder of this article.  However, check out this article if you're interested in more details on IP Rewrite and a deeper comparison between the two approaches.

What Changes Are Needed to My Existing Physical Network Switches?

NONE!  NVGRE can be implemented across an existing physical IP network without requiring changes to your physical network switch architecture.  Since NVGRE tunnels terminate at each Hyper-V host, the hosts handle all of the handiwork for encapsulating and de-encapsulating network traffic.  If you have firewalls that are blocking GRE tunnels between sites, you will need to configure your firewalls to support forwarding GRE (IP Protocol 47) tunnel traffic.

Security Note: NVGRE tunnels do not natively provide encryption of payload contents.  If an NVGRE tunnel is being extended across public network segments, I recommend considering IPsec as part of your network layer policies to authenticate and encrypt network traffic end-to-end between virtual machine endpoints.

Performance Note: If you are planning to leverage NVGRE to virtualize heavy network IO workloads, you should also consider network adapter hardware that supports GRE Offload within the network chipset.  Without GRE Offload support within the NIC, traditional NIC offload technologies will not work with GRE traffic.  A number of NICs supporting GRE Offload for Windows Server 2012 and Hyper-V Server 2012 are expected later this calendar year.

I'm Ready! Where Do I Start?

The best starting place is to first layout the addressing scheme for IP addresses and subnets that you'd like to virtualize.  When configuring Hyper-V Network Virtualization, there are two types of IP Addresses that you'll be interacting with:

  • Provider Addresses (PA) - these are unique IP addresses assigned to each Hyper-V host that are routable across the physical network infrastructure.  I like to think of "PA" addresses as "Physical Addresses", because they are assigned to physical Hyper-V hosts.  Each Hyper-V host requires at least one PA to be assigned.
     
  • Customer Addresses (CA) - these are unique IP addresses assigned to each Virtual Machine that will be participating on a virtualized network.  I like to think of "CA" addresses as "Container Addresses", because they are the IP Addresses assigned to each VM "container" for use by the guest operating system running inside that VM.  Using NVGRE, multiple CA's for VMs running on a Hyper-V host can be tunneled using a single PA on that Hyper-V host.  CA's must be unique across all VMs on the same virtualized network, but CA's do not need to be unique across virtualized networks (such as in multi-tenant scenarios where each customer's VMs are isolated on separate virtualized networks).

Let's look at a simple example of NVGRE with two Hyper-V hosts using PA's and CA's:

In this example, you'll note that each Hyper-V host is assigned one PA address ( e.g., 192.168.x.x ) used for tunneling NVGRE traffic across two physical subnets ( e.g., 192.168.1.x/24 and 192.168.2.x/24 ) on the physical network.  In addition, each VM is assigned a CA address ( e.g., 10.x.x.x ) that is unique within each virtualized network and is tunneled inside the NVGRE tunnel between hosts. 

To separate the traffic between the two virtualized networks, the GRE headers on the tunneled packets include a GRE Key that provides a unique Virtual Subnet ID ( e.g., 5001 and 6001 ) for each virtualized network. 

Based on this configuration, we have two virtualized networks ( e.g., the "Red" network and the "Blue" network ) that are isolated from one another as separate IP networks and extended across two physical Hyper-V hosts located on two different physical subnets.

Once you have the following defined for your environment in a worksheet, you're ready to move on to the next steps in configuring Hyper-V Network Virtualization:

  • PA's for each Hyper-V Host
  • CA's for each Virtual Machine
  • Virtual Subnet ID's for each subnet to be virtualized

Done! How Can I Configure Hyper-V Network Virtualization?

Hyper-V Network Virtualization policies can be centrally configured using PowerShell 3.0 and PowerShell Remoting for no additional cost.  In addition, System Center 2012 Virtual Machine Manager Service Pack 1, currently available as a public beta, also offers an enterprise GUI management console that can centrally deploy and manage Hyper-V Network Virtualization policies across a large number of Hyper-V hosts.

To understand the configuration steps for each type of virtual network addressing ( eg., PA's, CA's, Virtual Subnet IDs ) described above, let's step through the PowerShell 3.0 Cmdlets used to configure these policies one-by-one.  In these examples, we'll be focusing on the configuration steps for the "Blue" virtual network components on the Hyper-V hosts in the example illustrated above.  

Note: If you'll be using System Center 2012 to deploy and manage network virtualization policies as noted above, you won't need to manually run the specific PowerShell 3.0 Cmdlets below because System Center 2012 will run the appropriate PowerShell Cmdlets for you automatically to deploy the policies.  But, it still never hurts to understand what's happening behind the scenes! :-)

Here we go!  Let's get started configuring Hyper-V Network Virtualization via PowerShell 3.0 ...

  1. Enable the Windows Network Virtualization binding on the physical NIC of each Hyper-V Host ( Host 1 and Host 2 )
     
    Enable-NetAdapterBinding Ethernet -ComponentID ms_netwnv
     

  2. Configure Blue Subnet Locator and Route records on each Hyper-V Host ( Host 1 and Host 2 )

    New-NetVirtualizationLookupRecord -CustomerAddress "10.1.1.11" -ProviderAddress "192.168.1.10" -VirtualSubnetID "6001" -MACAddress "101010101105" -Rule "TranslationMethodEncap"

    New-NetVirtualizationLookupRecord -CustomerAddress "10.1.1.12" -ProviderAddress "192.168.2.20" -VirtualSubnetID "6001" -MACAddress "101010101107" -Rule "TranslationMethodEncap"

    New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000000000}" -VirtualSubnetID "6001" -DestinationPrefix "10.1.1.0/24" -NextHop "0.0.0.0" -Metric 255
     
    Note:     In the last command in this step above, a "RoutingDomainID" is also specified.  While this is not a network address per-se, each collection of virtualized networks that will route between each other must have a unique administrator-defined Routing Domain ID.  Using the example above, the "Blue" subnet and "Red" subnet do not have traffic routed between each other and, as such, would each require a unique Routing Domain ID.

  3. Configure the Provider Address and Route records on Hyper-V Host 1 ( Host 1 Only )
     
    $NIC = Get-NetAdapter Ethernet

    New-NetVirtualizationProviderAddress -InterfaceIndex $NIC.InterfaceIndex -ProviderAddress "192.168.1.10" -PrefixLength 24

    New-NetVirtualizationProviderRoute -InterfaceIndex $NIC.InterfaceIndex -DestinationPrefix "0.0.0.0/0" -NextHop "192.168.1.1"

  4. Configure the Provider Address and Route records on Hyper-V Host 2 ( Host 2 Only )
     
    $NIC = Get-NetAdapter Ethernet

    New-NetVirtualizationProviderAddress -InterfaceIndex $NIC.InterfaceIndex -ProviderAddress "192.168.2.20" -PrefixLength 24

    New-NetVirtualizationProviderRoute -InterfaceIndex $NIC.InterfaceIndex -DestinationPrefix "0.0.0.0/0" -NextHop "192.168.2.1"

  5. Configure the Virtual Subnet ID on the Hyper-V Network Switch Ports for each "Blue" Virtual Machine on each Hyper-V Host ( Host 1 and Host 2 )
     
    Get-VMNetworkAdapter -VMName BlueVM1 | where {$_.MacAddress -eq "101010101105"} | Set-VMNetworkAdapter -VirtualSubnetID 6001

    Get-VMNetworkAdapter -VMName BlueVM2 | where {$_.MacAddress -eq "101010101107"} | Set-VMNetworkAdapter -VirtualSubnetID 6001 

That's it! Once you've gone through these 5 steps, you should now be able to route traffic between Virtual Machines across the "Blue" virtual subnet using the IP address space of 10.1.1.x / 24.

Note: If Windows Firewall is enabled on the operating system within each Virtual Machine, you may need to configure Windows Firewall within each VM to allow the traffic you're using to test.  For example, to permit ping traffic between VM's with Windows Firewall enabled, you can use the following PowerShell 3.0 Cmdlets in each VM:

New-NetFirewallRule –DisplayName “Allow ICMPv4-In” –Protocol ICMPv4

New-NetFirewallRule –DisplayName “Allow ICMPv4-Out” –Protocol ICMPv4 –Direction Outbound

What's Next? Keep Going!

Below are some great resources to continue your learning process on Hyper-V Network Virtualization ...

How Are You Planning to Use Hyper-V Network Virtualization?

Have you found an interesting use case in your environment for Hyper-V Network Virtualization?  Be sure to share your story in the comments below!

HTH,

Keith

Comments

  • Anonymous
    January 01, 2003
    Hi Chris, There's not a lab guide yet, but the links to the demo scripts above are well-commented and can be leveraged to step through the process.  Great idea though ... we'll try to work a more formal lab guide into a future Knowledge Quest of the Early Experts program (http://EarlyExperts.net). HTH, Keith

  • Anonymous
    January 01, 2003
    Hi Chris, To connect the physical network world with one or more virtualized networks, a Hyper-V network virtualization gateway can be used - the Hyper-V Network Virtualization Gateway Architecture guide linked above provides a technical overview of several scenarios.  Essentially, a Hyper-V Network Virtualization Gateway is a server or appliance device that has one or more physical NICs that connect to the physical world, as well as one or more NICs that are bound to the network virtualization stack, so that the gateway can be configured to route between the two sets of networks as appropriate.  Think of it as an "edge device" for connecting to virtualized networks. Hope this helps! Keith

  • Anonymous
    January 01, 2003
    Hi Darryl, There hasn't been an official announcement yet on availability of the Hyper-V Network Virtualization Gateway provider yet for System Center 2012 SP1.  I'll be sure to share more info as soon as I have it. Best regards, Keith

  • Anonymous
    January 01, 2003
    Hi Steven, You can use either Windows Server 2012 or a 3rd party appliance for a Hyper-V Network Virtualization Gateway.  I believe that a configuration provider for Windows Server 2012 Hyper-V Gateways will be made available after SP1 of System Center 2012 is made generally available, but the general recommendation is to prefer one of the appliance solutions for production usage. Hope this helps! Keith

  • Anonymous
    January 01, 2003
    Hi Eric, The Hyper-V network virtualization gateway will have at least one physical NIC that is virtualized with the WNV driver and will have a connection and valid IP for each virtualized subnet through that NIC. This permits the VMs to be assigned a default gateway IP address that appears to be for a router that is on their local subnet, but in fact is an IP in the customer address (CA) space and is present in the virtualized routing domain tables on the host as a default gateway - in PowerShell, the command on the host to set this up would look something like this: New-NetVirtualizationLookupRecord -CustomerAddress "10.0.0.1" -ProviderAddress "169.254.254.254" -VirtualSubnetID "6000" -MACAddress "101010101101" -Rule "TranslationMethodEncap" -VMName "BlueS1-DG" Take a look at the gateway PowerShell script example linked above in the article - it provides a good walk-through of this scenario. Hope this helps! Keith

  • Anonymous
    January 01, 2003
    Hi Keith, When you mention Hyper-V Network Virtualization Gateway as a server, is there any way you can configure Server 2012 to be a gateway or are they all 3rd party servers/appliances? If you can configure Server 2012 then how do you then import it into SCVMM 2012 SP1 as a configuration provider in order to define it when creating your VM Networks? This seems to be the missing piece in my jigsaw at the moment Thanks for any help Steven

  • Anonymous
    January 01, 2003
    Hi Artur, Communication between virtualized networks and physical networks is handled by a Hyper-V Network Virtualization Gateway.  Check out the Gateway architecture guide for more details at technet.microsoft.com/.../jj618319.aspx. It sounds like, in your environment, network virtualization for your VM traffic makes the most sense to avoid ongoing management of over 400 VLANs. Hope this helps! Keith

  • Anonymous
    October 10, 2012
    Keith, I'll read technet docs about it but do you know if there's a lab guide or something like that for this feature ? Thanks a lot !

  • Anonymous
    October 10, 2012
    Thanks again Keith, I'm following the program and it really helps anyone studying the awesome new features offered by 2012

  • Anonymous
    October 14, 2012
    Thank you so much for putting this all together Keith. This makes life much easier for people working towards MS Private Cloud technologies.

  • Anonymous
    December 10, 2012
    The comment has been removed

  • Anonymous
    December 10, 2012
    Hello Keith, Thank you, that helped a lot to get a better understanding.

  • Anonymous
    December 28, 2012
    Hi Keith, Thanks !!! was looking for a very long time for this. Glad that search ends here.

  • Anonymous
    January 27, 2013
    Keith Thanks very much for the cogent presentation.  I've been looking for good info on this since before RTM last July. What I'm wondering is what IP to assign as the GATEWAY IP in the VM's when configuring their internal network addressing?  Would their private, isolated IP's use a gateway address of the IP address of the HV GATEWAY APPLIANCE then?

  • Anonymous
    February 03, 2013
    "You can use either Windows Server 2012 or a 3rd party appliance for a Hyper-V Network Virtualization Gateway. I believe that a configuration provider for Windows Server 2012 Hyper-V Gateways will be made available after SP1 of System Center 2012 is made generally available" Any clue when this is made available?

  • Anonymous
    April 17, 2013
    The comment has been removed

  • Anonymous
    May 10, 2014
    Pingback from ??????????????????????????? Software-defined Network (SDN) | Webtheboy.com ?????????????????????????????????????????????

  • Anonymous
    September 21, 2015
    Day1 of 31
    Hello October!!!
    31 Days of our Favorite Things in Windows Server 2012 Blog Series