This article contains steps to resolve dvPort conflicts between ESXi and vCenter when the "Out of Sync"
error is because of a VM.
If the below KB does not apply, see The vSphere Distributed Switch configuration on some hosts differed from that of VMware vCenter- "Out of Sync"
vCenter
> Networking
> vDS
> Summary
, you see the warning: The vSphere Distributed Switch configuration on some hosts differed from that of the vCenter Server.
vSphere ESXi 6.x
vSphere ESXi 7.x
vSphere ESXi 8.x
vSphere vCenter Server 6.x
vSphere vCenter Server 7.x
vSphere vCenter Server 8.x
1. Place host in maintenance mode to evacuate VMs.
2. Right-click host > Connection > Disconnect the host.
3. Right-click and remove host from inventory.
4. Right-click cluster > Add host > Re-add host to cluster.
5. Add host back to DVS. Right-click DVS > Add Manage hosts > Add host -> Add uplinks in the same order they were removed.
6. Take host out of maintenance mode.
Information gathering steps are explained below:
If you click on "Show Details" next to the message above, the hosts and dvPort numbers that are out of sync are listed.
Make a note of these dvPorts/Hosts
Navigate to vCenter > Networking > vDS > Ports
Scroll down the "Port ID" column to find one of the dvPorts from Step #2
Make a note of the portgroup listed in the "Port Group" column, there may be no VM listed in the "Connectee" column.
If no VM is listed in the "Connectee" column, there are three ways to potentially resolve the issue.
In most cases, the easiest way to clear this message it to remove the host from the vDS entirely. After removal, it can then be brought back in to the vDS and the message will clear. This involves a networking change, so it is recommended to do this step during a maintenance window, if possible.
Move all attached virtual machines to another host or to a standard switch.
A new standard switch can be built using one of the physical adapters that passes the correct VLANs from the vDS. See the note below on Load Balancing information.
Move all vmkernels from the vDS to a standard switch.
Again, a new standard switch can be built using one of the physical adapters that passes the correct VLANs from the vDS. See the note below on Load Balancing information.
Remove any remaining physical adapters from the vDS.
Remove the host from the vDS. Click Home > Networking. Right click the vDS, click Add and Manage Hosts > Remove Hosts, and follow the wizard. (Note: may need to also remove the host from inventory for some issues)
Add the host back to the vDS along with its vmkernels, physical adapters, and VMs.
Note: if you need to use the same physical adapters from the current vDS on the standard switch, check the Load Balancing on the distributed switch. To do this, click Home > Networking, then click the vDS that is being cleared. Next, click the three dots next to the port group you are copying, then click View Settings > Policies and scroll down to Load Balancing. If the Load Balancing is set to IP Hash, this setting must be broken on the physical switch in order to use these physical adapters on the standard switch.
Create a new blank VM (no OS needed)
Edit the VM and add the VM to the PortGroup that you identified in Step #5 of the "Information Gathering Steps", click Ok
SSH into the host with the blank VM
Navigate to the blank VM's .vmx file
Edit the .vmx file with "vi" editor
Change the value of "ethernet0.dvs.portId" to the port number from Step #2 above
Power the VM up
Migrate the VM to the host listed in Step #2
Migrate the VM back off this host
Refresh the vCenter Client
If there is a VM using the dvPort in the "Connectee" column, try the following:
Create a new portgroup with identical settings (VLAN, Teaming Policy, etc) to the portgroup from Step #5
Edit the VM, and put it in the new portgroup
After a short wait, refresh the vSphere Client to see if the host is in sync
If the host is still out of sync, migrate the VM to a different host in the cluster
If the host is still out of sync, try Method #1 or #2 above now that the dvPort is unused by a VM
Note: The vMotions on/off the problematic hosts are critical. The goal is to perform a task (related to the dvPort in conflict) that both ESXi and vCenter are aware of to force them both to re-synchronize.