VMware ESXi and vSphere Cluster Management

Configure ESXi Networking for Software iSCSI

Learn how to configure ESXi VMkernel networking for software iSCSI, including VLAN isolation, uplink mapping, port binding, multipathing, MTU validation, and troubleshooting.

ESXi software iSCSI uses the host's VMkernel networking to communicate with storage. A correct design gives the software iSCSI initiator one or more reachable network paths to iSCSI target portals while keeping storage traffic isolated and predictable.

This lesson covers the network portion of the configuration. After connectivity is working, configure target discovery and rescan the storage adapters.

How iSCSI Networking Works in ESXi

iSCSI is a storage protocol that carries SCSI block-storage commands over an IP network. The ESXi software iSCSI initiator starts sessions to an iSCSI target, which is a storage endpoint exposing volumes or LUNs.

The initiator sends this traffic through one or more VMkernel adapters. A VMkernel adapter is an ESXi host networking interface such as vmk0 or vmk1. It is different from a virtual-machine port group and should not be confused with the management network.

  • iSCSI VMkernel adapter: carries host storage traffic.
  • VM port group: connects virtual-machine network adapters to the network.
  • Management VMkernel adapter: carries services such as host management, unless additional services are deliberately assigned.

Each iSCSI VMkernel adapter needs a valid Layer 3 IP address and subnet mask that can reach the intended target portal network. A VLAN assignment by itself does not provide IP reachability.

Plan the Storage Network Before Configuration

Collect these values before changing an ESXi host:

  • Physical ESXi NICs that will carry iSCSI traffic, such as vmnic2 and vmnic3.
  • The standard vSwitch or vSphere Distributed Switch to use.
  • Physical switch ports and their intended access or trunk configuration.
  • IP addresses and subnet masks for each iSCSI VMkernel adapter.
  • VLAN IDs, if the storage network is logically isolated.
  • Target portal addresses, normally an IP address and TCP port.
  • The number of storage interfaces and expected paths presented by the array or NAS.

Confirm that the storage system has active iSCSI target interfaces and that a network path exists between every intended ESXi VMkernel adapter and its corresponding target interface. Plan redundancy around both sides: two ESXi uplinks are useful only when the storage system also provides corresponding reachable paths.

Do not add or rely on a default gateway merely to make an incorrectly designed storage network reachable. Use routing only when routed iSCSI is intentionally supported, documented, and configured by the storage design. Many isolated iSCSI networks use directly connected subnets instead.

Isolate iSCSI Traffic

The preferred design uses dedicated physical NICs and dedicated switching for iSCSI. This improves fault isolation, makes capacity easier to predict, and reduces exposure to general VM, management, and user traffic.

When separate hardware is unavailable, use a dedicated iSCSI VLAN. The VLAN configured on the ESXi iSCSI port group must match the physical switch path and the storage network design. The connected switch ports must be configured consistently for the selected access or trunk mode.

VLAN separation is not a complete security policy. Also restrict switch and storage access so that only authorized ESXi hosts can reach the target interfaces. Apply the storage array's initiator access controls and any required authentication separately.

Design Options

Design | Physical NIC count | VMkernel adapter count | Redundancy | Recommended use

Single-path iSCSI | 1 | 1 | None beyond the single link | Small environments or temporary connectivity

Two-path host-based multipathing | 2 or more | 2 or more | Independent host-to-storage paths | Production storage requiring path resilience

Dedicated physical network | Depends on path count | Depends on path count | Physical and logical separation | Preferred predictable storage design

VLAN-isolated shared network | Shared infrastructure | Depends on path count | Logical isolation only | Environments without dedicated switching or NICs

Single-Uplink iSCSI Design

The minimum design contains one physical NIC, one vSwitch or distributed-switch port group, and one VMkernel adapter dedicated to iSCSI.

  1. Create or select a vSwitch or distributed switch with the selected physical uplink.
  2. Create an iSCSI VMkernel port group with the planned VLAN ID.
  3. Add a VMkernel adapter to the port group.
  4. Assign an IP address and subnet mask, for example 192.168.50.11/24.
  5. Enable the iSCSI service on that VMkernel adapter.
  6. Verify reachability to the target portal, such as 192.168.50.100.

This design has a single physical path. A failed NIC, cable, switch port, or upstream switch can interrupt iSCSI access.

Two-Path Software iSCSI Design

For host-based software iSCSI multipathing, create separate VMkernel adapters and associate them with the software iSCSI adapter. Each VMkernel adapter should use one active physical uplink, while the other uplinks are placed in an unused or otherwise non-active state for that port group.

This mapping prevents both VMkernel adapters from unintentionally using the same physical NIC. It also avoids a teaming policy that defeats the one-VMkernel-to-one-uplink design expected for iSCSI port binding.

  1. Use independent physical NICs, for example vmnic2 and vmnic3.
  2. Create an iSCSI-A port group with vmk1 at 10.10.10.11/24. Make only vmnic2 active.
  3. Create an iSCSI-B port group with vmk2 at 10.10.20.11/24. Make only vmnic3 active.
  4. Connect the paths to corresponding target interfaces, such as 10.10.10.100 and 10.10.20.100.
  5. Confirm that the storage system exposes both interfaces to the ESXi initiator.
  6. Bind vmk1 and vmk2 to the software iSCSI adapter.
  7. Discover targets and rescan storage.

Multipathing requires both a valid network design and correct storage presentation. Multiple host NICs alone do not create multiple usable storage paths.

Configure the vSwitch and VMkernel Ports

Use clear names that identify purpose and path, for example PG-iSCSI-A, PG-iSCSI-B, vmk1-iSCSI-A, and vmk2-iSCSI-B.

  1. Create or select a standard vSwitch or vSphere Distributed Switch suitable for the storage traffic.
  2. Assign the intended physical uplink or uplinks.
  3. Create an iSCSI VMkernel port group and enter the planned VLAN ID.
  4. Add a VMkernel adapter and configure its IPv4 address and subnet mask.
  5. Enable the iSCSI service on the adapter.
  6. For multipathing, override the port group's NIC teaming policy so that one uplink is active and the other uplinks are unused or non-active.

In a two-path example, the resulting mapping can be documented as follows:

Port group | VMkernel adapter | VMkernel IP/subnet | VLAN | Active uplink | Storage target path

PG-iSCSI-A | vmk1 | 10.10.10.11/24 | 120 | vmnic2 | 10.10.10.100

PG-iSCSI-B | vmk2 | 10.10.20.11/24 | 121 | vmnic3 | 10.10.20.100

Enable and Associate Software iSCSI

Identify or enable the ESXi software iSCSI adapter. Its identifier commonly resembles vmhbaXX. When using VMware software iSCSI port binding, bind each eligible iSCSI VMkernel adapter to that adapter.

In the vSphere Client, the workflow is:

  1. Enable or select the software iSCSI adapter.
  2. Review the available VMkernel adapters.
  3. Bind the intended iSCSI adapters to the software iSCSI adapter.
  4. Proceed to target discovery, such as dynamic discovery through a configured target portal.
  5. Rescan the storage adapters after discovery and network changes.

Dynamic discovery means querying a configured target portal to learn which iSCSI targets are available. It is the next storage configuration step after the network path is working; it is not a replacement for VMkernel connectivity.

Useful ESXi Commands

Run these commands in an appropriate ESXi troubleshooting shell or through an approved remote administration method:

esxcli network ip interface ipv4 get
esxcli network ip interface list
esxcli iscsi adapter list
esxcli iscsi networkportal list -A vmhbaXX
esxcli iscsi networkportal add -A vmhbaXX -n vmkX
vmkping -I vmkX TARGET_IP
esxcli storage core adapter rescan --all

Replace vmhbaXX, vmkX, and TARGET_IP with the values from the host. Use the bind command only after the port group's failover policy has been configured for the intended path.

Validate Connectivity

Test from the specific VMkernel adapter that should reach the target. A general ping from the management interface does not prove that the iSCSI path is correct.

vmkping -I vmk1 10.10.10.100

Check each intended VMkernel-to-target combination. Validate the following:

  • VMkernel IP address and subnet mask.
  • Port group VLAN ID and physical switch VLAN configuration.
  • Physical NIC link state, cabling, switch port, and link speed.
  • Target portal address and storage interface status.
  • MTU consistency across the complete path.
  • Software iSCSI network portals and their VMkernel bindings.
  • Discovered storage paths after a rescan.

After discovery and rescan, all intended paths should appear as usable. Check that no unintended uplink failover or load-balancing arrangement allows both bound VMkernel adapters to use the same uplink.

Validation item | Expected result | How to check | Likely issue if unsuccessful

VMkernel addressing | Correct IP and subnet | Review VMkernel configuration or esxcli network ip interface ipv4 get | Incorrect address or mask

VLAN path | ESXi, switches, and target share the intended design | Review port group and switch configuration | Wrong VLAN or switch mode

Target reachability | vmkping succeeds from the intended adapter | Run vmkping -I vmkX TARGET_IP | Routing, ACL, link, or target-interface problem

Port binding | Every intended VMkernel appears on the software adapter | Run esxcli iscsi networkportal list -A vmhbaXX | Missing binding or wrong adapter

Storage paths | All expected paths are usable | Rescan and inspect storage paths | Missing target path or storage presentation issue

MTU | Packets traverse without fragmentation | Test standard or jumbo-frame payloads | MTU mismatch

MTU and Jumbo-Frame Consistency

The standard 1500-byte MTU is valid for iSCSI. Jumbo frames are optional and should be enabled only when they are supported and intentionally configured end to end.

If using an MTU of 9000, configure and verify the VMkernel adapter, virtual switch, physical switch ports, and storage target interfaces. Enabling jumbo frames on only one segment creates an inconsistent path and can cause failed tests, dropped traffic, or unstable performance.

vmkping -I vmk1 -d -s 8972 10.10.10.100

The payload value is suitable for a typical 9000-byte MTU path. Use this test only when jumbo frames are planned. If it fails, correct the inconsistent segment or return the path to the standard MTU.

Security and Operational Guidance

  • Permit iSCSI access only from authorized ESXi hosts to authorized storage interfaces.
  • Keep storage traffic separate from VM, management, and user traffic whenever possible.
  • Document VMkernel IP addresses, subnet masks, VLANs, uplink mappings, target portals, and expected paths.
  • Use maintenance windows for changes to active storage networking.
  • Verify that redundant paths work before changing or removing an active path.
  • Apply storage access controls and any required iSCSI authentication independently of VLAN isolation.

Troubleshooting Common Problems

The target cannot be reached from the storage VMkernel

  • Run vmkping -I vmkX TARGET_IP from the intended interface.
  • Verify the VMkernel address, subnet mask, and port group VLAN.
  • Check physical NIC link state and switch-port configuration.
  • Confirm that the target portal is online and belongs to the intended reachable network.
  • Check for an MTU mismatch if jumbo frames are enabled.

Only one path appears

  • Confirm that multiple VMkernel adapters were created and bound.
  • Review each port group's active and unused uplinks.
  • Ensure the adapters do not both use the same physical uplink.
  • Confirm that the storage system exposes separate reachable target interfaces.
  • Complete target discovery and rescan storage.

Connectivity works but performance is inconsistent

  • Check whether storage shares congested infrastructure with other traffic.
  • Review teaming and failover policies for unintended path movement.
  • Verify MTU consistency across the full path.
  • Inspect NIC and switch counters for drops, errors, oversubscription, or link-speed mismatches.
  • Confirm that all expected storage paths are active and correctly presented.

A VMkernel adapter cannot be bound

  • Verify that the adapter is enabled for iSCSI service.
  • Check the port group's uplink policy for the intended binding design.
  • Use esxcli iscsi adapter list to identify the correct software iSCSI adapter identifier.

Exam-Relevant Notes

  • Software iSCSI traffic uses VMkernel adapters, not VM port groups.
  • Every iSCSI VMkernel adapter requires valid Layer 3 addressing to the target network.
  • For software iSCSI port binding, use separate VMkernel adapters and map each to one active physical uplink.
  • Other uplinks should be unused or non-active on each bound iSCSI port group.
  • Multiple host paths require corresponding target interfaces and correct storage presentation.
  • VLAN isolation does not replace switch configuration or storage access controls.
  • Jumbo frames must be consistent end to end; standard MTU is acceptable.

Once the VMkernel paths are reachable and correctly bound, continue with target discovery and storage configuration. Related storage work may include adding a raw LUN after the storage presentation is complete.