Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
sanboot:ubuntu_iscsi [2010/01/20 04:05] gruffi |
sanboot:ubuntu_iscsi [2010/08/16 20:55] (current) cinquero |
||
|---|---|---|---|
| Line 199: | Line 199: | ||
| ===== FIXME: Notes from contributors ===== | ===== FIXME: Notes from contributors ===== | ||
| + | ==== Ubuntu 10.04 LTS / Lucid ==== | ||
| + | |||
| + | Disclaimer: use everything in this section at your own risk! Think for yourself. | ||
| + | |||
| + | With Lucid, it is basically the same as described above, except for: | ||
| + | |||
| + | * copying early_udev and bugfixing scripts is not necessary | ||
| + | * make sure the OS image contains its target definition under /etc/iscsi/nodes/... -- otherwise iscsid start will kill the connection upon boot. You get that target definition by mounting the iscsi target. iscsiadm seems to be creating it. | ||
| + | * use sysv-rc-conf to remove "networking" and "open-iscsi" from *all* run levels. | ||
| + | * make sure that *all* open-iscsi sysv links are gone. My experience shows that using sysv-rc-conf is *not* enough: | ||
| + | <code> | ||
| + | find /etc -name 'K*open-iscsi' | ||
| + | find /etc -name 'S*open-iscsi' | ||
| + | </code> | ||
| + | * One possibly has to repeat the previous step when upgrading/reinstalling open-iscsi. | ||
| + | * create /etc/init/open-iscsi.conf: | ||
| + | <code> | ||
| + | description "Open-iSCSI" | ||
| + | |||
| + | start on filesystem | ||
| + | # no stopping! | ||
| + | exec /etc/init.d/open-iscsi start | ||
| + | </code> | ||
| + | * Lucid detects on its own if rootfs is an iscsi target. It will prevent network shutdown on shutdown and read-only remounting of the rootfs should make sure that data gets flushed to disk. | ||
| + | * For your own convenience, edit the following line in /etc/default/grub as shown below: | ||
| + | <code> | ||
| + | GRUB_CMDLINE_LINUX_DEFAULT="ip=dhcp ISCSI_INITIATOR=<yourInitiatorName> ISCSI_TARGET_NAME=<yourTargetName> ISCSI_TARGET_IP=<yourTargetIp> ISCSI_TARGET_PORT=3260 quiet splash" | ||
| + | </code> | ||
| + | |||
| + | === Stabilization/Paranoia/Warnings === | ||
| + | |||
| + | in order to prevent data loss (for example, a corrupted dpkg db), one may do the following stuff: | ||
| + | |||
| + | * Enable data journaling. That will cut your maximum write performance in half. | ||
| + | * One may increase node.session.timeo.replacement_timeout in iscsid.conf to avoid escalation of temporary connection problems to upper layers. In *my* situation it (almost) *never* makes sense to tell the ext4 driver about I/O problems because there is no fallback. It would just give me an unclean filesystem (not unmounted properly, like a hard reset). However(!!), an unclean filesystem may be better than a totally screwed one: imagine your iSCSI target host crashes, looses some data that still has not been written to disk, and the client continues to use that target without doing a journal replay first... personally, I try to avoid that situation by never starting the iSCSI target automatically (removed from init scripts, starting it manually after killing the client machines...). IMHO the iSCSI protocol is a bit dumb. The target should detect a crash and refuse session continuation after restart... again, I'm not liable for *any* sort of data loss if you act according to these explanations. You *will* screw your data. Sooner or later. | ||
| + | * Additional warning: SAN boot using gpxe seems to not allow using a MaxSessions=1/MaxConnections=1 setting for the target, which would prevent concurrent accesses -- a very basic need for data integrity purposes. | ||
