Jump to content
SNS Users' Forums
  • Announcements

    • Eric Newbauer

      Follow SNS on Twitter!

      Get notifications via Twitter! Looking for instant updates? We're now also announcing new versions and beta programs via Twitter. Follow Studio Network Solutions on Twitter. Thanks!

Recommended Posts

Hi Ryan,

I got .35 installed, after i installed and uninstalled both versions several times.

Kind regards,

Karsten

Share this post


Link to post
Share on other sites

Update for .35

Nexenta 1.0.1. works (still slow), Preferences panel crash on disconnect (after correct umount), have to restart Mac

LIO 3.0.0. same globalSAN error code 110E

Share this post


Link to post
Share on other sites

Update for .35

- open-e 5.0: Copied 40GB without crash (was crashing after 2GB with .15)

Connect with Data Digest or Header Digest don't works anymore (was ok with .15): Login status code 207

- openfiler 2.3b2: Copied 90GB without crash (was crashing after 2GB with .15)

Connect with Data Digest or Header Digest don't works anymore (was ok with .15): Login status code 207

Openfiler iSCSI console shows some messages (same as in .15)

scsi_cmnd_start(1016) Unsupported 5a

cmnd_skip_pdu(454) 1f 1c 5a 0

scsi_cmnd_start(1016) Unsupported 5a

cmnd_skip_pdu(454) 20 1c 5a 0

.35 seams a little bit slower than .15, but much more stable

Share this post


Link to post
Share on other sites
Pursuant to my post of May 15, where I've got the iSCSI device showing up in Disk Utility but can't partition it due to "permission denied", I finally tracked down something in system.log. When I try to read the iSCSI device (by doing a "dd" of a few blocks to /dev/null), I get this:

kernel[0]: disk3: device/channel is not attached.

I hope that'll give you some idea of what's not happening in the iSCSI initiator. It looks like it's not taking the final step to make the device ready for use.

Google tells me that this message is usually seen with external USB disks when the connection to the host is flaky. There are no other messages here and the net connection is not flaky. In fact there is no net traffic whatsoever; this appears to be due entirely to OS X's internal notion of what "attached" means.

This is a post from the Open filers forum and should answer your question.

lately where users have said that they were planning to deploy OpenFiler systems with iSCSI volumes and to have those volumes mounted by multiple systems (often Windows boxes). Unfortunately, this is not possible with most file systems.

File systems such as ext3, ReiserFS, XFS, Fat32, and NTFS are NOT shared file systems that can be accessed by multiple systems at the same time. For a list of file systems you cannot use for this task, see the link below.

Disk File Systems - Wikipedia

As to which file systems you can use for this task, there are currently very few. Most are proprietary and are only distributed with high-priced software or hardware, such as that from Oracle, VMWare, and EMC. There are a few solutions that are available stand-alone but none are available for free for Windows and to my knowledge, no one here has tried to use any of the free Linux packages (such as GFS) with an OpenFiler iSCSI volume. For a list of what you may be able to try, check the link below.

Shared Disk File Systems - Wikipedia

In summary, if you are planning on having multiple clients connect to your OpenFiler server, I would really recommend that you use SMB for Windows systems and NFS for Linux. That said, if you do happen to get one of the above shared file systems working, please let me know what you did and that will be added to this thread.

Jason Litka

Utter Ramblings

Note there are a few but non for mac that I know of bar the Xsan from Mac. But this file system uses FC and cost a lot of $$ to setup with ISCSI. Not sure if it will let you have direct access to the volume as needed by Pro Tools and some other apps

Jason

Share this post


Link to post
Share on other sites
.35 on 10.5.3 works well with Openfiler 2.3RC

I too Confirm this, running on mac 10.4.11 and with .35 on openfiler 2.3RC works great. this .35 upgrade fixed the crashing problem i had when disconnecting targets

Jason

Share this post


Link to post
Share on other sites

Hi,

iSCSI works fine under Mac OS X 10.5.3 with globalSAN iSCSI Initiator 3.3.0.35 installed.

Server is a OpenSolaris 2008.05 machine with SunOS 5.11 snv_86 64 Bit Kernel.

iSCSI is simply shared by ZFS without any authentication.

zfs create -V 500G tank/iscsi
zfs set shareiscsi=on tank/iscsi

Nothing more. Works perfectly. Stay tuned for more feedback using this Volume as a Time Machine backup destination.

Best regards

Chris

Share this post


Link to post
Share on other sites

By now the Timemachine-iSCSI Backup System works fine. Also the suspend mode works perfectly. The speed is about 10-20MB/s writing which is very good for a consumer 1gbps nic. I hope that this doesn't change! ;-)

Best Regards

Chris

Share this post


Link to post
Share on other sites
Hi,

iSCSI works fine under Mac OS X 10.5.3 with globalSAN iSCSI Initiator 3.3.0.35 installed.

Server is a OpenSolaris 2008.05 machine with SunOS 5.11 snv_86 64 Bit Kernel.

iSCSI is simply shared by ZFS without any authentication.

# zfs create -V 500G tank/iscsi

# zfs set shareiscsi=on tank/iscsi

Nothing more. Works perfectly. Stay tuned for more feedback using this Volume as a Time Machine backup destination.

Best regards

Chris

When you mount your drive the first time did you have to format this for HFS?

For Mac, per the info I have Mac will not read a ZFS file system.

The ISCSI taret volumes may live on the ZFS file system on a lower layer, you will not see from the mac side.

Let me know as I have not see this work an would like to know if this is working how you are doing it.

thanks Jason

Share this post


Link to post
Share on other sites

After connecting to the iSCSI Portal aka "minifiler" I choose a Target on the Server. I log onto the target and Mac OS X recognizes the volume. It's like pluggin in a usb thumbdrive. Then you can make your choice on partitioning the volume. For example using the whole space for a HFS+ partition.

On the server side it's a ZFS volume. You have no direct access to the files on the iSCSI volume. I haven't try mounting it, but I think I'll make the volume unusable. Just a guess.

What you can do after mounting and partitioning the volume under Mac OS X is changing the size of the volume. For trying purposes I made a 5G volume, but for testing Time Machine it was way to small. So I made the volume bigger.

zfs set volsize=500g tank/iscsi

That's just it. You have to log off the iSCSI Target, an log on again to see the bigger volume, but after that, you have more space to use. Making a formatted partition smaller may run in a fault.

Hope that I could answer your question. If not. Just ask further! :-)

Best Regards

Chris

Share this post


Link to post
Share on other sites

Update for .35

Nexenta 1.0.1. works (still slow), Preferences panel crash on disconnect (after correct umount), have to restart Mac

LIO 3.0.0. same globalSAN error code 110E

I figured I would post that I am not having any issues now with NexentaStor 2.2.1b104, OS X 10.4.11 PPC xserve, and the great FREE globalSAN iSCSI 3.3.0.43. Seems like the issues have been worked out. With jumbo frames (9000MTU) enabled I am getting very good transmission speeds.

Share this post


Link to post
Share on other sites

Works great with NexentaStor 2.2.1b104. Hopefully this will continue with the 3.0 release. Thanks again SNS.

Share this post


Link to post
Share on other sites

Hi,

today I tried the globalSAN iSCSI initiator 4.1 on SnowLeopard 10.6.5 with the new Release of Oracle Solaris 11 Express. It didn't work and I got the following message:

---------

Connection error

Code E3FF8300. Target hadrware or software error

---------

Tests on MS Windows 7 and the integrated ISCSI Inititor works fine.

Thank you very much for your great work since years!

Regards,

Peter

Share this post


Link to post
Share on other sites

Peter, were you able to connect to that target with v.4.0 of the initiator, whereas you're now unable to connect with v.4.1 (beta) of the initiator? If so, please read this post and follow the instructions. Thanks!

Share this post


Link to post
Share on other sites

Eric, the same Error Message appears to that target with v.4.0 too. The new Oracle Solaris 11 Express is official new version of Open Solaris. I never had any problems with your ISCSI initiator to the target Open Solaris snv_134 in the past. V 4.1 beta and V 4.0 are working well to Open Solaris snv_134.

Should I follow the instructions of the post you mentioned?

Thanks for help.

Best regards

Peter

Share this post


Link to post
Share on other sites

Peter, I think not yet. We're trying to reserve those instructions for issues that appear to be new to v.4.1 beta. I think your issue may not be related to v.4.1. Please carefully check this thread and post your comments (success or failure!) there. I'll keep an eye out, and if this is looking like a 4.1 thing we may request that you send a TCP dump as noted earlier.

Thanks!

Share this post


Link to post
Share on other sites

Eric, the same Error Message appears to that target with v.4.0 too. The new Oracle Solaris 11 Express is official new version of Open Solaris. I never had any problems with your ISCSI initiator to the target Open Solaris snv_134 in the past. V 4.1 beta and V 4.0 are working well to Open Solaris snv_134.

Should I follow the instructions of the post you mentioned?

Thanks for help.

Best regards

Peter

I'm also seeing the same problem with Solaris 11 Express. I'm running globalSAN_4.0.0.204 a first gen Mac Pro running Mac OS X 10.6.5. I'm seeing the following error when connecting to Solaris 11:

Connection Error

Code E3FF8300. Target hardware or software error.

I am able to connect to OpenSolaris 09.06 fine with globalSAN_4.0.0.204. I am also able to run a other iSCSI initiators against Solaris 11 Express and they work.

Share this post


Link to post
Share on other sites

I'm also seeing the same problem with Solaris 11 Express. I'm running globalSAN_4.0.0.204 a first gen Mac Pro running Mac OS X 10.6.5. I'm seeing the following error when connecting to Solaris 11:

Connection Error

Code E3FF8300. Target hardware or software error.

I am able to connect to OpenSolaris 09.06 fine with globalSAN_4.0.0.204. I am also able to run a other iSCSI initiators against Solaris 11 Express and they work.

Ok, I just downloaded the 4.1 BETA. It's not working with anything. I try to just enter the IP of a portal and I get:

Connection error

Code E3FF820B. Invalid request type during Login

I did a full uninstall of globalSAN_4.0.0.204 before installing the Beta, and rebooted my machine.

Share this post


Link to post
Share on other sites

Ok, I just downloaded the 4.1 BETA. It's not working with anything. I try to just enter the IP of a portal and I get:

Connection error

Code E3FF820B. Invalid request type during Login

I did a full uninstall of globalSAN_4.0.0.204 before installing the Beta, and rebooted my machine.

I am seeing the same error with the 4.1 beta after upgrading to a Solaris 11 Express target.

ditto on the 4.0 error as well - I can add the portal with 4.0 but not connect to the target.

Share this post


Link to post
Share on other sites

I am seeing the same error with the 4.1 beta after upgrading to a Solaris 11 Express target.

ditto on the 4.0 error as well - I can add the portal with 4.0 but not connect to the target.

I Updated my two hosts to SolExpr 11 today and if I get some spare cycles tomorrow, I will try the 4.0 of GlobalSAN against it.

I didn't had a problem with GlobalSAN 4.0 against my oi_148 targets.

Cheers,

budy

Share this post


Link to post
Share on other sites

Hi,

today I re-installed GlobalSAN 4.0 (204) and connected successfully against my Sol11 Expr targets. So there's no general issue with GlobalSAN 4.0 and either Openindiana ol_147 or Solaris11 Express.

If GlobalSAN 4.0 doesn't connect successfully against Sol11 Express targets, there must be some other issue connected to that.

Cheers,

budy

Share this post


Link to post
Share on other sites

That's great. Could you share some details of your configuration with us? Maybe we can figure out what we are doing wrong... :)

For example, do you use chap authentication?

Hi,

today I re-installed GlobalSAN 4.0 (204) and connected successfully against my Sol11 Expr targets. So there's no general issue with GlobalSAN 4.0 and either Openindiana ol_147 or Solaris11 Express.

If GlobalSAN 4.0 doesn't connect successfully against Sol11 Express targets, there must be some other issue connected to that.

Cheers,

budy

Share this post


Link to post
Share on other sites

I was able to connect to my iscsi target...

I had to uninstall 4.1 and revert back to globalsan 4.0.

The culprit appears to be the Initiator Name field at the top of the settings pane. I filled this out with the following name I made up (wikipedia helped here: http://en.wikipedia.org/wiki/Iscsi#Addressing):

iqn.2010-04.be.bonovox:01

I could consistently reproduce the Software or Hardware Target error if I disconnect and erase that field.

I don't think I ever filled this out in the past when using targets on opensolaris 134b but with solaris 11 express this appears to be a problem.

The 4.1 beta actually warns you when you enter the settings pane if the initiator name is blank, saying it could be a problem with certain targets, and offers to generate a name for you. The auto-generated name has the EUI format instead of the IQN-style name above that I made up and used (see the wikipedia article). Neither one of the 2 initiator names worked for me with globalsan 4.1 - i kept getting a mixture of Login and Software-or-Hardware errors as I was playing around with different settings (add portal vs add target directly, error detection, alias) and trying to connect.

My setup is back up now with 4.0 though and I have no intention of going back and experimenting with the 4.1 beta again. I've spent enough time tackling this already :)

That's great. Could you share some details of your configuration with us? Maybe we can figure out what we are doing wrong... :)

For example, do you use chap authentication?

Share this post


Link to post
Share on other sites

Hi,

I was able to connect to my iscsi target...

I had to uninstall 4.1 and revert back to globalsan 4.0.

The culprit appears to be the Initiator Name field at the top of the settings pane. I filled this out with the following name I made up (wikipedia helped here: http://en.wikipedia.org/wiki/Iscsi#Addressing):

iqn.2010-04.be.bonovox:01

I could consistently reproduce the Software or Hardware Target error if I disconnect and erase that field.

I don't think I ever filled this out in the past when using targets on opensolaris 134b but with solaris 11 express this appears to be a problem.

The 4.1 beta actually warns you when you enter the settings pane if the initiator name is blank, saying it could be a problem with certain targets, and offers to generate a name for you. The auto-generated name has the EUI format instead of the IQN-style name above that I made up and used (see the wikipedia article). Neither one of the 2 initiator names worked for me with globalsan 4.1 - i kept getting a mixture of Login and Software-or-Hardware errors as I was playing around with different settings (add portal vs add target directly, error detection, alias) and trying to connect.

My setup is back up now with 4.0 though and I have no intention of going back and experimenting with the 4.1 beta again. I've spent enough time tackling this already :)

well… my COMSTAR setup is a bit more complicated, since I need to make sure that specific targets can only be accessed by specific initiators. As opposed to Linux iscsi-enterprise target, it's more complicated in COMSTAR. This is the reason, why I have been using meaningful initiator names (well, at least menaingful to me ;) ) forever. In the end the iSCSI RFC don't state any relation between the initiator name and any function or capability on the target side. This means, that one should be free to use either naming convention, be it the iqn. or eui. or naa. names as the initiator name.

To cut it short: I don't use (chap) authentication in COMSTAR and I haven't done so in Open-E either, since I restricted access on a lower level already. I still think the reason for COMSTAR to reject the login request from 4.1 is due to the fact that GlobalSAN 4.1 tries to negotiate about authentication.

As stated again earlier: 4.1 (246) omits the authentication probe in the login request and gets accepted, while 4.1. (247) introduces the authentication probe and gets rejected.

I could maybe create a new target on my Sol11 Expr host and configure authentication - that would be interesting…

Cheers,

budy

Share this post


Link to post
Share on other sites

×