Advanced iSCSI Settings

Software-based VM-centric and flash-friendly VM storage + free version

Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)

Post Reply
User avatar
DavidMcKnight
Posts: 39
Joined: Mon Sep 06, 2010 2:59 pm

Mon Jul 21, 2014 8:23 pm

Let me start with my question:

Why have the values in Advanced Settings for iSCSI been limited? How are valid values determined?

Here's the back story...

I've started testing V8 and I'm a little confused by the iSCSI section of the Advanced Settings. When I started using v5 then on into v6 I ended up hard coding some modified VMWare iSCSI settings for First Burst length, Maximum Burst Length, and Maximum Receive Data Segment Length on both the vSphere host and inside of Starwind. The result was some pretty good performance. When I try to enter those same values into v8 I get "Invalid Value Range" errors. Even with the default setting in v8 the vSphere host still connects to and mounts an iSCSI volume, but the performance is about 25% of what I'm getting from my production v6 servers.

So in v6 I have hard coded:
First Burst Length = 131072
Max Burst Length = 262144
Maximum Receive Data Segment Length = 131072

I have these same values hard coded on my vSphere serves.

Here a section from an old vSphere 4.1 document that I based these settings on.
FirstBurstLength – Specifies the maximum amount in bytes of unsolicited data an iSCSI initiator can send to the target during the execution of a single SCSI command. The default is 262144.

MaxBurstLength – Maximum SCSI data payload in a Data-In or a solicited Data-Out iSCSI sequence, in bytes. The default is 262144.

MaxRecvDataSegLen – Maximum data segment length, in bytes, that can be received in an iSCSI PDU. The default is 131072. This variable is half the size of MaxBurstLength and FirstBurstLength, that means whenever you want to change that value, you must also change accordingly the values of MaxBurstLength and FirstBurstLength.
An interesting thing I found when looking at the log files between a v6 server and a v8 server:

Here a section of a v6 server:
7/21 12:38:13.324 37c Params: <<< String param 'InitiatorName': received 'iqn.1998-01.com.vmware:vmware-06-1c837a94', accepted 'iqn.1998-01.com.vmware:vmware-06-1c837a94'
7/21 12:38:13.324 37c Params: <<< Enum param 'SessionType': received 'Discovery', accepted 'Discovery'
7/21 12:38:13.324 37c Params: <<< Enum param 'HeaderDigest': received 'None', accepted 'None'
7/21 12:38:13.324 37c Params: <<< Enum param 'DataDigest': received 'None', accepted 'None'
7/21 12:38:13.324 37c Params: <<< Numeric param 'DefaultTime2Wait': received 0, accepted 0
7/21 12:38:13.324 37c Params: <<< Numeric param 'DefaultTime2Retain': received 0, accepted 0
7/21 12:38:13.324 37c Params: <<< Boolean param 'IFMarker': received No, accepted 0
7/21 12:38:13.324 37c Params: <<< Boolean param 'OFMarker': received No, accepted 0
7/21 12:38:13.324 37c Params: <<< Numeric param 'ErrorRecoveryLevel': received 0, accepted 0
7/21 12:38:13.324 37c Params: <<< Numeric param 'MaxRecvDataSegmentLength': received 32768, accepted 32768
7/21 12:38:13.324 37c Params: >>> ErrorRecoveryLevel=0.
7/21 12:38:13.324 37c Params: >>> HeaderDigest=None.
7/21 12:38:13.324 37c Params: >>> DataDigest=None.
7/21 12:38:13.324 37c Params: >>> OFMarker=No.
7/21 12:38:13.324 37c Params: >>> IFMarker=No.
7/21 12:38:13.324 37c Params: >>> InitialR2T=No.
7/21 12:38:13.324 37c Params: >>> ImmediateData=Yes.
7/21 12:38:13.324 37c Params: >>> MaxRecvDataSegmentLength=131072.
7/21 12:38:13.324 37c Params: >>> MaxBurstLength=262144.
7/21 12:38:13.324 37c Params: >>> FirstBurstLength=131072.

7/21 12:38:13.324 37c Params: >>> DefaultTime2Wait=0.
7/21 12:38:13.324 37c Params: >>> DefaultTime2Retain=0.
7/21 12:38:13.324 37c Params: >>> MaxOutstandingR2T=1.
7/21 12:38:13.324 37c Params: >>> DataPDUInOrder=Yes.
7/21 12:38:13.324 37c Params: >>> DataSequenceInOrder=Yes.
I don't understand where that first red line is getting those values, but the last three reflect the hard coded values I have in both Starwind and VMware.

Here a section of a v8 server:
7/21 12:38:31.721 53c Params: <<< String param 'InitiatorName': received 'iqn.1998-01.com.vmware:vmware-06-1c837a94', accepted 'iqn.1998-01.com.vmware:vmware-06-1c837a94'
7/21 12:38:31.721 53c Params: <<< Enum param 'SessionType': received 'Discovery', accepted 'Discovery'
7/21 12:38:31.721 53c Params: <<< Enum param 'HeaderDigest': received 'None', accepted 'None'
7/21 12:38:31.721 53c Params: <<< Enum param 'DataDigest': received 'None', accepted 'None'
7/21 12:38:31.721 53c Params: <<< Numeric param 'DefaultTime2Wait': received 0, accepted 0
7/21 12:38:31.721 53c Params: <<< Numeric param 'DefaultTime2Retain': received 0, accepted 0
7/21 12:38:31.721 53c Params: <<< Boolean param 'IFMarker': received No, accepted 0
7/21 12:38:31.721 53c Params: <<< Boolean param 'OFMarker': received No, accepted 0
7/21 12:38:31.721 53c Params: <<< Numeric param 'ErrorRecoveryLevel': received 0, accepted 0
7/21 12:38:31.721 53c Params: <<< Numeric param 'MaxRecvDataSegmentLength': received 32768, accepted 32768
7/21 12:38:31.721 53c Params: >>> ErrorRecoveryLevel=0.
7/21 12:38:31.721 53c Params: >>> HeaderDigest=None.
7/21 12:38:31.721 53c Params: >>> DataDigest=None.
7/21 12:38:31.721 53c Params: >>> OFMarker=No.
7/21 12:38:31.721 53c Params: >>> IFMarker=No.
7/21 12:38:31.721 53c Params: >>> InitialR2T=No.
7/21 12:38:31.721 53c Params: >>> ImmediateData=Yes.
7/21 12:38:31.721 53c Params: >>> MaxRecvDataSegmentLength=262144.
7/21 12:38:31.721 53c Params: >>> MaxBurstLength=262144.
7/21 12:38:31.721 53c Params: >>> FirstBurstLength=262144.
7/21 12:38:31.721 53c Params: >>> DefaultTime2Wait=0.
7/21 12:38:31.721 53c Params: >>> DefaultTime2Retain=0.
7/21 12:38:31.721 53c Params: >>> MaxOutstandingR2T=1.
7/21 12:38:31.721 53c Params: >>> DataPDUInOrder=Yes.
7/21 12:38:31.721 53c Params: >>> DataSequenceInOrder=Yes.
I still don't know where that first red entry is coming from, but it is consistent.

But those last three values make little sense. Yes MaxBurstLength is 262144 on both Starwind and vSphere. But the other two do no match either Starwind nor vSphere settings.
User avatar
anton (staff)
Site Admin
Posts: 4010
Joined: Fri Jun 18, 2004 12:03 am
Location: British Virgin Islands
Contact:

Tue Jul 22, 2014 6:22 am

Please send whole log generated on attempt to establish an iSCSI handshake to support@starwindsoftware.com as typically we don't expect our customers to analyze logs on their own.
Regards,
Anton Kolomyeytsev

Chief Technology Officer & Chief Architect, StarWind Software

Image
Post Reply