Sean Wallbridge
itgroove has been busy building out our new Server 2012/Hyper-V infrastructure in support of our move to all new and shiny Exchange 2013, SharePoint 2013, Lync 2013 and Office 2013 along with our move to Windows 8 on all the client machines. We made the decision to move off VMware ESXi as our virtualization platform and onto Hyper-V as we are first and foremost a Microsoft shop. Server 2012 and Hyper-V now offer a compelling platform for virtualization and, frankly, if we can do what we want to do with products from one vendor rather than multiple vendors then so much the better. Hyper-V is no longer a poor relation to VMware in terms of performance or capabilities and, believe me, I was the most “dyed in the wool” rabid VMware user for many years so I’m not saying this just to toe the company line. I firmly believe that it’s now pretty much a level playing field between VMware and Microsoft.
During our migration we have been learning about the subtle differences between the two platforms and have had to adjust our thinking accordingly. Virtual networking, and specifically “virtual switches”, is one area where we have had to really make a conscious effort to adjust how we look at things and how we configure things. Let me explain …
In both VMware and Hyper-V you have to deal with virtual switching to “bridge” the virtual machines hosted on a virtualization host to your physical network. Both platforms allow you to create virtual switches that act pretty much the same a physical layer 2 switches and both platforms require you to create at least one virtual switch before VM’s can be connected to the outside world. But while the overall concept is the same the execution varies rather a lot between the two platforms.
VMware Virtual Switch
In VMware I can create a virtual switch and attach one or more physical NIC’s to the switch. If I create a virtual switch with 2 NIC’s then the switch would have theoretical throughput of 2Gbps assuming both underlying physical NIC’s were gigabit. When I attach VM’s to the switch the VM’s would route traffic over both NIC’s (in theory). I know in practice that traffic might “ping pong” across the NIC’s as they aren’t actually teamed together (bonded) but the point is the switch provides “bigger” bandwidth than a switch with only one NIC attached. (You can bond NIC’s for switches but that is beyond the scope of this blog.) Think of the switch as providing “load balancing” across the attached NIC’s as well as a certain amount of redundancy as the switch (and the attached VM’s) can survive a component NIC failure and keep connectivity in place. Our VMware configs usually had a couple of switches configured, each with a couple of NIC’s, and each switch would support multiple VM’s. VMware virtual switches normally do NOT have an IP assigned to the switch as underlying VMware doesn’t attempt to bind an IP to the physical NIC.
Here is the list of physical NIC’s in my lab ESXi box, one NIC is currently connected to the physical network:
And here is the current switch configuration:
In this case the switch is the default one created at installation time. It includes the single cabled NIC I have in place right now. Note that there are actually two networks configured – VM Network and Management Network. The Management Network actually has an IP address assigned as that is the IP address for the VMware host itself. In many cases when a VMware host has many NIC’s the Management Network might have a NIC all to itself. The VM Network provides switch connectivity to the VM’s attached to it and an IP address is NOT assigned to the network. Note: as there is only one NIC assigned to the switch connectivity to both the host and the VM’s would be lost if the NIC failed or was disconnected from the network.
As you can see I have now added a second virtual switch (it has a NIC that is NOT cabled in to the physical network at this point). I have removed the VM Network from the first virtual switch (vSwitch0) and added a new network, VM Network 2, to the second virtual switch (vSwitch1). Now I have completely segmented my management network (physical host access) from my virtual machine network (virtual machine access). In this case the host would be accessible from the physical network as its switch (vSwitch0) has an operational NIC attached. The Server 2012 VM on vSwitch1 would NOT be accessible from the physical network as its switch does not have an operational (cabled in) NIC attached.
And now I have removed the second virtual switch, added the second NIC to the first virtual switch and moved the Server 2012 VM back on to the VM Network on the switch. In this case both the host and the VM would be accessible from the physical network as the switch has at least one operational NIC attached to it.
VMware virtual switching is pretty configurable and elastic.
Hyper-V Virtual Switch
Hyper-V virtual switches do NOT have the same ability to bind multiple NIC’s into a switch config, at least not at the virtual switch level. Traditional Hyper-V “external switches” work on the paradigm of one physical host NIC being bound to the switch. If you have a server with a whole bunch of NIC’s then you would need to create a virtual switch for each NIC that you want to use with Hyper-V. Each switch can support multiple VM’s attached to it, just like VMware, but each switch can only have the one physical NIC bound to it.
With the advent of Server2012 and Hyper-V 3 the single NIC constraint can be circumvented by TEAMING NIC’s at the Server 2012 level through Server Manager. The resulting tNIC can then be selected as the “NIC” for a Hyper-V virtual switch and the virtual switch would then have the aggregated bandwidth of the underlying NIC’s. The caveat here is that the PHYSICAL SWITCH on the other end of the cables from the NIC’s has to also allow for port teaming either via a manual set up or via LACP.
The other thing to understand is that the virtual switch will “take over” most of the characteristics of the NIC/tNIC assigned to it. That means the virtual switch will take on the IP address – DHCP or STATIC – of the underlying NIC as the NIC is just a NIC to the Windows Server host. This is very important to understand when you are setting up Hyper-V, specially so on a single NIC server.
Here is the adapter configuration on my lab Hyper-V server:
This is pretty similar to my VMware server, I have two physical NIC’s but only one is actually cabled into the physical network at this time. You’ll also note the “vEthernet” connection, this is the single Hyper-V virtual switch that has been created on this box.
In the Hyper-V Manager on the server I see the following for the virtual switch config:
This is the switch that I created to support my first Hyper-V VM’s. It is created as an “External Network” which means that it provides connectivity between the attached VM’s and the physical network beyond the Hyper-V host. And, importantly, it is set to, “Allow management operating system to share the network adapter”. This is critical in a single NIC server or, as in my case, when there is only one connected NIC on a multi-NIC machine. This setting is analogous to the VMware “Management Network” in that it is what allows the Server 2012 host to “share” the NIC with the Hyper-V guests attached to the switch. If I had created this switch and NOT selected this setting I would have ended up NOT being able to access the HOST over the network as the switch would NOT share the NIC between the VM’s and the host (single operational NIC, remember?). When this setting is selected, the switch will take on many of the characteristics of the underlying NIC including its network address settings (DHCP or Static); therefore, the switch will bind itself to the IP assigned to the HOST.
This is a really important concept to grasp because I cannot create a switch and assign multiple NIC’s to it (as mentioned previously). If I have a server with a bunch of NIC’s and I go and create one virtual switch per physical NIC AND I select the “Allow management setting …” then I will be binding multiple IP addresses to my host and that is probably not what I want to do. In our office our sysadmin, Louis, was wondering why all of a sudden the Hyper-V host had pulled a bunch of DHCP addresses; the answer was he created a bunch of switches all of which had management turned on which, in turn, required an IP and the default setting is DHCP.
Note that the switch IP, if there is one, has no bearing on the IP’s assigned to the VM’s nor do the VM’s require the switch to have an assigned IP. If a switch has an IP then it is there strictly to provide connectivity passthrough to the host.
As you might imagine, it is not as easy to configure Hyper-V virtual networking to be as “elastic” as VMware virtual networking, VMware still outshines Microsoft in this regard. You CAN use NIC teaming at the Server 2012 level to create tNIC’s (teamed NIC’s) that can then be incorporated into Hyper-V virtual switches but there are caveats that have to be met. Your physical switches must “understand” how you have teamed the NIC’s and be configured (or configure themselves) accordingly. Also, depending on how the NIC’s are teamed there is the possibility of tNIC failure if an underlying teamed NIC fails. If a tNIC in a Hyper-V switch fails then the switch itself will fail. This is very different behaviour from that of the VMware virtual switching that I have discussed and it is something you need to understand as you move from VMware to Hyper-V.
Conclusion
VMware still has the edge on Microsoft when it comes to simple virtual switching (and simple is what we deal with in the SMB world). But the edge is slim and Hyper-V does offer real value and a compelling use argument. Like anything else in IT, you need to understand the strengths and weaknesses of the products you select and design your environment accordingly. I hope this discussion of VMware and Hyper-V virtual switching will help you in your endeavours.
Good article with simple explanation. That’s more than confirmation to what I want to figure out. As you said, Hyper-V Switch then only like NIC replication, or say it virtual NIC, taking over Host Connected NIC config and attributes.
In my case, the problem comes that we cannot differentiate Host NIC and VM NIC statically, even within same subnet. Of course that can be resolved by more complexity steps: add NAT and RSAS feature.
Good article with good explanation for one from VMware with many questions. But I have still a question/problem not answered after reading:
For testing I install a hyper-v “testhost” with 1x NIC, which get its IP from a phy. router(OK). After add role hyper-v with one external switch, shared the NIC, I get a new “NIC” – vEthernet(externalVS) , which has an IP from the router(OK). I create now a VM with 1x vNIC which connects to the ExternalSwitch. In VMware the VM should get an IP from the external router, because of “brideged”. But I get hier as a VM in Hyper-V only “169.254.x.y”. But if I set a static IP for this VM, there is no problem to connect external network. Why? (For learning Hyper-V 2012 I installed Hyper-V host on an ESXi5.1 , not a phy. Host. Maybe this is the problem?). Thanks.
Hi:
I’m not sure I completely understand your question but I’ll try to respond. Hyper-V will bind a NIC to a Hyper-V switch and then “pull” that NIC away from the host UNLESS you tick the box, “Allow management operating system to share this network adapter”. If you tick this box then BOTH the Hyper-V host AND a Hyper-V guest assigned to the Hyper-V switch can use the NIC. If you are working on a Hyper-V host with only ONE NIC then you would have to tick the box or you would cut off your host form network access as Hyper-V would grab the NIC only for the Hyper-V guest. My guess at this point is things are broken because you have tried to run a Hyper-V host as a VMware guest and the Hyper-V networking cannot make the bindings it needs to make because there is nothing physical for Hyper-V to attach to. This is not unusual when you try to run one hypervisor technology inside another. In other words, you are probably NOT going to get a Hyper-V guest to work properly from a Hyper-V host that is actually a VMware guest. You need to install Server2012 directly on a physical host in order to create usable Hyper-V guests.
Thank you so much. I’d like to be confirmed, that if my Hyper-V host is a phy. one, the VM will get his IP from the router on the external (phy.) , network, do same as VMs in VMware with “brieged network”. (This DHCP problem is one, that I can’t confirm without a phy. Hyper-V host. Maybe I’ll have more unexplained problems in such nested VMs, I don’t need to search the reasons…)
Yes! If you do all of this on a physical host and set the Hyper-V switch up correctly then your Hyper-V guest VM will get its IP from DHCP on the network (if that is how you have set up the VM) or will work on the static address you assign to the VM. The HOST will also work on its IP. All of this assumes that if you have only one NIC on the host that you have assigned the NIC to the Hyper-V switch and have allowed the Management OS to share the NIC. On the HOST the active NIC will be the vEthernet NIC created by the Hyper-V switch. This is a bit different from VMware but not totally dissimilar to the first VMware vSwitch that gets created that binds VMware management to that switch and the adapter. If you have a Hyper-V host with MULTIPLE NIC’s you could create Hyper-V switches that use all the NIC’s but one and not have any of the Hyper-V switches set to allow the management OS to share their NIC’s. In this case the host would “see” only the one NIC that is not assigned to the Hyper-V switches. Hopefully this answers your question, if not then send another reply and I’ll see if I can clarify further for you.
Thanks for this article! Virtual networking is one of the more challenging differences to grasp when moving from the VMware to the Hyper-V.
Jay:
You are very welcome. I agree, the networking thing is very different and, truth be told, Microsoft has a ways to go on this to make it equivalent to VMware. The other big challenge is “vConvert” for Hyper-V. I’ve used a Microsoft supplied tool to convert ESXi VM’s to Hyper-V and it was “okay” but no raving hell. P2V tools are also thin on the ground. I’m going to post at some point on my experience with those tools.
Thanks for the post. But what is IF I actually got two NICs I want to connect to one vSwitch. I dont speak about teaming.
Let’s say I want to connect another PC directly to my Server through a second NIC. This should then used in the virtual guest. Its the same network. You see I go somehow for bridging here…but can’t really find any tutorials how to do this…
You can’t do this the way that you want. A Hyper-V virtual switch can only contain a single NIC unless you bond NIC’s (which you have said you don’t want). I know there is a way to add nics at the virtual machine level for clustering purposes but that also does not serve the purpose you state. And I’m not really sure why you would want to do this. Are you trying to make the VM multi-homed? If you are just wanting to add a second IP to the VM on the same LAN then you can do this through the IP settings on the NIC in the VM and just add a second IP address.
Hi there! First off, great article and thanks for writing this and sharing with everyone!
Just one quick question about tNICs. Let’s say you have two 1 Gigabit NICs that formed a team. Does this theoretically give you a 2 Gigabit NIC? For VMWare’s virtual switch, that doesn’t seem like the case here, as traffic just ping pongs between either NICs?
To put it simply, I think of VMWare’s version as having 2 separate roads, where cars may be more congested on one road or the other, but both are usable. Whereas for Hyper-V or Windows Server’s NIC Teaming, it’s 2 roads combined into one huge road.
Just wondering if that’s correct or not? Thanks.
Hi!
As I said in my post, I was not talking about bonded NIC’s so the comment about traffic ping ponging is correct. You CAN attach bonded NIC’s to a VMware switch and gain the benefit of the bandwidth associated with bonding but, to be frank, I’ve never done it with VMware so I can’t comment much more. There is a procedure that you have to follow to bond the NIC’s that VMware and the hardware vendors document. Also, you need to understand that when you bond NIC’s the switch they talk to also have to have bonded ports (most forget this) in order for the bonding to operate correctly.
Robert