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.
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 Configuration) is also available here.