Unsolved
This post is more than 5 years old
19 Posts
1
964
October 28th, 2011 09:00
ESX across multiple FA pairs - LUN id question
Hello,
We have 6 node ESX 4.1 cluster. We want to map a dual port HBA to a DMX4 across two FA pairs. 7aa/10aa and 7ba/10ba. Is there any issues if the lun id is different across pairs?
ie:
DMX4 device is 3d4, lun id is 25 on 7aa/10aa
DMX4 device is 3d4, lun id is 45 on 10ba/10ba
When presented, ESX sees 4 paths (in the Manage Paths view) to the device configured as RoundRobin. It sees two paths discovered with id25, and two paths with lun45 on all six hosts.
I know the rule is you need to keep the lun id consistent on pairs (7aa needs to have the same lun id assigned as 10aa), but do you need to keep it the same across multiple pairs?
Thanks!
No Events found!
dynamox
9 Legend
•
20.4K Posts
1
October 29th, 2011 05:00
i think it should be consistent no matter how many paths you have it presented through. Are you using dynamic lun masking ? If yes, you could override default masking with the -lun # parameter to force the lun id to match with other FAs.
synsoc
19 Posts
1
November 2nd, 2011 09:00
Thanks Dynamox! That should help out. We also contacted VMware who provided this answer:
As for the LUN IDs, each LUN should be represented by a single consistent ID. Since version 3.5 Update 5 we use NAA instead of LUN IDs when the SAN supports them. Otherwise, we fall back to LUN IDs. So if your SAN supports NAA, then the LUN ID should not be an issue, but if you want to play it safe, I would keep them consistent as well.
We should be ok using the NAA id.
Allen Ward
4 Operator
•
2.1K Posts
1
November 6th, 2011 20:00
I'm with dynamox on this one. It's all well and good that it SHOULD be OK if the LUN IDs don't match, but if everything worked the way it should we would all be out of work :-)
I find it especially important to keep these LUN IDs consistent across ALL ports used for a device presented to a single or multiple ESX hosts. It gives you one more point of consistency when troubleshooting so that you don't get confused when the ESX support guys tell you to look at something and you think you are looking at what they told you to but you are really looking at something different.I'm sure it is fine for hosts that are already configured differently, but it can't hurt to try to maintain consistent IDs going forward...
Just my two cents worth (and I am admittedly a bit of a control freak when it comes to my Storage environments) *lol*
synsoc
19 Posts
0
November 10th, 2011 07:00
Agreed Allen. We found one final issue that using NAA with different id's due to multiple pairs of FA's (SPC2 bit set), vmdk vmotion would work fine to all esx servers in the cluster regardless of id, but RDM moves still failed. This would happen if you tried to move the VM from a server that had imported the rdm with a scsi id from one pair of FA's to a server that had discovered the same RDM with a different id from another pair of FA's.
We also found that even if the vmclient gui showed the scsi id being the same across all cluster members, running a command line dump showed that the servers we couldn't move the VM to had actually discovered it as the alternate id.
Long story short, always make sure scsi id's match for each host in the cluster across all paths. On DMX/VMAX we used dynamic masking, and single SG's on CX. Thanks again for the feedback Allen and Dynamox!
dynamox
9 Legend
•
20.4K Posts
1
November 10th, 2011 08:00
one thing to note on DMX4 and dynamic_lun option. The other day i had to add an extra pair of FAs to a host that was using dynamic_lun parameter. There were gaps in how the LUNs were presented to the host with dynamic_lun masking. So in order for me to match exact masking, i would first list devices and document their host address
------ ----- ----------------------- ---- --- ---- ---- ---- -------
69053
and then mask devices and specify LUN address
symmask -sid 123 -dir 14a -p 1 -wwn 21000024ff30cd71 add devs 14D1 -lun c -nop
if you were to simply use dynamic_lun option, it would put all devices nice and neatly into consecutive order and that would not match your existing FAs.