HPE Storage Users Group

You are right, you need to enable path_management for any new rcg via cli.

But when updating from inform os 3.1.2 to 3.1.3, you need path_management active for all existing rcg where both primaries and secondaries are exported to the hosts. But: The default is "off" (no path_management), and the installer for InformOS 3.1.3 needs to know for which rcg to activate it. It does by looking at the auto_failover policy - all rcgs who have auto_failover active get path_management. The problem: If you have only manual transparent failover (mtf) implemented, you 1) need path_management, but 2) do not have auto_failover set and therefore don't get path_management. Thus, your ESX will fail in destinguishing primaries from secondaries, and crash. Hard.

I did not test for 3.1.3 MU1 yet, but you need to activate auto_failover for all rcg in a mtf-config in order to successfully update from 3.1.2 to 3.1.3!

This is a nightmare. I hope hp are aware of this and include it in their upgrade plans as I have several customers who are looking to move up to 3.1.3 and have peer persistence setup.

And hp will be doing the upgrade.

phoglind wrote:About Cluster extension I was hoping they would support MSCS without any extra licenses except for Repl suite and Peer Persistence in 3PAR.

Path Management Policy seems to be changed in 3.1.3 and you need to set that trough CLI on all VMware RCgroups.

And yes we have Peer Persistence license and will repl synchronously.
All Pri/Sec volumes also need to have the same WWN as well as exported with the same LUN ID otherwise you will end up with multiple devices when scanning the hba's

We have implemented Quorum Witness on 3rd site and will add automatic failover protection for necessary volumes.

Remind me please, where is the setting to make sure they have the same wwn?

In the 3.1.3 Remote Copy guide under section 21 and page 164 it says:

Before you begin non-disruptive failover:
3: Ensure that all volumes to be exported on all primary
and secondary arrays share the same volume WWN.

I've played around with different ways to create the secondary volume.

1. From Provisioning tab right click an volume to be added to rcopy group
This way makes an secondary volume with altered WWN id

2. From Remote Copy tab right click and edit an rcg and add an new primary volume
This way both volumes get the same WWN id

I think I jumped across some text in the remote copy guide saying there are cli tools to sync this WWN id as well

Interesting, I've always done it using the first option, and I've never had an issues with peer persistence, even after thorough testing and manual/automatic failovers and fallbacks.

I thought VMware used the signature to identify the volume and so this wouldn't matter?

Where does it show the wwn of the vlun please? I don't have my own 3par to play with, only customers.....

3PAR-wise, it's in Provisioning --> VLUNS --> Active VLUNs and is called "Virtual Volume WWN". The last four digits are the last four digits of the 3PAR Serial Number (at least on our V400). There is another WWN-column ("WWN/iSCSI Name") which is something completely different, don't mix them up!

With the CLI, you can see the WWN with

On ESX, it's part of the the naa.<WWN>:1 - string.

On creating vvs with a common WWNs per CLI, you have two options as well:

1) Create primary and secondary on your own and change the secondarie's wwn per

2) Create just the primary volume, create the remote copy group, and make rcopy create the secondary with the command.

Right, so as long as you use the remote copy wizard to create the target volume it will automatically create it with the same wwn.