What is the Microsoft iSCSI initiator target limit ? I mean - how many disks from single iSCSI server can the initiator handle ? I have a FreeBSD 11.x kernel iSCSI target, and hundreds of disks configured, which the iSCSI server serves to hundreds of VMs, two disks per VM. I start to get the ctld errors as soon as I cross the treshold of 573 disks configured on the iSCSI server (one LUN per target; fewer disks work okay, furthermore, 573- disks connected continue to work, only newer disks, likt 574th and so one are troublesome). So now I wonder whether this is FreeBSD target bug, or Miscosoft initiator limitation.

Of course, I got the iSCSI Target Server Scalability Limits article, and the Microsoft iSCSI Software Target 3.3 one, but these are the target documents, not the initiator ones (at least as I interpret them).

Does someone have the experience of successfully working with 580+ disks from single iSCSI server, regardless of the iSCSI target implementation, but using the Microsoft iSCSI initiators (for example Windows 7 out-of-the-box iSCSI subsystem) ?

  • It's a great question and it was asked before: serverfault.com/questions/619904/… However, the answers seemed to be totally wrong to me. – batistuta09 Oct 2 '17 at 16:32
  • Is there any particular reason why are using one LUN per target instead of multiple LUNs per target? I would recommend you to create one more target on some other server (even on the same where initiator runs) and try to connect to it. If it works - it's definitely not the MSFT initiator issue. – Mind Parallax Oct 3 '17 at 13:45

Well, I've asked in the freebsd-stable@ mailing list, and after analysing the packet trace, here's what the developer of the FreeBSD Kernel iSCSI target told me:

Thanks for the packet trace. What happens there is that the Windows initiator logs in, requests Discovery ("SendTargets=All"), receives the list of targets, as expected, and then... sends "SendTargets=All" again, instead of logging off. This results in ctld(8) dropping the session. The initiator then starts the Discovery session again, but this time it only logs in and then out, without actually requesting the target list.

Perhaps you could work around this by using "discovery-filter", as documented in ctl.conf(5)?

I followed his advice, limited the discovery to only the targets that are accessible from the given initiator and the problem is gone.

So it seems to be some limitation in the MSFT iSCSi initiator, that is triggered on the discovery stage. Since the MSFT iSCSI Target has the limitation of 512 targets, its seems only understandable that the initiator starts to misbehave around the number of 573 targets.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.