Vmware Esxi

Configure a VMkernel Port for the VMware ESXi Software iSCSI Initiator

Learn how to create VMkernel iSCSI adapters, configure uplinks and discovery, bind ports, rescan storage, and verify multipathing on VMware ESXi.

A VMkernel adapter is an ESXi host network interface used by host services. Unlike a virtual machine network adapter, it does not belong to a guest operating system. ESXi uses VMkernel adapters for management, vMotion, vSAN, Fault Tolerance logging, provisioning, and storage traffic such as iSCSI.

This lesson explains how to create VMkernel adapters for the ESXi software iSCSI initiator, configure predictable physical paths, discover targets, bind adapters, and verify redundant storage access.

How VMkernel Networking Supports iSCSI

iSCSI transports SCSI block-storage commands over IP. An ESXi host therefore needs IP connectivity from a VMkernel adapter to one or more iSCSI target interfaces. A target portal is a target network endpoint, normally using TCP port 3260.

Keep storage traffic separate from unrelated host services whenever possible. Isolation can use dedicated physical networks, dedicated VLANs, separate port groups, or a combination of these methods.

Understand the Software iSCSI Initiator

An iSCSI initiator is the client that starts iSCSI sessions. The ESXi software iSCSI initiator runs in the host and uses VMkernel networking to connect to storage targets. After it is enabled, ESXi normally represents it as a storage adapter with a name such as vmhbaXX.

This differs from:

• Dependent hardware iSCSI: iSCSI functions are provided by a physical network adapter but depend on ESXi networking and host services.
• Independent hardware iSCSI: a dedicated adapter handles iSCSI processing and has its own hardware-specific configuration.
• Software iSCSI: ESXi provides the iSCSI client in software and sends traffic through configured VMkernel adapters and physical NICs.

The initiator has an IQN, or iSCSI Qualified Name. Storage arrays commonly use this identifier when granting a host access to target portals and LUNs. Record the IQN before configuring array-side host access.

Plan the iSCSI Network First

Before creating adapters, document the complete path from each ESXi VMkernel interface to each target portal. Decide whether the design uses one storage VLAN, separate storage VLANs, or routed networks. Port binding is commonly used when multiple VMkernel interfaces and target paths share an appropriate Layer 2 design; it is not automatically required for every routed iSCSI design.

• Choose dedicated or logically isolated iSCSI networks.
• Document iSCSI VLAN IDs, IP subnets, IPv4 or IPv6 addressing, prefix lengths, and target portal addresses.
• Plan MTU values. Jumbo frames such as 9000 bytes must be configured consistently on the ESXi switch, VMkernel interface, physical switches, and storage interfaces.
• Provide redundant physical NICs, switches, cables, and storage target ports where availability requires it.
• When using iSCSI port binding, ordinarily give each iSCSI VMkernel adapter one active physical NIC. Put other uplinks in unused status for that port group rather than ordinary active/standby failover.
• Do not add a default gateway merely to compensate for an incomplete routing design. Use the routing model required by the storage platform and network team.

Example Two-Path Design

In this example, the iSCSI-A port group has vmnic2 active and other uplinks unused. The iSCSI-B port group has vmnic3 active and other uplinks unused. Ideally, the two NICs connect through independent switch and storage paths.

Create an iSCSI VMkernel Adapter

1. Create or select a standard vSwitch or vSphere Distributed Switch port group dedicated to iSCSI traffic. Name it clearly, such as iSCSI-A or iSCSI-B.
2. Configure the port group's VLAN ID and physical uplinks.
3. Set the uplink policy so the intended VMNIC is active and other uplinks are unused when port binding is planned.
4. Add a VMkernel network adapter to the port group.
5. Assign an IPv4 or IPv6 address, subnet mask or prefix, and the intended MTU. Use a storage-network address, not the management address.
6. On versions and switch types that expose VMkernel service selection, enable the iSCSI service on the adapter.
7. Use a separate VMkernel adapter and port group for each independent storage path. A second adapter should not simply share the same physical path if redundancy is the goal.

In the vSphere Client, this workflow is generally available from the host's networking or VMkernel adapter configuration. Labels vary by vSphere release and by whether the port group is on a standard switch or distributed switch.

For a basic lab, one isolated port group and one VMkernel adapter may be sufficient. It provides connectivity but no host-side network path redundancy.

Enable and Configure Software iSCSI

1. Open the host storage adapters view and locate the software iSCSI adapter. Enable it if it is disabled.
2. Record its IQN and register that IQN with the storage array's host access configuration.
3. Configure discovery using dynamic discovery portals, static target entries, or both, according to the array design.
4. Configure CHAP or mutual CHAP only when required. The initiator and target authentication names, secrets, and direction must match the array configuration.
5. After changing adapter, discovery, or binding settings, rescan the storage adapters.

Bind VMkernel Adapters to iSCSI

iSCSI port binding associates selected VMkernel adapters with the software iSCSI adapter. It helps ESXi use the intended VMkernel-to-uplink relationships for multiple storage paths.

1. Open the software iSCSI adapter's network port binding view.
2. Add each intended iSCSI VMkernel adapter, such as vmk1 and vmk2.
3. Confirm that each adapter maps to the correct port group, VLAN, physical NIC, and target network.
4. Rescan after the binding operation and verify sessions and paths.

Port binding is not a universal requirement for routed iSCSI. Do not force a binding model that conflicts with the storage vendor's supported architecture.

Rescan, Discover LUNs, and Access Datastores

1. Rescan all storage adapters after enabling iSCSI, adding discovery entries, or changing port binding.
2. Verify that target portals and iSCSI sessions appear.
3. Verify that expected LUNs and paths appear in the host storage view.
4. For a new, confirmed-unused LUN, create a VMFS datastore if that is the intended use.
5. For a LUN containing an existing VMFS datastore, mount the existing datastore rather than formatting it.

See Configure the iSCSI Software Initiator, iSCSI Target Discovery, and Create a VMFS Datastore for related configuration tasks.

Verify Multipathing and Path Selection

Multipathing uses multiple paths between an ESXi host and a storage device. Redundancy may include separate VMkernel adapters, VMNICs, switch paths, VLANs or subnets, target portals, and array controllers. Two VMkernel adapters alone do not guarantee two independent paths.

For each LUN, verify the expected number of paths and identify the associated target portals and network routes. The array may expose optimized and non-optimized paths through ALUA, or Asymmetric Logical Unit Access.

ESXi uses a PSP, or path selection policy, to choose among available paths. Common policies include:

• Fixed: uses a preferred path when available and may fail over to another path.
• Most Recently Used: continues using the most recently active path according to the device and host behavior.
• Round Robin: cycles through eligible paths and may distribute I/O across them.

The correct PSP, ALUA behavior, and array claim rules depend on the storage vendor's supported configuration. Do not select a policy solely because it produces more visible paths.

Command-Line Validation

Run commands with appropriate ESXi privileges. Replace placeholder values with the identifiers in your environment.

esxcli network ip interface list
esxcli network ip interface ipv4 get

vmkping -I vmk1 10.110.0.20
vmkping -I vmk1 -d -s 8972 10.110.0.20

esxcli storage core adapter list
esxcli iscsi adapter get -A vmhbaXX
esxcli iscsi software set --enabled=true

esxcli iscsi adapter discovery sendtarget list -A vmhbaXX
esxcli iscsi adapter discovery sendtarget add -A vmhbaXX -a 10.110.0.20

esxcli iscsi networkportal list -A vmhbaXX
esxcli iscsi networkportal add -A vmhbaXX -n vmk1

esxcli storage core adapter rescan --all
esxcli storage core device list
esxcli storage core path list -d naa.ID

Use VMkernel-aware ping testing for each target portal. A normal ping from an unspecified interface does not prove that the intended iSCSI VMkernel path works.

For an MTU of 9000, a commonly used IPv4 payload test is -d -s 8972, but the correct payload depends on IP version and environment. Test every intended path and confirm the setting on every hop before relying on jumbo frames.

Validation Checklist

Troubleshooting Common Failures

Target is not discovered

• Check the target IP, TCP port, VLAN, subnet, and route.
• Run vmkping from the intended VMkernel adapter.
• Confirm that the array permits the ESXi initiator IQN.
• Check dynamic discovery or static target values and CHAP or mutual CHAP settings.
• Review ACLs, switch configuration, ESXi firewall rules, and array events.
• Rescan after correcting the configuration.

VMkernel adapter cannot be bound

• Ensure its port group has one intended active uplink and other uplinks set to unused.
• Confirm that the adapter is on a supported network design and has no incompatible service or configuration.
• Ensure that each bound adapter maps to the intended independent physical path.

Only one path appears

• Check whether both VMkernel adapters actually use the same NIC, switch, VLAN path, or target interface.
• Confirm that the array exposes the LUN through all intended target ports.
• Verify that the second adapter is bound and can reach its target portal.
• Check host sessions, device paths, and array-side host access settings.

Jumbo-frame testing fails

• Inspect the MTU on the vSwitch or distributed switch, VMkernel adapter, every physical switch path, and every target interface.
• Correct the smallest MTU in the path, or use MTU 1500 consistently.

Paths fail intermittently

• Review NICs, cables, switch ports, VLANs, target interfaces, and array events.
• Check for duplicate addresses and unsupported routing or teaming behavior.
• Verify the array's failover and ALUA configuration and use a vendor-supported PSP.
• Correct physical or logical instability before changing multipathing policy.

Operational Best Practices

• Use dedicated iSCSI VMkernel adapters and avoid unrelated services unless the design explicitly supports sharing.
• Use clear names that identify path, VLAN, subnet, and purpose.
• Document every mapping: VMkernel adapter, VMNIC, switch port, VLAN, IP address, target portal, IQN, LUN, and storage path.
• Keep ESXi, physical switches, and storage interfaces consistent with the supported MTU and iSCSI design.
• Follow array guidance for CHAP, mutual CHAP, ALUA, target presentation, and path selection policies.
• Test failure of each NIC, switch path, and target path during a controlled maintenance window.

Related lessons include iSCSI Initiators, iSCSI Naming and Addressing, iSCSI CHAP Overview, Configure iSCSI CHAP, Create Standard Switches, Distributed Switches Explained, and Browse VMFS Datastores.