Connect to a iSCSI Target with Ubuntu

Install Open-iSCSI Initiator

Type the following command at a shell prompt:

sudo apt-get install open-iscsi

Open-iSCSI default configuration

Default configuration file could be located at /etc/iscsi/iscsid.conf or ~/.iscsid.conf. Open /etc/iscsi/iscsid.conf file:

vi /etc/iscsi/iscsid.conf

Set node.session.auth.username, node.session.auth.password and other parameter as follows:

node.startup = automatic
node.session.auth.username = MY-ISCSI-USER
node.session.auth.password = MY-ISCSI-PASSWORD
discovery.sendtargets.auth.username = MY-ISCSI-USER
discovery.sendtargets.auth.password = MY-ISCSI-PASSWORD
node.session.timeo.replacement_timeout = 120
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.noop_out_interval = 10
node.conn[0].timeo.noop_out_timeout = 15
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.conn[0].iscsi.MaxRecvDataSegmentLength = 65536

Save and close the file. Restart open-iscsi service:

/etc/init.d/open-iscsi restart

Now you need to run a discovery against the iscsi target host:

iscsiadm -m discovery -t sendtargets -p ISCSI-SERVER-IP-ADDRESS

Note down the record id (such as found by the discovery. You need the same for login. Login, must use a node record id found by the discovery:

iscsiadm –mode node –targetname –portal –login

Finally restart the service again:

/etc/init.d/open-iscsi restart

This is why Thin Provisioning s*cks

The answer lies in the SCSI protocol.  As you know, our SAN is just a really big SCSI drive, for all that the server knows. It doesn’t know that the SAN is off on the network, and that the iSCSI initiator intercepts commands to/from the OS and redirects them over to us.
Unfortunately, the is no ‘delete’ command in the SCSI protocol. The server changes the File Table on one of the blocks of storage we’ve set aside for it the blocks it no longer needs, effectively deleting the data. But it never actually sends us a command ‘delete block 346135.’
Since we’re block storage, we are agnostic to the data stored on our blocks of disk space. The volume could be NTFS, or VMDK, we don’t know. So we dutifully mark any used blocks as dirty, and that’s how they stay, until the volume is deleted, or the server again writes over that block.
The server has the file table. So it knows where the blocks are, and which are used or not. When it reports that only 25GB of the 100GB volume are in use, you can believe it. When we say that 75GB of the 100GB are dirty, then you can believe us that at some point in time, data was written to all 75GB of space.
If you need to recover some of that space, then you will need to move the data off, delete the volume, and create a new, smaller volume. It’s the only way to recover dirty, yet un-used, space.

Source :

iSCSI and VMWare Tips

I found a great article named

A “Multivendor Post” to help our mutual iSCSI customers using VMware

You really should read it if your using a SAN in combination with ESX 3.5