HPE EVA Storage
1748224 Members
4487 Online
108759 Solutions
New Discussion юеВ

Re: EVA 4400: controller 2 never gets managing controller of a LUN

 
sam bell
Regular Advisor

EVA 4400: controller 2 never gets managing controller of a LUN

Hi,

even after creating a new vDisk with Preferred path/mode set to "Path B" the managing controller of the LUN always is controller 1 and not controller 2.

When changing the preferred path/mode for existing LUNs that are presented to VMware vSphere 4 from i.e. Path A (Controller 1) to Path B (Controller 2), the managing controller changes for some seconds but will then automatically revert to controller 1. This also happens when using fixed paths to Controller 2 in vSphere (where from my understanding the EVA should actually transition the LUN to the controller that is serving the most I/O).

Any ideas why it's not possible to get LUNs managed by controller 2? Firmware of the EVA 4400 is 09522000.

Thanks
11 REPLIES 11
V├нctor Cesp├│n
Honored Contributor

Re: EVA 4400: controller 2 never gets managing controller of a LUN

Please read this:

http://h20195.www2.hp.com/v2/getdocument.aspx?docname=4AA1-2185ENW.pdf

Section:

ESX multi-pathing configuration

sam bell
Regular Advisor

Re: EVA 4400: controller 2 never gets managing controller of a LUN

Thanks,

however, I've already read this document before and it actually states that I indeed should be able to change the controller ownership of a LUN by changing the preferred path mode. It also states that when using MRU or Round Robin in vSphere I actually should see a change to the new optimized path after changing the path mode on the EVA.

However, I'm not even able to change the path mode to controller 2 - even after setting path mode B, the managing controller means for the given LUN remains controller 1 or will revert back to 1 after seconds.

Uwe Zessin
Honored Contributor

Re: EVA 4400: controller 2 never gets managing controller of a LUN

Have you tried it with Path-A/B failover/failback?

That is the preferred setting when you use the RR path policy on ESX 4.
.
sam bell
Regular Advisor

Re: EVA 4400: controller 2 never gets managing controller of a LUN

Yes, but this doesn't change anything. After setting the path policy to path B-failover/failback, Command View shows that controller 2 is the managing controller. However, when doing a storage rescan in vSphere the paths remain the same (policy set to Round Robin which is ALUA aware and therefore should move to the optimized paths). After a minute or so, Command View again shows controller 1 as managing controller.

As written above, this also happens when creating new vDisks from Scratch - even when setting them to controller 2, controller 1 is shown as managing controller.

Seems to be an issue with the EVA and not with VMware I think.
Uwe Zessin
Honored Contributor

Re: EVA 4400: controller 2 never gets managing controller of a LUN

You don't need to do a storage rescan on ESX - the servers should notice the change within some minutes.
.
sam bell
Regular Advisor

Re: EVA 4400: controller 2 never gets managing controller of a LUN

Anyway, it doesn't work. The managing controller for the given LUN reverts back to controller 1 in less than a minute.
Uwe Zessin
Honored Contributor

Re: EVA 4400: controller 2 never gets managing controller of a LUN

That sounds strange. Maybe there is something wrong with Controller 2.
Cache battery? Anything in the controller logs?
.
sam bell
Regular Advisor

Re: EVA 4400: controller 2 never gets managing controller of a LUN

At least no errors. But controller 1 is reporting a significant amount of these messages:

http://www.abload.de/img/4400cachee4es.jpg

(An HSV300 controller has changed Battery Cache policy
View corrective actionsCorrective action code: 00)

I don't know whether this is normal and reporting controller controller 1 and not controller 2.
Uwe Zessin
Honored Contributor

Re: EVA 4400: controller 2 never gets managing controller of a LUN

It is not OK. Maybe it is this error:

c01941332 - ADVISORY: HP StorageWorks 4400 Enterprise Virtual Array can report false battery Hold Up Time (HUT) event: 0x0E13CA19

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c01941332
.