One of things I’ve noticed in the last two of more years is how “fuzzy” I’ve become about basic vSphere settings and options. The reasons why are many varied, but my fuzziness comes from no longer being an active VMware Certified Instructor. From about 2004-2009 I was regularly standing up in front of groups of 4-12 students working our way through the vSphere Platform. The other reason for my fuzziness is that I’ve been so focused on Site Recovery Manager and View/EUC issues that platform kind of disappeared into the background. Once your using other products that merely sit upon vSphere pretty quickly the nitty-gritty of individual settings becomes a bit of blur. The truth is if you don’t “use it” you “loose it”, and information that used to be at my immediate recall just isn’t there in the way it used to be. It’s either that or early onset Alzheimer’s!
Such is the case with “Port Binding” settings on Distributed vSwitches – these are important in a vCloud Director environment where the usage of ports on the switch is much more dynamic, and potentially of a larger scale if your working towards a multi-tennacy environment. I want to use this blogpost as way of re-enforcing those settings in my mind, but also to explain some of the new port binding options in the vSphere as they are used by vCD. Those new options might start you to re-think of the best method to allocate those port values.
To recap. Distributed vSwitches have port binding settings which appear on the properties of portgroup. In vSphere5.1 the web-client exposes new options for “Static Binding” that are NOT available under the ye olde C# vSphere Client:
So firstly you will notice that “Static Binding” has a new option for either elastic/fixed “port allocation”. It might seem a perverse use of English to talk of a portgroup having a static binding with elastic port allocations – but stick with me, it does make sense! The other important thing to know, is that Dynamic Bindings are “depreciated” and no longer recommended. This is something you will see if you select this type under the web-client. Despite the exposure in the UI for this reason I’m going to ignore the usage of “dynamic binding” altogether. I imagine the “support” for dynamic bindings in vSphere5.1 such as is it is merely there to allow for a smooth upgrade from one version of the platform to another.
I actually like the new interface because it seperates out – how ports are assigned from the process by which new ports are created. The term “binding” really refers to how the VM is assigned to the port – how those ports are consummed is a seperate matter. So there is a difference between “port binding” and “port allocation”. The port binding really is policy settings about what happens when a VM is powered off (does it release its grip (binding) on the port and allow another VM to use it OR does hold on the port for the next power on). Whereas the port allocation is about how new ports are generated (or allocated).
In the past it was ephemeral binding that was recommended in vCD for things like externel networks. This is was because these a manually created in vSphere, and assigned when you create an external network in vCD. This means they inherit the defaults settings unless the vSphere Admin changes them. In contrast portgroups created by vCD when needed such as VLAN/vCD-NI backed network pools would have the correct settings automagically assigned. The worry as ever is if the allocation was fixed, then you could run out of ports on the switch for power on events. If there isn’t a port then the VM within a vApp would produce an error.
Ephemeral binding allows new ports to created on demand at will. In fact if you select it you cannot set a number for the ports. It just keeps on creating new ports for new VM on demand, untill you reach the configuration maximums. With ephermeral there are no “port bindings” when a VM is powered off it releases the port it used, and it can be assigned to another VM. This sounds great on paper – but because the VM is never “returned” to its originally assigned port it makes monitoring and tracking the VM difficult with other systems. Although it “solves” the problem with the fear of running out of ports, the solution doesn’t offer the best result in environments where knowing precisely which port the VM is on is important.
Static Binding on the other hand maintains the affinity of the VM to the port it was assigned whether it is powered off or on. That allows for the track & trace of the VMs network port assignment. The trouble was if the default port value of 128 was used you could quickly run out of ports if you weren’t careful. vSphere5.1 introduces a new option – to allow for the functionality of “static binding” with a different way of controlling how the ports are consummed. With Static Binding+Elastic the default number of ports is 128, and once these are consummed another 8 ports are generated. With Static+Binding+Fixed – the default number of ports is 128, and when that allocation is met, no new ports can be generated. By using Static Binding+Elastic you get the benefits of the track and trace, without the fear of running out of ports. The new “elastic” option sort of makes the dynamic binding redundent. What confused me was some of the documentation around static binding. When you create portgroup manually on the Distributed vSwitch it defaults to 128 ports, but some of the documentation talks about there being 8 ports, and it expanding by the factor of 8. It sounds like that information is equally correct – because it describes what happens if portgroup is automagically created by vCD as can be seen in this screen grab:
So the default for vCD generated portgroups on a Distributed vSwitch is Static/Binding/Elastic and 8 ports at a time…