Migrating iSCSI networks when it shares same uplinks with other networks on a switch, while preserving its redundancy
search cancel

Migrating iSCSI networks when it shares same uplinks with other networks on a switch, while preserving its redundancy

book

Article ID: 419186

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

iSCSI redundancy on a vSwitch is achieved by creating two iSCSI VMkernel ports (e.g., vmk1 and vmk2), each mapped to a single dedicated physical NIC (vmnic). This configuration is critical for performance and redundancy because it isolates each path, allowing ESXi to detect two active storage paths for multipathing. If one NIC or path fails, iSCSI traffic automatically continues over the remaining path, providing seamless failover and resilient storage connectivity.

The following diagram demonstrates the configuration of the iSCSI network vmkernels on a vswitch.


     +----------------- vSwitch-----------------+
          |                                             |
        vmk1                                     vmk2
   (iSCSI Port 1)                      (iSCSI Port 2)
 Active: vmnic1                       Active: vmnic2
 Standby: None                      Standby: None
 Unused: vmnic2                     Unused:vmnic1    
          |                                             |
     vmnic1                                  vmnic2                          
          |                                             |
     Fabric A                                 Fabric B
          |                                             |
     Storage                                  Storage

 

When migrating this iSCSI network (e.g., from a vSphere Standard Switch (vSS) to a vSphere Distributed Switch (vDS)), simply moving one physical uplink (vmnic) will immediately break the corresponding iSCSI path. Because the other vmnic is explicitly set to Unused for that specific VMkernel port, there is no automatic failover path configured within the vSwitch.

Environment

VMware ESXi 7.x

VMware ESXi 8.x

 

Resolution

  • The only way to ensure uninterrupted storage access and maintain redundancy throughout the migration process is to move the iSCSI VMkernel port and its Active vmnic together, path by path.

  • Step-by-Step Migration Process

    This process assumes you are migrating from an existing switch (Source) to a new switch (Destination), such as migrating from vSS to vDS.

    1. Prepare the Destination Switch:

      • Create the target port groups on the Destination Switch (e.g., vDS).

      • Ensure the Destination Switch is correctly configured with access to the physical network fabrics (Fabric A and Fabric B).

    2. Migrate the First iSCSI Path (e.g., Path A):

      • Simultaneously move vmk1 and its Active physical uplink, vmnic1, to the Destination Switch.

      • Confirm that iSCSI connectivity is restored and running over this new path. ESXi should now detect the storage target via the new switch path (Fabric A).

    3. Migrate Other Network Traffic:

      • Once the first iSCSI path is confirmed operational, you can safely migrate all other non-iSCSI VMkernel ports (e.g., vMotion, Management) and any connected VMs from the Source Switch to the Destination Switch.

    4. Migrate the Second iSCSI Path (e.g., Path B):

      • Simultaneously move vmk2 and its Active physical uplink, vmnic2, to the Destination Switch.

      • Confirm that iSCSI connectivity is fully established and running over both paths on the Destination Switch.

    5. Final Cleanup:

      • Remove the original iSCSI VMkernel portgroups from Source Switch. The Source Switch can now be safely decommissioned or repurposed.

    6. A standard representation of vmkernel networks on a DVS is shown below :



Additional Information

For more details related  to migrating networks from Distributed to Standard switch, please refer : Migrate Virtual Machines (VMs) and VMkernel Adapters from Distributed Switch (vDS) to Standard Switch (vSS)

For more details related  to migrating networks from Standard to Distributed switch, please refer : Migrating from Standard to Distributed vSwitch