Inconsistent luns and different UUID's for datastores across ESX hosts IBM SVC

[shepnasty]

We are running 8 IBM 3850 M2 servers with 128 GB of mem each and (2) 4GB HBA's, Brocade Fiber Fabric (48K Directors), IBM SVC with DS 8100 storage behind it (majority of datastores - 34), Netapp V3140 delivering NFS datastores (10) and fiber datastores(1). We are on ESX 3.5 update 5 patched up to the most recent critical patches as of today. Our SVC firmware is out of date by 9 major versions (we know, we know) and Brocade is a couple major releases out. Netapp is up to the most recent release. Our SVC datastore LUNs are showing different LUN ID's and UUID across ESX hosts thus making inconsistent luns ( this is not good). We believe this might be a result of our SVC firmware or the way we are presenting the luns to each host as opposed to presenting (or mapping) a lun to a group of hosts in one initiator group or host group (Vendor vocab...). Different VMWare engineers seem to have a different opinions on this. Any input you have would be helpful on the subject.

Thanks!

[Aleksy]

We have a similar setup with the same problem. It seems that if you go to the SVC and under Vdisks select Vdisk-to-Host Mapping you will see that the same LUN has a different SCSI Id on 2 (or more) hosts; this is the problem. During the Vdisk assignment phase you have the option to specify the SCSI Id, you must enter the same SCSI Id that the LUN has assigned to the other SVC hosts. This should resolve the problem. Our ESX farm has 72 LUNs assigned to it and ensuring that the SCSI IDs are identical when we add a new ESX server is time consuming to say the least. It may be possible to script it using SVC CLI.

Hope this helps.

[shepnasty]

Thank you for your response Aleksy. We have been tinkering with finding an easy way to do this but don't see the option to assign SCSI ID during the Vdisk assignment phase. Perhaps it is in a newer version of software. Have you ever tried grouping the ESX servers WWN's together in one "HOST" to make this easier? This is how we do it on our NetApp, put all of the WWN's in one initiator group then map the LUN to that initiator group with the LUN ID and bam they all get it at once with the same ID.

[Aleksy · Accepted solution]

Hi,

We are running SVC code 5.1 but here is a snippet from the 4.2.1 configuration guide:

When you map a VDisk to a host, you can optionally specify a SCSI ID for the VDisk. This ID controls the sequence in which the VDisks are presented to the host. For example, if you present three VDisks to the host, and those VDisks have SCSI IDs of 0, 1, and 3, the VDisk that has an ID of 3 might not be found because no disk is mapped with an ID of 2. The cluster automatically assigns the next available SCSI ID if none is entered.

Source: ftp://ftp.software.ibm.com/storage/san/sanvc/V4.2.1/pubs/English/English_Configuration_Guide.pdf

So it should be available to you in version 4 also. It is not an option as such but shows up on the last screen where you "accept" the action.

We don't group servers together in zone sets, it can be a real nightmare if there is a problem since it can affect all the members in the set and is hard to diagnose. But I suppose if the servers are the same OS version etc and the HBAs are also identical it should be OK.

Be well,

Aleksy.

CONFIDENTIALITY NOTICE – AVIS DE CONFIDENTIALITÉ

This e-mail message is intended only for the above named recipient(s) and may contain information that is confidential. If you have received this message in error or are not the named recipient(s), please immediately notify the sender, delete this e-mail message without making a copy and do not disclose or relay this e-mail message to anyone.

Ce courriel est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus et peut contenir de l'information privilégiée, confidentielle et/ou dispensée de divulgation aux termes des lois applicables. Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez le mentionner immédiatement à l'expéditeur, effacer ce courriel sans en faire de copie et ne pas divulguer ou transmettre à quiconque ce courriel.

[shepnasty]

In the end the SVC just sucks!!! We are upgrading our Netapp filers and doing away with IBM storage. When virtualizing Netapp is KING!