Read Only Access

[AndrewL733]

Can your initiator support connecting to a Read Only volume? If yes, how? I have tried it and it seems to crash. The Microsoft Initiator CANNOT connect to a Read Only volume because it has to write something to the volume to connect.

I am told that the QLOGIC HBA's CAN connect to Read Only targets.

I am using a Chelsio Target (running on Linux) that offers me the possibility of setting Read Only access to specific initiators based on their "iqn" identification. Microsoft will let me create my own name. Does Rocket Division initiator have a way configuring the initiator name?

I hope you can answer both of those questions.

Thanks.

[Val (staff)]

Can your initiator support connecting to a Read Only volume? If yes, how? I have tried it and it seems to crash. The Microsoft Initiator CANNOT connect to a Read Only volume because it has to write something to the volume to connect.

I am told that the QLOGIC HBA's CAN connect to Read Only targets.

I am using a Chelsio Target (running on Linux) that offers me the possibility of setting Read Only access to specific initiators based on their "iqn" identification. Microsoft will let me create my own name. Does Rocket Division initiator have a way configuring the initiator name?

I hope you can answer both of those questions.

Thanks.

Hi,

What is the StarPort version?

1) We have not yet tried Chelsio Target with our initiator.
But our driver should work with any target that is iSCSI v1.0 compliant.
I suspect the read-only target sends something that Windows does not understand and this can lead to system crashes.

Please send Ethereal log files for StarPort and the MS initiator for the cases to my email address. This will help us to understand where the problem is.

2) The initiator name can be changed using the StarPort GUI -> Preferences -> Remote iSCSI devices -> initiator name prefix + postfix

Are there any information about how the Chelsio Target makes devices 'readonly'?
FYI Windows relays on the device's response to SCSIOP_MODE_SENSE where DeviceSpecificParameter includes MODE_DSP_WRITE_PROTECT bit to mark the device as 'read-only' one.
StarPort itself does not use the parameter at all. It passes data between the Windows storage stack and the device.

[AndrewL733]

Hi Valery,

This is from Chelsio's User Guide. Maybe they are creating "access control" in a non-standard way? It is not clear what happens when you use their various ACL methods.

BTW, I tested the most recent Starport Version. I downloaded the trial from the Rocket Division web site a couple of months ago. I no longer have it on my computer, but I am sure it was the most recent version.

If you want to look at the entire Chelsio User Guide, you can go to: ftp://rocketreadonly.dyndns.org and go to the "Chelsio" directory. I will only leave this on the ftp site for a day or so. Please let me know when you downloaded it.

FROM CHELSIO USER GUIDE


Target Access Control List (ACL) Configuration
The Chelsio iSCSI target supports iSCSI initiator authorization via an Access Control List (ACL).
ACL configuration is supported on a per-target basis. The creation of an ACL for a target establishes:
• Which iSCSI initiators are allowed to access it
• The type of the access: read-write, read-only or write-only
• Possible SCSI layer associations of LUNs with the initiator
More than one initiator can be allowed to access a target and each initiator’s access rights can be
independently configured.
There are two ways to create an ACL for a target:
1. Defined in the configuration file:
In the following example, for target “iqn.2005-com.chelsio.diskarray.san1”
• Initiator “iqn.1991-05.com.xxx:initiator1” is allowed read-write access to all the LUNs of the
storage at the target.
• Any initiator from IP address 192.168.1.100 is allowed read-only access to all the LUNs of the
storage at the target.
• An Initiator “iqn.1991-05.com.zzz:initiator3” from IP address 192.168.2.100 is allowed readwrite
access to LUN 0, and read-access to LUN 1 of the storage at the target.
target:
TargetName=iqn.2006-02.com.chelsio.diskarray.san1
TargetDevice=/dev/sda
PortalGroup=5@10.192.166.178:8000
ACL=iqn.1991-05.com.xxx:initiator1
ACL=192.168.1.100@ALL:R
ACL=192.168.2.100,iqn.1991-05.com.zzz:initiator3@0:RW,1:R
2. Dynamically added to a running target via iscsictl:
For example, a target “iqn.2005-com.chelsio.diskarray.san1” is already started.
• To add to the target’s ACL an initiator “iqn.1991-05.com.xxx:initiator1” with read-write access
to all the LUNs, issue the following command:
[chelsio@]# iscsictl –C target=iqn.2005com.chelsio.diskarray.san1 –
k ACL=iqn.1991-05.com.xxx:initiator1
• To add to the target’s ACL any initiator from IP address 192.168.1.100 with read-only access
to all the LUNs, issue the following command:

[Val (staff)]

Hi,

Thank you.

I've looked at the manual. Nothing about internals is there.

I guess analyzing of Ethereal/Wireshark log files are the only way to see what happens between the target and the initiator.
So if you are able to collect and send them to us, please do it. :)

[Val (staff)]

Hi,

From the log files you sent me I see that the Chelsio target does not set the mandatory MODE_DSP_WRITE_PROTECT bit in responses to SCSIOP_MODE_SENSE for read-only targets.
This leads to the problems in Windows clients.

The target should be fixed to allow Windows machines to use its read-only targets.

You could report the problem to Chelsio support or fix it yourself if you
have the sources for the target module.