VMware 3.5 and HP EVA with CA

[Siegwerk]

Dear all,

I´m struggling a litte bit when trying to understand how to configure VMware and the EVA/Continous Access. I found an HP guide (http://www.amrila.com/wp-content/uploads/2009/05/evacavmware.pdf) which confuses me.

On page 11 at the bottom you can read: "On the destination EVA (here: EVA-2) present all corresponding Vdisks with the same LUN IDs as on the source EVA-1."

So, i setup the ESX environment, created the LUNs on source, created the Data Replication groups and presented the source LUNs to the ESX hosts.

Do I also have to present the destination LUNs to the hosts?

What do I have to do if the source EVA has to go offline. My understanding: shutdown VMs, change LVM setting "LVM.DisallowSnapshotLun" to 0, unpresent old source LUNs, present destination LUNs one by one to one host, rescan that host and then re-register all virtual machines by searching the datastore and adding the vmx to inventory.

Seems too complicated for me... 😞 is there an easier way? And how will it be with VSphere 5 (as I read that the LVM settings are no longer available)?

Thanks in advance.

Peter

[a_p_ · Accepted solution]

If you'd have to do all of the steps you mentioned, CA would be pretty useless.

You don't necessarily need to present the mirror/target LUNs to the hosts. However, I'd recommend you do this to avoid loosing time in case you need to fail over. If all the LUNs from the target EVA are presented properly, all you need to do - on the storage side - in case of a necessary failover is to initiate the failover in the target replication group.

André

[Siegwerk]

Dear André,

thanks for your quick answer. So, VMware recognizes them as known LUNs and links the old virtual machines to the new storage?

Do I have to change one of the LVM parameters in case of a failover?

Best regards

Peter

[a_p_]

Exactly, with CA in place the mirrored LUN on the target EVA does not have to be resignatured after a failover.

I just did this a few weeks ago to migrate LUNs to another EVA node. It works perfectly.

André

[Siegwerk]

An additional thought that came in mind: As we don´t start from scratch, the presented target LUN does not have the same LUN ID as the original LUN.

That will cause problems, right?

Best regards

Peter

[a_p_]

Yes, this will definitely cause issues. You need to ensure the LUN-IDs are the same. This can be achieved by using the "Assign LUN" button rather than "Present Vdisk" when you present a LUN in Command View.

André.

[a_p_]

... almost forgot to mention: After failing over a LUN (replication group) you need to set the now active LUN on the target EVA from "read-only" to "read/write" access.

André

[Siegwerk]

Thanks once again for your great help.

As our environment was already completely setup with two EVAs, I have to create new LUNs and move the VMs to get a consistent state of LUN IDs on both sides. It´s time consuming but thanks to storage vmotion it will work without downtime.

I already created a new LUN, started the replication and presented it with the same LUN ID from both EVAs. Stopped the VM, failed over (Fail over and suspend), let the hosts scan for new storage and could start the VM without doing anything else. Remembering my first plan how to do it... this way seems a "little" bit more comfortable 😉

I hope with VSphere 5 it will stay the same way.

[a_p_]

I hope with VSphere 5 it will stay the same way.

Yes it will (if the EVA you have is supported!)

Thanks for the feedback though.

Two more hint. Unless you already do this,

- consider creating a separate replication group for each LUN. This will make it easier to e.g. failover LUNs for load balancing the EVAs.

- make sure you set a managing controller for each LUN (the same for the source and target LUN) There have been severe issues with some EVA firmware versions if the managing controller was not the same on the source and target.

André

[Siegwerk]

Thanks. I will take it in consideration.

Peter