Differences

This shows you the differences between two versions of the page.

Link to this comparison view

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]
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.

QR Code
QR Code sanboot:ubuntu_iscsi (generated for current page)