Firstly, sorry to hear you had a seemingly negative support experience - if you could please PM me the SR number I would like to have a look from our side and loop in my management with regard to this case.
As a daily practitioner of worst-possible-scenarios (mostly user/admin/architect-caused) I do understand your concern over clicking the button that is in reality going to do a lot of things and potentially reacting unwanted states.
From my own research and testing of upgrading vDS from 6.0 to 6.6 (on HOL, nested-homelab and physical) I have never encountered an issue that caused vSAN cluster to become partitioned (as opposed to migration testing ripping out a used uplink and migrating to a vDS which recovers in ~30 seconds on a HOL cluster).
That is not to say there is no possibility of a negative impact, there are known issues (and apologies but I am going to have to get this kb remediated as it makes it sound like it is NSX-specific when it does not appear to be so):
As our documentation advises, please take a backup of the vDS configuration before upgrading:
When it comes to networking change guidance I am generally overly-cautious, but this is borne of seeing how bad it can go when someone doesn't understand and/or know their network layout and/or the potential impact of the changes they are making (and wants to make them on the fly just because it is possible), thus I generally advise *if possible* that planned downtime or changing this during non-production hours is the best course of action. That being said, upgrading vDS is relatively low on the scale of things that you can change that have the potential to really break things (e.g. MTU/VLAN/physical changes).
Thank you so much for the reply. This is exactly the kind of response I was looking for. In that KB:
VMs and vmknics lose network connectivity if LAG ports are connected to DVS after VMs are connected and the DVS is upgraded:
- VM and vmknics dont have network connectivity.
To resolve this issue:
- Trigger reconfiguration of the affected VM by changing any DVPortgroup setting in the VC UI or through AP.
That is the note that caused me to seek out help.
Is this saying to reconfigure the VMs that loose network connectivity?
i.e. .. Set-NetworkAdapter –NetworkName “new portgroup” and then Set-NetworkAdapter –NetworkName “original portgroup” for all the affected VMs?
OR is saying to go in to the settings for the portgroups themselves and change a setting?
I know the likelihood of this is low.. but I want to be ready just in case. (600+ VMs on VSAN cluster).
"Is this saying to reconfigure the VMs that loose network connectivity?"
No, actually it says to basically make any DVPortgroup change that then triggers the switchover part of the upgrade that didn't complete - from reading the associated PR that particular issue appears to have been resolved in 6.7 U1.
"I know the likelihood of this is low.. but I want to be ready just in case. (600+ VMs on VSAN cluster)."
As the kb (and I) mentioned, it is recommended to perform this activity during a maintenance window - just because something can be done on the fly, doesn't mean it is advisable to do so.