“Computers are like bikinis. They save people a lot of guesswork.”
— Sam Ewing
The best feature of vDS is that its configuration is centralized to vCenter Server. In practice, it means that you create vDS and as you configure it, its changes are applicable to all connected hosts. You add a new host, just connect it to vDS, all port groups are already there. In just a few clicks, complete hosts networking is configured. You need a new network and VLAN, you just add a new port group and configure VLAN id. All hosts connected to vDS are gonna see it and all virtual machines can use it.
Distributed switch support private VLANs and standard switch do not.
vNetwork Standard Switch is available from VMware Infrastructure 3. It can be used without the vCenter server. vDS is supported by ESXi/ESX 4.x and higher. Hosts that belong to a dvSwitch do not need further configuration to be compliant.
Distributed switch or vDS provide similar functionality to standard switch or vSwitch. dvPortgroups is a set of dvPorts. The vDS equivalent of portgroups is a set of ports in a vSwitch. Configuration is inherited from dvSwitch to dvPortgroup, just as from vSwitch to Portgroup.
Virtual machines, Service Console interfaces (vswif), and VMKernel interfaces can be connected to dvPortgroups just as they could be connected to port groups in vSwitches.
There is a nice article regarding networking in Vmware at this link.
You have x hosts in your cluster managed by the vCenter server. If you are using standard switches, then you need to create a new switch for every new host joined to a cluster. If intended to add new VLAN you will need to create it on the every virtual switch at every host, using exactly the same name and VLAN number. It means x times doing the same job. It is time-consuming, and it offers space for a mistake. If the name is not exactly the same, live migration and high availability will not work. You can mitigate some of those problems by using the host profiles, but using distributed switches or vDS is the better option for many more reasons.
But what if you already have an infrastructure, with hundreds of virtual machines on standard switches? How would you change all VMs networking from standard to vDS? Let’s consider live migration as an option. Not to risk usurping your production network, maybe it would be a logical to prepare one host separate from the production environment, and configure it to use vDS. Then, when having everything up and running and tested, start transferring VMs to a new host. You will face the first problem if you try live migration. Here is what you will get.
It means that vCenter will not allow you to do the live migration. You now have two options.
Option 2 is mandatory if you want to migrate your complete Vmware environment to vDS, and that includes the vCenter server. You can`t shut down vCenter server since without it you can not access vDS. It does not mean that all VMs will lose networking if vCenter gets unavailable, it just means that you can not switch between networks, or portgroups, without Vcenter Server. You will not be able to see or select ports available on vDS if you access host directly and try to do change networking of a VM that way. So if you have vCenter as a VM, here is the simple way to mitigate the problem.
This is the example with the standard virtual switch. On the left sides are port groups, and on the right side, we can see two physical adapters connected to switch. Just to mention, two adapters are there for redundancy.
In the next step, we remove one physical adapter from the standard switch. Due to fact that switch has one remaining adapter, networking works like a charm.
We have our new distributed switch prepared, with same portgroups (same VLANs).
In the next step physical adapter removed from standard switch should be assigned to the distributed switch. That way we create a host that can serve as a bridge for migrating VMs.
If there are unused physical ports on the server we can skip this removing and adding procedure, and use them for the distributed switch directly. So open distributed switch from networking selection chose to add a host to it and select the free physical adapter.
Then, it will give you the option to migrate some host virtual adapters, for the moment let it be, just click next without selecting any.
That`s it. Host now uses both standard and distributed switches.
Now that we have the host prepared, so we can try live migration.
After migration just remember to edit networking of a VM and change interface or interfaces to adequate port groups on the distributed switch. Doing that you will lose few pings, and that is it. You can use this way for all VMs including vCenter server, and even Database server if you have it on different VM.
When migrating second physical adapter from standard to distributed switch, you will probably have to migrate some of the host’s virtual network adapters. If that is the case, take a great care and doublecheck destination port group to be the same function as the source network. It may be the management network and you may lose connectivity to host.
If you have enough resources, the best way is to have one server configured as a so-called bridge, with both types of switches, and one with just a distributed switch as a final solution. So you live migrate VM to a bridge server than change its adapters to vDS portgroups, and then move the VM again to the host with only vDS. That way you are almost eliminating any possibility for a failure to happen. You repeat the process until one more host is without any VMs. Then you connect that host to a distributed switch and remove it from standard switch completely. Repeat the process until all VMs are on the hosts with a distributed switch as the networking device.
In most cases, you will not get in this kind of situation because distributed switch or switches are already in use on your Vmware environment. If you are setting up new vCenter and cluster from scratch, I strongly advise you to use vDS. By my humble experience, it is far better and easier to use and manage vDS than standard virtual switches, especially in bigger environments. The need for migration can emerge from older Vmware surroundings. Those kind of systems were typically many times upgraded and scaled from few to many hosts. If that is the case, working and managing standard switches can be a great deal of trouble, and this is the way that I figured to be the best solution for changing networking type.
Once again thank you for reading,