The distributed switch (vDS) is a really nice piece of software within the vSphere environment. It offers a variety of very useful features (NIOC, Health Check, Central management, LACP, LBT, Netflow, and so many (features with fancy abbreviations) more). Especially if you want to move to NSX the distributed switch is mandatory. Since analytics showed me that views about my vDS blogposts are increasing it seems that there is a demand for the vDS within our virtualized environments (it’s still an enterprise+ only feature)
Migrating from a vSphere standard switch to a distributed switch is not that complicated at all if you plan it properly. Over the years I collected a lot of (troubleshooting) experiences with the vDS. Anyway I want you to learn from my mistakes to do (not-so-daily) tasks right from the beginning.
Assumptions
- Portgroup naming and VLAN configuration remain the same way as they were before.
- We have a minimum of 2 VMNICs connected to the existing virtual Standard Switch (vSS), the physical switch configuration is alignd to the current virtual configuration (VLAN tags, etc.)
Implications
During the process the networkcomponent failures that can be tolerated will be decreased. If a network device (switch/nic) is failing during the migration there might be an impact. Nevertheless during the migration no connectivity loss is expected.
Action List
- Create a new virtual distributed switch.
- Create the portgroups (for the VM and VMkernel ports) with the correct name, vlanid and port binding settings.
- Remove 1x uplink from the vSS and add it to the corresponding uplink port on the vDS.
- Migrate existing VMkernels from vSS to the corresponding vDS portgroup.
- Migrate VMs from vSS portgroups to the corresponding vDS portgroup.
- Remove the remaining uplinks from the vSS and add it to the corresponding uplink port on the vDS.
- Verify connectivity.
- Clean up the legacy.
- Evaluate, design and configured advanced vDS features.
Nice to know
Remember that once you have a vDS established in your environment you can migrate in vSphere 6.0 from a vSS to vDS during a vMotion procedure (Web Client only). Anyway you are not able to migrate back from a vDS to vSS.
In the following I describe the necessary steps in more detail. The steps are explained in a manual and an automated way involving PowerCLI. The Usage of the PowerCLI script increases the migration speed and mitigates the risk of ‘typo’ errors. But anyway I cannot give any guarantee/support for the scripts I am using. Please verify them and check what they are doing. They worked totally fine in my cases so far, if your environment differs from that one I have, the behaviour might be different. Any comments are appreciated.
The scripts used for an automated procedure can be found in my Github repository
Create a new virtual distributed switch and the corresponding portgroups
Manual
Go to the networking view. Select the datacenter where your vDS will be created, right click -> new virtual distributed switch. Follow the wizard. I would recommend to rename the dvUplink names (If applicable like align the dvUplink naming to the vmnics I will use afterwards)
Once the vDS is created, we need to create all portgroups the exists on the existing vSwitch.
Make sure not to do any typos in this case, otherwise you might lose connectivity in certain portgroups.
Automated
Open PowerCLI and connect to your vCenter where you want to place the vDS. Run the following snippet. The snippet just copies the existing portgroup names/vlan from a reference host (just select one with the correct network settings) and creates a new vDS with the health-check for MTU/VLAN/Nic-Teaming enabled. The vDS portgroups are default portgroups (static binding, no fixed size).
Risk of using this automation: low
### Change variables here $datacenter = Get-Datacenter -Name "LE01" $refESXi = 'ESX01.lenzker.local' # vSwitch portgroups from this vSwitch will be used $numUplinkPorts = 2 # Number of Uplinks $vDSName = 'LE01vDS' # name of the new VDS ### Logic $vDS = New-VDSwitch -Name $vDSName -Location $datacenter -NumUplinkPorts $numUplinkPorts $portgroups = Get-VMHost $refESXi | Get-VirtualPortGroup foreach ($pg in $portgroups){ If($pg.vlanid -eq 4095){ $vDS | New-VDPortgroup -Name $pg.name -VlanTrunkRange '0-4094' } else { $vDS | New-VDPortgroup -Name $pg.name -VlanID $pg.VlanID } } ### Enable the health-check Get-View -ViewType DistributedVirtualSwitch|?{($_.config.HealthCheckConfig|?{$_.enable -notmatch "true"})}|%{$_.UpdateDVSHealthCheckConfig(@((new-object Vmware.Vim.VMwareDVSVlanMtuHealthCheckConfig -property @{enable=1;interval="1"}),(new-object Vmware.Vim.VMwareDVSTeamingHealthCheckConfig -property @{enable=1;interval="1"})))} |
Remove 1x uplink from the vSS and add it to the corresponding uplink port on the vDS
Now we are ready to remove 1 vmnic from the current vSS which might remove the redundancy of our network.
Manual
Select your vDS in the networking view, do a right-click and chose Add and Manage Hosts.
Select Add Hosts
and select the chosen ones for the vDS.
You can minimze the click-overhead by selecting the template mode on the bottom.
Chose ‘Manage Physical Adapaters‘ and assign an existing uplink from the current vSS to the corrsponding dvUplink on the vDS. Make sure to configure it identical (same vmnic to same dvUplink)
Finish the wizard.
Automated
TBD
Migrate existing VMkernels from vSS to the corresponding vDS portgroup
Now the VMkernel ports get moved to the newly created vDS. If the portgroups and physical infrastructure are configured correctly you should not experience any connectivity problems. If you do so… you might never had a fully functional redundancy in the first place ;-).
Manual
Select your vDS in the networking view, do a right-click and chose Add and Manage Hosts.
Select Manage host networking
Reassign the vmkernel port from the vSS to the corrsponding vDS portgroup (verify it, please verify that you assigned the correct onces)
Finish the wizard.
Automated
Risk of using this automation: medium
#Migrate vNIC and VMkernelAdapter to vDS #Assumptions: Portgroup names on vDS are identical to those on the vSS |
### Change variables here $esxHosts = Get-VMHost 'esx01*','esx02*','esx03*' # comma seperated list of hosts where migration takes place foreach ($esx in $esxHosts){ $VMhostAdapters = $esx | Get-VMHostNetworkadapter | Where {$_.Name -match 'vmk'} foreach ($VMhostAdapter in $VMhostAdapters){ $currentPortgroup = $VMhostAdapter.PortgroupName $newPortgroupname = Get-VDPortgroup -Name $currentPortgroup Set-VMHostNetworkAdapter -PortGroup $newPortgroupname -VirtualNic $VMhostAdapter -confirm:$false } } |
Migrate VMs from vSS portgroups to the corresponding vDS portgroup
After the virtual ESXi adapters (VMkernel ports) we now move our virtual machines to the correct newly created portgroup.
Manual
Right click the vDS -> Migrate VM to Another Network
Select the source network (from the vSS) and as destination network the corresponding one on the vDS.
Select all relevant virtual machines and finalize the migration.
Automated
Risk of using this automation: medium
# Migrate VM from old to corresponding vDS portgroup |
### Change variables here |
$esxHosts = Get-VMHost 'esx01*','esx02*','esx03*' $vDSName = 'LE01vDS' ### Logic $vDS = Get-Virtualswitch -Name $vDSName foreach ($esx in $esxHosts){ $VMs = $esx | Get-VM foreach ($VM in $VMs){ $oldPGs = $VM | Get-VirtualPortGroup foreach ($oldPG in $oldPGs){ $newPG = $vDS | Get-VirtualPortGroup | Where {$_.Name -eq $oldPG.name} $VM | Get-NetworkAdapter | Where {$_.Networkname -eq $newPG.Name} | Set-NetworkAdapter -NetworkName $newPG -confirm:$false } } } |
Remove the remaining uplinks from the vSS and add it to the corresponding uplink port on the vDS & clean up
It’s time to move the remaining vmnic(s) from the old vSS (which is now unused) to the vDS and rebuilt a fully functional network redundancy.
Manual
Right click the vDS -> Manage Hosts
Manage host networking
Select the hosts
and assign the vmnic to the new vDS uplinks.
Before you finish this task. Make sure that no more VMs are connected to the old vSwitch otherwise VMs might lose connectivity.
Automated
TBD
Clean UP
Make sure to verify the connectivity of all components and clean up by removing old vSwitches.
Enjoy!