Wandering Thoughts archives

Another problem with iSCSI on Solaris 10

In addition to my earlier issues, here's a significant problem I've run into with how Solaris does iSCSI: there's no good way to get Solaris 10 to re-probe an iSCSI connection, especially if something goes wrong (for example, Solaris loses its connection to a target for long enough to give up on it, which takes less time than you might think).

There is no explicit command to restart or re-probe a specific target connection, nor does it happen implicitly if you run devfsadm. This leaves doing it by side effect, of which there are four approaches:

• often you can make Solaris do this by redundantly enabling the already-enabled appropriate target discovery method (for example, 'iscsiadm modify discovery -s enable' if you're using static configuration). However, this hasn't always worked for me.

  (Under at least some circumstances this will also pick up new LUNs and removed LUNs on existing targets.)

• if you are using static configuration, you can iscsiadm remove the specific target and then iscsiadm add it back again. If you are using SendTarget or iSNS discovery and you get multiple targets from a single discovery address, you are out of luck, since removing the discovery address will log you out of all targets found through that address.

• you can disable and then enable the entire discovery method.
• you can throw up your hands and reboot the machine.

Reading between the lines of the iscsiadm manpage, the approach of redundantly re-enabling a discovery method is sort of documented. Of course, I don't really trust that documentation because it claims that disabling a discovery method has no effect on targets already discovered by that method, which is a blatant lie.

All of this leaves me rather unhappy about the state of iSCSI in Solaris 10, because in a SAN environment, good management tools should not be a badly documented afterthought, they should be a core feature.