VMware ESXi and vSphere Cluster Management

Create a Standard vSwitch and VMkernel Port Group for vMotion in VMware ESXi

Learn how to create a standard vSwitch, configure a VMkernel port group, enable vMotion, and verify connectivity on every ESXi host.

vSphere vMotion live-migrates a powered-on virtual machine from one compatible ESXi host to another. During the migration, ESXi transfers the virtual machine's execution state over a host networking path.

This guide explains how to create that path with an ESXi standard vSwitch and a vMotion-enabled VMkernel network adapter. Configure compatible vMotion networking on every ESXi host that can be a migration source or destination.

How the vMotion network works

A vMotion network is a host-to-host network used for vMotion traffic. It should be dedicated when possible, or deliberately shared with other VMkernel services when the physical and logical design provides sufficient capacity and isolation.

vMotion is enabled on a VMkernel adapter, not on a virtual-machine port group. A VMkernel adapter is an ESXi host interface used by services such as management, vMotion, storage, vSAN, and fault tolerance logging.

Core components

• ESXi host: A VMware hypervisor that runs virtual machines.
• vCenter Server: The centralized management platform used to manage ESXi hosts and initiate vMotion operations.
• Standard vSwitch: A host-local virtual switch configured independently on each ESXi host.
• Physical NIC: A network adapter installed in the host.
• Uplink: A physical NIC assigned to a virtual switch, such as vmnic2.
• VMkernel adapter: A host network interface commonly named vmk0, vmk1, and so on.
• VMkernel port group: The configuration associated with a VMkernel adapter. It includes a network label, VLAN settings, IP configuration, and enabled host services.
• VLAN ID: An 802.1Q segmentation identifier applied when the physical network uses VLAN tagging.
• MTU: The maximum transmission unit, or largest packet size supported on a network path.

The standard vSwitch connects the VMkernel adapter to one or more physical uplinks. The VMkernel port group's label helps administrators identify the connection, but the label itself does not provide connectivity. VLAN configuration, IP addressing, routing, uplinks, and physical-switch settings determine whether hosts can communicate.

Prerequisites and design decisions

1. Confirm that the source and destination ESXi hosts are managed in the same vCenter Server environment for the intended standard vMotion workflow.
2. Confirm that every participating host has an available physical NIC or enough capacity on an existing uplink.
3. Identify the physical network, VLAN ID, IP subnet, gateway requirements, and MTU before starting.
4. Decide whether vMotion will use a dedicated standard switch and uplink or share a switch with other VMkernel services.
5. Plan a unique, mutually reachable VMkernel IP address for every participating host.
6. Verify that the physical switch permits the selected VLAN and supports the selected MTU end to end.
7. Use redundant uplinks when vMotion availability requirements justify them. Verify the corresponding physical-switch design and teaming policy.

Static IPv4 addressing is generally preferable for host infrastructure because addresses remain predictable. DHCP is valid only when reliable address assignment and infrastructure policy support it.

Example two-host design

In this example, two hosts use a dedicated vMotion network:

• ESX01: standard switch vSwitch-vMotion, uplink vmnic2, VMkernel adapter vmk1, address 192.168.120.11/24.
• ESX02: an equivalent standard switch and uplink arrangement, with VMkernel adapter vmk1 and address 192.168.120.12/24.
• Port group: vMotion on VLAN 120.
• Service: vMotion enabled on both VMkernel adapters.

The VMkernel adapter names may differ between hosts. The addresses must be unique, and the VLAN, MTU, and physical reachability must support communication between the two adapters.

Create the standard vSwitch and VMkernel port group

Perform these steps for the first ESXi host in the vSphere Client.

1. Select the ESXi host in the inventory.
2. Open Manage, then open Networking.
3. Choose the action to Add host networking.
4. For the connection type, select VMkernel Network Adapter.
5. Choose New standard switch.
6. Select the physical network adapter or adapters to assign as switch uplinks. For the example, select vmnic2. Add a second uplink if the design requires redundancy.
7. Enter a meaningful VMkernel port-group label, such as vMotion.
8. Enter the required VLAN ID, such as 120. Leave the VLAN configuration consistent with the physical-switch design.
9. Enable the vMotion traffic service for the VMkernel adapter. Do not enable it on a virtual-machine port group.
10. Configure IPv4 addressing. Select DHCP only when approved by the network design. Otherwise select static addressing and enter the host's unique IP address, subnet mask or prefix, and gateway when the design requires one.
11. Review the standard switch, uplink, port-group, service, VLAN, MTU, and IP settings.
12. Finish the wizard and wait for the host networking task to complete.

Standard switch:       vSwitch-vMotion
Physical uplink:       vmnic2
VMkernel port group:   vMotion
VLAN ID:               120
VMkernel adapter:      vmk1
ESX01 address:         192.168.120.11/24
ESX02 address:         192.168.120.12/24
Enabled service:       vMotion

Shared standard switch design

A dedicated vMotion switch is not the only design. A host can use one standard switch with multiple uplinks and separate VMkernel port groups. For example, a management port group and a vMotion port group can use different VLAN IDs and different VMkernel IP subnets. Enable the vMotion service only on the intended vMotion adapter, and confirm that the shared uplinks have adequate capacity and appropriate availability.

Repeat the configuration on every participating host

Create an equivalent vMotion-enabled VMkernel adapter on every ESXi host that may be a source or destination. Standardize the following:

• VLAN and physical network reachability.
• MTU and end-to-end jumbo-frame support, if used.
• vMotion service selection.
• Port-group naming for operational clarity.
• Uplink and redundancy design.

Assign a different VMkernel IP address to each host. A matching port-group label is useful for administration, but identical labels alone do not connect hosts. The underlying VLAN, IP subnet or routed design, uplinks, and physical-switch configuration must provide reachability.

Verify vMotion readiness

1. Inspect the VMkernel adapter on each host and confirm that it exists.
2. Confirm that the vMotion traffic service is enabled on the intended adapter.
3. Verify the adapter's IP address, subnet, VLAN ID, MTU, and active uplink.
4. Test VMkernel-to-VMkernel connectivity between the participating hosts.
5. Run a vMotion compatibility check or begin the migration workflow validation before moving a production workload.
6. Confirm that vCenter Server reports no networking-related vMotion configuration errors.

Optional ESXi CLI validation

Run these commands on an ESXi host using the actual adapter name and destination address:

esxcli network ip interface list
esxcli network ip interface tag get -i vmk1
vmkping -I vmk1 192.168.120.12

For a 9000-byte MTU path, test with an appropriately sized payload and do-not-fragment behavior:

vmkping -I vmk1 -d -s 8972 192.168.120.12

The large-payload test is meaningful only when every component in the path supports the configured MTU. Use the actual destination VMkernel IP address for the remote host.

Troubleshooting

No vMotion network is configured on a host

• Check whether the VMkernel adapter was created but the vMotion service was not enabled.
• Inspect both source and destination hosts.
• Enable vMotion on the intended VMkernel adapter.
• Confirm that the adapter is connected to the correct standard switch and port group.

VMkernel ping fails between hosts

• Verify the VLAN ID on both VMkernel port groups.
• Verify that the physical switch trunk or access-port configuration carries the vMotion VLAN.
• Check IP addresses, subnet masks, and any required routing.
• Confirm that an uplink is active and the physical link is available.
• Run vmkping with the intended source VMkernel adapter.

vMotion fails when jumbo frames are enabled

• Check the MTU on the VMkernel port group, standard vSwitch, physical NIC path, physical switches, and any routed segment.
• Use a large vmkping payload with the do-not-fragment option.
• If jumbo-frame support cannot be guaranteed end to end, configure MTU 1500 consistently instead.

Basic connectivity succeeds but migration validation fails

Network reachability is only one vMotion prerequisite. Host compatibility, CPU compatibility, storage accessibility, licensing, and other migration requirements can also cause a precheck failure. Review the detailed migration message in vCenter Server and separate network findings from broader compatibility findings.

Operational cautions

• Take care not to alter management connectivity unintentionally while adding or modifying host networking.
• Never assign the same VMkernel IP address to multiple hosts.
• Do not enable vMotion on an adapter connected to an unintended network.
• An incorrect VLAN, MTU mismatch, unavailable uplink, or missing physical-switch configuration can prevent migration.
• Test changes on a non-production host or maintenance window when the network design is new.

Exam-relevant notes

• vMotion traffic is enabled on a VMkernel adapter.
• A VMkernel port group is different from a virtual-machine port group.
• Every host that can participate in the migration needs compatible vMotion-enabled VMkernel networking.
• VMkernel IP addresses must be unique and mutually reachable.
• Port-group labels do not create connectivity; VLAN, IP, routing, uplinks, and physical-switch settings do.
• MTU must be consistent across the complete path when jumbo frames are used.

After the network is verified, continue with the vMotion standard switch and VMkernel port group procedure as a reference for repeating the configuration across hosts.