In this blog, the second in our series, we will take a closer look at Logical Networks and review some of the key considerations, best practice recommendations and guidance for designing, implementing and managing this component of your Virtualized Network Solution.
This posting took a lot longer and became a lot more involved than we had originally planned – so much so that we have split it into two parts. Part I looks at how Logical Networks fit into your Virtualized Network solution and how you should associate them with host computers since we know a number of you had questions around this and Part II, design and architecture – helping to answer the key question which is “how many logical networks do I need in my environment?”. We hope you enjoy Part I, the second part of this blog will be posted to TechNet a little later this month.
As you can imagine with all of the content we aim to put into each of these posts, we're little behind the schedule we had originally set for ourselves. Our plan called for two posts this month, one on Logical Networks and the other on Port Profiles and Port Classifications but given how this one has shaped up, we’re going to finish up the Logical Networking post this month and push back the next in the series until March. Look forward to reading your comments and feedback.
Nigel Cain & Damian Flynn
The VMM documentation indicates that “A logical network is used to organize and simplify network assignments for hosts, virtual machines and services. As part of logical network creation, you can create network sites to define the VLANs, IP subnets, and IP subnet/VLAN pairs that are associated with the logical network in each physical location.” It goes on to state that they can be used to describe networks with different purposes, create traffic isolation and even support traffic with different types of service-level agreements.
As logical networks represent an abstraction of the underlying physical network infrastructure, they enable you to model the network based on business needs and connectivity properties. Users can assign VM networks, which use logical networks for the physical connectivity, as part of virtual machine and service creation without having to understand the network details.
Although simplified a little, the following illustrates the different layers that make up the overall architecture of a virtualized networking solution, with the physical network and Hyper-V hosts at the bottom of the diagram and the deployed virtual machines and services on the top. To the right are the names of each component and, on the left, how these components are connected together. A Logical Switch, for example, is connected to a Logical Network via a Logical Network Definition.
Note: Although not shown above, clouds also have a direct relationship with Logical Networks and VMM uses this relationship to scope the list of VM Networks that can be used during virtual machine placement. To be placed in a cloud, a virtual machine must be connected to a VM Network which is linked to a Logical Network associated with the selected cloud
As you can see from the above, Logical Networks are connected to a number of components in the network solution architecture and it is clearly important to understand how and where these connections are defined if you need to troubleshoot issues with connectivity and/or have to make changes to your solution to reflect updated business requirements.
To aid understanding, let’s take an example organization which has operations in two locations, one in Seattle and the other in Reading. In the Reading site, three physical networks are used to separate different types of network traffic and to ensure quality of service; production, development and all virtual machine related traffic is hosted on the Datacenter Network, access to the SAN and other storage devices is via the Storage Network, with physical device management performed on the Management Network. The organization uses Windows Server 2012 Hyper-V for its Virtual Machine workloads and each of these machines is connected to all three of the physical networks (as shown).
We recognise that this host network design tends to not be the trend today but it is useful to highlight key concepts. In Windows Server 2012 environments, individual networks are exposed to the host through Virtual Network Adapters rather than Physical Adapters, creating what is commonly referred to as a Converged Network, for more details on this, please see the link below. We will take a more detailed look at converged networks in a later blog.
Returning to our example, we would expect to find a minimum of three logical networks in SC VMM 2012 SP1, one for each of one of the physical networks. In reality, however, you may find you need many more logical networks than you have physical – logical networks may be created to describe networks with different purposes; development, test or production, for example, to isolate network traffic and/or to support different types of service-level agreements (SLAs).
As the VMM documentation suggests, “logical networks represent an abstraction of the underlying physical network infrastructure, they enable you to model the network based on business needs and connectivity properties”. We will return to this theme and cover some of the key design decisions and best practice later in the blog but it would be reasonable to argue that administrators within our organization would like to isolate production traffic from development or test workloads and ensure that such traffic is provided with a higher service level, all of which represent good reasons for creating a logical network that is dedicated to production workloads.
We will use this example environment as the basis for our discussion and exploration into the connectivity between logical networks, physical hosts and VM Networks.
As stated earlier, a logical network is used to organize and simplify network assignments for hosts, virtual machines and services. As part of logical network creation, you can create network sites (otherwise known as Logical Network Definitions) to define the VLANs and IP subnets that are to be associated with the logical network in each physical location.
In our example organization, Hyper-V hosts supporting production workloads are situated in two physical locations, Reading and Seattle, with each site using a different VLAN and IP Subnet range. Virtual Machines running production workloads on hosts in the Reading Datacenter need to use VLAN18 and have an IP address in the 192.168.99.0/24 subnet, where those in Seattle should use VLAN 100 and have IP address in the 192.168.199.0/24 subnet. To allow the “Production” Logical Network to be supported in both of these locations, two Network Sites are required as shown:
The “Reading” Network site is scoped to Hyper-V hosts deployed in Reading. It defines the VLAN and IP Subnets that will be used by virtual machines that connect to the Production Logical network when running on a Hyper-V host in this location. The other network site is scoped to the “Seattle” host group and essentially defines the VLANs and subnets that will be used by virtual machines deployed in Seattle.
Note that scoping the logical network to a host group in the network site – as shown above - does not actually make the Logical Network available on any of the hosts within that group. It essentially prevents it from being associated with hosts that are not within that target group(s). To make the logical network available on a given host, you need to associate the logical network with a physical network adapter on that host.
In our example, READING-VMH2 is one of the servers located in the Reading Datacenter. The server is a member of the host group which is authorised for the “Production” Logical Network and as this logical network has been successfully associated with one of the physical network adapters (as shown below), it can be made available to virtual machines which are running on that host.
The expected result of this configuration (once it has been deployed to hosts in both locations) is that VMM will ensure that all newly created virtual machines are configured with the network information appropriate for the location in which they have been deployed. A machine deployed in Reading, for example, will use VLAN 18 and have an IP Address in the range 192.168.99.0/24.
Moving existing virtual machines between sites using VMM should also be possible, though with a number of caveats. The main one is that fact that the IP address assigned to the virtual machine will not be changed during migration. If the physical network is a stretched LAN, meaning that the same IP subnet is present in both locations, then the virtual machine will continue to communicate on the network once it has been moved. If, as in our example, each site has its own VLAN and IP Subnet, then although you will be able to successfully move the virtual machine to new location, it will have an incorrect VLAN/IP Address for that location.
Note: A Virtual Machine connected to a VM Network (see later) which uses Network Virtualization on the “Production” Logical Network has been enabled can be moved between hosts in Reading and Seattle without requiring any additional configuration.
If you associate one or more IP subnets with a network site, you can also create static IP address pools for those subnets. Static IP address pools make it possible for VMM to automatically allocate static IP addresses to Windows-based virtual machines that are running on any managed Hyper-V, VMware ESX or Citrix XenServer host. VMM can automatically assign static IP addresses from the pool to stand-alone virtual machines, to virtual machines that are deployed as part of a service, and to physical computers when you use VMM to deploy them as Hyper-V hosts. Additionally, when you create a static IP address pool, you can define a reserved range of IP addresses that can be assigned to load balancers as virtual IP (VIP) addresses. VMM automatically assigns a virtual IP address to a load balancer during the deployment of a load-balanced service tier.
Note: When using network virtualization, the Logical Network also has a relationship with deployed virtual machines, in that each machine must be allocated an IP address from one of the IP pools that have been defined for that Logical Network. The IP addresses from this pool - otherwise known as Provider Address (or PA) – must be routable between Hyper-V hosts.
If you configure a virtual machine to obtain its IP address from a static IP address pool, you must also configure the virtual machine to use a static MAC address. You can either specify the MAC address manually or have VMM automatically assign a MAC address from either a central MAC address pool or one that you have created for a specific network site.
The key question is how the association between the host and the logical network is established. You can clearly configure the network adapter settings by making the necessary changes on each host manually or via PowerShell when you have a large number of host machines to update. In SC VMM 2012 SP1, the recommended approach is to define the list of Logical Networks and the set of properties and capabilities you want to apply to (host) Network Adapters in Port Profiles and Logical Switches.
Port profiles and logical switches act as containers for the properties or capabilities – including Logical Networks - that you want configured on network adapters across multiple hosts. The primary benefit of using these concepts is that they allow you to consistently apply the same settings and capabilities to network adapters across multiple hosts. We will look at these concepts in much more depth in future blog posts but, for now, we will focus our attention on how they support the configuration of Logical Networks.
An Uplink port profile is essentially a template in which you define the list of Logical Network(s) that should be associated with any (physical) network adaptors that is applied to. It also allows you to specify the protocols that should be used if a “team” of network adapters in a host computer will be configured to use the same uplink.
In the majority of cases, you will create an uplink profile for every set of hosts that have the same physical connectivity as a result, you may find it necessary to create multiple uplink profiles for a single location in your datacentre, for example Cluster A may have one uplink profile and cluster B may use another even if they are in the same room. As a rough guide, if you have custom connectivity, have multiple physical networks and/or wish to restrict logical networks to specific hosts within a given physical location, then you will need to create additional Uplink Port Profiles. You will find much more information on this in our next blog.
In our example organization, a number of hosts in Reading and Seattle need to be associated with the Production logical network and Port Profiles and Logical Switches will therefore be used to help ensure host computers in each location are configured consistently. We assume that servers in each location have the same type of physical connectivity and will therefore create two Uplink Port Profiles – one for Reading and another for Seattle. For a complete solution, we would also need to define Uplink Port Profiles for non-production workloads, the storage network and the management network since these are present in each physical location but we will ignore these for the purpose of our example.
The following screenshot shows the network sites that are configured for the Reading – Production Uplink Port Profile. When this is applied to a host computer in Reading as part of Logical Switch deployment (see later), it will associate the selected network adapters with the Production Logical network.
In our example we have selected only one network site and hence one logical network. You can however, specify connectivity to multiple network sites. The net result is that when the Uplink Port Profile is applied to a network adapter on a host, that network adapter will be associated with all of the selected logical networks.
Note: If you want to enable network virtualization – which is the key theme of our blog series, you need to select the “Enable Windows Network Virtualization” check box in the Uplink Port Profile (as shown). At least one of the logical networks you select in this dialog must also have been configured to “Allow new VM networks created on this logical network to use network virtualization.”
Native Port Profiles – like Uplink Port Profiles above – are essentially templates which allow you to define offload settings and security settings for virtual network adapters. A number of these port profiles are provided by default and we note them in the context of this blog only to record the fact that they are made available to hosts as part of Logical Switch deployment (see below) and that they may be applied to a network adapter connected to a logical network, ensuring, for example, that the traffic passing through the adapter onto the logical network has the required IEEE priority tag and/or is subject to the appropriate bandwidth controls.
A Logical Switch brings together all of the different Uplink Port Profiles, Native Port Profiles, Port Classifications and Switch Extensions – we will look at all of these components in more detail in the next blog - that are relevant to a particular physical or logical network. It is essentially a template that contains an administrator defined set of parameters (port profiles, classifications, etc) which you can use to create Hyper-V Virtual Switches on any of the Windows Server 2012 host computers that connect to that network.
When you use a Logical Switch to create a Hyper-V Switch on a host computer, you select the most appropriate combination of Port Profiles, Classifications and Switch Extensions from the list of those defined in the Logical Switch. You can find more information on Hyper-V Virtual Switches at the link below:
As a general principle, you will need a Logical Switch for each physical network that exists in your environment but if you plan to restrict some Logical Networks to a limited set of hosts, as with our example organization, and/or have custom connectivity requirements you may find it necessary to create additional Logical Switches. We will cover some of the design rationale for logical switches in a future blog.
Since our example organization has three physical networks, Datacenter, Management and Storage, we will most likely create three Logical Switches according to the guidelines outlined above. However, only a limited number of hosts in Reading and Seattle will run production workloads and should be associated with the Production Logical Network we created earlier – the key question is whether we need an additional Logical Switch to support this environment.
Technically, nothing prevents us from including both of the “Production – Reading” and “Production – Seattle” Uplink Port Profiles into the Logical Switch we create for the Datacenter Network and allowing our administrator to choose the most appropriate settings and capabilities for the host they are working with. We can even rely on VMM to actively prevent administrators from using any of the “Production” uplinks when they are using the Logical Switch to create a Hyper-V Virtual Switch on a host that should not be associated with the Production Logical Network.
The downside with this as an approach is that we cannot be sure of a consistent configuration across hosts in Production – although Uplink Port Profiles are restricted to certain hosts, administrators can choose from any of the Network Adapter Port Profiles, Port Classifications and Switch Extensions that are available within the selected Logical Switch. We may also find that capabilities we want offered only on production systems - network traffic tagged with IEEE high priority and given maximum bandwidth for example – are associated with other (non-production) systems because the administrator selected the wrong Network Adapter Port Profile during Logical Switch deployment. To avoid this issue, we will create a separate Logical Switch for Hyper-V hosts in Reading and Seattle that will support production workloads (as illustrated below).
The new Logical Switch will contain the “Production – Reading” and “Production – Seattle” Uplink Port Profiles and a single Network Adapter Port Profile that we will use to ensure that network traffic from these hosts and the virtual machines running on those hosts are tagged with the required IEEE priority flags and are provided with the appropriate bandwidth guarantees. The Port Classification below is simply a “friendly” name for the Network Adapter Port Profile and will be displayed to users when they connect their virtual machines to the network.
We did not include any Switch Extensions in our example above – you may wish to include these in your Logical Switch to allow you to monitor network traffic, use quality of service (QoS) to control how network bandwidth is used, enhance the level of security, or otherwise expand the capabilities of a Hyper-V virtual switch created on a host computer. If these enhanced services should be restricted / deployed only on a limited number of hosts, you may need to consider creating an additional Logical Switch. You can begin utilizing Logical Switches without any advanced switch extensions and as the environment matures and/or your requirements change, these can be added at a later time.
In terms of our overall architecture, VM Networks are the final component we need to consider in this particular blog- in the sense that they provide the (network) interface through which a virtual machine connects to a particular Logical Network. Since all virtual machines must be connected to a Virtual Machine (VM) Network to be able to use and access network resources in SC VMM 2012 SP1, it follows that you will need at least one VM Network for each Logical Network.
If, however, you enable the Network Virtualization setting on the Logical Network (see earlier), multiple VM networks may be connected to the same Logical Network, with each one of these isolated from and totally unaware of the existence of any of the others. This concept is key to support multiple tenants (clients or customers) with their own networks and we will cover this in much more detail in a later blog.
It is important to note that the relationship between a VM Network and its (host) Logical Network is established when VM network is initially created (as shown) and cannot be changed afterwards. If you wish to use a different Logical Network, you will need to delete the existing VM Network and create a new one.
You can associate Logical Networks with each Hyper-V host manually or by using PowerShell but to ensure consistency and simplify management across multiple hosts, it is far more efficient to define the required properties and capabilities within Port Profiles and Logical Switches.
When a Logical Switch is applied to a Network Adapter in a Hyper-V Host, VMM uses the information contained in the Logical Switch and the (selected) Uplink Port Profile to create a Hyper-V Virtual Switch on the host and associate the Network Adapter with the required Logical Network(s), VLAN and IP Subnets. If you apply the same logical switch and uplink port profile to two or more adapters the two adapters will be teamed assuming that this option has been defined in the logical switch. The option to add/remove adapters (show above) will only be available if Uplink Mode has been set to “Team”.
Note: the host must be a member of a Host Group that has been scoped to those Logical Networks. If the host is not in an appropriate Host Group – deployment of the switch will fail with an “Out of Scope” error.
Returning to our example – a number of new Hyper-V hosts have been deployed in our Reading Datacenter in response to increasing demand for computing capacity in production. We need to make sure that each one of these hosts are configured for production workloads; meaning that physical network adapters are teamed (to provide maximum bandwidth and a degree of resilience to adapter failure) and associated with the Production Logical Network.
The following screenshot shows the Logical Switch being applied on one of the new servers. The administrator has selected the “Reading” Uplink Port Profile to ensure that the selected network adapters are configured with the VLAN and IP Subnets that are appropriate for this location
From this information, VMM will create a Hyper-V Virtual Switch on the host and use the Logical Network(s), VLAN and IP Subnets from the Uplink Port Profile to configure these properties on the selected Network Adapter(s). Note that once the switch has been deployed, the physical Network Adapter can no longer be configured through the UI or via PowerShell. All changes to the Logical Networks, VLAN and IP Subnets configured on the network adapter need to be made in the Uplink Port Profile.
Note: Regardless of any port profiles and logical switches you are using in your network configuration, you will need to indicate whether the network adapter will be used for virtual machines, host management, neither, or both. At least one Network Adapter in your host must be configured for management.
To quickly summarize, Logical Networks are used to organize and simplify network assignments for hosts, virtual machines and services. Network Sites are used to define the VLANs and IP subnets that should be associated with the logical network in each physical location and control which hosts (in that location) may be configured to support it. VM Networks provide the (network) interface through which a virtual machine will connect to a particular Logical Network.
You can associate Logical Networks with Hyper-V host manually (or via PowerShell) but to ensure consistency and simplify management across multiple hosts, it is far more efficient to define the required properties and capabilities within Port Profiles and Logical Switches.
Now we understand how Logical Networks are connected to a number of components in our virtual network solution. In part II of this blog post, we can turn our attention to Logical Network design and how Logical Networks act as the foundation for VM Networks.
Great post. Thanks a lot.
Please sirs can we have some more. Great post and essential.
Great Blogpost !
James van den Berg
I installed Vmm 2012 into an existing hyper-V environment running on Win2k8R2 and the system has picked up 2 separate logical networks. 2 Hyper-V hosts apear in one of the local networks and the third appears in a different logical network.
I can use network migrate whilst its like this, is it possible to change the host to a new logical network without affecting the running VM's ?
Apologies the post should read:
I cannot use network migrate whilst its like this, is it possible to change the host to a new logical network without affecting the running VM's ?
Looking forward to Part 2....any ETA?
Hey, thanks for the great info. I'd like to see if you can help me out though, I'm going through the process of using VMMT to migrate a large number of VMs from another platform to Hyper-V 2012. I can create the VM Network I need and everything looks good, but when I apply it to an existing VMMT migrated VM, I get:
The VLAN ID (X) is not valid because the vm network (XXXXXXX) does not include the VLAN ID in a network site accessible by the host.
Either specify a valid VLAN ID, or don't specify a VLAN ID and a valid one will be assigned automatically.
I'm dyin' here trying to figure out what's up. Can you help?
@ Andreas, Samuel & James - Thank you; Next one is coming very soon ;)
@Steve - We will cover this question in a upcoming post; but essentially you would want to create a new logical switch; to do this you would need to have at lease a single physical NIC on the host available to utilize with a host port profile, You can of course remove the already defined networks in your VMM environment, but you must be careful if these are live; as you could result in having these isolated, a good start is to move all the VMs off the host while you restructure it, then move them back, assigning to the relevant new virtual network.
what choice I have if we do not want user Windows network Virtulization. In another words our underlying Cisco Network create 4000 VLANS and I want to pre populate them in the SCVMM and have our cloud software decide which logical network and what Ip to assign to during VM placement. Like in the VMware you just create port on the virtual switch and teg the VLAN ID to it.
This is shaping up to be a great series, keep them coming.
One thing I have not been able to achieve in testing is the use of IP pools at the logical layer. Every time I have created a Virtual Network without isolation and assigned it to a logical network, I am not able to assign the IP pool to individual VMs. Is this meant to be limited for host addressing only?
Hi, this is a great post.
I'm working on setting up my own Hyper-V / SCVMM 2012 environment for school assginments and personal experiments. This is exactly the kind of information i need!
Please keep posting more ;)
I'm getting the same error as Brandon Lanford, can anyone assist us.
Folks, I have a M1000e with 16 blades that were all Hyper-v host in my lab that worked fine just using SCVMM 2012. I decommissioned 8 blades to reinstall WS2012 Datacenter with GUI with Hyper-v added as a role. I did this since I could uninstall the GUI
and WS2012 Datacenter turn into a core install (I like the option of having gui available if I need it). Well, I upgraded to SP1 before I added the 8 blades back to SCVMM and I am unable to figure this new networking stuff out and I'm no slouch at networking
either. MS does a great job of explaining how to do vlans, isolation-type, pvlans, logical networks, IP pools and network virtualization. What I can't find is a solid instruction on how to get my hyper-v host work on a similar network like they did before;
from my researching, its now termed the "no isolation" network (everything connected is connected to the same network). If they could get me back to where I was using sp1, I could at least get the newly build WS2012 datacenter "core" host w/hyper-v role,
added back into SCVMM and usable. Currently, I can add them back into SCVMM 2012 sp1 and they show up as host, but because I haven't figured out the new networking methodology, I can't use them from within SCVMM 2012 sp1.
I recently found a series of videos that is helping. I haven't gotten a chance to try all the stuff on the videos yet, but it looks promising. The link is:
channel9.msdn.com/search This channel9 has lots of great videos on hyper-v and a host of other MS products. Microsoft Virtual Academy =
www.microsoftvirtualacademy.com also seems to have a lot of good information (all free :-) )
These videos are as recent at April 2013.
Hope this helps someone that can figure this out and come back and help us! :-)
All, the second part of this section on logical networks covering architecture and design is just about ready to post so watch this space - hopefully it will have been worth the wait. We've split the material into a number of parts, the first one of which will be posted this week.
@Sunil, we cover logical networks and VLANs in the upcoming post. In VMM, create a single Logical Network, configuring the properties of the network to specify that “sites within this logical network are not connected”. then create a network site for each VLAN. When you create VM Networks for that Logical Network, you can manually choose which Network Site should be allocated to a VM Network or use automatic assignment
@Jon, Rick, thanks - hope you enjoy the rest of the series.
@Jon, Your VMs should pick up an IP address from the pool allocated to the logical network. Feel free to ping back with some more details on this one.
@Brandon, CypherBit, it might be worth taking a look at the logical network that's linked to your VM network to see whether there is a site defined (in that logical network) in which the VLAN is registered
@ andrej770, the no isolation network will cover in the upcoming post, you need to create a logical network, then create a VM Network linked to that network configured for "no isolation". In this case, the VM network simply acts as a “pass through” to the logical network (it emulates the behaviour that existed in 2012)
@ Nigel - OK, you didn't mention using a virtual switch at all in your quick summary. Am I to assume one is not used? In my old setup, each host still had a vSwitch I created that went with its logical network. BTW, I'm really looking forward to your next post. Great work so far sir!