mensi.ch

When open-iscsi automatically logs into different targets, the resulting sdX device nodes get created depending on the order of the successful logins. Variances in network latency result in inconsistent target to device mappings. However, you can use udev do create consistent symlinks.

Create a new rules file: rules.d/55-iscsi.rules

KERNEL=="sd*", BUS=="scsi", PROGRAM="/etc/udev/scripts/iscsidev.sh %b",SYMLINK+="iscsi/%c/part%n"


And the corresponding shell script: /etc/udev/scripts/iscsidev.sh

#!/bin/sh
BUS=${1}
HOST=${BUS%%:*}
[ -e /sys/class/iscsi_host ] || exit 1
file="/sys/class/iscsi_host/host${HOST}/device/session*/iscsi_session/session*/targetname"
target_name=$(cat ${file})
# This is not an open-scsi drive
if [ -z "${target_name}" ]; then
exit 1
fi
target_name=`echo "${target_name}" | sed -r -e 's/^.*:(.*)$/\1/'`
echo "${target_name}"

If your targets are named with the scheme iqn.YYYY-MM.DOMAIN:IDENTIFIER, the rule and script will create a symlink in /dev/iscsi/IDENTIFIER/part for the corresponding /dev/sdX entry and /dev/iscsi/IDENTIFIER/partY for /dev/sdXY. This has been tested on Debian Lenny with open-iscsi.

An easy and simple way to manage VMs with Xen is to let linux boot off NFS, so you can serve these filesystems off a central storage machine and still have access to the complete directory hierarchy, enabling you to do fancy stuff like incremental backups. Sure, NFS is not the best way to do this, but in a low budget situation or with older hardware, this solution works quite well.

Creating a DomU for use with NFS isn’t such a hard thing, there are several possible pitfalls though. Here is a step-by-step guide:

Create empty directory on the NFS server and export it with no_root_squash for the VM itself and the xenhost or the host you want to use to bootstrap the VM

/some/dir/www.example.org www.example.org(rw,no_root_squash,no_subtree_check)
/some/dir/www.example.org xen.example.org(rw,no_root_squash,no_subtree_check)


Don’t forget to reload NFS exports

exportfs -r


Mount it on the xenhost (or the host you’re using for bootstrapping)

mkdir /tmp/www.example.org
mount -t nfs xen.example.org:/some/dir/www.example.org /tmp/www.example.org


Use debootstrap to bootstrap an initial Debian lenny install

debootstrap lenny /tmp/www.example.org/ http://mirror.switch.ch/ftp/mirror/debian


We need to do some extra things inside the VM before we can actually boot it up, so we chroot into it

chroot /tmp/www.example.org


Correctly set the hostname

echo "www" > /etc/hostname


And the hostsfile, at least localhost is required

echo "127.0.0.1 localhost" > /etc/hosts


Add and configure the loopback interface

echo "auto lo" > /etc/network/interfaces
echo "iface lo inet loopback" >> /etc/network/interfaces


Add all desired sources to /etc/apt/sources.list

nano /etc/apt/sources.list


Install the bigmem kernel for your architecture. If you do not want to do this because you already have a kernel and an initrd, at least install udev.

apt-get install linux-image-2.6-686-bigmem


Install locales to get rid of warnings regarding LC_*

apt-get install locales
dpkg-reconfigure locales


Adjust initramfs for NFS support (set BOOT=nfs instead of local)

nano /etc/initramfs-tools/initramfs.conf


Add the xen frontend drivers to the initramdisk (add xen-netfront and xen-blkfront)

nano /etc/initramfs-tools/modules


Regenerate initramdisk

update-initramfs -u all


Spawn a console on hvc0 (add the following to /etc/inittab)

0:2345:respawn:/sbin/getty 38400 hvc0


Leave chroot

[Control-D]


Copy the kernel and initramdisk to some location on the xenhost

cp /tmp/www.example.org/boot/* /vmkernel/


To be able to use NFS properly be sure to:

• DO NOT add the root to /etc/fstab as this will cause problems with the checkroot rcS script
• Add ASYNCMOUNTNFS=no to /etc/default/rcS to be able to mount additional nfs shares

I recently updated a Debian etch machine with its root filesystem on an NFS share to lenny, which broke things a bit: During init, the filesystem somehow got remounted read-only and errors involving statd not being running occured. Additionally, other NFS mounts from /etc/fstab failed to mount at startup (but manually mounting them later worked)

I tracked down to first problem to checkroot.sh, which executes fsck if needed. Altough checkroot specifically checks for NFS being used for the root filesystem, it still tries to remount it which fails due to statd not running. This can be avoided by not adding the root filesystem to /etc/fstab so checkroot.sh will not try to do anything on it. This may be a slightly ugly workaround, but it seems to work fine.

The second problem can be worked around by setting ASYNCMOUNTNFS=no in /etc/default/rcS. I did not dive into the internals here, so I do not know the root problem causing this.

Apparently Debian decided to build libldap with GnuTLS instead of OpenSSL in Debian lenny, which can cause a lot of problems connecting to ldaps servers. Rebuilding the library with OpenSSL instead of GnuTLS fixed the problems for me.

Building the library by yourself is quite simple:

$ apt-get install dpkg-dev build-essential fakeroot debhelper libdb4.2-dev libgcrypt-dev unixodbc-dev libncurses5-dev libperl-dev libsasl2-dev libslp-dev libltdl3-dev libwrap0-dev debconf-utils po-debconf quilt autotools-dev libtool automake autoconf time libgnutls-dev libssl-dev
$ apt-get source libldap-2.4-2
$ cd openldap-2.4.11/


edit debian/configure-options to use OpenSSL instead of GnuTLS and then run the build. Make sure your loopback interface is configured and up and you have defined localhost in your /etc/hosts as the testsuite will fail othwerwise.

$ dpkg-buildpackage -rfakeroot -uc -us


You then should have a deb package with libldap build against OpenSSL.

If you do not want to rebuild libldap by yourself, feel free to use mine:

• debian lenny i386: libldap-2.4-2_2.4.11-1_i386.deb (md5: a5e37eb924b832192caa6312f21d7139)
• ubuntu hardy amd64: libldap-2.4-2_2.4.9-0ubuntu0.8.04.3_amd64.deb (md5: 49ccd6d71079102df6d91279b38eae1c)