A vSphere Distributed Switch health check can test a VLAN on an uplink that a particular port group is deliberately configured not to use. Its warning can therefore describe a real unsupported VLAN/uplink combination without proving that the current workload is using that combination. Compare the probe result with the effective port-group uplink policy before deciding whether the design is broken.
This is a source-only interpretation of vCenter 8.x behaviour. No health check was enabled or disabled, no packet probe run and no switch configuration changed. The example is hypothetical.
What the health check examines
KB 340928 describes checks for VLAN trunk agreement, MTU and teaming policy. VLAN and MTU checks require at least two active physical NICs; the teaming check also requires two hosts. These are feature prerequisites, not a statement that every pair of uplinks carries the same workload VLANs.
KB 408869 explains the important limitation: health check tests VLANs configured on the vDS across its uplinks. It does not use each port group's restricted uplink selection to declare every unselected combination irrelevant. If a physical port does not permit a VLAN configured elsewhere on the vDS, that combination can be reported Not Supported.
The same source describes real MTU mismatches and EtherChannel/IP-hash behaviour that can affect results. A familiar warning text is therefore not enough to choose one explanation. Read the specific physical adapter, VLAN and check type.
Map the tested combination to the intended path
Prerequisites are authorised read access to the vDS health-check result, the relevant distributed port group's teaming/failover policy, host uplink mappings and the physical switch's approved trunk record. Record vCenter/ESXi versions and the time of the warning.
Identify the affected host and physical NIC first. Then record the VLAN and whether the warning concerns VLAN, MTU or teaming. Do not translate an MTU warning into a VLAN fault without the accompanying details.
For the workload's port group, inspect active, standby and unused uplinks and any applicable override. Map the distributed uplink names to that host's actual vmnics and physical switch ports. A label such as Uplink1 is not sufficient if its physical attachment differs across hosts.
Finally compare the physical port's allowed VLANs and MTU with that exact combination. Preserve the design's intended failover path as well as its present active path. A warning on a standby path can expose a failure that normal traffic has not yet exercised.
KB 408869 lists two other distinguishable patterns: VLAN type None can appear as VLAN 0 Not Supported, and a vDS configuration restore can bring back references to old uplinks/VLAN trunks. Check the recorded port-group setting and restore timeline before attributing the warning to the current workload path. KB 340928 gives a default one-minute check interval; it is not proof that the latest displayed result is fresh.
Worked interpretation
Suppose fictional port group PG-App110 uses VLAN 110 and explicitly uses uplink A, with uplink B unused for that port group. Another port group uses VLAN 220 on B. The physical A port permits 110, the physical B port permits 220, and health check reports VLAN 110 unsupported on B.
That result is consistent with the probe behaviour in KB 408869. It does not, by itself, prove that PG-App110's current packets are being sent through B. The practical task is to verify that the documented restriction is effective for the relevant host and port group, rather than allowing VLAN 110 everywhere merely to remove a warning.
Now change B from unused to standby for PG-App110. The warning becomes material to the intended failover design: if B must carry VLAN 110 during a failure, its missing permission is an unresolved requirement. A healthy application on A does not validate B. No failover test is performed or recommended as an immediate diagnostic here.
Likewise, if a physical MTU is too small along the path, a restricted-VLAN explanation does not make that problem disappear. The source notes that round-trip health checks can involve more than the directly attached switch; match the evidence to the real path.
KB 408869 links a further article, “vDS Health Check reports unsupported VLANs for MTU and VLAN”. That follow-on procedure was not independently reviewed here and is not adopted as a repair. This article stays with the captured warning mechanism and its observation limits.
Avoid cosmetic repairs
Disabling the health check removes an observation mechanism, not a trunk or MTU fault. Broadening trunks changes network exposure. Moving uplinks between active and unused changes connectivity and redundancy. None is a harmless way to test an interpretation.
The health-check feature itself generates traffic and MAC-address activity. KB 340928 warns that the amount can be significant depending on the selected checks. Reading an existing result is different from enabling the feature across a production fabric, and this article does not authorise the latter.
Acceptance and reversal
The read-only outcome should identify the tested combination, the intended workload/failover combinations and whether a mismatch violates that design. If physical-switch evidence or host mapping is missing, the warning remains unresolved. Do not mark it benign from a single successful VM connection.
A future approved correction needs its own connectivity and failover acceptance plan. Preserve previous port-group and physical-port values before changes; reversing only one side can leave an inconsistent design. Reading configuration needs no rollback, and no operational validation has been claimed here.
Learning notes
- Health-check probe scope can exceed a port group's selected uplink path.
- An unused path and an intended standby path have different consequences.
- A warning must be compared with the complete design before it is accepted or repaired.
References
- A21-S1: During upgrade of vCenter Server from 7.0.3 to 8.0.3, there are now vSphere Distributed Switch MTU supported status errors on a few clusters.
- A21-S2: VMware vSphere Distributed Switch Health Check