Core to Scale iSCSI failure

[m3ds0]

Hi mates,

In my old Core configuration, the iSCSI has 6 portals which they listen to different TCP ports, after upgrading to Scale it seems the daemon is changed to scst and you cant listen to as many as you want listening ports and assign to portals which drives iscsi service to stopped state and not gonna start.

Does anybody experienced this problem or s there any solutions to fix the issue?

 

[HoneyBadger]

Hello @m3ds0

I can confirm that this workflow (different TCP listen ports on the same IP) doesn't seem to have been included in the SCALE UI right now - I don't have any more details or a quick solution right now, but wanted to let you know that I've communicated this back to Engineering.

Are you able to boot your TrueNAS system to a previous boot environment (through System Settings -> Boot and using the 3-dot menu to Activate a CORE environment?

 

[m3ds0]

Hello @m3ds0

I can confirm that this workflow (different TCP listen ports on the same IP) doesn't seem to have been included in the SCALE UI right now - I don't have any more details or a quick solution right now, but wanted to let you know that I've communicated this back to Engineering.

Are you able to boot your TrueNAS system to a previous boot environment (through System Settings -> Boot and using the 3-dot menu to Activate a CORE environment?

Thanks for your reply, actually the daemon configuration file and document seems scst doese not support multi ports listening on same IP.
BTW, right now I've rolled back to the CORE cause my backup is on these portals and i'll waiting to hear good the news.

 

[HoneyBadger]

Thanks for your reply, actually the daemon configuration file and document seems scst doese not support multi ports listening on same IP.
BTW, right now I've rolled back to the CORE cause my backup is on these portals and i'll waiting to hear good the news.

Glad that things are back in operation. It seems like it's presently a limitation of the iscst-scstd daemon that it can only listen on one port at a time - that one port can be changed, but that doesn't fit for your use case.

If this is being used for authentication/segmentation of LUNs, would you be able to migrate to a configuration using access/auth groups instead, and divide the extents that way?

 

[m3ds0]

Glad that things are back in operation. It seems like it's presently a limitation of the iscst-scstd daemon that it can only listen on one port at a time - that one port can be changed, but that doesn't fit for your use case.

If this is being used for authentication/segmentation of LUNs, would you be able to migrate to a configuration using access/auth groups instead, and divide the extents that way?

The point is lots of people like me may have scenarios like i told. Right now it's about 20 or more portals in my env which it takes time to migrate.
if i know the roadmap of the development team in this area i'll have good vision to decide to change the configuration or not. (Meant they gonna keep this daemon and maybe develop some features to scstd or not they will change the entire solution!)

Regards