Lab: VDS Health Check and Network Issue Diagnosis

VCF 9.0Intermediatevcp-foundation⏱ 60 min

Covers Obj 5.7 (Networks — VDS and VSS). Troubleshoot vDS configuration, port group issues, VMkernel adapters, and MTU mismatches.

Objectives

Run vDS health check and interpret results
Diagnose port group misconfiguration (VLAN, teaming, security)
Troubleshoot VMkernel adapter connectivity (vMotion, vSAN, management)
Identify and fix MTU mismatch issues
Differentiate VDS vs VSS capabilities and migration path

Prerequisites

VVF lab with vDS configured and operational

Prior labs: vvf-support-01

Required skills:

vCenter networking concepts
SSH access
Basic IP networking

Lab Environment

Holodeck VVF pod with vDS managing all host networking. 3 ESXi hosts with VMkernel adapters for management, vMotion, and vSAN.

Credentials

System	Username	Password
vCenter	`administrator@vsphere.local`	Holodeck default

Tasks

Task 1 Run vDS Health Check and Analyze Results

manageability

vDS Health Check is a built-in diagnostic tool that validates configuration consistency across all member hosts. Understanding health check categories is core to Obj 5.7.

Step 1

vCenter UI → Networking → select the vDS → Configure → Health Check. Enable both 'VLAN and MTU' and 'Teaming and failover' health checks.

Health check enabled. Status shows 'Running' for both categories.

Step 2

Wait 2-3 minutes for health check to complete. Navigate to Monitor → Health. Review results for each host.

Health check results show green/yellow/red status per host per category.

Step 3

VLAN health check: Verify that all configured VLANs on port groups are trunked on physical switches. Look for 'VLAN not trunked' warnings.

In Holodeck nested environment, VLAN trunking is simulated. In production, VLAN mismatch between vDS and physical switch is the #1 cause of VM network issues.

Step 4

MTU health check: Verify end-to-end MTU consistency. vSAN and vMotion port groups should show MTU 9000. Management port group shows MTU 1500.

MTU values consistent across all hosts. No 'MTU mismatch' warnings.

Step 5

Teaming and failover: Verify active/standby uplink assignments are consistent across all hosts. Look for 'Teaming misconfiguration' warnings.

All hosts show identical teaming policies for each port group.

Validation Gate

Check: vDS health check completed with all results analyzed

Expected: Health check shows green for all categories. Any warnings documented.

Common Errors

VLAN health check shows 'Not supported' on nested ESXi

Cause: Nested environment doesn't support CDP/LLDP for physical switch detection

Fix: Expected in Holodeck. In production, verify physical switch trunk configuration manually.

MTU health check shows mismatch

Cause: One host has MTU 1500 on vSAN VMkernel while others have 9000

Fix: Edit VMkernel adapter: Networking → VMkernel adapters → select vmk → Edit Settings → MTU → 9000.

Task 2 Diagnose and Fix Port Group and VMkernel Issues

availability

Port group misconfiguration and VMkernel adapter issues are the most common network support tickets. Systematic diagnosis is essential.

Step 1

Simulate issue: Edit a VM port group's VLAN ID to an incorrect value (e.g., change from VLAN 10 to VLAN 99). Verify VM loses connectivity.

VM on modified port group loses network connectivity. Ping fails.

Step 2

Diagnose: Check VM → Summary → Network. Note port group name. Navigate to vDS → port group → check VLAN configuration. Compare with working VMs on same segment.

VLAN mismatch identified between affected port group and expected VLAN.

Step 3

Fix: Edit port group → VLAN → restore correct VLAN ID (10). Verify VM connectivity restored.

VM regains network connectivity. Ping succeeds.

Step 4

VMkernel adapter check: Navigate to each host → Configure → VMkernel adapters. Verify: vmk0 (Management, VLAN 10), vmk1 (vMotion, VLAN 20), vmk2 (vSAN, VLAN 30).

All VMkernel adapters show correct VLAN, IP, and service tags.

Step 5

Test vMotion connectivity: Select a VM → Migrate → Change compute resource → select different host. If vMotion VMkernel is misconfigured, migration fails with 'No compatible host' or timeout.

vMotion succeeds if VMkernel adapters correctly configured. Failure indicates vmk1 issue.

Step 6

Check NIOC (Network I/O Control): vDS → Configure → Resource Allocation. Verify shares and limits for each traffic type (VM, vMotion, vSAN, Management).

NIOC shows traffic type allocations. System traffic types have appropriate shares (vSAN = High, vMotion = Normal).

Validation Gate

Check: Port group issue diagnosed and fixed; VMkernel adapters verified; NIOC reviewed

Expected: All VMs have connectivity. VMkernel adapters correctly configured. NIOC allocations appropriate.

Common Errors

vMotion fails with 'Source detected that destination failed to resume'

Cause: MTU mismatch on vMotion VMkernel between source and destination hosts

Fix: Verify both hosts have same MTU on vMotion VMkernel. Set both to 9000 for optimal performance.

vSAN health check shows 'Network: All hosts not connected'

Cause: vSAN VMkernel adapter on one host has wrong IP subnet or missing service tag

Fix: Edit vmk2 → verify IP is on correct subnet. Ensure 'vSAN' service is enabled on the VMkernel adapter.

Task 3 VDS vs VSS Comparison and Migration Awareness

manageability

Exam Obj 5.7 specifically calls out VDS and VSS differentiation. Support engineers must understand when and how to migrate from VSS to VDS.

Step 1

Document VDS advantages over VSS: centralized management, NIOC, port mirroring, NetFlow, LACP, health check, private VLANs, network policy backup/restore. VSS is per-host only.

Step 2

Check current vDS version: Networking → vDS → Summary → Version. VVF 9.0 supports vDS 9.0. Note backward compatibility (can manage older vDS versions).

vDS version 9.0 confirmed.

Step 3

Review vDS port mirroring capability: vDS → Configure → Port Mirroring. This feature is VDS-only and critical for network troubleshooting.

Port mirroring lets you copy traffic from one port to another for packet capture — essential for diagnosing application network issues. Not available on VSS.

Step 4

Document VSS-to-VDS migration process: (1) Create vDS and port groups matching VSS config, (2) Add hosts to vDS, (3) Migrate VMkernel adapters from VSS to vDS port groups, (4) Migrate VM networking, (5) Remove VSS.

Migration is non-disruptive if done correctly — one uplink at a time. Critical: never migrate all uplinks simultaneously.

Step 5

Note: VVF strongly recommends vDS over VSS. VSS is legacy and lacks features required for vSAN health monitoring and NIOC traffic shaping.

Validation Gate

Check: VDS/VSS comparison documented; migration process understood

Expected: Feature comparison table created. Migration process documented with safety notes.

Common Errors

VSS-to-VDS migration causes network outage

Cause: All uplinks migrated simultaneously — host loses management connectivity

Fix: Always migrate one uplink at a time. Verify management connectivity after each uplink migration before proceeding.

Final Validation

vDS health check run, network issues diagnosed and fixed, VDS/VSS differences documented

✓ vDS health check passed → All categories green (or documented warnings for nested env)

✓ Port group VLAN issue fixed → VM connectivity restored after VLAN correction

✓ VMkernel adapters verified → All hosts have correct vmk0/vmk1/vmk2 configuration

✓ VDS vs VSS documented → Feature comparison and migration process documented

Cleanup / Restore

• Restore any modified port group VLAN settings to correct values

• Revert to vds-baseline snapshot if needed

Design Reflection (VCDX)

Network architecture directly impacts all other VVF components. vSAN requires dedicated high-bandwidth network segments. NIOC ensures traffic isolation without physical NIC separation.

Requirements

All VM traffic isolated by VLAN
vSAN and vMotion traffic on dedicated VMkernel adapters with MTU 9000

Constraints

Holodeck nested environment limits VLAN trunk verification
Physical switch configuration not accessible in nested lab

Assumptions

vDS health check provides accurate configuration validation
NIOC shares are sufficient for workload traffic patterns

Risks

MTU mismatch between hosts causes silent performance degradation on vSAN
VLAN misconfiguration isolates VMs without clear error messages

Self-Assessment Discussion Prompts

Why does vSAN require MTU 9000 and what happens if one host has MTU 1500?
How would you use vDS port mirroring to diagnose a VM-to-VM latency issue?
What is the safe sequence for migrating uplinks from VSS to VDS?

Extensions

Configure vDS port mirroring and capture traffic with tcpdump on an ESXi host

Test NIOC by generating heavy vMotion traffic and observing bandwidth reservation

Practice VSS-to-VDS migration using a test host with VSS configured

⚠ Known Pitfalls (from Community KB)

vDS health check must be manually enabled — it's disabled by default and does not run automatically

Changing VLAN on a port group affects ALL VMs on that port group immediately — test on non-production port group first

NIOC is only available on vDS — VSS has no traffic prioritization capability

References

vSphere Distributed Switch AdministrationTier 1 — Official
vSAN Network RequirementsTier 1 — Official
Network I/O ControlTier 1 — Official

Mark complete