@Dids I have added your github issue here also.

 

Took a while, but I got this absolutely fantastic plugin working, however I noticed that occasionally it shows error: /Settings/iSCSISettings: wrong csrf_token in the syslog. I believe this happens when making changes, as I end up with a white screen and have to reload the page.

Additionally, at least when connecting from a Windows client, the following message/warning gets repeated over and over again in syslog:

iSCSI/iqn.1991-05.com.microsoft:didspc: Unsupported SCSI Opcode 0x85, sending CHECK_CONDITION. target_cmd_parse_cdb: 9 callbacks suppressed

These aren't blocking issues by any means, but figured they were still worth reporting.

Also slightly off topic, but are there plans to allow default/any initiator names, without having to configure them every time? Granted this can become a security issue, but the iSCSI servers I've dealt with before have allowed any initiator name.

 

I will look into them.

 

you can still use the targetcli in the short term to add default/any init names if that is allowed, but will investigate putting into the plugin and look at csrf issues.

 

https://github.com/SimonFair/unraid.iSCSI/issues/3

Edited July 9, 20214 yr by SimonF

https://github.com/SimonFair/unraid.iSCSI/issues/4

 

The following error repeats in syslog:

FILEIO: Not able to process I/O of 10841088 bytes due toFD_MAX_BYTES: 8388608 iovec count limitation

Based on this and this, it looks like it's a relatively old bug, which should've been fixed in newer LIO versions, but I'm not entirely sure if this plugin provides its own version or if it's using the one bundled with Unraid, as I believe it's part kernel modules and part CLI tools.

On 7/9/2021 at 8:44 PM, SimonF said:

https://github.com/SimonFair/unraid.iSCSI/issues/4

 

The following error repeats in syslog:

FILEIO: Not able to process I/O of 10841088 bytes due toFD_MAX_BYTES: 8388608 iovec count limitation

Based on this and this, it looks like it's a relatively old bug, which should've been fixed in newer LIO versions, but I'm not entirely sure if this plugin provides its own version or if it's using the one bundled with Unraid, as I believe it's part kernel modules and part CLI tools.

 

Hi Simon, it's Dids from GitHub.

 

Just wanted to provide more details on this particular error:

- Running on Unraid 6.9.2

- Using the iSCSI target plugin with FileIO images on the primary pool (HDD)

- Attempting to install OS's, such as Windows 10, on the iSCSI target/FileIO image through iPXE, but the installation itself keeps failing and at the same time I see the FileIO errors in Unraid's syslog (found information via Google on "FileIO" and "FD_MAX_BYTES" that seemed to indicate it being a bug, which was already patched in newer versions)

- When I dedicated an entire physical hard drive to iSCSI, it works as expected

It might also be worth mentioning that the "Support Thread" link the plugin adds to Unraid doesn't actually link to here, but to the forum frontpage, which made me assume there was no support thread.

11 minutes ago, Didstopia said:

Hi Simon, it's Dids from GitHub.

Have you read my previous answers on the two issues on Github?

 

12 minutes ago, Didstopia said:

- Attempting to install OS's, such as Windows 10, on the iSCSI target/FileIO image through iPXE, but the installation itself keeps failing and at the same time I see the FileIO errors in Unraid's syslog (found information via Google on "FileIO" and "FD_MAX_BYTES" that seemed to indicate it being a bug, which was already patched in newer versions)

What is a newer version? This plugin uses the latest version of targetcli-fb and all other required dependencies.

You are talking about the Kernel I think, from what I know these errors where patched out somewhere in the Linux Kernel v3 and should be included in every Kernel version higher than 4.

 

12 minutes ago, Didstopia said:

It might also be worth mentioning that the "Support Thread" link the plugin adds to Unraid doesn't actually link to here, but to the forum frontpage, which made me assume there was no support thread.

I'm currently working with @SimonF on another solution how the plugin is installed and the link will be updated when the new version drops, you can also find the support link on Github in the Readme.

 

 

Is the other issue resolved now that was also part from FileIO, don't remember exactly what it was...?

7 minutes ago, ich777 said:

Have you read my previous answers on the two issues on Github?

As Issues have been disabled for the GitHub repository, I'm no longer able to access or read them, but I looked through my emails and I'm assuming it was the one about harmless opcodes trying to read SMART data but failing due to it being a virtual disk/image?
If so, that is very good to know, thank you.

 

7 minutes ago, ich777 said:

What is a newer version? This plugin uses the latest version of targetcli-fb and all other required dependencies.

You are talking about the Kernel I think, from what I know these errors where patched out somewhere in the Linux Kernel v3 and should be included in every Kernel version higher than 4.

I can only assume, but my own research led me to this bug report, which seems to confirm it being a LIO (see message #28 in the bug report): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805252

 

7 minutes ago, ich777 said:

I'm currently working with @SimonF on another solution how the plugin is installed and the link will be updated when the new version drops, you can also find the support link on Github in the Readme.

Great, thank you.

 

7 minutes ago, ich777 said:

Is the other issue resolved now that was also part from FileIO, don't remember exactly what it was...?

I unfortunately don't recall any other issue, other than the syslog spam caused by large amounts of files/writes.

When possible, I will attempt to replicate the issue with FileIO and the latest version of this plugin, to confirm whether or not it still is an issue, or even if the issue was elsewhere (in iPXE for instance).

1 minute ago, Didstopia said:

I'm assuming it was the one about harmless opcodes trying to read SMART data but failing due to it being a virtual disk/image?

Exactly, or better speaking that is not the whole story but it is harmless...

 

2 minutes ago, Didstopia said:

I can only assume, but my own research led me to this bug report, which seems to confirm it being a LIO (see message #28 in the bug report): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805252

This was the issue for Debian, this was patched out in Kernel somewhere between Kernel v3.8 and v4.

 

How have you formated the disks with GPT or Legacy? I think this is more of a formatting issue within Windows, have you already tried to installed a Linux Distro on a FileIO volume, also I don't recommend doing so because performance will most likely suffer from the FileIO volume.

 

4 minutes ago, Didstopia said:

I unfortunately don't recall any other issue, other than the syslog spam caused by large amounts of files/writes.

When possible, I will attempt to replicate the issue with FileIO and the latest version of this plugin, to confirm whether or not it still is an issue, or even if the issue was elsewhere (in iPXE for instance).

Keep in mind that FileIO can be a best and it is not really easy to tame... most people, at least that I know and that I spoke to are using iSCSI to pass through a whole disk to get the highest performance out of it.

I'm using iSCSI too with a SSD in my server and that is passed through to Windows because I simply have no space in my SFF build.

1 hour ago, Didstopia said:

I'm no longer able to access or read them,

I have re-enabled github for the time being.

We have changed the load process and set version to match Targetcli version. As the new version is less than current version you need to uninstall and re-install. Further updates will follow standard udate process. There is no functional update in the revised install.

Edited July 16, 20214 yr by SimonF

2 hours ago, SimonF said:

We have changed the load process and set version to match Targetcli version. As the is less than current version you need to uninstall and re-install. Further updates will follow standard udate process. There is no functional update in the revised install.

what affect will this have to peoples existing production setups by uninstalling and reinstalling?

4 hours ago, Joedy said:

what affect will this have to peoples existing production setups by uninstalling and reinstalling?

Nothing.

I have designed the plugin initially in that way that the configuration is not deleted even when you uninstall the plugin because if you unstall it by accident this can result in really bad experience for the users.

 

Just be sure to remove the plugin, restart your server and then reinstall it again from the CA App.

Of course do this when the clients are offline or just be sure that non of them is writing or reading from their assigned iSCSI disks.

23 minutes ago, ich777 said:

Of course do this when the clients are offline or just be sure that non of them is writing or reading from their assigned iSCSI disks.

I've found windows to be pretty gracious in handling the iscsi disks coming online and offline, which often happens as I'm doing maintenance on the array.

25 minutes ago, tjb_altf4 said:

I've found windows to be pretty gracious in handling the iscsi disks coming online and offline, which often happens as I'm doing maintenance on the array.

Yes that's true.

I also implemented a function that iSCSI is unmounted when the array is stopped and started when the array is started, only for security reasons...

2 hours ago, tjb_altf4 said:

I've found windows to be pretty gracious in handling the iscsi disks coming online and offline, which often happens as I'm doing maintenance on the array.

I run through a windows server 2019 as a file server with several connectors and don't have any issues, very quick to access everything but I do have a 10GB fibre card in it and the file server.

2 hours ago, ich777 said:

Nothing.

I have designed the plugin initially in that way that the configuration is not deleted even when you uninstall the plugin because if you unstall it by accident this can result in really bad experience for the users.

 

Just be sure to remove the plugin, restart your server and then reinstall it again from the CA App.

Of course do this when the clients are offline or just be sure that non of them is writing or reading from their assigned iSCSI disks.

cheers thank you.

Hi guys. 
First of all, it’s nice Plugin and i get it to work yesterday. I’m new to iSCSI and have a question. 
 

I only can create a FileIO Device and not a Block Device in the GUI. I can’t select a disk. Is this a normal behavior or do I miss something? 
 

Can’t attach a photo at the moment. 

1 hour ago, DiaboloVampire said:

Is this a normal behavior or do I miss something? 

Have you got a spare disk that is not assigned to the Array or to a Cache Pool?

 

If not that's the problem.

I just installed the plugin and created a initiator by going to "add target", then I added a lun. I am trying to use the client on windows server 2012 r2, it can see the target but the status shows "inactive". what did I miss? 

42 minutes ago, Xxharry said:

I just installed the plugin and created a initiator by going to "add target", then I added a lun.

Have you also assigned the initiator identification to the LUN?

What does the syslog from unRAID say?

 

I think it may be missing which initiators can access the LUN.

54 minutes ago, ich777 said:

Have you also assigned the initiator identification to the LUN?

What does the syslog from unRAID say?

 

I think it may be missing which initiators can access the LUN.

I see the below log

 

Jul 31 13:34:55 UnRAID kernel: iSCSI Initiator Node: iqn.1991-05.com.microsoft:win-ra6eums5oqa is not authorized to access iSCSI target portal group: 1.

Jul 31 13:34:55 UnRAID kernel: iSCSI Login negotiation failed.

Jul 31 13:35:36 UnRAID kernel: iSCSI Initiator Node: iqn.1991-05.com.microsoft:win-ra6eums5oqa is not authorized to access iSCSI target portal group: 1.

Jul 31 13:35:36 UnRAID kernel: iSCSI Login negotiation failed.

Jul 31 13:36:26 UnRAID kernel: iSCSI Initiator Node: iqn.1991-05.com.microsoft:win-ra6eums5oqa is not authorized to access iSCSI target portal group: 1.

 

how do I assign initiators to the LUN?

Are you able to provide a screen print of the initiators tab or the status page. 

 

I actually 

Just now, SimonF said:

Are you able to provide a screen print of the initiators tab or the status page. 

 

I managed to create the initiator. its working now. I didnt do the "Add IQN" (second line) bit.

Thanks

 

Very cool plugin, I have an external AccuRAID AR316IR iSCSI is there anyway to connect a drive to unRAID I have it working on the network with other Windows Machines, but I'd like to create a share for unRAID to use (without having to leave a computer on and sharing that way).... ??

Edited August 18, 20214 yr by iDJMic

6 hours ago, iDJMic said:

I have an external AccuRAID AR316IR iSCSI is there anyway to connect a drive to unRAID I have it working on the network with other Windows Machines

You want to mount/add a iSCSI drive to unRAID if I understand that right?

If yes, that's not possible, this is only a iSCSI target where initiators can connect to.

 

The problem with mounting a iSCSI drive to unRAID is if the iSCSI target is not on or reachable unRAID won't start the Arry on boot because the drive is basically missing.

13 hours ago, ich777 said:

You want to mount/add a iSCSI drive to unRAID if I understand that right?

If yes, that's not possible, this is only a iSCSI target where initiators can connect to.

 

The problem with mounting a iSCSI drive to unRAID is if the iSCSI target is not on or reachable unRAID won't start the Arry on boot because the drive is basically missing.

 

Just wanted to add a drive on the iSCSI under unassigned devices.