== Another problem with iSCSI on Solaris 10

In addition to my [[earlier issues SolarisiSCSI]], 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.