OK, I promised, so here we go! The other seven parts of this series have all dealt with the technical aspects of vSwitches, pNICs, Port Groups and such. This part will deal with the more mundane aspect of naming standards. While maybe not as glamorous, this is definitely one of the most important aspects of building your virtual infrastructure. Oh, by the way, the names I used in this series of article (i.e. PG_APP1, PG_VMotion, etc.) are really bad names for a production environment!
A naming standard is exactly what the title sounds like – a standard for defining the names of things. In my opinion, a naming standard should achieve a couple things:
- Provide a simple, consistent method for assigning names to objects – there is nothing “arbitrary” about a naming standard
- Be flexible enough to accommodate most, if not all, use cases
- Provide an effective means for all parties involved to understand what is being described
While these may seem really obvious and simple to achieve, there can be alligators hiding just beneath the surface!
The first two are, indeed, fairly simple. It’s that third bullet that can cause heartburn. Why? Because there are so many parties involved! First, you have the ESX administrators. They need to be able to accurately connect a virtual machine to the proper port group. Failure to do so could result in a VM that is unable to communicate, or worse, a VM that can communicate on the wrong network! Next, you have the OS administrators who are responsible for administering the guest operating system within the VM. They have to be able to effectively communicate to the ESX admin which network to connect the VM to. This person has absolutely no idea what a “port group” is and they’re not interested in learning…it’s just outside the scope of their responsibility. And if you think the OS admin doesn’t know what a port group is, imagine what the application admin knows!
So, up to this point, we’ve got three different points of view. We’ve got an application administrator who knows that his application needs to be on the SAP network; an OS admin who wants his VM connected to the production network; and an ESX admin who doesn’t care what the functionality is – he just wants to know what port group to connect the vNIC to. Oh yeah, there is one other group who has an interest in this whole thing – the network admins. These folks don’t know about applications, don’t care about operating systems, and stare at you blankly when you mention port groups – all they understand is that a host system needs to be connected to a particular VLAN number!
As you can see, the real challenge of defining a naming standard is developing a common vernacular so that everyone understands what everyone else means when they identify their network. I’ve seen all sorts of standards put into use. Some are better than others, and some are simply miserable!
Virtual switches are actually very simple to name…accept the default value of “vSwitch#” where # is the incremental count of vSwitches that have been created. The first vSwitch to be created will be “vSwitch1”, the second will be “vSwitch2”; I think you get the idea, so I’m not going to spend any more time on vSwitch naming.
Port Groups are another matter all together! By default, when you install ESX, there will be a single vSwitch created (vSwitch1) and it will have two port groups created on it. These port groups will be named “Service Console” and “Virtual Machines” to reflect their intended usage. This is a valid naming convention (i.e. name the port group based on the services that will be connected to it), but it does have some limitations. Think back to our discussion above. The ESX admin will feel right at home, but does “Virtual Machines” mean anything to the application administrator? The OS administrator? Or the network administrator? Probably not.
This is a prime example of a name that doesn’t fulfill our stated objectives. So, what is a good naming standard? Well, let’s consider everyone we have to satisfy:
- Application Admin: We need to be able to let the application administrator communicate the function of the port group
- Server OS Admin: Needs to be able to communicate the environment into which the VM needs to be placed
- ESX Admin: Will be creating the port group and assigning the name. Is also responsible for actually connecting a vNIC to a port group. Needs to be able to understand what his customers are asking him to do
- Network Admin: Needs to be able to communicate and understand where the vNIC needs to reside within the overall network infrastructure
So, a possible option for a naming standard could be something like this:
SAP Prod VLAN123
This is actually pretty good. We know that the port group is used to support the SAP application in the production environment and that it lives on VLAN 123. There are a couple of issues with this standard, though. The biggest “problem” from my point of view is the use of spaces. Spaces do not cause a problem in a virtual environment; however, they can present an interesting challenge when it comes to automation. Spaces are viewed as delimiters in most scripting languages, so if your script developer (or the script developer of the third-party product or the guy on the Internet who developed a cool script) isn’t careful, you can have some “unexpected behaviors” at some point in the future.
It’s actually a simple matter to protect against this type of scripting error: don’t use spaces in your naming standard! So, you could name your port group something like this:
Now we have a standard name that is easily understood by all parties involved and protects against poor scripting habits. While this is certainly not the “end-all and be-all” naming standard, it does meet our stated goals. You should look at your environment and develop a standard that meets the requirements identified above plus whatever other requirements you may have. If you can do that – and stick to it – you will have a virtual networking stack that meets your needs and is simple to administer. That’s my definition of goodness.
I’d like to thank you for taking the time to read through this series of articles. It’s been an interesting challenge for me to commit all of this to “paper” and I hope you’ve found it useful. Look forward to more stuff from me in the future!