Hello, I've got an Infortrend A16E-G2130 and I'm trying to get this bad boy to connect with my ESXi 4.1 machine. Both have the latest firmwares and patches, and I've configured this thing exactly as it seems you should. I've created a target on the SAN and added the iqn of the ESXi box and my laptop as well just for testing. I can map and mount via my laptop but when I try using the ESXi box, the LUN shows up as dead? Not sure whats going on.
Is your laptop still connected to the LUN. If it is and it is a Microsoft OS it will lock the LUN and the ESXi host cannot connect to it. Try disconnecting the laptop and adding the LUN to your ESXi host.
Yea, it won't connect either way. I just tested the iSCSI target with the laptop to make sure it wasn't an issue SAN side. I've disconnected the laptop and I didn't mount or format or anything once I connected. I just wanted to make sure it showed up in disk management and in volume & devices section of iscsicpl. This is baffling, I have management traffic on the VMKernel adapter enabled, and it does not work.
Do you have a second VMkernel protgroup for your iSCSI? You don't want the Management traffic on the same VMkernel as your iSCSI. If not create one and then disable and re-enable your iSCSI software initiator.
Right now I am trying to use the same "VMKernel" I use to connect with the vSphere Client. Are you saying I should create a second VMKernel port and assign it to the same virtual switch?
It can be a part of the same vSwitch But you need a second VMkernel portgroup with its own IP address for the iSCSI. Here is a link to a quick configuration for iSCSI.
http://www.techhead.co.uk/vmware-esxi-4-0-vsphere-connecting-to-an-iscsi-storage-target
I just tried making it its own VMKernel, it didn't work. I also tried creating a VMKernel adapter on its own adapter on a different interface; that also didn't work. I also tried switching the LUN's channel on the SAN, once again no good. The thread I listed below has a similar issue with my exact model SAN (Infotrend EonStar A12E-G2121. I can't figure out if the commands listed are to be run on the ESXi console or the SAN to disable this ALUA thing. The one guy said he literally had to downgrade to ESXi 4.0 to restore iSCSI functionality.
http://communities.vmware.com/thread/211369?start=15&tstart=0
http://communities.vmware.com/thread/281568?tstart=0
Solved! ALUA was the issue! It needs to be disabled for this particular Infortrend model! The clues I pieced together from this forum helped me out tremendously! Its like detective work! I found a command for an older ESXi and then couldn't figure out how to get it to work, but eventually I did! This is the command I ran.
Once again, this was an Infortrend A12E-G2121 running the latest firmware dated 1/31/2011
Time for a beer!
Glad you got it worked out. Hope you enjoyed those beers!
Wow. I never thought I'd find something so specific!
That's exactly my problem and the fix worked! Thanks!
Hi
I had exactly the same problem, and your solution save my life.
Thanks!
I am now having the same issue with ESXi 5.0. The commands have changed slightly and I cannot seem to figure out the proper syntax to remove this rule.
From what I gather, the syntax should be:
This is not working, if anyone could chime in, that would be great, otherwise I'll work on a solution and post back here when I figure it out.
esxcli in ESXi 5 has changed - you need to look around in here:
esxcli storage core claimrule remove
Matt,
I am aware of the changes in the esxcli, the command I listed above theoretically should work. The command you suggested is for the core storage, I am looking specifically at the NMP SATP plugin. If I run esxcli storage nmp satp rule list, I can see the rule which I wish to remove. For some reason, I just can't get the syntax right for removal, or maybe the rule can no longer be removed.
I see what you mean.
Honestly, rather than remove this part of the ruleset, it wouldbe better to *add* a rule with the options you want:
esxcli storage nmp satp rule add -c tpgs_off -e "Options for Infortrend SAN" -V "IFT" -P "VMW_PSP_MRU" -s VMW_SATP_ALUA
This assume that the vendor string for Infortrend is 'IFT', which according to Infortrends docs, it should be.
This makes a specific claim rule for that array rather than changing the values for the defaults.
~ # esxcli storage nmp satp rule list -s VMW_SATP_ALUA
Name Device Vendor Model Driver Transport Options Rule Group Claim Options Default PSP PSP Options Description
------------- ------ ------ ------- ------ --------- -------------------------- ---------- ------------- ----------- ----------- ------------------------------------
VMW_SATP_ALUA NETAPP system tpgs_on VMW_PSP_RR NetApp arrays with ALUA support
VMW_SATP_ALUA IBM 2810XIV system tpgs_on VMW_PSP_RR IBM 2810XIV arrays with ALUA support
VMW_SATP_ALUA IFT user tpgs_off VMW_PSP_MRU Options for Infortrend SAN
VMW_SATP_ALUA system tpgs_on
Didn't work. My logs still show this.
WARNING: NMP: nmp_SatpClaimPath:2093:SATP "VMW_SATP_ALUA" could not add path "vmhba42:C0:T2:L5" for device "Unregistered Device". Error Not found
How can I delete that default VMW_SATP_ALUA rule? Everything began to work fine previously with this rule deleted. I see that there is a a "Rule Group" column where this is listed as being in the System group. Do I need to specify that as a switch in the removal command syntax?
Does your rule list show the rule added? Does the vendor ID match (I dont have an IFT array play with).
You may not be able to remove the default rules anymore (because, honestly, its always been VMW's stance that you should be creating device specific rules).
Yes, it does show that the rule has been added. I am unsure of how to verify what the actual Vendor ID is for the Infortrend, I figured I would find that in the logs and I'm assuming that it is identifying it as an "Unregistered Device".
Run this and paste back:
esxcfg-scsidevs -l
Nothing useful in that; it only listed local devices such as the CD-ROM drive and the directly attached Intel RAID, nothing in there about anything remote. I'm going to see if I can get an output of a rescan of the software iscsi. That doesn't seem to be giving much info either though.