VMware ESXi and vSphere Cluster Management

Configure a VMkernel Port for the ESXi iSCSI Software Initiator

Learn how to create and configure a VMkernel adapter on an ESXi standard vSwitch, validate iSCSI connectivity, configure discovery, and prepare for multipathing.

An ESXi software iSCSI initiator communicates with storage targets over TCP/IP. It uses a host-side VMkernel adapter, commonly identified as vmkN, as the source interface for that traffic.

This guide explains how to create an iSCSI VMkernel adapter on an existing standard vSwitch, assign static IPv4 settings, test the path to an iSCSI target portal, and continue with target discovery and storage validation.

What the iSCSI VMkernel Port Does

A VMkernel port is a host networking interface used by ESXi services such as management, vMotion, vSAN, fault-tolerance logging, and IP storage. The specific interface used for iSCSI is a VMkernel adapter.

The iSCSI software initiator is an ESXi software storage adapter that starts iSCSI sessions to an iSCSI target. A target is a storage-system endpoint that presents block storage to an initiator. The target is reached through a target portal, which normally consists of an IP address and TCP port 3260.

An iSCSI VMkernel adapter is different from these other objects:

  • VMkernel adapter: A host network interface with its own IP configuration and service role.
  • Virtual-machine port group: A network attachment point used by virtual-machine network adapters. It does not replace an iSCSI VMkernel adapter.
  • Management network: A VMkernel network used for host administration. It may be physically capable of reaching storage, but using it for iSCSI is usually less isolated and less desirable than using a dedicated storage network.

The adapter requires Layer 3 connectivity to the iSCSI storage network. Each VMkernel adapter has its own IP address and subnet mask or prefix length. If a target portal is outside the local subnet, the host routing configuration must provide an appropriate path, including a suitable gateway where required.

Plan the iSCSI Network Before Configuration

Gather the following information before opening the vSphere Client:

  1. Identify the existing standard vSwitch that will carry iSCSI traffic.
  2. Confirm that its physical uplink or uplinks connect to the intended storage network.
  3. Determine whether the environment requires a dedicated iSCSI VLAN or an otherwise isolated storage network.
  4. Choose an unused static IPv4 address and the correct subnet mask for the new VMkernel adapter.
  5. Record the iSCSI target portal address or addresses. The usual TCP port is 3260.
  6. Confirm that the planned address does not conflict with another VMkernel adapter, ESXi host, storage controller, or other device.
  7. Decide whether the design is single-path or multipath. Redundant designs require independent physical paths, eligible VMkernel adapters, and storage-side target paths.

For a simple same-subnet design, the VMkernel adapter and target portal might use 192.168.50.11/24 and 192.168.50.100. Communication within that subnet does not normally require a gateway. A gateway becomes important when target portals or other required services are on a different subnet.

Configuration Values

Setting | Example value | Purpose | Validation

Network label or port group name | iSCSI Storage | Identifies the host network used for storage traffic | Confirm the label on the standard vSwitch

Standard vSwitch | vSwitch-iSCSI | Carries the VMkernel traffic to the physical network | Verify the intended physical uplink is attached

VLAN ID | 50 | Separates iSCSI traffic at Layer 2 when VLANs are used | Compare the port-group VLAN with the physical-switch configuration

VMkernel adapter name | vmk2 | Identifies the host interface | List adapters in the vSphere Client or with esxcli

IPv4 address | 192.168.50.11 | Provides the host address on the storage network | Check for uniqueness and correct subnet

Subnet mask or prefix length | 255.255.255.0 or /24 | Defines the local storage subnet | Compare with the target portal network

Default gateway | Environment-specific | Routes traffic to another subnet when needed | Review the host routing design

MTU | 1500, or 9000 for validated jumbo frames | Sets the maximum packet size | Test the complete path with vmkping

Physical uplink | vmnic2 | Connects the vSwitch to the external storage network | Trace the NIC to the physical switch and storage network

iSCSI target portal | 192.168.50.100:3260 | Identifies the storage endpoint | Test reachability from the selected VMkernel adapter

Create a VMkernel Adapter on an Existing Standard vSwitch

  1. Sign in to the vSphere Client with permission to modify the ESXi host network.
  2. Select the ESXi host that will connect to iSCSI storage.
  3. Open the host's Networking configuration.
  4. Start the workflow to Add networking or add a host network adapter. The exact wording can vary by vSphere release.
  5. For the connection type, select VMkernel Network Adapter.
  6. Select the existing standard switch that has the intended storage uplink. Do not create an unrelated switch path unless that is part of the approved design.
  7. Select an existing port group or create the iSCSI-specific port group required by the workflow.
  8. Use a meaningful label such as iSCSI Storage or iSCSI-vmk1.
  9. Set the VLAN ID to match the planned storage network. Use the value required by the physical-switch design.
  10. Configure the VMkernel IPv4 settings as described below.
  11. Review the summary and complete the adapter-creation workflow.

The resulting adapter should appear on the selected standard vSwitch and in the associated port group. The port group supplies network properties such as the label, VLAN ID, and NIC-teaming policy; the VMkernel adapter supplies the host IP identity and service configuration.

Configure Static IPv4 Networking

Use static IPv4 settings for storage networking unless the environment has a deliberate, tested alternative. Predictable addresses make target access control, troubleshooting, documentation, and multipathing easier.

  1. Select Static IPv4 for the VMkernel adapter.
  2. Enter the planned unused IPv4 address.
  3. Enter the correct subnet mask or prefix length.
  4. Review the gateway. For a target on the same subnet, a gateway is generally not needed for that local communication. For a target outside the local subnet, routing must be designed correctly and the applicable gateway must be configured.
  5. Review host-level gateway and DNS settings if they are used by the surrounding configuration. DNS is not a substitute for IP reachability to a target portal.
  6. Confirm that the IP address is not assigned to another VMkernel adapter, ESXi host, storage controller, switch interface, or other device.

Do not assume that assigning several addresses automatically creates redundancy. Redundancy depends on separate network paths, correct teaming, target portals, storage-side presentation, and supported iSCSI path configuration.

Validate the New Network Adapter

Check the vSphere Client Configuration

  • Confirm that the new VMkernel adapter exists.
  • Confirm that it is attached to the intended standard vSwitch and port group.
  • Verify the VLAN ID and compare it with the physical-switch port configuration.
  • Verify that the standard vSwitch has the intended physical uplink.
  • Check the IP address, subnet mask, gateway, and MTU.

List VMkernel Addressing from ESXi

esxcli network ip interface ipv4 get

Use the output to confirm that the iSCSI adapter has the planned IPv4 address and subnet information. Replace the example adapter name in later commands with the actual value, such as vmk2.

Test Reachability Through the Specific VMkernel Adapter

vmkping -I vmkN <iSCSI_target_portal_IP>

The -I option ensures that the test uses the selected VMkernel interface rather than relying only on the host's general routing choice. A successful test verifies basic IP reachability, but it does not prove that iSCSI authentication, target access control, or LUN presentation is correct.

If jumbo frames are intentionally configured end to end, test the larger path:

vmkping -I vmkN -d -s 8972 <iSCSI_target_portal_IP>

This test is appropriate for a 9000-byte MTU path only when the VMkernel interface, standard vSwitch, physical switches, and storage interfaces are configured consistently. Ordinary ping success does not prove that jumbo frames work.

Configure iSCSI Target Discovery

Creating the VMkernel adapter establishes a network path; it does not add storage devices by itself. The next task is to configure the software iSCSI adapter with target discovery information.

Depending on the storage design, configure one of these methods:

  • Dynamic discovery: Enter a target portal. The target returns the available targets through that portal.
  • Static discovery: Enter an individual target name and its portal explicitly.
  • Other applicable discovery: Use the discovery method supported by the ESXi version and storage platform.

Every configured target portal must be reachable through the intended iSCSI VMkernel network. After changing discovery settings, rescan the storage adapters and verify targets, devices, and paths.

esxcli iscsi adapter list

This command identifies the available software iSCSI adapter, typically with a vmhba-based name.

esxcli iscsi adapter target portal list -A vmhbaN

Use this command to review target portals associated with the selected iSCSI adapter after discovery is configured.

In the vSphere Client, use the host storage view to rescan storage adapters. Verify that expected devices and datastores become visible only after the storage array permits the ESXi initiator and presents the appropriate LUNs.

Multipathing and VMkernel Port Binding

Multipathing uses multiple paths between an ESXi host and storage. It can improve availability and may improve performance, depending on the array and path-selection policy. A common software iSCSI design uses multiple VMkernel adapters with VMkernel port binding.

Port binding associates multiple eligible VMkernel adapters with the software iSCSI adapter so that separate storage paths can be established. Each bound adapter should map to an independent physical network path when redundancy is intended.

A commonly used teaming pattern is one active uplink per iSCSI VMkernel port group, with the other storage uplinks unused for that port group. This prevents the same port group from using an unintended alternate uplink and makes the physical path relationship clear. The exact design must be validated against the applicable VMware and storage-vendor guidance.

Design element | Single-path configuration | Multipath configuration

VMkernel adapters | One iSCSI VMkernel adapter | Two or more eligible iSCSI VMkernel adapters

Physical NICs | One intended storage uplink | Separate dedicated NICs or independent physical paths

Storage network paths | One storage network path | Separate storage networks, switches, fabrics, or validated equivalent paths

Port binding | Usually not required for a single path | Bind each eligible VMkernel adapter as supported by the design

Expected path count | One operational path per presented device | Multiple operational paths per presented device when the array and configuration support it

Failure tolerance | Loss of the path can interrupt access | A supported alternate path can preserve access after a path failure

Multiple VMkernel IP addresses alone do not provide end-to-end redundancy. Check the NIC, cable, physical switch, VLAN, storage interface, target portal, array access control, and ESXi path configuration as a complete chain.

Practical Configuration Examples

Single-Path iSCSI on a Standard vSwitch

An ESXi host has a storage-dedicated standard vSwitch with one physical uplink connected to the iSCSI VLAN.

  1. Create a VMkernel adapter in a port group labeled iSCSI Storage.
  2. Assign the static address 192.168.50.11/24.
  3. Use target portal 192.168.50.100 on TCP port 3260.
  4. Test the path with vmkping -I vmkN 192.168.50.100.
  5. Configure dynamic or static target discovery.
  6. Rescan storage and confirm the expected device and path.

Two-Path Software iSCSI Design

Use two dedicated physical NICs connected to separate storage network paths or switches. Create two VMkernel adapters, for example 10.20.10.11/24 and 10.20.20.11/24.

  1. Associate each adapter with its intended storage port group.
  2. Configure each port group so its intended uplink is active and the other storage uplink is unused, as required by the validated design.
  3. Bind both eligible VMkernel adapters to the software iSCSI adapter.
  4. Configure target portals on both storage networks.
  5. Rescan storage and confirm that multiple paths are operational.

Same-Subnet Target Access

If the VMkernel adapter and target portal are on the same storage subnet, use a static address and matching subnet mask. A gateway is normally unnecessary for that local-subnet communication, but review the host routing design for the complete environment.

Validation Checklist

Check | Expected result | Where or how to verify

VMkernel adapter exists | The new vmkN is present and has an address | Host networking view or esxcli network ip interface ipv4 get

Correct vSwitch and VLAN | The adapter uses the planned standard vSwitch, port group, and VLAN | Standard vSwitch and physical-switch configuration

Correct IP configuration | Address and mask match the storage plan and do not conflict | VMkernel IPv4 settings and address-management records

Target portal ping succeeds | The selected VMkernel interface reaches the portal | vmkping -I vmkN <portal-IP>

Software iSCSI adapter enabled | The software adapter is available | esxcli iscsi adapter list or host storage configuration

Targets discovered | Configured target portals and target names appear | iSCSI adapter discovery view or portal-list command

Storage devices visible | Expected LUNs and devices appear after rescan | Host storage devices view

Multiple paths visible when applicable | Each presented device has the expected active paths | Storage paths view or esxcli storage core path list

esxcli storage core path list

Use the path listing after discovery and a storage rescan to inspect path state. Confirm that paths expected by the design are present and operational.

Operational and Security Considerations

  • Use a dedicated storage network when possible. Avoid exposing iSCSI traffic to general virtual-machine or user networks.
  • Use a dedicated iSCSI VLAN or isolated network where required by organizational and storage architecture.
  • Apply access controls to iSCSI VLANs and target portals according to security policy.
  • If jumbo frames are used, configure and test the MTU consistently from the VMkernel adapter through every switch and storage interface.
  • Document VMkernel names, IP addresses, VLAN IDs, target portals, uplinks, target names, and associated storage paths.
  • Do not change active storage networking without an approved maintenance plan, a tested rollback procedure, and an understanding of the impact on mounted datastores.

Troubleshooting

The Host Cannot Reach the Target Portal

Likely causes include an incorrect VMkernel address or mask, an incorrect VLAN ID, a physical-switch port assigned to the wrong VLAN, a missing uplink, incorrect routing, or a firewall or ACL restriction.

  1. Run vmkping with the intended VMkernel adapter.
  2. Verify the vSwitch uplink and trace it to the correct physical switch port.
  3. Compare VLAN and IP settings with the storage interface.
  4. Check host routing when the target is outside the local subnet.

The Portal Is Reachable but No LUNs Appear

IP reachability does not guarantee storage access. Check that the software iSCSI adapter is enabled, discovery is configured correctly, the target name and portal are correct, and the storage array permits the ESXi initiator. Confirm that a LUN is mapped to the host and rescan storage adapters.

Only One Path Appears in a Redundant Design

Check that both VMkernel adapters are bound and eligible, each has the intended physical uplink, and separate target portals and storage-side paths are configured. Also verify the physical NICs, switches, VLANs, array ports, and vendor support for the selected port-binding design.

Jumbo-Frame Testing Fails but Ordinary Ping Works

An MTU mismatch can allow small packets while dropping larger ones. Validate the MTU on the VMkernel adapter, standard vSwitch, every physical switch hop, and the storage interface. If the complete path cannot support the configured frame size, use the standard MTU instead.

Exam-Relevant Notes

  • The software iSCSI initiator uses a VMkernel adapter for IP communication with targets.
  • A VMkernel adapter is not the same as a virtual-machine port group or the management network.
  • Creating the VMkernel adapter provides network connectivity but does not perform target discovery or present LUNs.
  • Target discovery must use reachable portal addresses, followed by a storage rescan.
  • Multipathing requires more than multiple IP addresses: it requires independent physical paths, correct binding and teaming, target portals, and storage-array support.
  • Use vmkping -I vmkN to test the path from a particular VMkernel interface.

For a focused follow-up, continue with VMkernel port configuration for the iSCSI software initiator.