uninspired
Contributor
Contributor

iSCSI LUNs visible in Discovery tabs, not in devices under Storage Adapters

Jump to solution

So, the gist of the problem is in the title. The question ultimately is: What would cause iSCSI targets to show up in the Static Discovery tab of my iSCSI Initiator  properties, but NOT show up in the list of devices in the Details  section of my Storage Adapter properties? I added the new IP of my iSCSI  server in the Dynamic Discovery tab, and all of the proper disks showed  up immediately in the Static Discovery tab, but I can't actually attach  any of them or add them to Storage.

Since moving  to vSphere 5, I'm having more problems than in the past with iSCSI LUNs.  We recently had to make some physical and IP changes, and I'm  struggling to get my iSCSI volumes reconnected. Though I'm posting about  a specific instance (something I need to get up in production ASAP),  I've experienced the same thing on an entirely different cluster with an  entirely separate SAN.

Anyone run into anything similar? Basically, I know  the hosts can see the iSCSI volumes, but they aren't available for me to  add as storage to the cluster.

NOTE: This same storage was attached to this same cluster last week. The only thing that has changed is IP addresses of the adapters and the SAN. Also, the Network Configuration tab of the iSCSI software initiator shows all three bound vmk bindings as "compliant."

Thanks

Message was edited by: uninspired (added NOTE at bottom)

0 Kudos
1 Solution

Accepted Solutions
Josh26
Virtuoso
Virtuoso

Hi,

Thanks for the update.

VMware specifically announces that routed iSCSI is not supported unfortunately. So yes, the issue lies in the ESXi SCSI software adapter. The problem is it's often a good thing - many performance issues on other platforms relate to routers on iSCSI.

View solution in original post

0 Kudos
13 Replies
kjb007
Immortal
Immortal

Can you log in to the console, and run 'esxcfg-volume -l'?

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
0 Kudos
uninspired
Contributor
Contributor

It returns nothing. No error, but no information, either.

0 Kudos
kjb007
Immortal
Immortal

Are there network permission that need to be updated as well?  I had some issues getting iSCSI working correctly also, some were from storage, and some from the ESXi side.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
0 Kudos
uninspired
Contributor
Contributor

No permissions issue that I can think of. I'm using an EqualLogic SAN, and I limit access to the volumes by iSCSI initiator name (which didn't change) rather than IP. Do not use CHAP, either.

0 Kudos
kjb007
Immortal
Immortal

May be time to disable/re-enable the initiator and try a reboot if you haven't already done so :  http://kb.vmware.com/kb/1038065

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
uninspired
Contributor
Contributor

No luck. Thanks for the article reference, though -- it was definitely worth a shot. I ended up opening a ticket with VMware.

0 Kudos
Josh26
Virtuoso
Virtuoso

Please keep us up to date on how your ticket goes - I'm very interested in what would cause this.

0 Kudos
uninspired
Contributor
Contributor

Well, VMware never got back to me (guess it's better to call than to open a ticket online), so I figured it out myself.

In the past, our SAN subnet was not routed, so we had to put our iSCSI adapters on IP ranges within the same subnet as the SAN. Our new environment is (supposedly) not like that -- any subnet should be able to route to any other subnet. So, for example, the SAN is in the 10.50.50.x subnet, and Windows boxes in the 10.50.40.x can mount those iSCSI volumes without issue. However, when I tried the same thing with out ESXi cluster, it could *see* those volumes, but not attach to them. I ended up having to assign IP addresses in the 10.50.50.x to get them attached.

I'm not sure if this is typical SAN behavior or if it's an ESXi iSCSI Software Adapter peculiarity, but the same behavior was occurring between three different SANs (EqualLogic, EMC VNXe, Isilon). It's a bit inconvenient, as we have each SAN on a different subnet, so I have to burn three different adapters if I want to attach to all three SANs.

0 Kudos
Josh26
Virtuoso
Virtuoso

Hi,

Thanks for the update.

VMware specifically announces that routed iSCSI is not supported unfortunately. So yes, the issue lies in the ESXi SCSI software adapter. The problem is it's often a good thing - many performance issues on other platforms relate to routers on iSCSI.

0 Kudos
uninspired
Contributor
Contributor

Any idea how to handle SANs on multiple subnets, then? i.e., If I'm limited to one iSCSI software adapter that will not route, how can I connect to iSCSI targets on multiple subnets?

By the way, I'm unable to connect to NFS storage on a different subnet, as well. I had hoped it was iSCSI-specific, but apparently vmware won't route *either* network storage option.

0 Kudos
kjb007
Immortal
Immortal

The iSCSI bindings is unsupported ONLY if you are binding your vmkernel ports for multipathing.  Without this, the connection should work just fine.

http://blogs.vmware.com/vsphere/2011/08/vsphere-50-storage-features-part-12-iscsi-multipathing-enhan...

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Josh26
Virtuoso
Virtuoso

Kanuj Behl wrote:

The iSCSI bindings is unsupported ONLY if you are binding your vmkernel ports for multipathing.  Without this, the connection should work just fine.

-KjB

Do you mean "routing" instead of "multipathing" ?

The link you posted demonstrates using iSCSI bindings in a multipathed environment and recommends it.

Whilst you may be able to route without bindings, it doesn't make it supported.

0 Kudos
kjb007
Immortal
Immortal

Routing is supported without vmkernel binding.  Without binding, which provides a better way to multipath, the older method multiple subnets to iSCSI targets still works.  It's also mentioned in the comments in the same article.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
0 Kudos