iSCSI connection errors connecting to EqualLogic storage

R

rhp

New Member
Nov 10, 2026
3
0
0
Hi all,

We are in the process of moving from vSphere/ESXi to Proxmox (as many are).
Our setup uses two dedicated 10Gbps nics per host to connect iSCSI to a Dell EqualLogic storage array. This is the same setup as we are using on vSphere.
We use multipath on top of the iSCSI connections and we are using LVM on top of the iSCSI LUNs.

We used this document https://linux.dell.com/files/whitepapers/iSCSI_Multipathing_in_Ubuntu_Server.pdf for the initial setup.

Although it appears to be working, we see many iSCSI level errors, with dropping connections, and even some I/O errors now and then.
The errors we are seeing include:
  • iscsi_tcp: datalen 10957675 > 262144
  • received itt 8568d1c expected session age (8)
  • [sdaz] tag#28 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=50s
    [sdaz] tag#28 CDB: Write(16) 8a 00 00 00 00 00 9c a3 a9 00 00 00 06 80 00 00
  • ping timeout of 5 secs expired, recv timeout 5, last rx 4793794517, last ping 4793799680, now 4793804800
  • I/O error, dev sdo, sector 4047049216 op 0x1:(WRITE) flags 0x4a00 phys_seg 83 prio class 2
I have attached our iscsid.conf and multipath.conf.

We are having some trouble identifying the root cause of these issues, since (as far as we can tell). We have tried to fiddle with some of the iscsid timeout settings and tried various multipath options, but without making much of a difference.

We hope that there are some experts here that recognize some of these errors, and are willing to help us out.
 

Attachments

Last edited:
Hi @rhp , welcome to the forum.

At first glance - you have a network configuration/path problem. You've provided config files but did not supply any running state from the system. The state may contain the key.

You mentioned that the configuration was lifted from VMware - that is not always possible without changes. Few things worth collecting first, please provide them as text using CODE tags the forum edit box:
ip a
iscsiadm -m session
iscsiadm -m target
iscsiadm -m session -P 2
Is MTU correct?

rhp said:
iscsi_tcp: datalen 10957675 > 262144
Click to expand...

What this means: The initiator read a PDU header saying the data segment is about 10.9 MB. This is obviously larger than the negotiated MaxRecvDataSegmentLength is 256 KB. No real target sends a 10.9 MB segment - that number is invalid, which means the initiator was parsing bytes that are not a real PDU header.
This could also be caused by your NIC offload. Frankly, the troubleshooting you need to do is not PVE specific but rather standard Linux/Network debug.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Hi @bbgeek17,

Thanks for taking the time to respond to my message.
The output is a bit large for code blocks, so I attached them as files instead.

We checked the MTUs on all nics, in the switches and in EqualLogic. They are all set to 9000.

Code: 
~# iscsiadm -m target
iscsiadm: target mode is unkonwn/unsupported

Frankly, the troubleshooting you need to do is not PVE specific but rather standard Linux/Network debug.
Click to expand...

We are well aware of this, but we thought this might be a good place to start.
If you can recommend a forum where we'll have better chances, I'm happy to move the conversation there.
 

Attachments

Assuming for the moment that you thoroughly applied all the kernel level values recommended in the Dell guide, and those are _critical_ for operations of a Linux Multihome system (same network on multiple interfaces). Your next best step is to disable NIC offload:
ethtool -K <nic> gro off lro off

But, I would first disconnect one of the paths (physically, virtually, deconfigure) and try access with single path only. Get your configuration to the most minimal workable set and start building from there.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
I tried running `ethtool -K <nic> gro off lro off` and it gave me this output:


Code: 
~# ethtool -K nic3 gro off lro off
Actual changes:
rx-gro: off
rx-gro-hw: off [not requested]

It seems "lro" does not work on my systems.
 
rhp said:
It seems "lro" does not work on my systems.
Click to expand...
It is possible, it is also possible it was already disabled. I don't know what NIC you are using. You should be able to check supported modes in your documentation.

Make sure you disable it on both card, you can also try to disable various other offloads:
ethtool -K nic2 tso off gso off
ethtool -K nic3 tso off gso off

You can check the state with:
ethtool -k nic3 | grep -E "generic-receive-offload|large-receive"


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
You must log in or register to reply here.
Top Bottom
Back