What determines EVA4000 Lun's Managing Controller

[Tim Nelson]

EVA4000
What determines a LUNS managing controller.

I as because I am seeing a group of 6 luns presented to one server assigned to "top controller"

For other luns going to other servers there seems to be a mix, top or bottom.

Any ideas or comments ?

Can it be changed ?

[gabbar · Accepted solution]

What determines a LUNS managing controller?

http://bizsupport.austin.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=3664583&prodTypeId=12169&objectID=c01733603

Can it be changed ? yes, this can be done by using the preferred path option in CV EVA.. this is well described in EVA user guide

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01721462/c01721462.pdf?jumpid=reg_R1002_USEN

check out page 42

hope this helps

[Tim Nelson]

Thanks Gabber,

I had the right manual just needed the kick to get the right page.

Any idea why all 6 luns would have been assigned to top_contoller instead of being randomly set top and bottom ?

I am trying to find the relationship between that assignment and 11.31 multipathing.

Is multipathing forcing all to top or something else. I certainly would like to spread the love but not fight the software.

I am going to review a number of other hosts ( non-11.31) to see if any primary paths are set to the wrong managing path. If so, according to the documents, the EVA should have recognized the proxy ios and change the managing controller..

[Uwe Zessin]

Initial assignment can be set with CV-EVA. A host can request an ownership transfer (at least on active/passive arrays).
The EVA also monitors the traffic and if the majority of traffic goes through the non-managing controller it will transfer ownership.

Your system state is very typical for a VMware ESX environment. It uses the first path it finds for data I/O to all virtual disks. After some time, all vdisks have moved to one controller, oops.
In ESX3 you have to make an explicit path selection to prevent this.

I guess "11.31" implies HP-UX? Maybe it works similar.

[gabbar]

"Any idea why all 6 luns would have been assigned to top_contoller instead of being randomly set top and bottom ?"


from white paper "HP-UX 11i v3 Native Multi-Pathing for Mass Storage"
=======================================================================
Note: For devices implementing the T10 ALUA (Asymmetric Logical Unit Access) standard (refer to SPC-3 section 5.8), the SCSI stack on HP-UX 11i v3 automatically detects the set of lunpaths to the optimized target port groups and uses only these lunpaths for I/O transfer according to the I/O load balancing policy set for the disk device. Lunpaths to un-optimized target port groups are put in standby state and are not used for I/O transfer. You can disable this behavior by setting the alua_enabled attribute to â falseâ for the disk device. In this case the support of the ALUA standard is ignored by the SCSI stack and all lunpaths are used for I/O transfer.
=======================================================================

so please check if this enabled on the host


You can download the Whitepaper from following link

http://docs.hp.com/en/native-multi-pathing/native_multipathing_wp.pdf

[Tim Nelson]

Uwe,
My thought would then be to reassign 1/2 the luns to bottom controller and then force/re-config 11.31 multpath to follow that path.

Thanks Gabbar,

[Uwe Zessin]

Yes, that makes sense.