Page 1 of 1

open-iscsi w/ starwind

Posted: Wed Aug 08, 2007 8:54 pm
by MrSouth
Hi,

I've set up StarWind 3.5 build 20070726 on a windows xp box and want to test it's connectivity with a debian etch stable machine running open-iscsi
(open-iscsi/etch 2.0.730-1etch1).
When exporting the dvd-writer on the windows box as a SPTI device, open-iscsi fails to generate a device node for it. Checking the logs for StarWind i found this particular error:

8/8 23:40:20.531 928 SPTI: '\\.\E:': scsiPassThrough failed: The parameter is incorrect. (code: 87).
8/8 23:40:20.531 928 SPTI: '\\.\E:': IOCTL_SCSI_PASS_THROUGH_DIRECT (before):
[[ hex dump here ]]
8/8 23:40:20.531 928 SPTI: '\\.\E:': IOCTL_SCSI_PASS_THROUGH_DIRECT (after):
[[ hex dump here ]]

The login process viewed from the debian box to the iscsi target goes fine. (i even noticed activity in initiating the dvd-drive). However no node is generated. (sdX device).
Other types of devices (ramdrive, image file) work without a problem.

I know chances are 50:50 for failure in both sides (starwind or open-iscsi)
but i would be very gratefull if someone from the development team takes a look on the log i would provide.
Same open-iscsi initiator was used with an older version of starwind 2.3.0 with the same dvd-rw as SPTI device and it worked. (open-iscsi generated successfully a node device).

Thanks in advance,
Please advice.

Re: open-iscsi w/ starwind

Posted: Wed Aug 08, 2007 10:11 pm
by anton (staff)
Dump current version and download new one from the site. Re-published version 3.5 (different build number) has SPTI related bug fixed. Thanks!
MrSouth wrote:Hi,

I've set up StarWind 3.5 build 20070726 on a windows xp box and want to test it's connectivity with a debian etch stable machine running open-iscsi
(open-iscsi/etch 2.0.730-1etch1).
When exporting the dvd-writer on the windows box as a SPTI device, open-iscsi fails to generate a device node for it. Checking the logs for StarWind i found this particular error:

8/8 23:40:20.531 928 SPTI: '\\.\E:': scsiPassThrough failed: The parameter is incorrect. (code: 87).
8/8 23:40:20.531 928 SPTI: '\\.\E:': IOCTL_SCSI_PASS_THROUGH_DIRECT (before):
[[ hex dump here ]]
8/8 23:40:20.531 928 SPTI: '\\.\E:': IOCTL_SCSI_PASS_THROUGH_DIRECT (after):
[[ hex dump here ]]

The login process viewed from the debian box to the iscsi target goes fine. (i even noticed activity in initiating the dvd-drive). However no node is generated. (sdX device).
Other types of devices (ramdrive, image file) work without a problem.

I know chances are 50:50 for failure in both sides (starwind or open-iscsi)
but i would be very gratefull if someone from the development team takes a look on the log i would provide.
Same open-iscsi initiator was used with an older version of starwind 2.3.0 with the same dvd-rw as SPTI device and it worked. (open-iscsi generated successfully a node device).

Thanks in advance,
Please advice.

Thanks a lot

Posted: Thu Aug 09, 2007 11:42 am
by MrSouth
thanks, will get back with test results :)

However, minor issue, maybe suggestion, open-iscsi node discovery shows up the virtual ram device and cddvd device - presumably the iso virtual dvd device, although i didn't explicitly set up these nodes (no ram disk / no cddvd device)... Sort of a hidden device "feature"...not set but visible ... activated

Can i bypass this issue somehow? besides unloading the module's dlls directly from the config file. Any suggestion from your side if it's safe to do so?

Thanks,
M.

Re: Thanks a lot

Posted: Thu Aug 09, 2007 11:47 am
by anton (staff)
StarWind starts with one small RAM disk by default. CD/DVD was created by you (sharing DVD burner thru the SPTI).
MrSouth wrote:thanks, will get back with test results :)

However, minor issue, maybe suggestion, open-iscsi node discovery shows up the virtual ram device and cddvd device - presumably the iso virtual dvd device, although i didn't explicitly set up these nodes (no ram disk / no cddvd device)... Sort of a hidden device "feature"...not set but visible ... activated

Can i bypass this issue somehow? besides unloading the module's dlls directly from the config file. Any suggestion from your side if it's safe to do so?

Thanks,
M.