Create a vSphere Distributed Switch and Port Groups

Object	Scope	Purpose
vSphere Distributed Switch	vCenter datacenter	Centralizes switch, uplink, monitoring, traffic-management, and host networking policy
Uplink port group	One vDS	Provides named uplinks that map to each host’s physical NICs, such as vmnic0 and vmnic1
Distributed port group	One vDS	Applies VLAN, teaming, security, shaping, and port-binding policy to VM or VMkernel connections
Distributed port	One connection	Connects an individual virtual NIC or VMkernel adapter to a distributed port group

Last reviewed September 9, 2026. The screenshots in this article were captured in a 2019 vSphere environment and are retained as a legacy visual reference. Menu names and available switch versions vary by release. Use the current Broadcom compatibility matrix and product documentation as the source of truth.

---

Table of contents

1. What a vSphere Distributed Switch does
2. What a distributed port group does
3. Planning checklist
4. Create the distributed switch
5. Create distributed port groups
6. Add hosts and migrate networking
7. Validate the design
8. Troubleshooting and rollback
9. VxRail and VCF considerations
10. Frequently asked questions

What is a vSphere Distributed Switch?

A vSphere Distributed Switch is a centrally managed virtual switch that spans participating ESXi hosts in a vCenter datacenter. You define the switch, uplink names, port groups, and policies once in vCenter instead of recreating equivalent settings independently on every host. vCenter supplies the management plane; each attached host maintains a proxy-switch representation that forwards traffic in the data plane.

That distinction matters during an outage. Existing workloads already assigned to static distributed ports continue forwarding when vCenter is unavailable, but changes that require a new static port assignment cannot be made until vCenter returns. A vDS therefore improves consistency without removing the need for a tested management-network recovery path.

Design question	vSphere Standard Switch (vSS)	vSphere Distributed Switch (vDS)
Configuration scope	One ESXi host	Multiple hosts in a vCenter datacenter
Policy consistency	Recreated and maintained per host	Defined centrally and propagated to attached hosts
Management dependency	Can be changed directly on the host	Most switch and port-group configuration is controlled through vCenter
Typical use	Simple, isolated, bootstrap, or recovery networking	Consistent cluster networking, monitoring, traffic management, and larger operational domains

What is a distributed port group in VMware?

A distributed port group is a reusable network-policy object on a vDS. Virtual-machine NICs and VMkernel adapters connect to its distributed ports and inherit settings such as VLAN mode, teaming and failover, security, traffic shaping, and port binding. A name such as DVPG-Management-VLAN10 describes the logical policy; it does not create or allow VLAN 10 on the physical switches.

Static binding is the default and Broadcom’s general-use recommendation. A port is assigned when a VM or VMkernel adapter connects and remains reserved until that connection is removed. Ephemeral binding lets an ESXi host create a port without vCenter, which can help with specific recovery paths such as reconnecting the vCenter Server VM. It carries operational tradeoffs and should be used intentionally, not as the default for every workload.

Plan the vDS before changing host networking

• Compatibility: select a distributed-switch version supported by vCenter and every ESXi host that will attach to it. Do not select a newer switch version simply because the wizard offers it.
• Licensing and privileges: confirm the required vSphere entitlement and that the operator can create and modify distributed switches, port groups, and host networking.
• Physical mapping: document each host’s vmnic-to-switch-port mapping, link speed, redundancy pair, trunk configuration, and any LAG or LACP dependency.
• VLAN parity: verify that every destination port group uses the intended VLAN and that the VLAN is allowed across the complete physical path.
• MTU parity: align the vDS, VMkernel adapter, physical switch, and routed path. A larger virtual MTU does not help if one physical hop still drops the frame.
• Traffic inventory: map management, vMotion, storage, fault-tolerance, replication, NSX, and VM networks to explicit destination port groups.
• Teaming policy: define active, standby, and unused uplinks per port group. Confirm that the policy matches the physical-switch design.
• Recovery access: confirm out-of-band console or DCUI access before moving vmk0, and document the source configuration.
• Change scope: use one test host and one network at a time. Avoid moving all uplinks, VMkernel adapters, and workloads in a single unverified step.

Step 1: Create the vSphere Distributed Switch

1. In the vSphere Client, open Networking.
2. Right-click the target datacenter and choose Distributed Switch > New Distributed Switch.
3. Enter a name that identifies the switch’s scope and purpose.
4. Select a vDS version compatible with the vCenter Server and all participating hosts.
5. Set the uplink count to match the host design. This creates logical uplink names; physical NICs are assigned later.
6. Choose the Network I/O Control setting required by the design. The option is not a substitute for capacity planning.
7. Create a default port group only if its VLAN and policy are already known; otherwise create explicit port groups after the switch.
8. Review the summary and create the switch.

Legacy vSphere Client screenshots: switch creation

These images show the same high-level workflow in the older interface. Treat the listed vDS versions as historical examples, not a current compatibility matrix.

Step 2: Create and verify distributed port groups

Create the destination port groups before migrating a host. For each source network, record the source port-group name, VLAN, MTU context, teaming order, security overrides, traffic shaping, and attached VM or VMkernel interfaces. Build the destination policy from that inventory instead of assuming the defaults are equivalent.

1. Right-click the vDS and choose Distributed Port Group > New Distributed Port Group.
2. Use a name that identifies the traffic function and VLAN.
3. Keep Static binding for general use unless a documented recovery requirement calls for ephemeral binding.
4. Select the VLAN type and ID that match the physical trunk and network design.
5. After creation, edit the port group to set teaming and failover, security, shaping, monitoring, and other required policies.
6. Repeat for management, vMotion, storage, VM, and other traffic classes before migrating any adapters.

Legacy vSphere Client screenshots: port-group creation

Step 3: Add hosts and migrate networking safely

Broadcom’s production migration guidance uses a staggered approach when redundant physical NICs are available. The objective is to maintain one known-good path on the source vSS while establishing and validating the destination vDS path. A maintenance window, host evacuation, and network-team coordination may still be appropriate for the environment.

1. Confirm console access, host health, physical-switch configuration, and the destination port groups.
2. Right-click the vDS and choose Add and Manage Hosts > Add hosts.
3. Select one test host.
4. Move one redundant physical NIC from the source vSS to a vDS uplink. Leave the other source uplink in service.
5. Confirm that the new uplink is up and that its physical switch port carries every required VLAN at the expected MTU.
6. Assign the selected VMkernel adapter to its matching distributed port group. Move management traffic only after destination reachability is verified.
7. Migrate a small, controlled set of VM network adapters to their matching port groups and test connectivity.
8. After management, VMkernel, and workload validation passes, move the remaining physical uplink and apply the approved active/standby policy.
9. Repeat host by host. Do not treat success on one physical path as proof that every host port and trunk is configured identically.

Legacy vSphere Client screenshots: adding hosts

Step 4: Validate before expanding the migration

• Verify both physical uplinks are up at the expected speed and mapped to the intended dvUplinks.
• Confirm vCenter-to-host management connectivity remains stable and no network rollback event occurred.
• Check VLAN reachability from management, vMotion, storage, and test-VM networks.
• Validate end-to-end MTU with the appropriate VMkernel test. The vmkping MTU and jumbo-frame guide provides a practical workflow.
• Test vMotion and any storage path that uses a migrated VMkernel adapter.
• Test a workload on each migrated distributed port group, including gateway, DNS, and application reachability where appropriate.
• Test uplink failover one path at a time and confirm the port-group active/standby policy behaves as designed.
• Review host and vDS health, alarms, out-of-sync status, and recent tasks before migrating the next host.
• Export the vDS configuration, including all port groups, after the design is validated and after significant changes.

Troubleshooting and rollback

Symptom	Likely fault domain	First check
Host disconnects and the task rolls back	Management VLAN, MTU, teaming, uplink, or physical path	Compare source and destination settings, then verify the entire physical path carries management traffic
Uplink is up but a VLAN does not pass	Trunk allow list, native/tagged mismatch, or port-group VLAN	Compare port-group VLAN mode with the physical switch-port configuration
Only one host or uplink fails	Per-port cabling, trunk, LAG, or vmnic mapping	Compare the failed host’s physical mapping with a known-good host
Small packets work but jumbo traffic fails	End-to-end MTU mismatch	Test from the correct VMkernel interface with do-not-fragment semantics
VMs run but cannot be reconnected while vCenter is down	Static port binding requires vCenter for a new assignment	Restore vCenter or use a preplanned recovery network; do not convert every port group to ephemeral
vDS or port group is out of sync	Failed policy propagation or unresolved host connectivity	Correct the underlying configuration and review the vDS health and task history

vSphere network rollback is designed to reject or revert management-network changes that break host-to-vCenter connectivity. If the automated rollback is triggered, treat it as evidence that the destination path is not ready; verify VLAN, MTU, uplink, and teaming alignment before retrying. Do not disable rollback as a routine workaround.

For vSphere 7.0 and later, Broadcom also documents a DCUI Restore vDS recovery option for supported management-network failures. Confirm console access before the change so this path is available if vCenter cannot reach the host.

VxRail and VMware Cloud Foundation considerations

The original version of this article showed an additional vDS for a VxRail environment with extra physical adapters. That was one specific deployment pattern, not a universal recommendation. Current VxRail and VCF designs may create or manage distributed switches, port groups, uplinks, and VMkernel networks through solution workflows. Before adding or changing a vDS, confirm that the design is supported by the exact VxRail, VCF, vCenter, ESXi, and NSX versions in use and that the change will not conflict with lifecycle automation.

For NSX-backed environments, separate the vDS underlay responsibilities from overlay-segment behavior. The VMware NSX GENEVE overlay guide explains transport nodes, TEP reachability, and MTU validation.

Frequently asked questions

Are vDS, VDS, DVS, and distributed virtual switch the same thing?

Administrators commonly use all four terms for the vSphere Distributed Switch. VMware and Broadcom documentation most often uses vSphere Distributed Switch and abbreviations such as vDS or VDS.

What is the purpose of a VMware port group?

A port group gives a set of virtual connections a consistent network policy. On a vDS, the distributed port group defines VLAN, teaming, security, shaping, and binding behavior across participating hosts.

Does a distributed switch stop working if vCenter is down?

No. Existing traffic on already assigned distributed ports continues forwarding on the ESXi hosts. However, vCenter is normally required to change vDS and port-group configuration or assign a VM to a new static distributed port.

Should every management port group use ephemeral binding?

No. Static binding is the default general-use choice. Ephemeral binding is valuable for specific recovery scenarios because a host can create a port without vCenter, but it has performance and operational tradeoffs. Apply it only where the recovery design justifies it.

Can I migrate from a standard switch to a vDS without downtime?

A staged migration with redundant uplinks can preserve a live path and reduce interruption risk, but it is not a blanket zero-downtime guarantee. The result depends on correct VLAN, MTU, physical-switch, teaming, VMkernel, and workload configuration. Use a maintenance plan and test one host at a time.

Official Broadcom references

• vSphere Distributed Switch upgrade best practices and compatibility
• Best practices for migrating ESXi hosts between vSS and vDS
• Understanding network rollback and recovery in vSphere 7.0 and later
• Exporting, importing, and restoring distributed-switch configurations
• Static and ephemeral port binding on a vSphere Distributed Switch

Continue reading

Useful Ruby Shell vSAN Commands

Explore another guide in this topic and build on what you have just read. Read the article →

Stay informed

Make your next architecture decision with confidence.

Get Paul Bryant's practical guides to enterprise AI, hybrid platforms, and day-2 operations by email. New articles as they publish. Unsubscribe anytime.

Email Address

Get new articles