Unsolved
This post is more than 5 years old
1 Rookie
•
116 Posts
0
1568
January 26th, 2016 21:00
VPLEX 2.4 error with 2 x VPLEX Local
I have a single fabric with two VPLEX local setup. Each VPLEX local is having its own dedicated VNX backend. I noticed that with VIPR 2.4, at anyone time, if i have two VPLEX defined in the VIPR, I will always get the error message below. if I delete away one VPLEX from VIPR, the order can go through.
Create Block Volume Name: stupidvipr, Size: 5368709120, Virtual Pool: urn:storageos:VirtualPool:937c0c5b-d4fd-47e3-abb4-63ff87267e74:vdc1, Virtual Array: urn:storageos:VirtualArray:6aebdb55-bf2b-4250-a50a-893450d81e39:vdc1, Project: urn:storageos:Project:c3441e7c-2321-459a-bf06-2fc8a4b7d860:global 3 minutes
com.emc.vipr.client.exceptions.ServiceErrorsException: 5 Errors occurred
Error 18000: An error occurred while executing a job in the VPLEX device. Could not find storage system CLARIION+CKM00141000866
Error 18000: An error occurred while executing a job in the VPLEX device. Could not find storage system CLARIION+CKM00141000866
Error 18000: An error occurred while executing a job in the VPLEX device. Could not find storage system CLARIION+CKM00141000866
Error 18000: An error occurred while executing a job in the VPLEX device. Could not find storage system CLARIION+CKM00141000866
Error 18000: An error occurred while executing a job in the VPLEX device. Could not find storage system CLARIION+CKM00141000866
at com.emc.vipr.client.core.impl.TaskUtil.checkForErrors(TaskUtil.java:99)
at com.emc.vipr.client.Tasks.waitFor(Tasks.java:129)
at com.emc.sa.service.vipr.tasks.LongRunningTasks.executeTask(LongRunningTasks.java:47)
at com.emc.sa.service.vipr.tasks.LongRunningTasks.executeTask(LongRunningTasks.java:11)
at com.emc.sa.engine.ExecutionUtils.execute(ExecutionUtils.java:80)
at com.emc.sa.engine.ExecutionUtils.execute(ExecutionUtils.java:71)
at com.emc.sa.service.vipr.ViPRExecutionUtils.execute(ViPRExecutionUtils.java:41)
at com.emc.sa.service.vipr.block.BlockStorageUtils.createVolumes(BlockStorageUtils.java:261)
at com.emc.sa.service.vipr.block.CreateVolumeService.execute(CreateVolumeService.java:47)
at com.emc.sa.engine.ExecutionEngineImpl.execute(ExecutionEngineImpl.java:190)
at com.emc.sa.engine.ExecutionEngineImpl.runService(ExecutionEngineImpl.java:128)
at com.emc.sa.engine.ExecutionEngineImpl.executeOrder(ExecutionEngineImpl.java:72)
at com.emc.sa.engine.ExecutionEngineDispatcher.processOrder(ExecutionEngineDispatcher.java:50)
at com.emc.sa.engine.ExecutionEngineDispatcher$Consumer.consumeItem(ExecutionEngineDispatcher.java:91)
at com.emc.sa.engine.ExecutionEngineDispatcher$Consumer.consumeItem(ExecutionEngineDispatcher.java:85)
at com.emc.storageos.coordinator.client.service.impl.DistributedQueueConsumer$1.run(DistributedQueueConsumer.java:80)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Andrew291
92 Posts
0
January 27th, 2016 02:00
You may want to try setting up two different virtual arrays and define the VPLEX ports in each and also the VNX ports. This way when you provision from one VSA and a specific pool you are defining which VNX/VPLEX you will be using. Please let me know if this helps. ViPR is probably confused on which VPLEX to use at this point because all of the frontend and backend ports are all in one fabric / virtual array.
Andrew
wanaka
1 Rookie
•
116 Posts
0
January 27th, 2016 03:00
Hi,
I suspect the problem was due to the confusion by VIPR because of Single Fabric. In zoning I have specific performed the zoning in a one to one relationship (one VPLEX can only use one VNX). In the ViPR I have also defined two separate Virtual array to segregate the two vplex. Each virtual array will have its own virtual pool that specific select the corresponding VNX. In a typical VPLEX metro environment, customer is also likely to have two VPLEX within the SAN since the SAN is connected via ISL. I wonder how will that work out.
bmcfeeters
1 Rookie
•
72 Posts
0
January 28th, 2016 07:00
If there are multiple VPLEX local systems within one vArray and automatic zoning is disabled on the vArray then this can occur. What seems to be happening is a mismatch of the VPLEX and the desired backend VNX. To ensure that the appropriate combination is picked everytime separating out the each VPLEX and VNX combo into its own vArray is the way to go.
wanaka
1 Rookie
•
116 Posts
0
January 28th, 2016 22:00
Hi,
I have setup two different VA and using manual zoning. The VNX to vplex zoning is also separated both apart. The result is the same. The only way to solve this problem is to use a different switch or fabric to segregate the two vplex.
julien3192
38 Posts
0
January 29th, 2016 00:00
How did you build your VA ? Did you specify the Networks ?
julien3192
38 Posts
0
January 29th, 2016 01:00
OK. What I meant is : in your Networks, did you check the box in front of your vArrays ?
Doing this can lead to issues and it usually must look like this, especially when you have streched fabrics (= no VF or VSAN):
Please contact me offline, I can give your some assistance.
wanaka
1 Rookie
•
116 Posts
0
January 29th, 2016 01:00
Hi,
Yes I did specify the network but as I only have single fabric so there is only one network. Both VA has the same network. Since the zoning mode is manual, I only zone specific VNX to specific VPLEX exclusively, VIPR should not be confused which VPLEX it can use to provision. I can provision using both VPLEX without any problem but only once after that it just cannot work without get rid of the other VPLEX. This problem was finally resolved after I create virtual fabric in Brocade switch to separate the VPLEX to two different fabric and thus end up with two different network in VIPR.
Andrew291
92 Posts
0
January 29th, 2016 02:00
You may also want to ensure you naming within arrays and VPLEX is unique. ViPR could be getting confused between the arrays if naming is the same.