vmware SRM duplicate LUN's when scan array P4000

does this help?  http://theether.net/kb/100132

I have seen that document before. unfortunately i deals with IBM not the HP P4000

what happends when you run through the array configuration? Does it see the replicated LUNs as one to one?

If you haven't installed vCenter plug-in for HP SAN Insight it may be a good idea as it will let you view your SAN luns inside of vCenter and deploy datastores without going to the Lefthand managment first.

it gets 23% done scanning the array and says duplicate lun id's found.  we have 2 esxi hosts with round robin iscsi connections which im wondering if that is what is causing the sra to see duplications.

I will install the vcenter plugin for SAN and see if that sheds any light. thank you for the suggestion.

Do a lun scan and see if you have (1) or a :1 behind the same LUN, this will indicate that it's seeing it twice due to Multipath.

the point of the article is that there are duplicate LUN id's and you can check the logs to confirm it.  The instructions in the article are specific to IBM only in the way to resolve the issue, otherwise; it's the same problem across SAN platforms

here's an example of what the SRM logs show:
[#1] log4j:WARN No appenders could be found for logger (org.exolab.castor.xml.Unmarshaller).
[#1] log4j:WARN Please initialize the log4j system properly.
[#1]
[2011-04-26 22:40:12.190 01760 info 'PrimarySanProvider'] discoverLuns exited with exit code 0
[2011-04-26 22:40:12.190 01760 trivia 'PrimarySanProvider'] 'discoverLuns' returned <?xml version="1.0" encoding="ISO-8859-1"?>
[#1] <Response>
[#1]     <ReturnCode>0</ReturnCode>
[#1]     <InitiatorGroupList/>
[#1]     <LunList arrayId="GMI-PRI;2586C5C2ABB5CE6E2F3D40EFE46B3371">
[#1]         <Lun id="17424;VMVOL1">
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17424:vmvol1">0</Number>
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17424:vmvol1">0</Number>
[#1]             <Peer>
[#1]                 <ArrayKey>GMI-DR;82ECF792AE4E3B95FDBFE87FC80EA97B</ArrayKey>
[#1]                 <ReplicaLunKey>2586C5C2ABB5CE6E2F3D40EFE46B3371;GMI-PRI;17477;VMVOL1_Sch_RS_1_Pri</ReplicaLunKey>
[#1]             </Peer>
[#1]         </Lun>
[#1]         <Lun id="17435;VMVOL2">
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17435:vmvol2">0</Number>
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17435:vmvol2">0</Number>
[#1]             <Peer>
[#1]                 <ArrayKey>GMI-DR;82ECF792AE4E3B95FDBFE87FC80EA97B</ArrayKey>
[#1]                 <ReplicaLunKey>2586C5C2ABB5CE6E2F3D40EFE46B3371;GMI-PRI;17485;VMVOL2_Sch_RS_1_Pri</ReplicaLunKey>
[#1]             </Peer>
[#1]         </Lun>
[#1]         <Lun id="17437;VMVOL3">
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17437:vmvol3">0</Number>
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17437:vmvol3">0</Number>
[#1]             <Peer>
[#1]                 <ArrayKey>GMI-DR;82ECF792AE4E3B95FDBFE87FC80EA97B</ArrayKey>
[#1]                 <ReplicaLunKey>2586C5C2ABB5CE6E2F3D40EFE46B3371;GMI-PRI;17486;VMVOL3_Sch_RS_1_Pri</ReplicaLunKey>
[#1]             </Peer>
[#1]         </Lun>
[#1]         <Lun id="17439;VMVOL4">
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17439:vmvol4">0</Number>
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17439:vmvol4">0</Number>
[#1]             <Peer>
[#1]                 <ArrayKey>GMI-DR;82ECF792AE4E3B95FDBFE87FC80EA97B</ArrayKey>
[#1]                 <ReplicaLunKey>2586C5C2ABB5CE6E2F3D40EFE46B3371;GMI-PRI;17487;VMVOL4_Sch_RS_1_Pri</ReplicaLunKey>
[#1]             </Peer>
[#1]         </Lun>
[#1]         <Lun id="17457;VMVOL5">
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17457:vmvol5">0</Number>
[#1]             <Number targetId="iqn.2003-10.com.lefthandnetworks:gmi-pri:17457:vmvol5">0</Number>
[#1]             <Peer>
[#1]                 <ArrayKey>GMI-DR;82ECF792AE4E3B95FDBFE87FC80EA97B</ArrayKey>
[#1]                 <ReplicaLunKey>2586C5C2ABB5CE6E2F3D40EFE46B3371;GMI-PRI;17488;VMVOL5_Sch_RS_1_Pri</ReplicaLunKey>
[#1]             </Peer>
[#1]         </Lun>
[#1]     </LunList>
[#1] </Response>

[2011-04-26 22:40:12.193 01760 error 'PrimarySanProvider'] Encountered LUN '17424;VMVOL1' with duplicate number ';0;iqn.2003-10.com.lefthandnetworks:gmi-pri:17424:vmvol1'

On the Lefthand what LUN number are assigned to the  LUN?  Looks like LUN ID is 0 (zero) on all the LUNs.  Ensure that the LUNs numbers are unique on the SAN

so it would appear that you need to change the presentation of the LUN's.  http://communities.vmware.com/thread/261016?tstart=0 mentions using the VIP???  not sure what that is, but it might make more sense to you.

anyone know how to change the LUN ID's on a P4000? I see they are all set as 0 in vcenter but I can't find anywhere in HP CMC to change the LUN ID's.

Give HP a call, I'm sure that can point you in the right direction within a few minutes.

If we only resent one esxi server it works.  But if we present both servers we get the error.  Even if we cluster the two esxi hosts we get the error

that's correct since every LUN has the same LUN ID.

Let me clarify.  It works if we remove one esxi host and keep both San units.  It doesn't work if we have 2 esxi hosts and 2 San. Units.  So the problem seems to be between the hosts and not the San.

that sounds like you have the LUN's presented differently to the two hosts...

How long ago did you purchase SRM?  Whenever you buy a VMware license, you have to buy Basic or Production support with it so you may still be under support for this product.  The reason I bring this up, is because I've talked to people who work/worked for VMware and they heavily recommended that any new install of SRM be purchased with installation services due to the fact that it can be very hard to install and configure correctly without prior knowledge of it.

We've been working with HP support as the HP SRA is what is presenting the LUN information incorrectly to vmware.  It's escalated to level 3 but so far no luck.

At least you know that it wasn't a checkbo that you've missed

CR5150, Did you get a response from HP about the duplicate LUN error?  I'm running into the same problem.

Thanks.

No. They have web trying to reproduce the problem. No eta. Weve been waiting since January.

no resolution. please close

no resolution. HP is working on a fix.