Need some input on how to fix this situation without rebuilding the whole damn cluster...
I have vSM providing VXLAN virtual wires/networks for vCloud Director. As a part of some host updates--migrating from all 1Gbps to 1/10Gbps mixed--I was able to rearrange the NICs on the hosts and add additional uplinks to the total available on the DVS switch that VXLAN is "riding on." In the course of making these updates, I also renamed the uplinks, which resulted in errors and discovery of the root problem.
The errors were popping up when trying to instantiate a new VXLAN network. The vCloud error was pretty inscrutable (as usual), but trying to manually create a new network in vSM provided useful information: the error was a failure to set the teaming mode for the new port group, and it referenced one of the former uplink names.
After I added additional "dummy" uplinks to the DVS and renamed them so that the old names were included, the virtual wires could be built just fine. However, in reviewing the new portgroups, it was clear that vShield was building them using the original, pre-reconfiguration uplink names, ignoring all the new uplinks: the new uplinks were set as "unused" in the teaming properties, and the "active" were the dummy uplinks that had no physical adapters associated with them!
I've restarted vSM, re-entered the vCenter credentials to try and get it to re-sync with the network configuration, but to no avail.
I need some way to force vSM to re-enumerate that DVS that VXLAN is using so that it'll end up with the correct uplinks. To date, my Google-fu has failed me, so I'm hoping someone on the forums might have a clue. Heck, for all I know, this is a defect that I've just uncovered...