Blog Archives

vSphere – Networking – ESXi Single NIC VDS Management Migration

Well, I wasn’t sure how to name this blog as VMware continues to use all kinds of different lingos for all of their bells and whistles. I had the unique opportunity to begin working with migrating management interfaces or also know as vmkernel interfaces around from VSS to the DVS switching. This present a lot of struggles but it seems to me that VMware has really improved this functionality in the later versions of vSphere. I recall running into many kinds of issues when doing this on 4.0. So far using a vCenter 5 server with a mix of 4.1 and 5.0 host testing has proved to be seamless and non-interruptive. However, I would still highly recommend considering all your options and testing this method THOROUGHLY before ever touching production environments.

I was able migrate a single physical NIC running ESXi management from a VSS to a VDS. This video covers how I did that. The reason for the video was because I got all kinds of senseless google links when trying to search for something documented. So, I did myself a favor and published one.

Remember, this is a test and this is only applicable for me to use in a few environments. In most cases I use redundant NICs. Now the real kicker about this is that to migrate from a VDS to a VSS requires a bit more thinking and planning. Especially if you only got access to a single PNIC. Maybe I will cover that some other time… for now try to use two. Also, this may be a solution for environments running single 10GB and need to use PVLANS or centralize managment.


Network Troubleshooting 101 – vSphere VM Guest (Updated)

General Information (VMware information): (Updated)
What is Beacon Probing?
Well, if you don’t know I would give the following Kb a read.
You can find that here:

Let’s hope I can do this some “Justice”

A few weeks ago I ran into an issue where VM NICS would just randomly go down. The only way I could get them back online was to perform a vMotion of the VM to another host and resetting the port connection on the dvSwitch seemed to fix the issue. So essentially I wanted to highlight some basic troubleshooting steps and things you can do to help you better pin point where the issue may be occurring.

  1. From the Guest VM having the issue attempt to ping any other VM on the same host, switch, and portgroup. This will allow to pin point the issue to see if it is related to the physical or virtual networking.
  2. Enabling Beacon Probing can help detect upstream failures. (Be sure to read up on it) Enabling beacon probing will increase bandwidth utilization and CPU cycles on an ESXi host so simply consider the tradeoffs.

Why I need to enable it?
VMware recommends to  introduce this change for either permanent or temporary use. Beacon probing as stated above can help or allow us to detect other failures which may occur upstream. When the failure occurs on the VM this will help you isolate the issue as being related to the VMware Virtual networking or the Physical switching (So can troubleshooting). If the failure happens on the VM and the Virtual Switch uplinks trigger an alert this will help you to pin point the issue.

Implementation Instructions:

Enabling Beacon Probing for Distributed Virtual Switch for a vCenter:

  1. Before enabling Beacon Probing I will engage James Hendrock to get Bandwidth utilization before and after enabling Beacon probing.
  2. Log on into the vSphere Client and connect to any vCenter you want to change it on
  3. Browse to Home > Inventory > Networking
  4. Expand the following objects in the tree to the left: (see figure)
  5. Right Click a Port Group under the dvSwitch switch > Edit settings…
  6. Highlight under policies the Teaming and Failover: (see figure)
  1. Select Network Failover Detection Dropdown (should currently say Link Status only) > Select Beacon Probing (see figure)
  2. Click Ok
  3. Repeat steps 4-7 for all other Port Groups on dvMgmt dvSwitch.

Take Away:

  1. Beacon probing is best used with a 3-pNIC configuration with even a N+2 Switching design being highly recommended
  2. Beacon probing configured with 2-pNICs means that whether or not you use it in a N+1 configuration it will detect a downstream failure but it has no way of knowing which uplink is bad.
  3. In a 2-pnic configuration if one fails it will trigger a redundancy lost message but at the same time just shotgun traffic down both pNICs to ensure communication is sent.
  4. If you are going to use Beacon Probing you must also consider the network design.

Resources: 0 273356736 0 273356736

***Disclaimer: The thoughts and views expressed on  and Chad King in no way reflect the views or thoughts of his employer or any other views of a company. These are his personal opinions which are formed on his own. Also, products improve over time and some things maybe out of date. Please feel free to contact us and request an update and we will be happy to assist. Thanks!~

%d bloggers like this: