One of my resolutions for 2013 is to write and post articles more frequently. Here's my first attempt.

At my company we are heavy users of VMware/ESX/ESXi. It's what we have used for well over 8 years. One of the reasons why: it just works, it's stable, and (as it related to this post) the virtual networking is just simpler (in my opinion).

We are heavy users of VLANs in our virtual infrastructure. Each VLAN has a purpose: production workloads, test workloads, management devices, virtual desktop infrastructure (VDI), utility servers, etc. With VMware's networking implementation it is fairly straightforward:


. Create a virtual switch (Standard or vDistributed)
. Assign physical NICs to the virtual switch
. Create a port group
. Assign a VLAN ID to that port group
. Assign a NAME to the port group


It's not quite as simple as that: adding physical NICs, trunking VLANs at the physical switch, etc, all has to be done but you get the gist.

That last point in the list above is key - each port group has a name. If one wants to change to which VLAN a particular VM is connected, just change the port group in the VM settings and assign it to another port group - by name. One only has to remember the VLAN ID once when creating the port group and then it's done.

Now shift to (my understanding) of how Hyper-V networking and virtual switches work:


. Create a virtual switch
. Choose External, Internal, or Private
. Assign a single NIC or NIC team to the switch
. Choose whether the management OS can use the adapter
. Assign a VLAN ID for the management OS if appropriate


Here is where my dislike of Hyper-V network steps in. When one creates a new VM and it must be assigned a particular VLAN it has to be done by VLAN ID number and not using a friendly port group name.

I assume for most admins this configuration setting is not a large inconvenience as they may only have 3 or 4 VLANs. However, what if you have 10 or 15 or 50 VLANs in your environment? Every time you create a machine you have to know which VLAN ID number corresponds to the proper network segment for your new Management VM, or your new SQL server VM.

We also had some stability issues with Hyper-V 2008 R2 with regards to Live Migrations and Storage Migrations getting stuck thereby placing that VM in limbo. I'm sure that Microsoft has done much work in improving the stability of these features in Server 2012, but that VLAN issue hasn't changed from the preliminary testing I've performed.

All of the other features provided in Windows Server 2012 and Hyper-V look incredible and if stability has improved then we'll have to look long at hard at using Hyper-V as our baseline hypervisor. However please Microsoft, don't make use memorize 50 VLAN IDs, and don't introduce some crazy new VLAN name service we have to install. How about a nice concept like the VMware port group?

I'll post more about our Hyper-V 2012 testing soon.

Thanks for reading.