We have a VMAX 40K on Enginuity 5876, being managed by a Unisphere for VMAX vApp running SE 7.6.2. I have an AIX host with a dozen source TDEVs. From the vApp, I created a symclone session from the AIX source TDEVs to another batch of TDEVs, using just the source/target Symm Devs. Session ran just fine and completed with no issues.
Two weeks later, the AIX admin wants to create his own symclone session, using the same source TDEVs, but different destination TDEVs. He created a local device group on the host and attempted to activate it. He didn't get an error, but immediately saw my symclone target IDs, not his. In fact, every attempt to active his session completed successful, but only ran my session to my target TDEVs (as defined in my file), not his TDEVs (as defined by his device group).
We terminated my session, then his activation completed without any errors. I would expect either his symclone command from the host should have failed at the command line, or it should have re-established my session and updated the target devices with new data (the clone session was never activated from what I could tell).
I'd suggest giving it another try, but have your AIX administrator use the -exact flag against his device group when initially creating/activating his clone sessions. The -exact flag tells symclone to use the pairing relationships defined in the specified DG/CG/file, instead of reusing the existing clone sessions.
No, this was specific to the device group only. When using device files, each session worked without a problem. This was specifically activating his device group....
Try setting the SYMAPI_COMMAND_SCOPE = ENABLE in the options file.
This tells the symclone command to only operate on the exact pairing specified in the device group. If you use a file, then this is not necessary, as it is being told explicitly which pairs to operate on.
Sure enough, Sean and RHaselton are spot on. When we call the symclone activate or recreate with the "-exact" flag, ew get the expected behavior. Without -exact, however, the activate only appears to look at the already-created session.
On another host, I tried RHaselton's suggestion and changed the daemon.options file. Sure enough, the symclone activate on the device group worked as expected.
But my admin and I want to know: why didn't the symclone just fail or report an error, instead of leading us to believe everything happened as expected? When I double-checked, it never ran his session, only mine. Had he attempted to vary on his volumes, he would have found nothing but empty disks.
Here is the output from "symcli -env" and looking at the COMMAND_SCOPE explanation:
SYMCLI_COMMAND_SCOPE : Sets the scope of the device selection process.
ENABLED limits the operation to the devices within
the scope of the command. DISABLED performs the
operation on the devices within the scope of the
command plus any additional devices associated by
session and/or state. The default is DISABLED.
So by default, when trying to act upon a concurrent setup (single src, multiple tgt's), it will only report and act upon the currently associated tgt devices, since they are already associated with the source. It can be confusing if you've never used DG's with concurrent setups.
The only thing that puzzles me about your original question is usually when I try this, I get a message stating that the device(s) are already in the requested state (created or activated). It may be an order of operations thing there.
Looks okay to me. So, we set the daemon options flag SYMAPI_ALLOW_DEV_IN_MULT_GRPS = ENABLE, so that we can take the same source devices, and put them into multiple device groups. Then, we tried to establish a clone on the other device group:
seancummins
2 Intern
•
226 Posts
2980
1
Posted October 2nd, 2014 11:00
Karl,
I'd suggest giving it another try, but have your AIX administrator use the -exact flag against his device group when initially creating/activating his clone sessions. The -exact flag tells symclone to use the pairing relationships defined in the specified DG/CG/file, instead of reusing the existing clone sessions.
Thanks,
- Sean