With vSphere 7.0 there are now ~4 types of switches available in the VMware ecosystem. Here is a quick overview of the different types and where you will encounter/use them.
vSwitches are responsible for layer 2 traffic forwarding.
A physical NIC (pNIC) can only be connected to one switch (regardless of type) at a time. Especially with the super-high-bandwidth pNICs available nowadays, you see more servers with only 2 pNICs available for VM traffic. This is important to take into account with your designs, especially regarding the N-VDS.
All switches use a type of portgroup to connect either uplinks (to the pNICs) or downlinks (to the VMs or vNIC).
The Standard vSwitch (VSS) is the default switch that is local only to the ESXi host on which it resides. This is the most basic version of vSwitch. It has no capabilities for replication or virtual networking, and is VLAN only. The VSS is the only non-distributed switch type in this list.
Is completely independent of vCenter or NSX (V or T), and as such is also the most reliable when things go wrong, but also lacks a lot of functionality you need in a modern SDDC. It is not a type of vSwitch you’d see in enterprise environments.
VMkernel ports created on the vSwitch have their own portgroups that do not allow VMs to be attached to it.
The distributed version of the vSwitch. The name Virtual Distributed Switch, vSphere Distributed Switch (VDS), or Distributed vSwitch (DVS, dvswitch) are used somewhat interchangeably. This is the switch type necessary for NSX-V, and currently the most encountered type of switch.
Under the hood this is more or less a vSwitch (or Host Proxy Switch) on each host with managment components in vCenter. It allows you to have consistent configurations for your environment. Supports many more functions and (VMware) products than the VSS. Also supports IPFIX/NetFlow.
You can create portgroups as regular VLAN-based endpoints for your VMs, or you can leverage the NSX-V Logical Switches to provide virtual networking endpoints using VXLAN.
It is very dependent on vCenter to function properly, without it you might have some serious problems to get your environment back up and running after a vCenter failure. It might be useful to have a vSwitch or an Ephemeral binding portgroup available for such an occasion. From KB article 1022312:
Note:Ephemeral port groups are generally only used for recovery purposes when there is a need to provision ports directly on a host, bypassing vCenter Server.
The VDS has been updated throughout the history of vSphere, and comes back in this list as the vSphere 7.0 VDS.
Also called opaque switch because it is not manageable by vCenter, but only through the NSX-T manager. In fact, the switch doesn’t even show up in vCenter! Only the portgroups created through the NSX-T interface will appear in the networking tab of vCenter. N-VDSes are distributed, like the VDS. The N-VDS is based on the VDS, essentially a fork, and is similar in function to a KVM Open vSwitch.
Portgroups for this type of switch are called segments and leverage the Geneve protocol. You can also add VMkernel ports to this switch in order to use a collapsed 2-pNIC design.
Typically, the N-VDS owns the Tunnel EndPoints (TEPs) for the ESXi hosts.
In vSphere 7.0 you have the option to use the switch below instead of having to use an N-VDS for your transport nodes. Edge nodes will still use the N-VDS.
Currently you will see these types of switches with NSX-T deployments in vSphere environments below version 7.0. I’m expecting to see less and less of this type of vSwitch for transport nodes as more environments get upgraded and migrated.
For simplicity’s sake VMware has updated the distributed switch to combine all the functionality of the VDS with that of the N-VDS. So, not really a fourth type of switch, but it does behave a bit different. Best practice is to have this type of switch for your environment to get all the features and benefits.
Note: this is only relevant for transport nodes. Edge nodes with only Edge-VMs, or bare-metal Edges do not need the regular VDS components, so they still use the N-VDS (or a slimmed down version of the 7.0 VDS which boils down to the same thing).
Portgroups for this switch can be either VLAN or NSX Distributed Portgroups. The latter are called segments and can only be managed through the NSX-T Manager, much like opaque switches. The context menu from the vSphere Client gives you a direct link to the NSX-T manager.
Moving onward this will be the default type of switch for new deployments. At this time this is more of a greenfield type of switch, because there’s not really a smooth upgrade path to the 7.0 VDS + NSX-T segments yet. You can migrate to it, but this is a manual process with some service interruptions.
For KVM hosts you have the Open vSwitch (OVS) which is used by NSX-T. The N-VDS on these nodes is an implementation of OVS.