HPE Storage Users Group

P10800, running 3.1.3 MU1.

We want to be able to failover with SRM individual applications.
So I created application based VV's, and Remote Copy Groups for each app.
The RCG VV sets were then presented to my host set.
SRM is integrated with SRA, and the 3PAR. Everything tested out ok, and works.

The problem I run into now, is I need to add a new VV to an existing RCG. No big deal. I create the new VV, and go into remote copy, and add it to the RCG. And it errors out. "Unable to extend vv set, due to conflict on lun xx, set <host set>".

VVset1 - LUN ID's 1-10
VVset2 - LUN ID's 11-20
Host Set - VVset1+VVset2.
When adding a new VV to VVset1, it tries to use LUN ID 11 which is already in use, and not the next available LUN ID 21.

The VV sets were exported using Auto LUN assignment. I don't want to have to micro-manage LUN ID#'s.

Has anybody run into this before?
Is there any way to correct this, or work around?

Thank you.

Scott

The best idea you can have is stop using vvset.
I suggest to our customer to never use both hostset and vvset.

Both Remote 3PAR support, and our ASM has told us to use the VVset's that the Remote Copy Group creates when exporting to the hosts.
In the training classes, the instructor recommended using Host and VV sets.
To change it all at this point would be very, very painful. But I suppose it could be done.
About 1000 VM's would be impacted.

1000 VMs on 20 datastores... Well... That's quite a huge density...

maybe a lot of small VM's?

When we implemented our 3pars, the HP rep advised that host sets are great, VV sets not so much. So just use the host sets.

lol. no.
that was just an example.
183 datastores across 23 volume sets.
Varying between 1TB, or 2TB in size.
Total used about ~300TB

not for nothing, but can you add an additional range of luns to the vvset export?

So for instance, vvset1 uses 1-10, vvset2 uses 11-20. The issue is adding the 11th volume to vvset1 is more luns than it was originally configured for. So could you set it up like:

vvset1 export: 1-10,21-30
vvset2 export: 1-10,31-40

?

I don't know because I don't use vv sets, but was just thinking

When you add the VV to a set, there is no option to change it's LUN ID or set a new range. it just auto increments...in the GUI.
There might be an option in the CLI. I haven't looked into that yet.

Hi All,

Were you able to resolve this issue. I have run into the same situation now.

We have VV sets and Host sets.

The VLUN range for VV set has reached maximum limit and not able to add VV to VV set.

Regards,
Sri

ScottB: The best practices guide (4AA4-4524ENW) says "always leave a gap of LUN IDs between two volume sets." I think you have to either change your setup, or you add another vv set, put all new vvs in there and remember to "always leave a gap of LUN IDs between two volume sets"...

We learned to NEVER EVER use the VVsets that remote copy groups create, the hard way: If you do so, you can not stop mirroring and delete the rc-group (for whatever reason), because you would loose the vv-set - and so, your servers would loose access to the vvs...IMC and CLI simply refuse to delete the rc-group. We had problems with an array, wanted to mirror to another one for the time HP needed to analyze and repair the damaged system, but were stuck with rc-groups including the damaged system. VVs can not live in two synchronous rc-groups at the same time, but we could not delete the old, stopped one because of exporting the rc_<whatever>-set, and therefore needed a downtime. Big fun.


RitonLaBevue: To be honest, I completely disagree. VV- and Host-Sets are IMHO one of the smartest things the 3par-mgmt-concept has - if used correctly. Did you encounter any serious problems because of using sets? The mentioned best practices guide is very distinctive about his:




The only thing that sucks about sets is those 250+ additional "RCP_" vv-sets littering our V400...

_________________
When all else fails, read the instructions.