Oct 202010
 

Well, my Ubuntu Server box running Lio-Target is still running great, and performing perfectly under the continous stress testing I’ve done.

While I’m waiting for a few more days of the stress test to finish, I’m setting up my old Soekris Net4801.

I’m install Ubuntu Server 10.04 TLS on to the Soekris Net4801 via remote PXE netboot. Afterwards I’m going to compile Lio-target 3.4 (kernel 2.6.34) on the device and test out performance of the iSCSI target. It won’t be anything special since the net4801 is so slow, but it’ll be interesting to see for sure.

I’ll also be sticking in a PCI – USB2.0 card inside of the net4801 to get USB2.0 speeds on a removal drive.

After this little experiment I might rip out the cross compiler and build Lio-Target on a Linksys WRT610N if I can to check out the performance on that. I know these little devices have quite a bit of power, gigabit networking, and a single USB 2.0 port built right in!

As promised I’ll be posting more detailed posts in the future once all the fun is done!

Oct 192010
 

So here’s the deelio…

Both Lio-target 3.2, 3.4, and 4.0rc always end up causing a CPU stall on CentOS within 6 hours of a single ESXi host using it. I could get it to bug out quicker while performing heavy usage.

Right now I’m testing it out on Ubuntu, it’s already looking more stable.

If anyone knows why it’s soo buggy on CentOS, PLEASE leave a comment, I’d really like to get it running.

Also had a bunch of problems compiling lio-utils both on CentOS and Ubuntu. If you use git, and install 3.0 it will install on CentOS, then u can install the newer version after. However installing the latest stable doesn’t work, comes up with a bunch of errors.

I’ll be posting another blog entry in regards to running Lio_Target on Ubuntu 10.10 within the week!

Update:

PLEASE VISIT http://www.stephenwagner.com/?p=300 for an updated tutorial on how to get Lio-Target running stable on CentOS 6!

Oct 082010
 

Just got my test network setup:

  1. HP Proliant ML350 G5 – Running ESXi
  2. HP Proliant DL360 G5 – Running ESXi
  3. HP Proliant DL360 G5 – Running ESXi
  4. Custom Intel Server – Running vSphere (management server)
  5. Super Micro Server – Running CentOS 5.5 with lio-target (iSCSI Target)
  6. 2 X HP MSA20 – Running Multiple Arrays/Targets connected to Super Micro Server

The HP servers are booting ESXi via USB keys. The Super Micro Server has one single internal drive for OS, and connected to multiple MSA20 arrays acting as iSCSI targets. The custom intel server is running the vSphere vCenter Management software.

I’ve Storage vMotion’ed multiple test VMs to the iSCSI arrays. Currently testing! Speed is AMAZING! And judging from the logs on the Super Micro Server, the iSCSI SCSI persistent reservations ARE being handled properly J

More to come, stay posted!

Update: After testing this for a few days, I noticed that although SCSI reservations were being handled properly (which is great), for some reason the kernel on the storage server would stall. Causing the storage system to crash. I’ve only been able to get it to do this, when two ESXi boxes are concurrently accessing the same datastore. I’ve been trying to re-replicate this in different circumstances (one ESXi initiator, using Windows to test the target, etc… but have been unable). I might test the 4.0 release candidate soon.

Oct 052010
 

PLEASE VISIT http://www.stephenwagner.com/?p=300 FOR AN UPDATED TUTORIAL.


Disclaimer: Please note that whenever doing any of the steps mentioned in this post, if you do not know what you are doing, you can render your linux install usless. Please do NOT use this in a production environment, and only use for testing. I’m not liable if you toast your linux install.

First and foremost, you need to know that from what I understand, the typical kernels that ship with CentOS have numerous patches, modifications, and updates from the typical Linux kernel releases. This is one reason why the releases of the kernels are always behind compared to ones that are actively being developed. I could be wrong, but I think the Redhat kernel patches are applied to CentOS kernels.

This tutorial will walk you through on how to get you up and running in the dirtiest and quickest method. You may and probably will have to modify things, re-compile, etc… to resolve any issues you may run in to.

I wrote this article only to help more people get up and running with one of the only open-source Linux iSCSI targets that has been certified by VMware (Certified when running on certain appliances) to be used in a vSphere environment (supports Vmotion, SCSI reservations, etc…)

I’m going to assume you have CentOS 5.5 installed and is fully up to date.

Anyways, here’s a breakdown of what we will be doing to get Lio-Target to run on CentOS:

  • Download lio-target modified kernel
  • Download lio-utils
  • Compile a modified kernel using existing kernel .config file
  • Compile and install lio-utils
  • Sample commands to setup a dedicated drive on your system as a iSCSI target (to test)
  • Compose two quick and dirty config files so lio-target can run

Download the lio-target modified kernel

For this step, you will need to have git installed. From what I understand git is not an option during the CentOS install, and cannot be installed using the default typical yum repos. To get git installed, we will first add the “RPMFusion” and “EPEL” yum repos.

(Info on how to install these can be found at http://rpmfusion.org/ and https://fedoraproject.org/wiki/EPEL)

Once you have installed these, it’s time to install git. This can be easily done by typing:

yum install git

After git is installed, it’s now time to download the lio-target kernel.

Type in:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core-2.6.git lio-core-2.6.git

It is now downloading the source. After this is complete, change directory to the new directory that was created, and type in:

git checkout origin/lio-3.4

You now have the source.

Download lio-utils

This is a pretty simple step. If you just completed the step above, make sure you cd back in to a directory that you can use as a workspace, and make sure you do NOT do this, inside of the directory that was downloaded above. Type in:

git clone git://git.kernel.org/pub/scm/linux/storage/lio/lio-utils.git lio-utils.git

This should create a directory called “lio-utils.git”. This step is done.

At this point

You should have two directories inside of your workspace:

lio-core-2.6.git

lio-utils.git

Compile a modified kernel using existing kernel .config file

It is now time to build a kernel. First of all, issue a uname –a and note the kernel you are running. In my case it’s “2.6.18-194.17.1.el5″. I’m going to take a config file from the boot directory that matches the number, and copy it to the lio-core-2.6.git directory, only change the name to “.config”. This is what I would type in on my end:

cp /boot/config-2.6.18-194.17.1.el5 /root/lio-core-2.6.git/.config

This command above would copy the config for the CentOS kernel, and move it to the lio-core-2.6.git directory with the new name of “.config”. Now change into the lio-core-2.6.git directory:

cd lio-core-2.6.git

At this point we are going to run a command to help the config adjust to the newer kernel version. Type in:

make oldconfig

This will spawn numerous messages. You can just go ahead and keep hitting enter. It will seem like an endless loop, however eventually it will complete. Now the next step, this is important. By default, new kernels use a different sysfs structure. We need to turn on the depreciated item that CentOS uses. Type in:

make menuconfig

Navigate to:

“General Setup”, then check (put a star in the box) for “enable deprecated sysfs features to support old userspace tools”.

Now hit tab to select exit. Once again tab to exit at the main menu. We are now ready to compile! To do a quick compile, type in:

make && make modules && make modules_install && make install

Feel free to disapeer for a while. This will take some time depending on the performance of your system. Once done, you now have a kernel with lio-target built in that is compiled and installed.

Keep in mind that this is NOT the default kernel, and you will have to select this to boot when starting your system. To change this, modify /etc/grub.conf and change the default value to whichever item it is (remember that the first item is 0, and not 1).

Let’s boot the new kernel. Safely shut down your linux box, reboot, and when grub shows up, boot using the new kernel you compiled.

Please note: This guide is a quick and dirty way to get this up and running. Since we skipped customizing the kernel, the kernel you compiled will no doubt come up with errors on boot. I simply ignore this. You can too, just to get this up and running. You can come back at a later time and refine your custom kernel to be used.

Compile and install lio-utils

This is simple. Change directory to the directory where you downloaded lio-utils.

cd /root/lio-utils.git

And to compile and install:

make

make install

And BAM, you’re done, that was easy!

Sample commands to setup a dedicated drive on your system as a iSCSI target (to test)

It’s show time. I’m still fairly new to the configuration and usage of lio-target, so I’m just posting the commands to get it working on a dedicated disk. There are no manual (man page) entries installed by lio-utils, so you will need to use lio_node –help and tcm_node –help for more information on proper usage.

Keep in mind, DO NOT use your linux disk as a iSCSI target! Let’s pertend we have a second disk in the system /dev/sdb that we want to turn in to a target. This is what we would type:

tcm_node –block iblock_0/array /dev/sdb

/etc/init.d/target start

lio_node –addlun iqn.2010.com.stephenwagner.iscsi:array 1 0 iscsi00 iblock_0/array

lio_node –listendpoints

lio_node –addnp iqn.2010.com.stephenwagner.iscsi:array 1 192.168.0.10:3260

lio_node –listendpoints

lio_node –disableauth iqn.2010.com.stephenwagner.iscsi:array 1

lio_node –addlunacl iqn.2010.com.stephenwagner.iscsi:array 1 iqn.CLIENTINITIATORHERE.com 0 0

lio_node –enabletpg iqn.2010.com.stephenwagner.iscsi:array 1

The above will create a target, and discovery portal for /dev/sdb on 192.168.0.10. This will also disable CHAP authentication, and will allow the initator I specified above to connect.

Please change /dev/sdb to the drive you want to use

Please change iqn.2010.com.stephenwagner.iscsi:array to the iSCSI target you want to call yours.

Please change 192.168.0.10 to the IP of the iSCSI target your configuring. Leave port as 3260.

Please change iqn.CLIENTINITIATORHERE.com to the iqn for your initiator (client). This will be set on the client you are using to connect to the iSCSI target.

BAM, your target is up and running! Keep in mind, this configuration is lost upon reboot.

Compose two quick and dirty config files so lio-target can run

Here’s what you need to put in the config files to make the above config work on boot:

/etc/target/tcm_start.sh should contain:

tcm_node –block iblock_0/array /dev/sdb

/etc/target/lio_start.sh should contain:

lio_node –addlun iqn.2010.com.stephenwagner.iscsi:array 1 0 iscsi00 iblock_0/array

lio_node –addnp iqn.2010.com.stephenwagner.iscsi:array 1 192.168.0.10:3260

lio_node –disableauth iqn.2010.com.stephenwagner.iscsi:array 1

lio_node –addlunacl iqn.2010.com.stephenwagner.iscsi:array 1 iqn.1991-05.com.CLIENTINITATOR.com 0 0

lio_node –enabletpg iqn.2010.com.stephenwagner.iscsi:array 1

After you make these config files. You should be able to start lio-target in a running state, by issuing:

/etc/init.d/target start

And remember, that you can always view a live feed of what’s going on by issuing:

tail –f /var/log/messages

Hope this helps!

Oct 042010
 

For the first time I decided to test compability of non-hp branded drives inside of the HP MSA20 array.

First I installed a 500GB SATA2 Seagate drive I had laying around. It detected it perfectly and is working.

The ACU on CentOS 5.5 shows as follows:

Logical Drive
Status    OK
Drive Number    1
Drive Unique ID    XXXXXXXXXXXXXXXXXXXXXXXXXXX
Size    476908 MB
Fault Tolerance    RAID 0
Heads    255
Sectors/Track    32
Cylinders    65535
Strip Size    128 KB
Array Accelerator    Enabled
Disk Name    /dev/cciss/c0d0

I also just populated another bay with a Seagate 2TB SATA2 drive I just found, and it works aswell. ACU reports as follows:

Physical Drive
Status    OK
Drive Configuration Type    Unassigned
Size    2000.3 GB
Drive Type    SATA
Model    Seagate ST32000542AS
Serial Number    XXXXXXXX
Firmware Version    CC34

Keep in mind that no matter what size of drive you have, there is a 32-bit SCSI LUN limitation of under 2TB (I don’t know exactly what it is). Although you can create large arrays, your logical drives will not be able to go over this limitation.

Oct 032010
 

I’ve been messing around with this one old array that has a slew of problems for some time now.

One thing I just figured out today, if you have an MSA20 and even though all the drives have a green light and are NOT marked as failed, the drives still can be in very bad shape.

Example: I have 5 X 250GB SATA drives, and EACH of the 5 drives had failed. The MSA20 said the drives were good, however multiple I/O errors were showing up on the kernel logs on a CentOS 5 install. Taking the drives out and testing them on a different system and NOT using the MSA20 shows that the drives are physically dead. Furthermore, popped in some random 500GB SATA drive I had sitting around in to the MSA20, and now the MSA20 works beautifully!