iSCSI discovery problem

[oreeh]

Hi,

I've successfully installed and configured IET - no problem so far.

Then I've created a test lun and configured ESX to use it - again no problem.

After some successful testing I removed the iSCSI LUN from ESX , deleted it on IET, created a new one and configured ESX to use it.

Now ESX tries to access the old (deleted) LUN and the vmkernel log gets filled with the following message:

messages.1:Jan 31 17:56:14 XXX iscsid\[16990]: iSCSI poll session ioctl failed for iqn.2007-01.xxx.xxx:iscsi.disk1, rc 0

Is there a way to "convince" ESX not to search / access the old deleted LUN?

[LeoKurz2]

Some iSCSI configurations need a reboot to succeed You could try the options of "esxcfg-swiscsi" on the COS to "refresh" the iSCSI environment, VI-client is not very reliable in this respect...

HTH

__Leo

[acr]

Have you removed this from the DynamicDiscovery Tab on the Initator..?

Then from the DataSores..i.e. Inventory --> DataStores --> Delete the DataStore Name, as it will still be there..

[oreeh]

Have you removed this from the DynamicDiscovery Tab

on the Initator..?

yes

Then from the DataSores..i.e. Inventory -->

DataStores --> Delete the DataStore Name, as it will

still be there..

yes

[oreeh]

after a rescan with esxfg-swisci I get the following message i vmkernel

SCSI: 8021: vmhba40:1:0:1 status = 0/1 0x2 0x8 0x0

WARNING: SCSI: 7916: status No connection, rstatus #c0de00 for vmhba40:1:0. residual R 999, CR 80, ER 3

WARNING: FS3: 4008: Reservation error: No connection

A grep -R -i "oldiscsilun" in /etc shows nothing

BTW: in VI client I was unable to disable the iSCSI initiator (I didn't try it with esxcfg-swisci - at the moment there's a VM running on the storage)

[Paul_Lalonde · Accepted solution]

ESX does hold on to iSCSI LUNs in one of its configuration databases. Try renaming the iSCSI LUN iqn and alias in the ietd.conf file so that ESX things its completely different.

Chances are ESX just got confused if the iqn and alias of the previous IET LUN is the same as the old one.

Paul

[oreeh]

the old and new names and aliases are completely different - I even changed the reported serial number

[oreeh]

meanwhile I stopped all VMs and rebooted the ESX server - still the same messages in vmkernel

[oreeh]

Do you know where this configuration database resides in the COS?

[Paul_Lalonde]

Dumb question, but what kind of network switch are you using? Try powering the switch off and on again... doubtful, but I've seen switches mess up MAC tables this way.

Paul

[oreeh]

Since it's only testing I simply plugged a crossover cable between the dedicated iSCSI interfaces (GBit)

[oreeh]

ESX does hold on to iSCSI LUNs in one of its

configuration databases.

That was the problem.

After deleting all referneces to the old LUN in /var/lib/iscsi/vmkbindings and vmkdiscovery everything works as expected.

THX

[jasonboche]

I've had to go through several steps to rid a running ESX 3.x host of swISCSI. Sometimes even all of these steps do not work because the host is rendered unstable and the iscsi module panics, won't unload, etc.

1. In the VIC, Storage Adapters, Properties, General, Configure, Uncheck "Enabled"

2. esxcfg-swiscsi -d

3. esxcfg-swiscsi -k

4. delete applicable iscsi target entries from:

/var/lib/iscsi/vmkbindings

/var/lib/iscsi/vmkdiscovery

5. esxcfg-swiscsi -e

6. esxcfg-swiscsi -s

7. Repeat step 1

8. In VIC, Run a rescan of vmhba40 to get rid of the old iscsi symbolic link in /vmfs/volumes/

[java_cat33]

Hi Oliver - sorry for posting on your answered thread..... however I am having similar issues as to what you experienced (I believe). Any help on my post would be much appreciated (in case I am forgetting something??)

I have tried what you have listed on your post..... still not fixed

http://communities.vmware.com/message/865096

Thanks :smileygrin: