== Some notes on Solaris 10 U4 x86 as an iSCSI target
The latest release of Solaris 10 (S10U4 or 8/07 depending on how you
like to label it) has a built in iSCSI target implementation, and ZFS
even has integration with it so that it is easy to export space from
ZFS pools. I've been poking it a bit, resulting in some things I want
to note down for my own later reference.
* Solaris 10 iSCSI target stuff is handled with the _iscsitadm_ command,
which is helpfully only one letter away from the _iscsiadm_ command
to administer [[Solaris iSCSI initiator settings SolarisiSCSI]]. The
two commands are very similar and take options in the same way, except
when they pick different vocabulary for the same command; _iscsiadm_
uses 'add' and 'remove', but _iscsitadm_ uses 'create' and 'delete'.
(It is possible that this difference is deliberate, in order to
prevent accidentally doing an operation with the wrong program.
The fly in the ointment is that the command options are generally
completely different, so I'm pretty sure that the attempted
operation would fail anyways.)
* the very first thing you need to do is use _iscsitadm modify
admin -d ~~
~~_ to tell the iSCSI target stuff where to store
state information, like what targets you've defined. If you do
not do this, nothing will complain, but (among other things) all
of the targets you've carefully manually defined will disappear
when you reboot.
(I think ZFS targets created with the _shareiscsi_ ZFS property
might still persist.)
* in targets with multiple LUNs, you should make LUN 0 (the first
one created) be a little dummy LUN that never actually gets used
(a few megabytes of backing file will do). This is because you
cannot modify LUNs except by deleting and recreating them, and
you cannot delete LUN 0 unless there's no other LUN.
* setting the ZFS _shareiscsi_ property creates a separate iSCSI target
for every shared ZVOL, even if they're inheriting the property from a
filesystem. If you need to bundle things into multiple LUNs on the
same target, you will need to do things by hand.
* there seems to be no way to manually set the iSCSI name of a target
when you create it. This seems unfortunate and limiting, since
there are a number of situations where you need to set the iSCSI
name to something specific.
* _iscsitgtd_ periodically dumps core in _/_, sometimes with
multi-gigabyte core files that will fill up your root filesystem
(I have seen it dump over a 5 gigabyte core file).
In general iscsitadm seems biased towards creating a new iSCSI target
for every separate bit of target storage that you have. If you are using
one of the dynamic discovery methods on your iSCSI initiators this is
not too bad, but it is going to be horrible if you're using a static
configuration; for static configurations you really want LUNs within a
single iSCSI target.