If an ESXi host was connected to a Distributed Virtual Switch (DVS) and you were not able to properly remove it from the vCenter inventory, which cleans up the VDS as part of the removal, then you will be left with a stale VDS configuration.
Of course, the ideal workflow is to clean this up within vCenter Server but if you some how lost access or the vCenter Server was deleted and you might be wondering how to manually clean this up?
I have seen several variations of this question get asked internally on how how to retrieve the DVPort ID and/or Stats on a vSphere Distributed Switch (VDS). Usually the question is prefaced with an example output from an ESXi host like the one show below using a classic CLI called esxcfg-vswitch. As you can see, there are a number of DVPort IDs which are either mapped to a physical NIC on the ESXi host or to a specific VM and its network adapter, if there is more than one.
My usual response for these sort of questions is that yes, it can be programmatically and automatically retrieved without going directly to an ESXi host. The answer is by using the vSphere API and specifically the set of methods provided by the VirtualDistributedSwitch managed object, which will allow users to retrieve all things related to the VDS.
Note: Although PowerCLI does provide some higher level cmdlets for managing VDS and Distributed Virtual Portgroups (DVPG), not everything that is available in VDS API is available through these higher level cmdlets, but that does not mean you can not use PowerCLI to easily retrieve all this additional information.
At VMworld this year, I had received several questions from customers asking whether it was possible to move an ESXi host configured using LACP/LAG from one vCenter Server to another, similar to the workflows outlined here or here. Not having spent much time with LACP/LAG, I reached out to a fellow colleague who I knew would know the answer, Anothony Burke, who you may know as one of the co-creators of the popular Automation tool PowerNSX.
Anthony not only verified that there was indeed a workflow for this scenario, but he was also kind enough to test and verify this in his lab. Below is the procedure that he had shared with me and I merely "prettified" the graphics he initially drafted up 🙂
At a high level, the workflow is similar to the ones shared earlier. The main difference is that for an LACP/LAG-based configuration, you must convert from VDS to VSS and then disconnect from one vCenter Server to the other, you can not simply disconnect and "swing" the ESXi host like you could for non-LACP/LAG configuration or you will run into issues. Once you have re-added the ESXi host to the new vCenter Server, you simply reverse the procedure from VSS to VDS and re-create your LACP/LAG configuration.
Step 1 - Here is an example of a starting point, where we have an ESXi host with 2 pNICs (vmnic0 and vmnic1) connected to an LACP bundle which is then associated with a physical switch.
