We are on the home stretch of our Automating your vSphere Upgrade blog series. The final step of completing our upgrade will be upgrading our Virtual Distributed Switch (VDS). When upgrading your VDS on vSphere 6.7 the version is actually 6.6 (we will cover the details later). Please make sure prior to upgrading your VDS to 6.6 all ESXi hosts have been upgraded to ESXi 6.7, if you still have hosts on ESXi 6.5 you will only be able to upgrade to version 6.5.
Considerations for Upgrading your Virtual Distributed Switch
The first consideration we would like to think about is why would I want to upgrade my VDS? Well if you had previously upgraded from vSphere 5.5 your VDS still may be on version 5.5 and this is not compatible with vSphere 6.7. Another reason is that we can review the new features that are listed below, we can see this when we click on the (i) within the VDS GUI. We can see that upgrading to version 6.0 gets us NIOC v3 and IGMP/MLD snooping, version 6.5 gives us port mirroring enhancements and version 6.6 gets us mac learning. If you run any nested virtualization in your environment this is a great enhancement as we no longer require you to enable promiscuous mode on your VM port group.
Another consideration I like to recommend is that you keep your VDS upgraded to the same version as your ESXi hosts whenever possible. Previously in most vSphere versions it has always been said that upgrading your VDS can be done at anytime and is a non-disruptive upgrade., but we always want to use caution and do this within a maintenance window. The VDS upgrade is also something that has no rollback, once it is complete it is permanent unless you have completed a backup.
With vSphere 6.7 and the introduction of VDS version 6.6 there are some known issues and considerations I want to mention prior to getting started upgrading our switch. A question I get asked quite frequently is why is vSphere 6.7’s VDS version 6.6? The answer is quite simple, VMware on AWS (VMC) shares quite a bit of the same code as vSphere On-Perm and since there were no major changes to the VDS features or functionality the version stayed the same. Prior to upgrading our VDS version to 6.6 we definitely want to make sure we review KB52621. This KB covers considerations around known issues upgrading to version 6.6. Some of these considerations are making sure to put DRS into partially automated mode since if a vMotion occurs during the upgrade the VDS upgrade will fail. To take these considerations into account, we will make sure to include this in our Upgrading your Virtual Distributed Switch automation.
Prior to upgrading we also need to verify that all hosts have been upgraded to vSphere 6.7 so we do not have any errors. If there is a incompatible host attached the upgrade will not be allowed to proceed.
To validate our ESXi host version for all hosts attached to our VDS we can do so as follows.
We can see here that one of our hosts is not upgraded to 6.7 so if we were to proceed with upgrading our VDS it would fail. Before we proceed on to our next section we will make sure to upgrade our ESXi host to vSphere 6.7. If we were to attempt to upgrade our VDS prior to upgrading we would have encountered an error such as below.
Upgrading your Virtual Distributed Switch
Now that we are ready to move forward with upgrading our VDS, we will take some of the above considerations into place. Since we know if a vMotion is occurring during upgrade it will fail. We will make sure that if DRS is enabled we will put it into Partially Automated mode. Also, since we know we cannot rollback from a version upgrade we will make sure to take a backup prior to our upgrade. Unlike our previous blogs where we used simple one-liners, we will utilize a bit more logic in this upgrade that will be required as a script.
As an introduction to the below script we will outline what it does. At the top we define variables for the VDS Name, Version we wish to upgrade to and the cluster(s) in which the VDS is attached. We will then check if DRS is enabled on the vSphere Cluster. If DRS is enabled we will store the current DRS Automation level and set it to Partially Automated, Backup the VDS, Upgrade the VDS and then we will restore the DRS Level back to the original state. If DRS is disabled, we perform a Backup of the VDS and then Upgrade the VDS.
You can see the sample code below. As with any code from the Internet you should review it first, then test it in a separate test environment before running it against production systems & infrastructure. While we strive for accuracy, changes in the products over time sometimes mean different results than what was originally intended.
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Connect-VIServer"ds-vcsa-03.cpbu.lab"|Out-Null
$VDSwitch="VDS"
$VDVersion="6.6.0"
$Cluster=Get-Cluster"Cluster"
If($Cluster.DrsEnabled-like"True"){
Write-Host"DRS is Enabled, it will be temporarily disabled during upgrade."-ForegroundColor"Green"
$ClusterDRSLevel=$Cluster.DrsAutomationLevel
Write-Host"DRS Cluster is currently set to $ClusterDRSLevel. Will change back when complete."-ForegroundColor"Green"
As we can see the upgrade is now complete. Even though the upgrade is itself a simple one-liner (Get-VDSwitch -Name $VDSwitch | Set-VDSwitch -Version $VDVersion), we can automate the pre-requisites, backups and considerations to make this a more seamless upgrade. If you are interested in understanding how you can upgrade your VDS through the UI please see my colleague Nigel Hickeys blog here.
You can find more information on Backing Up and Restoring your VDS here and more information on Upgrading your Virtual Distributed Switch here.
Conclusion
As we have now completed Automating our vSphere Upgrade we can see it wasn’t so bad after all. Im hoping this series has helped you better understand what it takes to Automate your vSphere Upgrade and for those of you with large environments it gives you an idea on how you can start to streamline the upgrades across your entire vSphere environment.
