How to Create a Virtual Switch in VMware Workstation and VMware ESXi: A Complete Step-by-Step Guide
A virtual switch is the foundation of VMware networking, enabling VMs to communicate with each other and with external networks. In VMware Workstation, virtual switches (via Virtual Network Editor) define how guest VMs connect to the host and the outside world. In VMware ESXi, vSwitches provide enterprise‑grade connectivity, supporting VLANs, NIC teaming, and integration with vCenter for centralized management. Creating a virtual switch is a mandatory first step in configuring VM networking, whether for lab setups in Workstation or production clusters in ESXi. This guide walks through the process in both platforms, highlighting the differences and best practices.
What Is a VMware Virtual Switch and Why It Matters
How Virtual Switches Replace Physical Network Infrastructure
A VMware virtual switch is a software‑based Layer 2 switch that connects virtual machine NICs to physical uplinks and logical port groups. Instead of relying on physical switches, it provides internal packet forwarding between VMs on the same host and external connectivity through physical adapters. Virtual switches enforce VLAN tagging, security policies, and traffic shaping entirely in software, eliminating the need for dedicated hardware. They scale with the hypervisor, allowing administrators to define isolated networks, segment workloads, and integrate with distributed switching for cluster‑wide consistency. In practice, the virtual switch is the foundation of VMware networking — every VM’s traffic flows through it before reaching the physical network.
The Three VMware Virtual Switch Types at a Glance
| Switch Type | Platform | Scope | Management Point | License Required |
|---|---|---|---|---|
| Standard vSwitch (vSS) | ESXi / ESX / ESX Server | Single host | VMware Host Client / vCenter per host | Free / Standard |
| Distributed vSwitch (vDS / dvSwitch) | vSphere + vCenter | Multiple ESXi hosts | vCenter Server only | vSphere Enterprise Plus |
| Virtual Network Editor | VMware Workstation / Player | Desktop hypervisor | Workstation UI | Workstation Pro/Player license |
Key Components: Port Groups, Uplinks, VMkernel Adapters, and NICs
- Port Groups → Logical collections of ports on a vSwitch. They define network policies (VLAN ID, security, traffic shaping) and connect VMs to specific networks.
- Uplinks → Physical NICs on the ESXi host mapped to the vSwitch. They provide external connectivity to the physical network.
- VMkernel Adapters → Special interfaces used by the hypervisor for management traffic, vMotion, storage (iSCSI/NFS), and fault tolerance. They operate at the host level, not the VM level.
- Virtual NICs (vNICs) → Network adapters assigned to individual VMs. Each vNIC connects to a port group, which in turn connects through the vSwitch to uplinks and VMkernel services.
Together, these components form the logical path: VM vNIC → Port Group → vSwitch → Uplink → Physical Network, with VMkernel adapters providing host‑level services.
How to Create a Virtual Switch in VMware Workstation
Prerequisites: VMware Workstation Pro vs. Player — What Each Supports
- Workstation Pro ✅ → Includes the Virtual Network Editor, allowing full custom vSwitch creation (Bridged, NAT, Host‑Only).
- Workstation Player ❌ → Limited networking; no Virtual Network Editor, cannot create custom vSwitches.
Step‑by‑Step: Opening the Virtual Network Editor in Workstation
- 1. 🖥️ Launch VMware Workstation Pro.
- 2. ⚙️ Go to Edit → Virtual Network Editor.
- 3. 🔑 Click Change Settings (requires admin/elevated privileges).
- 4. ➕ Click Add Network → select a VMnet slot (VMnet2–VMnet19).
- 5. 🌐 Choose the switch type:
- Bridged → Direct connection to physical NIC.
- NAT → VM traffic routed through host’s IP.
- Host‑Only → Isolated network between host and VMs.
- 6. 📝 Configure subnet IP and subnet mask for Host‑Only or NAT networks.
- 7. 💾 Click Apply, then OK
Virtual Switch Modes in VMware Workstation: Bridged, NAT, and Host-Only Explained
| Mode | VM Connectivity | Gets External IP | Use Case |
|---|---|---|---|
| Bridged | Connects directly to physical network via host NIC | Yes (from DHCP or static) | VMs that need full LAN/internet access |
| NAT | Shares host IP through address translation | No (uses host's external IP) | Isolated VMs needing internet without LAN exposure |
| Host-Only | Communicates only with host and other VMs on same VMnet | No | Isolated lab networks, internal-only VM clusters |
| Custom | User-defined VMnet, no automatic configuration | Configurable | Advanced lab topologies |
Assigning the New Virtual Switch to a VM Network Adapter
- 1. 🖥️ Open VM Settings for the target VM.
- 2. 🔌 Select Network Adapter from the hardware list.
- 3. 🎛️ Choose Custom: Specific virtual network.
- 4. 📡 From the dropdown, select the VMnet you created earlier (e.g., VMnet2).
- 5. 💾 Click OK to save and apply the configuration.
Verifying Connectivity After Switch Creation in Workstation
- ✅ Power on the VM and check its network adapter settings inside the guest OS.
- 🌐 Run a simple ping test to the host or another VM on the same VMnet.
- 🔍 For NAT or Bridged networks, confirm internet access by opening a browser.
- 🛠️ If connectivity fails, re‑check subnet IP/mask and ensure the VMnet is correctly mapped in the Virtual Network Editor.
How to Create a Standard Virtual Switch in VMware ESXi
Prerequisites: ESXi Host Client Access, Physical NIC Availability, and Port Planning
- 🖥️ Access to the VMware Host Client (
https://[ESXi-IP]/ui). - 🔌 At least one available physical NIC (vmnic) for uplink assignment.
- 📋 Planned port groups and VLAN IDs for workload segmentation.
Step‑by‑Step: Adding a Standard vSwitch via the VMware Host Client (ESXi 7.0 / 8.0)
- 1. Log in to the VMware Host Client at
https://[ESXi-IP]/ui. - 2. In the left Navigator, right‑click Networking and select Add standard vSwitch.
- 3. Click Add uplink and assign a physical NIC (vmnic) as the uplink.
- 4. Enter a name for the virtual switch (e.g.,
vSwitch1). - 5. Expand Link discovery and choose one option:
- 6. In Protocol, select Cisco Discovery Protocol if using Cisco switches.
- 7. Expand Security and configure policies:
- 8. Click Add to create the vSwitch.
Adding a Port Group to the New Standard vSwitch
- 🗂️ Go to Networking → Port groups → Add port group.
- ✏️ Enter a name (e.g., App‑Network).
- 🔖 Assign a VLAN ID.
- 🔗 Select the vSwitch created above.
Adding a VMkernel Adapter for Management, vMotion, or Storage Traffic
- ⚙️ Navigate to Networking → VMkernel NICs → Add VMkernel NIC.
- 🔗 Assign it to the appropriate port group.
- 🌐 Configure IP settings.
- ✅ Enable required services (Management, vMotion, iSCSI/NFS, Fault Tolerance).
Verifying Standard vSwitch Configuration in the Host Client Topology View
| Policy | Reject Behavior | Accept Behavior | Recommended Default |
|---|---|---|---|
| Promiscuous mode | VM receives only its own addressed frames | VM receives all frames on the VLAN | Reject |
| MAC address changes | Drops inbound frames if guest OS MAC differs from .vmx | Allows frames to new MAC address | Reject |
| Forged transmits | Drops outbound frames with mismatched source MAC | No filtering on outbound frames | Reject |
How to Create a Distributed Virtual Switch in VMware vSphere (vCenter)
When to Use a Distributed vSwitch Instead of Standard vSwitches
- 🏢 Large environments with many ESXi hosts.
- 🔄 Consistent vMotion networking across hosts.
- 🎛️ Centralized VLAN and port group management.
- ⚖️ Network I/O Control for traffic prioritization.
- 🔍 Advanced features like port mirroring for monitoring.
Licensing Requirement: vSphere Enterprise Plus
- 🔑 Enterprise Plus license required for vDS.
- 🆓 Free trial includes vDS for 60 days.
- ❌ Free ESXi edition does not support vDS.
Step 1 — Create the Distributed Virtual Switch in vCenter
- 1. 🖥️ Open vSphere Client → navigate to Hosts and Clusters.
- 2. 📂 Right‑click the target Datacenter → Distributed Switch → New Distributed Switch.
- 3. ✏️ Enter a name (e.g.,
DSwitch01) and confirm datacenter location. - 4. 📡 Select Version → match the lowest ESXi host version in the cluster.
- 5. ⚙️ Configure settings:
DPortGroup01).- 6. ✅ Review and click Finish.
Step 2 — Add ESXi Hosts to the Distributed Virtual Switch
- 1. 📂 Right‑click the new vDS → Add and Manage Hosts.
- 2. 🔧 Select task → Add hosts.
- 3. ➕ Click New hosts (+) → tick target ESXi hosts → confirm compatibility.
- 4. 🔌 Assign physical NICs (vmnics) to uplinks.
- 5. 🌐 Manage VMkernel adapters → keep
vmk0on standard vSwitch for management continuity. - 6. 🛠️ Optionally migrate VM adapters to new vDS port groups.
- 7. ✅ Review and click Finish.
Step 3 — Add VMkernel Adapters to the Distributed Port Group
- 1. 📂 In Networking, right‑click the distributed port group → Add VMkernel Adapters.
- 2. 🖥️ Select attached ESXi hosts.
- 3. ⚙️ Configure adapter:
- 4. 🌐 Configure IPv4 settings → assign static IPs per host.
- 5. ✅ Review and click Finish.
Step 4 — Verify VDS Topology and Export Configuration
- 🗺️ Navigate to Distributed Switch → Configure → Settings → Topology → confirm hosts and port groups.
- 💾 Export configuration via Actions → Settings → Export Configuration for backup.
VDS-Exclusive Features Not Available on Standard vSwitches
| Feature | Standard vSwitch | Distributed vSwitch |
|---|---|---|
| Per-host manual configuration | Required | Not required (centrally managed) |
| Network I/O Control (inbound shaping + reservations) | No | Yes |
| Port mirroring | No | Yes |
| Network health check (VLAN, MTU, NIC teaming) | No | Yes |
| Private VLAN (PVLAN) | No | Yes |
| LACP (Link Aggregation Control Protocol) | No | Yes |
| NetFlow support | No | Yes |
| LLDP (Link Layer Discovery Protocol) | No | Yes |
| VM port blocking | No | Yes |
| Network vMotion (preserves VM port connectivity) | No | Yes |
| vNetwork API (third-party virtual switches) | No | Yes |
| Backup and restore of switch configuration | No | Yes |
| vCenter required | No | Yes |
| License required | Standard | Enterprise Plus |
How to Create a Virtual Switch in VMware ESX Server (Legacy)
ESX vs. ESXi: Key Architecture Differences Affecting vSwitch Creation
- 🖥️ ESX → Included a Service Console (Linux‑based OS) for management.
- ⚙️ ESXi → Stripped hypervisor kernel, no Service Console, managed via Host Client or vCenter.
- 🔄 Result → vSwitch creation workflow differs: CLI in ESX vs GUI/API in ESXi.
Creating a vSwitch in VMware ESX via the Service Console (CLI Method)
- ➕ Create vSwitch:
esxcfg-vswitch -a vSwitch1- 🔌 Add uplink NIC:
esxcfg-vswitch -L vmnic1 vSwitch1- 🌐 Add port group:
esxcfg-vswitch -A "VM Network" vSwitch1Creating a vSwitch in VMware ESX via the Legacy VI Client (GUI Method)
- 1. 🖥️ Open VI Client → go to Configuration tab → Networking.
- 2. ➕ Launch Add Networking wizard.
- 3. 🔧 Select connection type: Virtual Machine or VMkernel.
- 4. 🌐 Assign physical NICs and configure port groups.
Creating a vSwitch in VMware Server 2.x (Hosted Hypervisor)
- 📂 In VMware Server Management Interface:
- Navigate to Virtual Machine → Network Settings.
- Configure virtual switch under Infrastructure → Networking.
Migrating from ESX/VMware Server Legacy vSwitches to Modern ESXi vSS or vDS
- 🔄 Legacy ESX/Server vSwitches are not directly portable.
- 📦 Migration requires manual recreation of port groups, VLANs, and uplinks in ESXi.
- 🛠️ For large environments, consider Distributed vSwitch (vDS) for centralized management.
Virtual Switch Configuration Best Practices Across All VMware Platforms
NIC Teaming: Assigning Multiple Uplinks for Redundancy and Load Balancing
- 🔌 Always assign two or more physical NICs to a vSwitch uplink group.
- ⚖️ Enables load balancing and failover protection.
- 🛡️ Critical for production workloads — prevents single NIC failure from isolating VMs.
VLAN Configuration: Tagging Port Groups for Network Segmentation
- 🏷️ Use VLAN IDs on port groups to logically separate traffic (e.g., management, storage, VM networks).
- 🔒 Ensures isolation between workloads and departments.
- 🌐 Align VLAN IDs with physical switch configuration to avoid mismatched tagging.
MTU Settings: When to Use Jumbo Frames (9000 bytes) vs. Standard (1500 bytes)
- 📦 Standard MTU (1500) → Default, sufficient for most VM traffic.
- 🚀 Jumbo Frames (9000) → Recommended for storage traffic (iSCSI/NFS) and high‑throughput workloads.
- ⚠️ Must be configured consistently across vSwitch, VMkernel adapters, and physical switches to avoid fragmentation.
Security Policies: When to Override the Default Reject Settings
- 🔍 Promiscuous Mode → Default Reject; enable only for IDS/firewall appliances.
- 🆔 MAC Address Changes → Default Reject; allow only if guest OS legitimately changes MAC (rare).
- 📤 Forged Transmits → Default Reject; enable only for specific network appliances requiring custom MAC usage.
- 🛡️ Best practice → Keep defaults unless a documented use case requires override.
Separating Traffic Types: Management, VM, vMotion, and Storage on Dedicated vSwitches
| Traffic Type | Dedicated vSwitch | Recommended VMkernel Service | Notes |
|---|---|---|---|
| Management | vSwitch0 (default) | Management Network | Never share with untrusted VM traffic |
| VM data traffic | vSwitch1 | None (VM port groups only) | Assign uplinks from separate pNICs |
| vMotion | vSwitch2 | vMotion | Dedicate high-bandwidth NIC pair |
| iSCSI / NFS storage | vSwitch3 | Storage (iSCSI/NFS) | Jumbo Frames (MTU 9000) recommended |
| Fault Tolerance logging | vSwitch4 | Fault Tolerance Logging | Low-latency NIC recommended |
Virtual Machine File Recovery After vSwitch Misconfiguration or Network Failure
How vSwitch Misconfiguration Can Lead to VM Inaccessibility and Data Loss
- 🔌 Incorrect uplink assignment → datastores unreachable.
- 🏷️ VLAN misconfiguration → isolates VMs from management traffic.
- ❌ Accidental deletion of a port group → running VMs lose connectivity.
- ⚠️ Result → VMFS datastores inaccessible, VMs orphaned, potential metadata corruption.
Recovering VMFS Datastores and VMDK Files with DiskInternals VMFS Recovery™
- 📖 Native VMFS reader → supports VMFS 3, 5, and 6.
- 💾 Recovers VMDK images across vSphere, ESXi/ESX Server.
- 🔑 SSH‑based remote recovery → works even if management vSwitch is degraded.
- 🗂️ Full RAID support (0, 1, 4, 5, 6, 10, JBOD, LVM).
- ⚡ Fast Recovery Mode vs 🛠️ Full Recovery Mode depending on damage level.
- 👀 100% read‑only preview before purchase.
- 📦 Handles files up to 64 TB; VMFS5 with 100k+ files.
- 🏆 22+ years experience; 90%+ success rate.
- 🤝 Guided Recovery Service available for complex cases.
- 🖥️ Compatible with Windows 7–11 and Windows Server 2008–2022.
Step‑by‑Step: Using VMFS Recovery™ After a Network‑Induced Datastore Failure
- 1. 💻 Download and install DiskInternals VMFS Recovery™ on a Windows management machine.
- 2. 🔑 Connect to the ESXi host via SSH (enable SSH in Host Client → Manage → Services).
- 3. 📂 Select the target VMFS datastore or physical disk/RAID array.
- 4. ⚡ Run Fast Recovery Mode first; escalate to Full Recovery Mode if needed.
- 5. 👀 Preview recovered files in read‑only mode to confirm integrity.
- 6. 📤 Export recovered VMDK images or files to a local drive, network share, or FTP destination.
Backing Up vSwitch Configuration to Prevent Repeat Incidents
- 💾 For Distributed vSwitches → Export config in vCenter: Actions → Settings → Export Configuration.
- 🗂️ For Standard vSwitches → Use Host Profile export or PowerCLI Get‑VirtualSwitch.
- 🛡️ Regular backups ensure quick rollback if misconfiguration occurs again.
Ready to get your data back?
To start recovering your data, documents, databases, images, videos, and other files, press the FREE DOWNLOAD button below to get the latest version of DiskInternals VMFS Recovery® and begin the step-by-step recovery process. You can preview all recovered files absolutely for FREE. To check the current prices, please press the Get Prices button. If you need any assistance, please feel free to contact Technical Support. The team is here to help you get your data back!
Troubleshooting Common VMware Virtual Switch Errors
No Connectivity After Creating a New vSwitch: Checklist
- 🖥️ Verify VM network adapter is assigned to the correct port group.
- 🔌 Ensure uplinks are mapped to active physical NICs.
- 🌐 Check IP configuration inside the guest OS.
- 🛠️ Confirm VLAN IDs match physical switch settings.
Physical NIC Not Available as Uplink: Causes and Fixes
- ❌ NIC already assigned to another vSwitch.
- 🔧 NIC disabled or driver not loaded.
- 🔄 Re‑scan hardware in ESXi Host Client → Manage → Networking → Physical NICs.
- 🛡️ Replace faulty NIC if hardware failure is suspected.
Port Group VLAN Mismatch: Diagnosing with Network Health Check (vDS)
- 🏷️ VLAN ID mismatch between vDS port group and physical switch trunk port.
- 🔍 Use Network Health Check in vDS to detect inconsistencies.
- ⚙️ Correct VLAN IDs on both vDS and physical switch.
VMkernel Adapter IP Conflict After vSwitch Migration
- 🌐 Duplicate IPs assigned during migration.
- 🛠️ Verify VMkernel NICs in Host Client → Networking → VMkernel NICs.
- ✏️ Assign unique static IPs per host to avoid overlap.
vCenter Offline: Can the Distributed vSwitch Still Function?
- ✅ Yes — vDS continues forwarding traffic even if vCenter is offline.
- ⚠️ Limitation → Cannot modify vDS configuration until vCenter is restored.
- 🛡️ Best practice → Export vDS configuration regularly for quick recovery.
Conclusion: Choosing the Right VMware Virtual Switch for Your Environment
At the core, VMware offers multiple virtual switch types, each aligned to platform scale and licensing:
- 🖥️ Workstation → Uses the Virtual Network Editor for desktop‑level VMnet creation.
- ⚙️ ESXi → Relies on the Host Client for per‑host standard vSwitches.
- 🌐 vCenter → Unlocks the distributed vSwitch (vDS) for multi‑host management, centralized VLANs, and advanced features like Network I/O Control.
- 📜 Legacy ESX/VMware Server → Requires CLI (esxcfg‑vswitch) or VI Client workflows.
The governing principle: match the switch type to the platform, the scale, and the licensing tier. For desktop labs, VMnet suffices; for single hosts, vSS is efficient; for enterprise clusters, vDS is essential.
Finally, remember that network misconfiguration or hardware failure can put datastore data at risk. 🛡️ DiskInternals VMFS Recovery™ provides the safety net — restoring VMFS datastores, VMDK files, and VMX configs when connectivity errors or vSwitch failures leave VMs inaccessible.