I-Space Research Labs

ISCSI diskless workstations

by on Oct.29, 2010, under ISCSI, Tech Stuff

Wow, been a long time since I posted on here, and looking at the previous post… I had just gotten promoted and I was full of optimism that was going to Change the World. Well, eventually reality has its way of rudely awakening people, and gosh… well at least I’m back doing what I do best, which is building and fixing things.

So what have I been cooking up lately? Diskless ISCSI workstations. A PC without a hard drive installed internally, but still has a block device for storage because it has an ISCSI drive mounted across the network. After a few false starts, it’s surprisingly easy to do with any RedHat 5.1 or later.

ISCSI boot has been mainline in RHEL since 5.1, meaning that you don’t need to make a custom initrd with the ISCSI modules in it, since RedHat has already done it. I haven’t done with this Fedora yet, but I’m going to assume that Fedora has this capability as well.

The first thing we need to do is set up an ISCSI server. In an ideal environment, we would use a SAN that either has an ISCSI gateway attached to it, or a server attached by Fibre Channel that can serve out the disk. In a not-so-ideal environment, like the one I’m using to evaluate this setup, I’m just sharing out one of the extra hard disks in the server that I’m using. Install scsi-target-utils and iscsi-initiator-utils and we’re already almost done.

Now we need to make a block device to share out. We can either share out a raw block device or an LVM. LVM has many advantages like snapshotting, so let’s carve out a 50Gb LVM:

lvcreate -L 50G -name iscsiworkstation /dev/vg-iscsi

We now have /dev/vg-iscsi/iscsiworkstation, and we need to set up the ISCSI daemon to share it out. The ISCSI daemon is called tgtd, and its config file is at /etc/tgtd/targets.conf.

<target iqn.2010-10.net.isrlabs.iscsiserver:lun1>
backing-store /dev/vg-iscsi/iscsiworkstation

This is the simplest setup we can make. This will share out the LVM to any IP addresses. One thing to note here is the IQN- it is the target name. You really could put anything here, but there is a naming convention that everyone is supposed to use. You would want to use a different IQN for each target that you’re setting up. If I wanted to share out another LUN, maybe to a different workstation, I’d want to set make a new IQN for that. I’d likely change :lun1 to :lun2, so it’s unique but I can still tell what’s going on.

Now, about ACLs, because I screwed this up once and the second workstation I kicked overwrote the first worstation’s LUN because I didn’t mask it off properly. You can mask off your LUNS to only one IP address (or multiple), and use CHAP to authenticate the client and/or server. CHAP’s not great but it’s better than nothing, and useful if you’re bouncing around various IP addresses and still need to make sure that you’re the only one that can access the share. We can mask off LUNs by using the initiator-address directive inside the target stanza. Here’s how we can tie it all together:

<target iqn.2010-10.net.isrlabs.iscsiserver:lun1>
backing-store /dev/vg-iscsi/workstation1
<target iqn.2010-10.net.isrlabs.iscsiserver:lun2>
backing-store /dev/vg-iscsi/workstation2

Now we’re getting a little more advanced, but this is how we can share out multiple LUNs, and make it so each workstation can see only its own disk. Also, make sure you spell “initiator-address” correctly. If you don’t, tgtd will silently ignore that line, and the ACL will default to ALL. Suddenly, your workstation’s LUN is being overwritten by that new one you just kickstarted.

Start up the tgtd daemon. You will also need TCP3260 open if you’re using iptables or any kind of network filtering (firewall).

Now on to the workstation. I normally use a prebuilt kickstart file either from Spacewalk/Satellite server or a handcrafted one. One of the gotchas you need to look out for is that the ISCSI stuff needs to be BEFORE any disk commands. If you zerombr, wipe partitions, all that jazz, the ISCSIĀ  info needs to be before this. It makes sense, the system needs to know about the disks before it can do anything with them. If you already have a nice kickstart file, then all you need to do is add two lines near the beginning, before any of the disk stuff:

iscsiname <pick a name>
iscsi –ipaddr=<ip address of iscsi server> –port 3260

Through trial and error, and at least with RedHat, you do need to specify the port. Kickstart normally, and it should work. If you’re using Satellite Server to build your kickstarts, it puts the ISCSI stuff in the wrong place and will fail after it tries to find disk. I usually manually export the kickstart file and point the system at that. I don’t know if Spacewalk has the same problem, or even if RedHat has fixed this in more recent versions of Satellite, but it’s something to watch out for.

If you’re going to do it from the linux installer command line, let’s assume that you’re going to install via HTTP:

linux ks=http://my.webserver/myRPMdir iscsiname <something> iscsi –ipaddr=<address of iscsi server> –port=3260 ip=<workstation ip> netmask=<mask> gateway=<gateway> dns=<dns ip>

Of course, if you have a .ks file, you can point the URL at that instead.

The workstation should boot and install normally. The trick is after the kickstart is done, you need to copy the kernel and RAMdisk to your tftp server so when the workstation PXE boots, it can download and install those and continue to boot normally. You did know that you need to set up DHCP, TFTPD and the PXE boot environment, right?

:, ,

Leave a Reply

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...


All entries, chronologically...