The Great vSwitch Debate – Part 8 (Final)

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:

                SAP_Prod_VLAN123
                SAP_Dev_VLAN224
                Mail_DMZ_VLAN400
                VIAdmin_Admin_VLAN10
                WinAdmin_Admin_VLAN11
                Backup_Backup_VLAN543

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!

About these ads

Tags: ,

About Ken Cline

vExpert 2009

29 responses to “The Great vSwitch Debate – Part 8 (Final)”

  1. Dave Convery says :

    Ken –
    I finally sat down and read through all 8 posts! *GASP*. Excellent work!

  2. Allen says :

    Nice post. I read this as I was in the process of renaming just about all of our port group labels. Our environment basically outgrew the original naming convention, so it was time to fix that. I pretty much used the exact same naming convention funny enough, except no underscores or “VLAN” (I just put the # on the end without the acronym “VLAN”). I feel validated now…

  3. r spangler says :

    Nice groups of articles, thanks!

    What would someone have to do to become your student? I’m a veteran network person who sees the potential of this and cloud computing and want to be part of it. I liken it to the Novell and MS take off in the 80’s but with more dimensions and depth.

    I’m currently looking for a position that will let me grow into a technology while contributing softskills and previous experience. Is that possible?

    Feel free to ignore this nut, but I really am looking for a new horizon and place to contribute to. VM seems to be the recommendation from my groups of friends.

    Thanks,

    Roger Spangler

    • Ken Cline says :

      Hey Roger,

      Well, by reading this blog, you are effectively my student. There are lots of really great bloggers who share their knowledge freely. If you haven’t yet found Eric Seibert’s vmware-land.com and vsphere-land.com, I encourage you to pay the sites a visit. Eric has done a great job of collecting a list of relevant sites about VMware technology. Use his site as a springboard to find other bloggers and content providers. You’ll have more than enough to keep you busy for a long time!

      Yes, it is very possible to find the type of position you’re looking for. Bring yourself up to speed on the technology (you can run VI-3 and vSphere inside VMware Workstation for learning purposes – evaluation licenses are free). Hang out on the VMTN forums (communities.vmware.com), and jump in with both feet!

      Best of luck,
      KLC

      • Ami says :

        I’ve accomplish installing the vSphere on a ws6.5.2 but it does not allow to power up any VM – any ideas (Besides license)

        10x

      • Ken Cline says :

        My first guess would be that your host system does not have VT (or AMD-V) technology or that it has it and it’s not enabled…

  4. ak says :

    Hi
    Excellent stuff If you can cover Distrubited switch in the same lucid and depth in part 9 (OK i am greedy these are so insightful I cant help) and Nexus 1000v in part 10 it would be great for lesser mortals like me !!

    • Ken Cline says :

      Hey ak,

      Give me time :)

      I’ll get around to covering the new features before too long.

      Thanks for the comment,
      KLC

  5. David says :

    Where is Ken? When are we going to get more excellent posts? Hello anyone there?

    • Ken Cline says :

      Hi David,

      I fell off the edge of the Earth and am struggling to get a hand hold to climb back on! Life has been hectic and time to write has been scarce. I will get back to it shortly, I hope.

      Thanks for stopping by – and keep checking back. One day you will be surprised to find another article or eight :)

  6. Chris says :

    Ken –
    I just found this blog and I have to say, great articles. This is what I have been looking for.

    I would like to pose a question to you or anyone else out there who wants to contribute. We are using vSphere4 and have purchased Enterprise Plus although we are a relatively small shop. I really like the dvSwitch feature. Not having to recreate vSwitches on each host is very nice and makes it easier to manage. Before I ask my question, I want to say, I noticed how you seem to recommend separate vSwitches with separate pNICs. I understand the reasoning for separate pNICs but my question is, why not create one dvSwitch with 8 uplinks and create different Port Groups? Then, you can assign each Port Group to two Uplinks on the dvSwitch and still obtain pNIC seperation. (If I could attach a drawing I would)

    To provide an example, our current environment consists of three hosts, each with 8 pNICs. There is one dvSwitch with 8 uplinks and 4 Port Groups. Each Port Group gets 2 uplinks assigned to it as the active NICs. For redundancy, there are two additional uplinks assigned as Stand-by NICs. (These are all spread around equally. No two pairs of active uplinks are the same stand-by uplinks for other port groups) I hope I described it clearly enough.

    My ultimate question is: Is this a proper/secure configuration? And if not, what would be the correct way to go about it?

    Thanks for your time and the great blog.
    Chris

    • Ken Cline says :

      Hi Chris,

      Absolutely nothing wrong with your configuration. It is a perfectly proper & secure configuration. The only time you would have the possibility of a security issue would be when you’re using a standby NIC that is also serving as an active NIC for another function. To help protect against that eventuality, I would recommend the use of VLANs to separate traffic (see my reply above concerning VLANs and security).

      Thanks for stopping by!
      KLC

  7. vedDupZedge says :

    Waow enjoyed reading this article. I added your rss to my google reader.

  8. Sherwyn aka Infolookup says :

    Ken,

    I just started reading part one but was wondering if there is a PDF version of all the parts, I am working on a project and this will come in real handy to read digitally offline.

    All the same excellent contribution.

  9. Frank says :

    Hi, This post are very good, cuold you do similar post for the new vDS in Vpshere? I like see your impresions for this configurations in vDS enviroments.

    Thanks for all

  10. Daniel Myers (@Dmyers_) says :

    Thanks for this set of articles, Excellent reading and very educational!

  11. Todd says :

    Ken,

    Excellent article, I made it through all of them. Being a past VMW SE and continued enthusiast on the topic. I still found many good tips and info. Sure would be nice to see an update on utilization of 10GB and design criteria.

  12. Andrew Miller says :

    Erm….I hate to be picky and contradict but the first vSwitch (created during ESX/i install) is actually vSwitch0.

    An update around dvSwitches and/or Cisco Nexus v1000 at some point would be fantastic.

    • Ken Cline says :

      Yes, you’re right (re: vSwitch0), and I know that! Sometimes my fingers and brain become disconnected from one another, allowing my fingers to say things they’re not supposed to say…

      I’ve been thinking about a dvSwitch update. I can’t seem to get beyond thinking ;)

  13. Ajay says :

    Hey ken!

    If i explain something about vSwitches to anybody from now on, you bet all the credit will go to you.

    I consider myself fortunate to have come across this series of yours. SO much so that i have completed all the eight parts in a single sitting. thats how good your writing has been. saying thank you to you, will be an understatement.

    Thank you much. This will now definitely help me crack vDS.

  14. 54 says :

    thank u very much, much impressed with your detailed eloboration

  15. bh says :

    Perfect. I’m from China. I like your post. It’s very helpful.

  16. Brendan says :

    Cheers for your time creating these posts! Brilliant… Have you had chance to get past your ‘thinking’ stage for episode 9!! Thanks again

  17. carl says :

    a must read article pertaining to vswitch networking side

Trackbacks / Pingbacks

  1. The Great vSwitch Debate – Part 8 (Final) | Revolusionline - December 4, 2011

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 34 other followers

%d bloggers like this: