Configuring vNetwork Distributed Switch for VMware View

A vNetwork Distributed Switch is an aggregation of per-host virtual switches presented and controlled as a single distributed switch through vCenter Server at the Datacenter level. The vDS abstracts configuration of individual virtual switches and enables centralized provisioning, administration, and monitoring.


It is not hard to realize how a VMware View environment with thousands of VMs and hundreds of subnets, hosts and VLANs could benefit from centralized administration. The truth is that without dvSwitches a simple network change, such as a PortGroup creation, could end up being a painful manual intervention to each host. At best, you have in-house Powershell skills this change could end up with the creation of a customized script.

However, because of the way VMware View Linked Cloning technology works it is necessary to implement a particular configuration in order use dvSwitch. But before moving ahead let’s see how dvSwitches and dvPortGroup work.

A dvPortGroup is a group of dvPorts that share the same configuration template. This configuration is inherited from the dvSwitch to the dvPortgroup. ESX hosts keep a local cache of the vDS and DVPort information, to use when vCenter is unavailable:

Host DVPort state:    /etc/vmware/dvsdata.db
VM DVPort state:      /vmfs/volumes/<storage>/.dvsData
(both are non-editable binary files)


When VMware View tries to refresh, recompose or rebalance a virtual machine most implementations using dvSwitches will end up with an error that says:
A general system error occurred:DVS error: see faultCause. Cannot find a useable port in DVS dvSwitch. The source vim.dvs.DistributeddVirtualPort 116 is in use. DVS dvSwitch port 116 is connected to entity replica-8d2f5e51-1c44-4916-8ab8-a3dd0fc4a293 vnic


This error is displayed even if there are free ports in the dvSwitches. VMware View refresh, recompose or rebalance processes will try use the same port that has been already assigned to the replica.


The DVPort binding types are as follows:

Static Binding (Default): means that the dvPort is assigned to the virtual machine at configuration time. When all the ports are booked by virtual machines, it is not possible to connect to any more virtual machines, regardless of whether the connected virtual machines are powered up or not, and an error message is displayed. The assigned dvPort is immediately pushed to the host, written to the host’s cache and written in the VM’s vmx file.

Dynamic – assigned when the VM is powered on, and then pushed to the host. There is no guarantee that the VM will get the same DVPort on the next power on.  However it uses a concept similar to DHCP in that if the same port is available then it will renew that one and this allows for over committing the number of dvPorts.

Ephemeral (No Binding) – a new port on every power-on. The port is destroyed when the VM disconnects from the port. This behaviour resembles the behaviour in the standard vSwitch. If you select this option, the numbers of ports are automatically set to 0, and the Portgroup allocates one port for each connected virtual machine, up to the maximum number of ports available in the Switch.


If your VMware View implementation is using Linked Cloning technology (View Composer) it is vital to set the dvPortGroup Port Binding to either Dynamic or Ephemeral (no binding). I personally like to set them as Ephemeral – no binding.


After you create the dvPortGroup you will need to change the network at your Master image from standard switch to vDS with dynamic or Ephemeral port binding and create a new snapshot. After that you must recompose a test desktop with the new snapshot.

If everything works as expected it will not be necessary to recompose all VMs (this could take a long time depending on the size of your environment). Using the vNetwork Distributed Switch administration interface you will be able to simply change the network from the standard switch to vDS. Despite this is a non disruptive technology I recommend a small outage window for the change.


VMware KB1010593 (vNetwork Distributed PortGroup configuration) provides additional information on how to configure dvSwitches

Although vNetwork Distributed Switches may have advantages if compared with Standard vSwitches a sound design is required in order to provide high availability. In most cases I would recommend a hybrid approach. Here you will find a post from Duncan Epping with PROs and CONs.

A white paper (VMware® vNetwork Distributed Switch: Migration and Con­figuration) is also available here.


1 ping

Skip to comment form

    • David Henderson on 11/02/2013 at 2:18 am

    With vSphere 5.1 and View 5.2 is the use of ephemeral binding still the recommendation for View? I am experiencing the exact behavior described in this article when recomposing my linked clone pool; out of ports on my DV Portgroup even though there are plenty available. This VMWare blog recommends using static binding over epemeral

    What is best practice here?

  1. David, yes, you should utilize ephemeral binding.

    • David on 11/02/2013 at 1:07 pm

    Thanks for the quick reply. One last question. If my vCenter goes offline will my View desktops that are already created still work? We have them set so every time someone logs off they are refreshed. I thought I read somewhere that ephemeral binding needs vCenter

  2. Yes, they will continue to work. Despite configurations are done via vCenter, the intelligence is all host based. In saying that, for non-persistent desktops highly recommended to utilize multiple vCenters. See this

    • Michael on 01/25/2014 at 2:56 pm

    I understand what the vmk port is in your diagram, but what does the sc port stand for?

  3. Michael, this is an old post. In the past ESX used to have a Service Console port. Now this is the Management Network in ESXi and not full featured shell is available anymore.


  4. I am looking into some errors that linked to this article, is there a VMware document that describes why you should not use static binding for vmview linked clones? I just want to read up on it more. We have small pools but the dvports were originally setup as static. Deleting a virtual machine and then having it rebuild by the composer has always worked to fix the error.

    • Darwin on 11/07/2014 at 8:37 pm

    That is a good way of a particular configuration. Thanks for this article.

  1. […] Configuring vNetwork Distributed Switch for VMware View? Pagefiles and VDI. Not so […]

Leave a Reply

Your email address will not be published.