One of the problems with today’s siloed IT departments is that they don’t scale very well to changing technology. The truth is, we are entering an age of tremendous overlap in IT, and virtualization is no exception.
When it comes to new Hyper-V virtualization projects, for example, system administrators are typically concerned with server issues like processing power and storage I/O. They usually don’t worry too much about the network.
But with virtual machines, the network doesn’t stop when the cable plugs into the network interface card (NIC). It extends into the inner workings of our hosts and virtual machines via the virtual switch. How you utilize this technology can affect the performance of you external storage network and even the security of your host. Additionally, how you approach the virtual network will determine the success of your virtual infrastructure as you expand and scale up your Hyper-V deployment.
When addressing a host, you need to determine your virtual network needs. Yes, some virtual machine deployments are simple, but if you are dealing with iSCSI storage, servers that require security or features like Live Migration, you need to consider how the configuration of the virtual network switch will impact performance and security.
Like physical switches, virtual switches have ports that connect the virtual NICs on the VMs. The virtual switch lives on the host, otherwise known as the parent partition. You can use it to do 802.1q trunking and tag virtual LANs (VLANs) to specific ports. What you can’t do is access the virtual switch as you would a Cisco physical switch because it doesn’t have its own operating system. Although the VMware platform has the option to add this kind of feature by purchasing a Cisco virtual switch, in many cases it hardly seems necessary.
What you do need is an understanding of your current network configuration, how specific settings are assigned and what a configuration change will do to your connectivity.
Working with VLANs
Let’s start with the VLAN, which is used in the network to provide separate subnets within the same physical infrastructure. Even though many server NICs have supported VLAN tagging, it is rarely used. Now that you are hosting several servers on a single physical server, you need to be able to send traffic from a single NIC to separate subnets. So unless you are going to provide a separate physical NIC for virtual servers on each subnet, you’ll want to get familiar with VLANs. Note that when both the physical switch port and the virtual switch on your Hyper-V server support VLANs you have the ability to break up that traffic without the need for separate physical ports.
You can set a VLAN ID for each virtual NIC from a virtual machine. This NIC then connects to a specific virtual switch that will then connect to a physical NIC. All of the VLAN ID tagging will be passed through that physical port when trunking is enabled. You can also set a VLAN ID on the virtual switch, but it only signifies the VLAN ID used by the parent partition via that virtual switch. There is even a way to set your virtual NICs to talk on multiple VLANs if necessary, but that is aWindows Management Instrumentation (WMI) change not exposed in the GUI.
If you decide to connect virtual NICs using different VLAN IDs to the same virtual switch, you will not be able to network them together because the virtual switch does not do layer 3 routing. Instead, that traffic will pass to the external network. Once there, VLAN routing rules of the external network will determine how those machines communicate with each other.
When working with VLANs it’s important to understand that you cannot make up your own standards when sending this tagging to your physical network. The VLAN IDs need to be set up at the switch and router level with full involvement of your network engineers. They will often have a predetermined configuration for VLANs that you will need to follow depending on the network need of the particular virtual machine.
In order to pass all of that VLAN tagging data to the virtual switch, you must use a physical NIC that supports 802.1q trunking and have a port on the switch where trunking is enabled. This trunking passes all of the VLANs, but the switch doesn’t allow the traffic to mix. They are really on different segments, so the trunking protocol has to be enabled to see the VLAN-tagged packets. Also, remember to set the VLAN of the switch to the VLAN the parent partition needs to communicate on.
Virtual network rules to live by
Best practice dictates that your parent partitions should not mingle with the virtual machines. Putting the host on the same network as the VMs may expose the entire host system to security issues, which may in turn expose those virtual machines on the host. When configuring for this scenario, you should uncheck the box that reads “Allow management operating system to share this network adapter.” This means you need to give the host its own dedicated NIC apart from the NIC used to push virtual machine traffic.
So how many physical NICs do you really need on a typical Hyper-V server? If you plan to use trunking, iSCSI storage, Live Migration and employ best practices for security, you should have four. If you want to play it safe with NIC teaming, multiply this by two. That gives you:
- a NIC for virtual machines using VLANs for any network segmentation needed
- a NIC for management of the host
- a NIC for the iSCSI connection, which leaves plenty of bandwidth free to send those storage packets
- a NIC for Live Migration bandwidth needs, for when a machine moves all the contents of RAM from one machine to the other without exposing those contents to the regular network
VLANs and trunking add flexibility to where your virtual machines are hosted. Take advantage of these features, but remember to keep the settings straight with your networking team. You don’t want to cause an outage because of a misconfiguration. Make sure you are communicating your needs to them so that they can provide you with matching configurations on their physical switches.
ABOUT THE AUTHOR
Eric Beehler has been working in the IT industry since the mid-90’s, and has been playing with computer technology well before that. He currently provides consulting and training through his co-ownership in Consortio Services, LLC.