Dear VMware 3.4 guru's,
GOAL: I am attemtpting to get my VMware ESX 3.5 (update #5) hosts (which are either running on HP G3 DL360 (P31 bios) or G3 DL380 (P29 bios) with (4) 1000MB NICs, connected to a 48-port Gig-E managed switch (Netgear GS748TR) with all ports belonging to the same VLAN (for now), to DISCOVER the iSCIS (LUN's) I've created on the Netgear ReadyNAS (4TB model: 2100 firmware is RAIDiator 4.2.8) which is also plugged into the GS748TR switch.
CURRENT RESULT (as of Dec 16, 2009 5pm EST): I have tried a million things and I can't get ESX to discover any iSCSI LUNs I create on the ReadyNAS 2100. However, my Windows 7 Enterprise software iSCSI identifies the Netgear iSCSI LUNs in about 4 seconds! If you can answer, "What does Windows 7's iSCSI software initiator do...that VMware's ESX 3.5.0 update 5 does NOT do...when scanning (the virtual HBA) for iSCSI targets - and you'll likely solve this riddle!"
However, I want to give you the accurate impression that I did try everything you can think of to ensure it isn't "operator error". I assume "operator error" at nearly every turn. I think I've found some type of incompatibility, but I'd sure like some fresh (way smarter) brains attacking my problem.
Physical Layer: I have checked, rechecked, & triple checked the physical layer. I have (one by one) unplugged each NIC card of each server to correctly map each NIC to a switch port (so I can implement vlan in the future). In VMware vSwitch0 is just the service console and it belongs to the 10.1.1.x subnet, vswitch1 has the VMKernel port for iSCSI and it also belongs to the 10.1.1.x subnet - I have DISABLED VMotion. I can log into the Linux BASH shell of these servers and ping to everything (GS748TR, firewall, & hosts). I have run vmkping X.X.X.X command to verify connectivity to my iSCSI VMKernel port! Also, I've run esxcfg-swiscsi -e enables, -d disables, -q is service up or down, -s scans for targets, -k kills/clears iSCSI stack, -r restores sw iSCSI stack, - h help.
Inside VMware using VIC client -> Configure Tab -> Network Tab
NIC 0 = Service Console, ip 10.1.1.201/24, Port # 6 on GS748TR
NIC 1 = VMKernel for software iSCSI, ip 10.1.1.202/24
NIC 2 = unassigned
NIC 3 = unassigned
Inside VMware using VIC client -> Configure Tab -> Storage Adapter Tab -> Select iSCSI -> click on Properties - > Configure - click Enable - > Dynamic Discovery Tab -> enter 10.1.1.1 (port #1 on ReadyNAS) and 10.1.1.2 (port #2 on ReadyNAS) (which I ping to verify connectivity long before), CHAP Tab - ensure CHAP is disabled.
Inside the Netgear ReadyNAS 2100 -> Network -> Interface -NIC 1 Tab - ensure ip address is 10.1.1.1 vlan & jumbo-frames are DISABLED. Same for NIC 2 (10.1.1.2).
Inside ReadyNAS 2100 -> Services -> Standard File Protocols -> CIFS, NFS, FTP, HTTP, HTTPS are all enabled.
Inside ReadyNAS 2100 -> Volumes - > Volume Settings -> iSCSI Tab -> Create iSCSI Target (aka LUN), activate or disable iSCSI LUN target, choose name - vmlunxx in my case, choose size - 50 GB in my case, CHAP settings - all disabled, Access Controls - where you can identify the name of only the software initiators that can see this LUN/target.
The Windows 7 software initiator can see iSCSI LUN/Targets on the ReadyNAS as long as they are "active" without regard for whether the Microsoft iSCSI initiator has NOT been included in the list of initiator to authorize.
The symtom: I tell the VMware ESX 3.5.0 (update #5) host to rescan the virtual iSCSI HBA for new devices (targets). The task usually times out. It has NEVER found an iSCSI target
"Why don't I just give up and migrate to vSphere 4 where software iSCSI is supposedly much easier to configure?" Good question, but the answer is because HP G3 DL360's & DL380's have 32-bit XEONs (which suprised me) - vSphere4 requires 64-bit CPUs - and before a smart aleck corrects me - I don't mean true 64 bit - I mean x64.