Welcome to the vSphere 5.1 Deep Dive Series, focused on announcements made at VMworld 2012 US. You can click me to return to the directory.

Another VMworld is upon us, and promises to yet again unleash a hurricane of excitement around the various products and services that are offered by VMware. Through some good fortune, I was invited to participate in an early access program so that I could digest the fruits of VMware’s labor a bit early, and deliver content to you in a longer form, lab tested format. All of the technology presented here has been verified and “tinkered with” in the Wahl Network lab on VMware ESXi 5.1.0 build 613838 (beta).

This deep dive series will go into all of the awesome goodies that are baked into the newly released vSphere Distributed Switch (vDS) in version 5.1. I’ve broken the posts up into 4 different parts so that you can sample them at your leisure without having to run through a 40 mile long post. Here are the links to the entire series:

Without further ado, let’s get started.

Embrace The Web Client

My long time friend and enemy, the vSphere Client, is slowly shuffling off into the corner as his spiffy new buddy takes the spotlight. The vSphere Web Client is officially taking the position of lead access method moving forward past vSphere 5.1. While VMware has made the comment that they will continue to support the vSphere Client (which you may also know as the Windows Client or the Thick Client), new functionality and features will be tightly integrated with the Web Client.

I’d highly advise that you begin getting comfortable with the Web Client. After using the vSphere Client for many years, I can say that the Web Client does take some getting used to – often times I’d have both open and fight the urge to switch back. That being said, the Web Client has a ton of functionality in it, requires no install (yay), and has many features that the vSphere Client simply does not have (such as multitasking, scalability, etc.).

Since this is a vDS deep dive, I’ll spotlight a few differences I noticed between the two clients right away.

Creating a vDS

When creating a vDS, the first few screens look almost identical to the vSphere Client. As seen here, I have selected the new vDS version 5.1.0.

The third screen offers some neat functionality that is missing in the vSphere Client. Not only can I toggle NIOC (enabled by default), but I can edit the default port group name. Normally I just decline the offer to make a default port group because it’s a name I don’t like (dvPortgroup). Here, I can make my first one and name it. Nothing earth shattering, but a thoughtful improvement.

Managing Hosts on the vDS

I am pointing this out because I was confused the first time I saw this. When you go to manage hosts on a vDS, the list is empty by default. I thought perhaps I stumbled upon a bug or did something wrong. In actuality, I just needed to press the “Choose Existing” button (highlighted below) to see the hosts that belonged to the vDS.

Now, on to the good stuff.

Network Health Check Overview

The new Network Health Check feature is top of my list of exciting new features in the new vDS 5.1. It offers administrators the ability to check for a few common misconfiguration errors before you ever put a virtual machine or VMkernel port on the wire.

Per VMware:

This tool is very helpful in an organization where the network administrators and vSphere administrators respectively take the management ownership of physical network switches and vSphere hosts. In such organizations vSphere admins can provide the network related warnings to the network admins and help identify issues quickly.

The Network Health Check feature looks at three distinct configurations: VLAN, MTU, and Teaming.

VLAN Mismatch

In a VLAN mismatch case, the virtual switch VLAN does not match an available VLAN on the physical switch. I think this is a rather common issue from a day-to-day perspective. For example, say that you want to use VLAN 555 for virtual machine traffic on a portgroup. If VLAN 555 does not exist on the physical switch, you won’t really know about it unless you pass some traffic on the switch first (typically by throwing a VM onto the portgroup and seeing if it can ping something). Those days are over!

As seen here, my lab host has a vDS configured named “WahlNetwork-vDS1” with Health Check enabled. I have created a number of different portgroups using VLAN 10, 254, and 555.

Only VLAN 10 exists upstream on the physical switch and shows a VLAN Status of “Supported” while all the others are “Not supported”. I am now aware that I need to check the physical interface to see what VLANs are assigned or use a different VLAN on my virtual switch (in a normal situation I may have simply entered the wrong VLAN number). Also in this example below, I want to emphasize that I have no virtual machines running at all – the Health Check can operate with absolutely nothing on the portgroup.

Under the hood, the vDS is sending some broadcast frames out to see if the VLAN exists. Note that this essentially limits the checking to the access layer, and will not flow further to the distribution (aggregation) or core layers.

MTU Mismatch

The new Network Health Check feature is also able to find MTU mismatches from the vNIC, virtual switch, physical adapter (vmnic), and physical switch port. This is very handy in the use case of Jumbo Frames, as there are a lot of touch points that require setting an MTU of 9000.

Teaming Mismatch

The final check is for a teaming mismatch. If the physical switch is configured for EtherChannel (or Link Aggregation Group), you are supposed to set the portgroup to use a teaming policy of IP Hash. The Health Check will identify when a mismatch occurs.

In the case below, I have enabled IP Hash on a portgroup on a set of uplinks that are not in an EtherChannel. This creates a mismatch, as the virtual side is set to IP Hash while the physical side is not.

Alarms

The checks also produce alarms in vCenter that can trigger an event of your choosing (such as an email), so you don’t have to poke your nose into the Monitor section of the vDS all the time. This could also be a great watchdog for ensuring that no changes are made throughout the day, or be something you have send an alert to your network team so they can promptly correct any changes that were made.

Thoughts

VMware has really done a great job at listening to their customers, both directly and from a support case standpoint, to build in a feature that administrators really needed. Moving forward, you can now validate that the network is healthy prior to deploying virtual machines, and without having to read through configuration dumps or have a read only access to the physical switches. Additionally, if a misconfiguration does exist, you learn about it in a manner of seconds, rather than having to test yourself.