With Equallogic every volume is a target, and the 'container' becomes LUN 0 for that target. This is by design.
As for the Compellent; I assume you mean the "Host LUN" number? Are the 2 LUNs owned by the 2 different controllers maybe? If so, can you fail it over to see if it changes the HLU? If it is in production, you may want to open a support ticket before doing anything.
Which Compellent system do you have as you didn’t state it in your post? What is the current version of SCOS that is on your Compellent? Which version of VMware are you using as well?
Please let us know if you have any other questions.
This is to be expected. When a Volume is created and you select to automatically map it through a controller it will map through each controller alternately. So the first Volume goes through controller A and the next volume goes through controller B. Each controller can have the same LUN number as the other controller because they do not use the same connections. If you look at each volume showing as LUN #1 in the connections tab you will see that each is using different HBA connections from the controllers which is what differentiates the connections.
The best way to identify a Volume in VMWare is by looking at the Volume Serial number in the Compellent SAN and comparing it to the Volume serial number in VMWare.
Thanks for replying. Below is a short overview of the versions used in our environment.
It's a fibre channel setup not iSCSI. But a similar problem.
Compellent SC4020 + SC220 enclosures on both sites
vCenter version: 6.5.0 build 7515524
ESXi version: 6.5.0, 7388607
SRM version: 6.5.1.14612
Compellent SRA version: 18.1.1.173
Compellent Firmware version: 7.2.31.3
Enterprise Manager version: 18.1.20.114
After upgrading SRA from version 16.3.10.127 to 18.1.1.173 on 2 vCenter servers we get 3 issues:
On the protected site the status of the replication is "unknown" on the local array
On the protected site we get the error "Duplicate LUN '5' for initiator group '49243.3338675433' found for devices '49243.67' and '49243.68' in SRA's 'discoverDevices' response on the local array
On the failover array the Datastore and Status entries are "unkown".
We can identify the LUN/Volumes on the Compellent Storage and they have the same LUN id.
The LUNs that SRM is complaining about are replicated to another Compellent device, but are not used in SRM.
Did you ever find a resolution to your issue? I have it on a fresh install but am using vCenter 6.7 with 6.5 hosts and SC5020's. Did yo have to revert to SRA 16.3.10.127?
hellraiseruk
38 Posts
0
October 4th, 2012 07:00
I've opened a ticket with Compellent, thought it might be best :)
Cheers
JD
Dev Mgr
4 Operator
•
9.3K Posts
0
October 4th, 2012 07:00
With Equallogic every volume is a target, and the 'container' becomes LUN 0 for that target. This is by design.
As for the Compellent; I assume you mean the "Host LUN" number? Are the 2 LUNs owned by the 2 different controllers maybe? If so, can you fail it over to see if it changes the HLU? If it is in production, you may want to open a support ticket before doing anything.
faajbuhr
6 Posts
0
May 9th, 2019 02:00
Hi,
Have you ever resolved this issue?
We are experiencing the same problem.
Thanks in advance
DELL-Sam L
Moderator
•
7.8K Posts
0
May 9th, 2019 06:00
Hello faajbuhr,
Which Compellent system do you have as you didn’t state it in your post? What is the current version of SCOS that is on your Compellent? Which version of VMware are you using as well?
Please let us know if you have any other questions.
DELL-Bob Mi
2 Intern
•
230 Posts
0
May 9th, 2019 11:00
Hello faajbuhr,
This is to be expected. When a Volume is created and you select to automatically map it through a controller it will map through each controller alternately. So the first Volume goes through controller A and the next volume goes through controller B. Each controller can have the same LUN number as the other controller because they do not use the same connections. If you look at each volume showing as LUN #1 in the connections tab you will see that each is using different HBA connections from the controllers which is what differentiates the connections.
The best way to identify a Volume in VMWare is by looking at the Volume Serial number in the Compellent SAN and comparing it to the Volume serial number in VMWare.
faajbuhr
6 Posts
0
May 9th, 2019 23:00
Hi,
Thanks for replying. Below is a short overview of the versions used in our environment.
It's a fibre channel setup not iSCSI. But a similar problem.
After upgrading SRA from version 16.3.10.127 to 18.1.1.173 on 2 vCenter servers we get 3 issues:
We can identify the LUN/Volumes on the Compellent Storage and they have the same LUN id.
The LUNs that SRM is complaining about are replicated to another Compellent device, but are not used in SRM.
Roger-Roger
1 Message
0
June 1st, 2020 01:00
Hi faajbuhr,
Did you ever find a resolution to your issue? I have it on a fresh install but am using vCenter 6.7 with 6.5 hosts and SC5020's. Did yo have to revert to SRA 16.3.10.127?
Cheers
Roger