Hooking up a EVA5000 (VCS 3.028-Active/Passive) to a vMware Esx Machine

[Alzhy]

Planning to hook up a vMware ESX machine to our SAN to our EVA5K. In the Bewst Practices Doc - it is written:

Single point of attachment VMware Infrastructure 3 servers must be configured (zoned) so they attach to the EVA through a common controller and host port in order to avoid controller "thrashing". Thrashing is a condition where both controllers alternate as the active or owning controller of a shared virtual disk. This behavior can be observed using EVAperf to monitor shared LUNs.

Does anyone know what this means as far as Zoning?

Also, what other things should we be aware of?

Thanks a lot!

[BelaGuez · Accepted solution]

Zoning is required with any single attached server.

Zoning is not really covered in any of the SAN material or courses as its something thats done on the Fibre switches rather than anything to do with the EVA itself.

As I'm sure you know due to the way EVA's work that for every HBA a host has it can see two paths into the array. So for a normal dual attached server it sees four paths and thats why you normally install SecurePath or MPIO type software or kernel versions.

However those software products only support a dual attached host. As far as I know there is no software available to support just a single connected server.


Therefore zoning refers to configuring the Fibre switches themselves into zones so that the single attached server can only see a path into the array through one of the two controllers.

This can be done either on a port based level or at a WWID level. In our environment we have zones created that contain the WWID aliases, for example to create a zone on a Brocade Fibre switch you whould use the following commands:

aliCreate "Name of server", "50:00:aa:aa:aa:aa:aa:aa" (WWID of ESX server's HBA)

This creates an alias within the switch for this host which just makes things easier.

zoneCreate "Name of Zone", "EVA1_L_FP2;Alias of Server from above"

This then creates the zone, the EVA1_L_FP2 is referencing an alias that should already exist with your switches from when HP did your install.

There are 5 alias's for the controllers. A single alias that contains all 4 WWID's of the 4 controller ports and then an alias for each individual controller port.

E.g.
EVA1_L_FP1
EVA1_L_FP2
EVA1_U_FP1
EVA1_U_FP2

The zone then needs to be added to the running configuration of the switch and enabled. Instructions for this can be found in the switch documentation.

Be aware that you need to carefully plan zoning to ensure that you don't overload individual controllers or controller ports

[Alzhy]

Thank you BelaGuez,

My question really is how you interpret the quote from the vMware ESX Best Practices Document w/c I will quote again:

"Single point of attachment VMware Infrastructure 3 servers must be configured (zoned) so they attach to the EVA through a common controller and host port in order to avoid controller "thrashing". Thrashing is a condition where both controllers alternate as the active or owning controller of a shared virtual disk. This behavior can be observed using EVAperf to monitor shared LUNs."


Am I to assume your interpretation means the ESX will only be hooked up using 1 HBA?

Can you please elaborate more?

[BelaGuez]

Thats what I took "Single point of attachment VMware Infrastructure 3..." to mean yes. That you would be connecting the ESX server using only one HBA.

Whether or not you can use two HBA's I'm not sure with ESX

[Alzhy]

BelaGuez,

Here's where I got the vMware to EVA Best Practices.

http://h71019.www7.hp.com/ActiveAnswers/downloads/VMware3_StorageWorks_BestPractice.pdf

I think you're correct. The clause was meant for single HBA connections. Dual Connections are as well supported.

[Uwe Zessin]

You are correct:

- multipath connections are supported and VMware ESX server knows how to deal with them

- the confusing paragraph describes single-path connections. If you have two or more servers, you are supposed to 'connect' them to the same controller port (e.g. A-FP1). Otherwise, a server that is connected to the non-owning (passive) controller (B) will initiate a failover for all affected virtual disk(s).

Now, this will take the connections to controller A into passive mode which the servers connected to A-FP1 do not like. They will initiate a failback from B to A and so on...