vDS Host Shows Out of Sync: Trace the Listed Ports First

A vSphere Distributed Switch (vDS) shows the warning "The vSphere Distributed Switch configuration on some hosts differed from that of the vCenter Server", and one or more hosts show Out of sync in the vDS Status column. The usual reflex is to click Rectify, or to remove the host from the switch and add it back.

Broadcom's articles show that this warning has several different causes, and some of them are not fixed by either action. This guide shows how to record what the warning actually names, so the owner can pick the documented path for that cause. It changes nothing.

This guide is based on source research only. Nothing in it was run. Host names, port numbers and VM names below are fictional.

What Broadcom documents

The common thread: the warning can name specific ports on specific hosts. What those ports are connected to points to candidate documented paths. It does not prove a single cause: KB 412915 says the list of causes is not fully understood, and more than one mismatch can exist at once.

Before you start

• Read access to the vDS in the vSphere Client Networking view: Summary, Ports, Hosts and Monitor > Events.
• The vCenter version and build, read from vCenter's own summary, and each affected ESXi host's version and build, read from the host's summary. KB 412915's stated environment is vCenter 8.0 U3 and ESXi 8.0 U3, and the vCenter build matters for PR 3575427.
• The datastore of any VM you will look up, and the storage owner's retained record of that datastore's state. Without it, the inaccessible-datastore case below cannot be confirmed.
• A change record for the switch and the listed hosts, if one exists (recent vDS upgrade, MTU or LAG change, host maintenance, template conversions).

Do not click Rectify, remove or re-add hosts, change uplinks, change VM NICs, convert templates or remove VMs while you collect this record. Each of those is a change, and some of them make the original evidence harder to read.

Step 1: record what the warning names

From the warning, use Actions > Show Details (KB 434563). Record:

If Show Details lists no ports, record that. The port-by-port classes below then do not apply, and the case goes to the owner with the event times.

Step 2: look up each listed port

In the vDS Ports view, find each listed port and read its Connectee column (KB 412915). Then look up the connectee in inventory. Each row below is a candidate class, not a proven cause. Where the evidence a row asks for is missing, record the port as "candidate, unconfirmed".

The table is an editorial grouping of the four KBs and the release note. A single warning can list ports in more than one class, and a port's class does not show that no other mismatch exists on that host. Record each port separately, and keep "unresolved" as an outcome.

Worked example (fictional)

The vDS DSW-PROD shows host esx-07 Out of sync. Show Details lists ports 1204 and 3381. The earliest retained DvsHostWentOutOfSyncEvent for esx-07 is on Monday at 02:40 AEST; the event list covers the previous 30 days. Rectify is greyed out. vCenter reports an 8.0 Update 3 build earlier than Update 3h, and esx-07 runs ESXi 8.0 Update 3. The example is complete only for what this record states.

Reading it:

• Port 1204 is consistent with KB 434563, and the datastore record supports it. It goes to the storage owner: the question is why DS-ARCH is inaccessible, or whether app-old-03 is still needed.
• Port 3381 is consistent with KB 429675. It goes to the vSphere owner, who decides whether to use that KB's remedy as a planned change.
• These two classes do not show that esx-07 has no other mismatch. If the warning remains after the owners act, the case returns as unresolved.
• The vCenter build is below Update 3h. That is recorded as possible exposure to PR 3575427; it does not explain either listed port.

Contrasting record (fictional)

Show Details lists port 2290 on host esx-02. The Ports view shows no connectee, and no VM in inventory has that port. vCenter is below 8.0 Update 3h. This is consistent with PR 3575427 but does not prove it: the release note gives no empty-Connectee test, and the other causes in KB 412915 are not excluded. The record goes to the owner with the vCenter and ESXi builds, marked "cause unresolved". Attributing it to PR 3575427 needs port-to-host association evidence or Broadcom support confirmation. Neither a switch change nor an upgrade is decided from this guide.

Troubleshooting

Acceptance checks

1. The vDS, affected hosts, listed ports (or none), earliest retained event with its time zone and the period the events cover, and the Rectify state are recorded.
2. Each listed port has its connectee and the connectee's state recorded.
3. Each port is placed in one candidate class (inaccessible VM, template, accessible VM, no connectee) or marked unexplained. No class is recorded as the proven cause without the evidence its row asks for, such as the datastore record or association evidence.
4. The vCenter version and build and each affected ESXi host's version and build are recorded, and the vCenter build is compared with 8.0 Update 3h (ISO build 25092719).
5. No switch, host, VM, template or database change was made while collecting the record.
6. Each class goes to its owner with its documented path named, not run.

Risk notes

• Rectify and host removal are changes to the switch. KB 434563 and KB 429675 show causes outside the switch that neither action resolves.
• Replacing a VM NIC interrupts that VM's network connection. KB 412915 labels phase 1 non-disruptive, but the VM on that port loses its connection while its NIC is replaced, so the VM owner plans it.
• Removing a VM from inventory is not deleting it, but it does remove it from management. Only the VM owner decides that.
• The database script is support-led. KB 412915 says to stop and open a support case if any result differs from the expected one.
• Upgrading to 8.0 Update 3h is a planned upgrade. It fixes one documented cause, not every Out of sync warning.

These are source-documented behaviours. Expert review and a lab check are still needed before any change to a vSphere environment.

Learning notes

• Out of sync means vCenter's record of the switch and the host's own copy of it disagree.
• The warning may name specific ports. When it does, those ports are where to look first.
• An inaccessible VM on an inaccessible datastore, or a template, on a listed port is consistent with a documented cause outside the switch settings. It does not rule out other mismatches.
• A port with no connectee on a build earlier than 8.0 Update 3h is possible exposure to a fixed vCenter issue, not proof of it.
• The database script exists, but only with Broadcom support.

References

Related articles

• How to design and troubleshoot VMware networking, which covers end-to-end traffic paths and safe switch changes.