Before we looks at this new networking feature of W2012 Hyper-V, lets look at what we have been using in Windows Server 2008/R2. Right now, if you create a VM, you give it one or more virtual network cards (vNICs). Each vNIC is connected to a virtual network (basically a virtual unmanaged switch) and each switch is connected to one physical NIC (pNIC) or NIC team in the host. Time for a visual:
Think about a typical physical rack server for a moment. When you connect it to a switch the port is a property of the switch, right? You can configure properties for that switch port like QoS, VLANs, etc. But if you move that server to another location, you need to configure a new switch port. That’s messy and time consuming.
In the above example, there is a switch port. But Microsoft anticipated the VM mobility issue and port configuration. Instead of the port being a property of the virtual network, it’s actually a property of the VM. Move the VM, you move the port, and you move the port settings. That’s clever; configure the switch port once and now it’s a matter of “where do you want your workload to run today?” with no configuration issues.
OK, now let’s do a few things:
- Stop calling it a virtual network and now call it a virtual switch.
- Now you have a manageable layer 2 network device.
- Introduce lots of new features for configuring ports and doing troubleshooting.
- Add certified 3rd-party extensibility.
We have different kinds of Virtual Switch like we did before:
- External – connected to a pNIC or NIC team in the host to allow VM comms on the physical network.
- Internal – Allows VMs to talk to each other on the virtual switch and with the host parent partition.
- Private – An isolated network where VMs can talk to each other on the same virtual switch.
Although I’m focusing on the converged fabric side of things at the moment, the extensibility is significant. Companies like Cisco, NEC, Five9, and others have announced how they are adding functionality. NEC are adding their switch technology, Five9 are adding a virtual firewall, and Cisco have SR-IOV functionality and a Cisco Nexus 1000v that pretty much turns the Hyper-V Switch into a Cisco switch with all the manageability from their console. The subject of extensibility is a whole other set of posts.
With a virtual switch I can do something as basic as this:
It should look kind of familiar I’ve already posted about NIC teaming in Windows Server 2012. Let’s add a team!
With the above configuration, the VMs are now connected to both the NICs in the host. If one NIC dies, the team fails over and the VMs talk through the other NIC. Depending on you load distribution setting, your VMs may even use the aggregation of the bandwidth, e.g. 2 * 10 GbE to get 20 Gbps of bandwidth.
With NIC teaming, we have converged two NICs and used a single pipe for VM communications. We haven’t converged any fabrics just yet. There’s a lot more stuff with policies and connections that we can do with the Virtual Switch. There will be more posts on those topics soon, helping us get to the point where we can look at converging fabrics.