When testing vMotion network connectivity from an ESXi host, vmkping can return Unknown interface 'vmkX': Invalid argument even though the VMkernel adapter exists and works for vMotion.
This behavior is almost always related to the vMotion TCP/IP stack or another non‑default stack (vxlan, provisioning) being used on the VMkernel interface.
Scope and prerequisites
This document applies to:
- ESXi hosts using dedicated vMotion VMkernel adapters (often on the vMotion TCP/IP stack).
- Environments where vmkping from ESXi fails with an “Invalid argument” or “Unknown interface” error when specifying
-I vmkX.
Prerequisites:
- Shell/SSH access to the ESXi host (Tech Support Mode / SSH enabled).
- vSphere Client access to verify VMkernel and TCP/IP stack configuration.
Problem description and symptoms
Typical error messages
When running vmkping from ESXi to test vMotion connectivity, you might see:
Unknown interface 'vmk1': Invalid argumentvmkping: sendto() failed: Invalid argument
This usually occurs with commands like:
vmkping -I vmk1 <peer_vmotion_IP>vmkping <peer_vmotion_IP>
Functional impact
Despite the error:
- vMotion may still work successfully because the vMotion TCP/IP stack is functioning correctly.
- Standard
pingfrom ESXi or from external devices to the vMotion IPs may fail because the vMotion stack is L2‑only or has no gateway.
Root cause
vMotion TCP/IP stack behavior
VMkernel adapters can be attached to different TCP/IP stacks:
defaultTcpipStack(usually Management, vMotion, vSAN in simple setups)vmotion(dedicated vMotion TCP/IP stack)vxlan,vSphereProvisioning, etc.
- When a VMkernel adapter is created on the vMotion stack, the gateway option disappears in the UI because this stack is designed as an L2 network for vMotion traffic.
- vmkping uses the VMkernel’s TCP/IP stack, not the host’s management stack, and requires explicit stack selection for non‑default stacks.
If you call vmkping without telling it which TCP/IP stack to use, it assumes defaultTcpipStack.
When the interface is actually on vmotion, this mismatch causes the Unknown interface or Invalid argument error.
Identification: confirm VMkernel and TCP/IP stack
Perform these checks from an ESXi shell:
1. List VMkernel interfaces and stacks
esxcli network ip interface list
- Look at
Name(vmk0, vmk1, …) andNetstack Instancecolumns to see which stack each VMkernel uses (e.g.,defaultTcpipStack,vmotion,vxlan).
esxcfg-vmknic -l
2. List available TCP/IP stacks
esxcli network ip netstack list
3. Validate vMotion tagging and IPs
- For each host, open Configure → Networking → VMkernel adapters.
- Verify:
- Which vmk is enabled for vMotion.
- Whether it uses the vMotion TCP/IP stack or the default stack.
- IP address, VLAN, and port group settings.
Correct test methods for vMotion network
Option 1 – esxcli (recommended for vMotion stack)
Use esxcli network diag ping and specify the VMkernel and the netstack:
esxcli network diag ping -I vmk1 --netstack=vmotion -H <target_vmotion_vmk_IP>
- Replace
vmk1with the local vMotion VMkernel name. - Replace
<target_vmotion_vmk_IP>with the vMotion VMkernel IP of the peer ESXi host.
This method works even when the vMotion stack is L2‑only with no gateway.
Jumbo frame / MTU test
For MTU 9000 testing, include payload size and do‑not‑fragment options:
esxcli network diag ping -I vmk1 --netstack=vmotion -H <target_vmotion_vmk_IP> -s 8972 -d
- For MTU 9000, payload 8972 bytes plus headers approximates the full frame and validates end‑to‑end jumbo support.
Option 2 – vmkping with netstack parameter
If you prefer vmkping directly:
vmkping -S vmotion -I vmk1 <target_vmotion_vmk_IP>
or
vmkping ++netstack=vmotion -I vmk1 <target_vmotion_vmk_IP>
-S vmotionor++netstack=vmotionselects the vMotion TCP/IP stack.- Stack name is case‑sensitive and must match the value from
esxcli network ip netstack list.
For MTU testing:
vmkping ++netstack=vmotion -I vmk1 -s 8972 -d <target_vmotion_vmk_IP>
Step‑by‑step troubleshooting workflow
Use this procedure when you see Invalid argument while testing vMotion.
Step 1 – Confirm VMkernel stack and role
- On each host, run:bash
esxcli network ip interface list - Identify:
- Which vmk has vMotion enabled.
- Its
Netstack Instance(e.g.,vmotion).
- In vSphere Client, verify that vMotion is enabled on that vmk and that IPs are in the correct vMotion VLAN/subnet.
Step 2 – Reproduce the error with standard vmkping
vmkping -I vmk1 <target_vmotion_vmk_IP>
- If you get
Unknown interface 'vmk1': Invalid argument, this confirms the mismatch between vmkping’s default stack and the interface’s actual stack.
Step 3 – Test with correct netstack
vmkping -S vmotion -I vmk1 <target_vmotion_vmk_IP>
# or
esxcli network diag ping -I vmk1 --netstack=vmotion -H <target_vmotion_vmk_IP>
Step 4 – Validate MTU and physical network
If connectivity works but jumbo frame tests fail:
Step 5 – Check routing/gateway expectations
- For vMotion TCP/IP stack, Layer 3 routing typically requires configuring a default gateway for that stack in Networking → TCP/IP configuration on the host.
- Without a gateway or static route, vMotion stack pings to other subnets will fail even if same‑subnet pings work.
Example command set (copy/paste)
Adjust interface names and IPs before using.
# 1. Inventory VMkernel interfaces and stacks
esxcli network ip interface list
esxcfg-vmknic -l
esxcli network ip netstack list
# 2. Test vMotion vmk using vMotion stack (esxcli)
esxcli network diag ping -I vmk1 --netstack=vmotion -H 10.10.20.12
# 3. Test vMotion vmk using vmkping with netstack
vmkping -S vmotion -I vmk1 10.10.20.12
vmkping ++netstack=vmotion -I vmk1 10.10.20.12
# 4. Jumbo frame tests (MTU 9000)
esxcli network diag ping -I vmk1 --netstack=vmotion -H 10.10.20.12 -s 8972 -d
vmkping -S vmotion -I vmk1 -s 8972 -d 10.10.20.12