HBA/LUN names - do they need to be same across Hosts?

[TB_Rich]

Hi,

I have a question about LUNS and FC. Does the hba name need to be the same in hosts accessing the same LUNS?? Been a long time since I touched FC I'm afraid!

Bascially, if hostA access's lunA via hba1, its path name would be something like hba1:0:0:1 AND If hostB accesses lunA via hba2, it would be hba2:0:0:1. Is this a problem that the name is inconsistent? I thought I read somewhere that names (conical names??) have to be the same?

Man I love NFS so much more than FC!!

Many Thanks if somebody could clariffy FC/LUN naming for me

Rich.

[kjb007]

Names and targets will vary depending on which path is discovered first, but the Lun ID's presented to the hosts should be consistent across servers sharing the same LUN.

-KjB

[jpdicicco · Accepted solution]

What you're looking at is good-old CTD/CTL (controller, target, device/LUN) naming. This is just a reference to how you are getting where you are going. Each device must be unique to a controller, and each LUN can only be used once on a controller. ESX maxes out at 255 LUNs (see configuration maximums for more detail on this).

So, you don't have to match any of it across hosts. It is, however, advisable for your sanity to make sure that every datastore that is presented to a host in an HA cluster be presented to all hosts. This prevents issues with VM migration.

It also makes it easier to troubleshoot (esp. communicating with a dedicated storage group) if each of the LUNs presented gets the same number on each host.

Happy virtualizing!

JP

Please consider awarding points for correct and/or helpful answers

[kjb007]

In addition to that, if you don't code a certain LUN id to a host, then a device scan can return the LUNs in a different order to the same host that was previously mounting that LUN under a different ID. If that happens, then you could run into a snapshot condition, where the ESX sees the same volume as a snapshot, and disables access to it until you forcibly mount it, change the ID back, or resignature it.

-KjB

[TB_Rich]

Thanks guys, so basically the hba name is totaly irrelevant and it's a case of making sure each host has the right(optimal) target path to the desired LUN.

Kjb, you have touched on the main reason I'm asking, I ran into this resig probalem many moon's ago with an old FC MSA SAN. I'm now settiing up RDM's on a NetApp (and have been enyoing NFS for a long time) and have not touched on FC for quite some time. I expect/hope! it will come back to me as I'm playing about but what is it that needs to be done to code the LUNS to the host(s) to avoid these issues???

Or if you could point me at the right PDF I would appreciate that.

Many Thanks,

Rich.

[kjb007]

When you're presenting the LUNs from the NetApp, since your datastore LUNs have to be shared, create a new igroup with all of the shared hosts WWNN's, and when you present the LUN to that igroup, give it a Lun ID. That way, you give the same LUN id across all hosts, and you have it static in your configuration.

-KjB

[TB_Rich]

That is what I have done to another of our smaller sites on a NetApp which does use FC. I have got 3 hosts there with dual HBA's, added all 6 WWPN's to an iGroup on each head of the Filer and simply given each LUN a LUN id which is then presented to all ESX hosts.

I didnt realise it was even possible to duplicate LUN id's as it requests a unique id which is not in use on either head of the Filer.

Thanks for your help.

Rich.