Add optional iSCSI target/export support for Mayastor volumes

[Masorubka1]

Is your feature request related to a problem? Please describe

Mayastor appears to be focused primarily on NVMe-oF-style volume access. This is a strong fit for modern Kubernetes storage, but it makes interoperability testing harder for clients, tools, and environments that still depend on iSCSI.

iSCSI support would help users who need compatibility with existing initiators, legacy systems, hypervisors, lab environments, or storage tooling where NVMe-oF is not available or not yet integrated.

Describe the solution you'd like

Add an optional iSCSI export mode for Mayastor volumes.

At minimum, it would be useful to support:

• exposing a Mayastor volume as an iSCSI target
• stable target IQN generation or configurable IQNs
• mapping one Mayastor volume as one LUN
• basic discovery through SendTargets
• standard SCSI read/write commands over iSCSI
• optional CHAP authentication
• Kubernetes/CRD-level configuration for enabling iSCSI export per volume

This would not need to replace the existing NVMe-oF path. It could be an optional compatibility/export layer for users who explicitly need iSCSI.

Describe alternatives you've considered

The current workaround is to place another Linux iSCSI target implementation in front of a block device, for example LIO/targetcli or tgt. This works for simple testing, but it adds another moving part and does not test Mayastor-native export behavior directly.

Keeping NVMe-oF as the only supported access protocol is also possible, but it does not help environments or tools that require iSCSI compatibility.

Additional context

My use case is interoperability testing for an open-source pure-Rust iSCSI initiator/client library:

https://github.com/Masorubka1/iscsi-client-rs

The library already implements login negotiation, CHAP authentication, PDU parsing/framing, SCSI READ/WRITE, READ CAPACITY, R2T/Data-Out flow, NOP, logout, sense parsing, and integration tests against Linux tgt/LIO-style targets.

A limited initial implementation would already be useful, for example:

• single-session support
• ERL0 only
• no advanced multipath support initially
• optional basic CHAP
• one exported LUN per Mayastor volume

If Mayastor had optional iSCSI export support, I would be interested in testing compatibility against it and reporting issues from the initiator/client side.

[tiagolobocastro]

Hey, this is an interesting topic

So we used to actually support iSCSI :) (and NBD too), but we dropped it since we were focusing on nvmeof only

Also there may be some additional challenges to bring it back since we now make use of the nvmf subsystem pause to safely modify the replicas (with all I/O on all cores flushed and paused)

iSCSI on the backend may also be an interesting proposition if we want to consume SAN storage without binding it to the kernel

As it stands this seems to be a niche requirement since we haven't encountered it before; that being said if someone is up for adding iSCSI support I wouldn't be against it - though I don't see us having the bandwidth to picking this up otherwise

[Masorubka1]

Sorry, I only saw this reply now - thanks, this is very useful context.

The backend direction is especially interesting to me. My project is a pure-Rust iSCSI initiator/client, so the “consume SAN storage without binding it to the kernel” use case sounds closer to what I could realistically help with.

Would a limited prototype be useful for Mayastor?

• Rust userspace iSCSI initiator as a library
• connect to an external iSCSI target/SAN LUN
• start with single session, ERL0, one LUN, basic READ/WRITE/READ CAPACITY, optional CHAP

I am not yet familiar enough with Mayastor internals, but if backend iSCSI consumption is more interesting than frontend iSCSI export, I can look into where such an integration point would fit.