iSCSI discovery issue - no targets found

[java_cat33]

Hi - I have sucessfully implemented OpenFiler (OF) and have enabled the iSCSI service.

ESX Server - 3.5

The OF server has just been rebuilt - the lun names are different - ESX was connected to the old luns (this was not removed from ESX before having to be rebuilt).

The iSCSI client is also allowed through the firewall of the ESX server.

I have created two luns within OF - and have created two networks within OF that are allowed access to the iSCSI storage. The two networks that are allowed access to this storage is the ESX vmkernel network and the ESX Service Console network. The iSCSI storage interface is bonded on 4 nics - this address can be pinged from the ESX server service console.

I read a post on an OF forum indicating if you have more than one iSCSI target within OF - you must edit the ietd.conf file on the OF box as both luns will have the same lun id - this was the case - both of my luns were numbered lun 0 - now one of them is lun 0, the other lun 1. Here is the post....

I have also followed the steps as posted on Oreeh's thread....

http://communities.vmware.com/thread/70908#

Most the steps were relevant to me..... I had old traces of the previous iSCSI lun before I rebuilt OF - these have now been deleted from /var/lib/iscsi/vmkbindings as per the steps indicated in the above post of Oreeh's.

I have the CHAP authentication configured correctly within the iSCSI software initiator with ESX - the username and password is identical to what is setup on OF.

It was mentioned in Oreeh's thread to try renaming the iSCSI LUN iqn and alias in the ietd.conf file so that ESX thinks its completely different - I can't find this file

Below is some of the logs from the vmkernel....

Feb 16 15:18:32 tstesx10 vmkernel: 0:02:26:31.811 cpu2:1036)iSCSI: no LUNs detected for session 0xb603f90 to iqn.2006-01.com.openfiler:esx_iscsi.iscsi_templates

Feb 16 15:18:36 tstesx10 vmkernel: 0:02:26:35.770 cpu1:1037)iSCSI: no LUNs detected for session 0xb619a00 to iqn.2006-01.com.openfiler:esx_iscsi.iscsi_vms

Feb 16 15:18:37 tstesx10 vmkernel: 0:02:26:36.675 cpu1:1035)SCSI: 861: GetInfo for adapter vmhba32, , max_vports=0, vports_inuse=0, linktype=0, state=0, failreason=0, rv=-1, sts=bad001f

Feb 16 15:18:37 tstesx10 vmkernel: 0:02:26:36.680 cpu2:1036)SCSI: 861: GetInfo for adapter vmhba32, , max_vports=0, vports_inuse=0, linktype=0, state=0, failreason=0, rv=-1, sts=bad001f

Feb 16 15:18:37 tstesx10 vmkernel: 0:02:26:36.689 cpu1:1037)SCSI: 861: GetInfo for adapter vmhba32, , max_vports=0, vports_inuse=0, linktype=0, state=0, failreason=0, rv=-1, sts=bad001f

Does anyone know what's going on here?

Oh yeah - one other thing - within OF - It shows the two iqn sessions from ESX - each identifier is unique for each lun.

[DArndt]

One thing that caused me problems, was that under the openfiler admin for the volume in the iSCSI CHAP authentication if I filled in both incomming and outgoing user I couldn't get the discovery to work. After removing the outgoing user authentication and leaving the incomming username and password, I was finally able to discover the LUN's and connect to them.

Not sure if that is your issue but it fixed discovery for me.

Dave

[java_cat33]

Thanks Dave. I have tried that also..... actually at the moment I have disabled CHAP from within ESX and turned off authentication against the iSCSI lun.

I've just checked the vmkdiscovery and vmkbinding files - these both show the correct iSCSI lun details - I just can't see it!!

[java_cat33]

I have disabled CHAP authentication now - still no result however.

I've also completely removed the iSCSI target detail from within the software initiator of ESX and disabled it - rebooted ESX, deleted entries from bindings and discovery file - rescanned........ it identifies the presented iSCSI lun in the discovery and bindings file....... just does not appear as a target within VC, I've checked the messages file - this appears OK too....

The ietd.conf file I mentioned in my first post is a config file that resides on the OF box..... I managed to change the iqn identifer within ESX - this is now different.

I've also removed one of the iSCSI luns too - just to simply the setup for troubleshooting

[java_cat33]

OK - I've completely rebuilt the OF appliance now - it's patched, iSCSI is enabled, luns created etc etc..... when I look at the ietd.conf file on the OF box.... it displays the below.....

Target iqn.2006-01.com.openfiler:esx_volumes.dev_iscsi

Lun 0 Path=/dev/esx_volumes/dev_iscsi,ScsiSN=whbzrc-DHAd,Type=fileio

Target iqn.2006-01.com.openfiler:esx_volumes.dev_templates

Lun 1 Path=/dev/esx_volumes/dev_templates,ScsiSN=395D8R-b5qG,Type=fileio

Please note - my understanding is that there is a known bug with OF when creating more than one iSCSI lun - it gives every target a lun ID of 0 - I've ammeded the above so one is 0, and the other is 1.

Now.... when I look at the vmkbindings file on the ESX box........ it displays the below..

1. Format:

2. bus target iSCSI

3. id id TargetName

#

0 0 iqn.2006-01.com.openfiler:esx_volumes.dev_templates 0

0 1 iqn.2006-01.com.openfiler:esx_volumes.dev_iscsi 0

And if I look at vmkdiscovery......

0 0 iqn.2006-01.com.openfiler:esx_volumes.dev_templates

0 1 iqn.2006-01.com.openfiler:esx_volumes.dev_iscsi

Does it matter that the target id's on the ESX box for the iSCSI volumes does not match the id's set in the ietd.conf file on the OpenFiler appliance?

I would have thought it would - so I changed the order around in the ietd.conf file, restarted the iSCSI server service on the OF, re-scanned the initiator within ESX - still same problem - does not display target within VI client. I changed the ietd.conf file back to it's original settings.

I think I must be close to cracking this.... the fact that the targets are in the vmkbinding and vmkdiscovery file definitely shows that ESX can see the target..... but for some reason it does not display the target within the VI client when doing a rescan?????

[DArndt]

The Openfiler and ESX targets don't have to match, mine are not the same. I also had an issue during setup where the username for CHAP needed to be atleast 11char, not sure why, but it didn't work with a shorter username for me.

-

---

Target iqn.2006-01.com.openfiler:vg1.main

Lun 0 Path=/dev/vg1/main,Type=fileio

IncomingUser username password

Target iqn.2006-01.com.openfiler:vg2.backup

Lun 1 Path=/dev/vg2/mirrored,Type=fileio

IncomingUser username password

-

---

1. Format:

2. bus target iSCSI

3. id id TargetName

#

0 3 iqn.2006-01.com.openfiler:vg1.main 0

0 5 iqn.2006-01.com.openfiler:vg2.backup 0

-

---

[java_cat33]

Thanks - That's good to know

I have an active case open with HP/VMWare now - will keep ya posted on the progress

What kernel on OF are you running? Weird problem with CHAP...... I've currently got CHAP disabled for the time being until this is sorted

[DArndt]

I am using Kernel Version 2.6.19.7-0.3.smp.gcc3.4.x86_64(SMP)

Dave

[java_cat33]

I've now sorted this..... issue was with OpenFiler after installing system update patches.... it's working now I'm gonna leave it alone :smileygrin:

There's a certain order you need to install patches, update Conary etc in order for it to work for me.

[Zenrin]

A few things to note that I ran into while setting up an iSCSI system using openfiler and ESX.

First thing I found is that your iSCSI username and password can only have A_Z,az and 0~9 in these fields. Use of special characters like #$!@, etc are not handled well, and ESX stores these very strangely in local the iSCSI initiator configuration file. The other thing I see in your configuration, which was an intermittent problem for me is that you have the parameter Type=fileio in your LUN definition, you will need to manually update this to Type=blockio. This will avoid issues you may encounter later.

I know this is an old thread, but for those who are upgrading to vSphere, there is an additional tweaks on openfiler that you will need to make to get better performance. Enabling Jumbo Frames. While there are several places you need to change in ESX and your network switch, you can modify openfiler to support jumbo frames by changing the MTU on your network interfaces to 9000. To make this occur at every startup add MTU=9000 to each interface in /etc/sysconfig/network-scripts named ifcfg-eth? or ifcfg-bond?.

-Zen