VMware vSphere provides powerful networking capabilities that allow tremendous flexibility in moving packets both within the virtual environment and from virtual to the physical network and physical into the virtual. Perhaps the most important component of the vSphere network infrastructure is the virtual switch or vSwitch.

Table of Contents

VMware offers two different types of vSwitches that allow moving network traffic, the vSphere Standard switch and the vSphere Distributed Switch. When getting into the realm of larger environments as well as more advanced networking requirements and interacting with VMware NSX, the vSphere Distributed switch or VDS is the preferred and even necessary type of vSwitch that must be deployed to utilize and interact with the advanced networking components. There are several considerations to be made when utilizing the VMware vSphere Distributed Switch.

Protect Your Data with BDRSuite

Cost-Effective Backup Solution for VMs, Servers, Endpoints, Cloud VMs & SaaS applications. Supports On-Premise, Remote, Hybrid and Cloud Backup, including Disaster Recovery, Ransomware Defense & more!

Let’s take a look at VMware vSphere Distributed Switch best practices and note the considerations that need to be made when deploying and utilizing the VDS.

Comparing the vSphere Standard Switch and vSphere Distributed Switch

The common vSwitch that is typically deployed on day 1 vSphere environments is the vSphere Standard Switch or VSS. The VSS is the common switch that is deployed when you first install ESXi on a physical host. This is the type of switch the default management VMkernel interface is attached to out of the box.

The major difference between the vSphere Standard Switch and vSphere Distributed Switch is the location where they are installed. The VSS only requires that you have an ESXi server in the environment and nothing more. However, the VDS requires a vCenter Server for deployment. The VDS is created in vCenter and then the VDS configuration is pushed down to the host when the host is added to the vSphere Distributed Switch.

Download Banner

The primary benefit to this approach is that provisioning and managing vSphere Distributed Switches is simplified since you can perform the management tasks on the VDS from a centralized location within the vSphere client connected to vCenter Server. With the vSphere Standard Switch, the switch configuration is host-centric and must be configured on each host to match the other hosts for aligning network services and resources for virtual machines.

The VDS has a component of the virtual switch architecture called the dvuplink. The new dvuplink component is mapped to the physical network adapters or vmnics on each host. It is a template of sorts for individual vmnics on each host. Properties such as network teaming, load balancing, and failover policies are configured on dvuplinks. These are automatically applied to vmnics on individual hosts when a host is added to the VDS and also when each vmnic on the host is mapped.

vds

VMware vSphere Distributed Switch traffic types and dvportgroups (Images courtesy of VMware)

The dvportgroups is similar to the port groups on standard switches as these are the mechanism by which connectivity through the VDS to the physical network is made. Attributes such as the VLAN ID, port security, teaming, traffic shaping, load balancing and others are configured on the dvportgroups.

The vSphere Distributed Switch introduces a new way to load balance traffic across teamed adapters. The new mechanism is called load-based teaming or LBT. The uniqueness of the solution comes with the way that traffic is load balanced in that both egress and ingress traffic are load balanced. This is opposed to only the egress means of load balancing with hashing algorithms with virtual switches or EtherChannel on the physical switch side.

Another unique feature when comparing VDS with VSS is the Network I/O Control or NIOC feature that is used for traffic management. This feature is only available on the VDS. The NIOC feature of VDS utilizes a concept similar to the resource pools with CPU and memory on the compute side, except with I/O. Network administrators with the VDS can allocate I/O shares to different traffic types. A great use case where NIOC can help tremendously is in a converged network configuration where you have multiple types of network traffic utilizing one physical network adapter, such as virtual machine traffic and vMotion traffic. With NIOC, you can can ensure that one traffic type does not saturate the throughput on the physical adapter, negatively impacting performance of one or the other.

The vSphere Distributed Switch is a required switch type for use with VMware’s NSX software-defined networking solution. To use the more advanced features of VMware NSX such as logical switching, the vSphere Distributed Switch must be used instead of the vSphere Standard Switch.

As shown, there is a wide range of really great features and that are afforded to organizations as well as technologies that require running VMware vSphere Distributed Switches to host production workloads. The vSphere Distributed Switch or VDS is a powerful centrally managed mechanism that allows organizations to have a scalable and easily managed solution for hundreds or even more ESXi hosts. Additionally, it allows powerful capabilities. We have touched on a few best practices at least indirectly, however, there are few other best practices to keep in mind with vSphere Distributed Switches.

VMware vSphere Distributed Switches Best Practices

Let’s briefly consider the following best practices with the VMware vSphere Distributed Switch:

  • Deploy the same number of physical network adapters and port speeds to all the hosts connected to the VDS
  • Created consistent mapping of vmnics between hosts as it reduces complexity and confusion
  • Use NIOC with multiple traffic types traversing one adapter
  • Keep around a vSphere Standard Switch for emergency connectivity
  • Backup your vSphere Distributed Switches


Same number of physical network adapters and port speeds across hosts

As a best practice, VMware recommends that customers deploy hosts with the same number of physical network adapters and similar port speeds across the hosts that connect to the vSphere Distributed Switch. This helps to alleviate confusion and any performance and configurational differences between hosts that are connected to the vSphere Distributed Switch.

Created consistent mapping of vmnics between hosts

Again, this is a best practice that helps to reduce complexity and confusion between hosts that are added to the vSphere Distributed Switch. Since the interface will allow choosing different mappings if required between dvuplinks to vmnics between hosts, customers need to make sure that if mappings are different, they have a use case that supports this configurational difference.

Use NIOC with multiple traffic types traversing one adapter

It is common with high bandwidth adapters such as 10 gig and higher for customers to utilize physical network connections for more than one type of traffic. A classic use case is virtual machine traffic and vMotion traffic. To keep from having one type of traffic from saturating all the available bandwidth, use Network I/O Control to ensure that all types of traffic have sufficient bandwidth for operations as configured with the I/O shares.

Keep around a vSphere Standard Switch for emergency connectivity

It is extremely common now to run the vCenter Server inside a VM instance with the VCSA appliance. This is a great way to take advantage of the high-availability mechanisms found in vSphere such as HA and fault tolerance. However, utilizing vSphere Distributed Switches with vCenter housed in a VM can lead to a “catch 22” if a misconfiguration of the VDS happens. If a misconfiguration is made with the VDS that affects the vCenter Server, the networking for vCenter may be unavailable or offline. However, you need vCenter for the networking misconfiguration to be resolved, since VDS configuration changes require vCenter. It is good to keep around a vSphere Standard Switch on the hosts for the purposes of connecting the VMkernel mgmt port and then connecting vCenter Server to this same vSphere Standard Switch so that connectivity can be restored to remediate the misconfiguration.

Backup your vSphere Distributed Switches

There is a mechanism in the vSphere Client to backup the vSphere Distributed Switch and it is a great idea if you are making configuration changes or other actions that may lead to the VDS being in a bad state. The backup can be restored using the vSphere Client and the VDS configuration. Even if the entire switch is deleted, it can be restored to its original state.

Concluding Thoughts

In the world of VMware vSphere, the vSphere Distributed Switch is a powerful mechanism for having a centrally managed and feature virtual switch that allows the latest and greatest features and functionality. The VDS greatly simplifies management and provisioning of virtual switches across the ESXi host infrastructure since the switches are created in vCenter and then ESXi hosts are then added to the switch. This eliminates possible misconfiguration across hosts that are manually configured with vSphere Standard Switches on each host instead. For those who want to take advantage of VMware NSX in the environment need to utilize the vSphere Distributed Switch as well for the advanced networking features such as the NSX Logical Switch. By following these and other best practices with the VMware vSphere Distributed Switch, organizations can have a stable, efficient, network environment with advanced features running on top of the VDS infrastructure.

Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.

5/5 - (1 vote)