QNAP iSCSI with (snow) Leopard and global SAN

Posted on September 15, 2009 by
At the office we picked up a¬†QNAP TS-809 Pro Turbo, and loaded it with 8 1.5T drives. The QNAP is an interesting, if a little pricey device. Essentially it’s a mini-itx core 2 duo MB with 2 Gig-Es, some usb’s and lots of sata ports. 8 of which are in nice little hot-swap trays. In general the unit is well built and well thought out. It runs Linux and they don’t try to hide it, giving you shell access and even maintaining info on how to add additional ports.
The iSCSI implementation is ietd, and they’ve made some modifications to the configuration components so that it integrates well into their environment. Unfortunately there is one anomaly which some other linux iscsi (ietd based) setups share. And this anomaly prevents the Global SAN iSCSI initiator (and the ATTO one) on OSX from being able to use an iSCSI device if there is >1 iSCSI device being shared from the QNAP.
Our intended use for the QNAP was TimeMachine. At least for some of us the plan was to export 1T or so via and iSCSI device, map it to our desktop and let TM run as it sees fit.
The first machine worked, well, but when we tried to add my machine, it would connect, but the device would not appear in DiskUtility. I could, however, attach to the device used by the first machine successfully.
After much trial and error and googling, we discovered the issue. The devices were being exported with different LUN numbers. It was following this pattern:
Device 0 – LUN 0
Device 1 – LUN 1
Device 2 – LUN 2
Both initiators expected something to be at LUN 0, which makes sense, and the spec is a bit vague. It seems as though the Solaris initiator will scan all the LUNs, perhaps the windows one does as well.
This seemed like an easy fix, and wasn’t really too difficult, but there is no documentation on the startup scripts on the QNAP, so perhaps this will save you some time.
First, here’s what to change to fix it, at least with¬†Version 2.1.4 build 0317T of the QNAP software.
move /sbin/ietadm to /sbin/ietadm.bak
create /sbin/ietadm with the following content:
x=echo $* | sed ‘s/–lun=[0-9]\+\b/–lun=0/’
/sbin/ietadm.bak $x
be sure to chmod the new /sbin/ietadm to mode 755, you will also want to make a copy of this script, and store it somewhere, if you update your QNAP software, it may overwrite these changes. If/when that happens be sure to re-move /sbin/ietadm so you get the newest version.
For those that want to know what is going on here, I’ll give you a quick run-down. ietadm is the (semi) standard control command for the (ietd) iSCSI target that QNAP is using. We verified that the LUNs were set to different values by cating /proc/net/iet/volume. Then we started looking for config files, /mnt/HDA_ROOT/.config/iscsi.conf contains a config file, but it is not any real standard format, and it appears as though it is consulted for very little, so that was a dead end. We then looked for startup/shutdown scripts and found and iSCSItrgt one. It ran a few instances of a QNAP proprietary command (or so we think) called getcfg which looked to pull some globals out of various files. Then it launched ietd and ran something called iscsiutil. That was a binary that called /sbin/ietadm with various parameters. This looked to be another QNAP only command, and we had no way to edit it. A google of ietadm told us that it was used to do pretty much everything, and was a ‘stock’ command. We replaced /sbin/ietadm with a simple script that dumped its args to a file, and added a new Target. This showed us that it was, as we had guessed, adding devices with –lun=0, –lun=1, etc. We then tested manually editing those commands and changing the –lun= args to all = 0….voila, we could use multiple targets. So we then crafted the above script to replace all the –lun= directives with –lun=0.


This entry was posted in Uncategorized

Leave a Reply