FlashCopy NoCopy Setup
Version 6.3.0.1

IBM calls this a Global Mirror with Change Volumes

The main purpose for this is to lessen the resource use between two V7000 during the mirroring process.
A standard global mirror on a busy or performance miss matched V7000’s can cause 1920 error and stop the mirroring process.
Global Mirror with Change Volumes helps eleviate this problem by on sending changes and only sending when it can.
If a mirror process is missed it will try again every 300 seconds by default.

On the source V7000 – Choose which volume you want to mirror
On the target V7000 – Create a volume with the same name and size of the source volume.

On the source V7000
Create an new consistency group
Copy Services
Remote Copy
Click New Consistency Group
Enter the Name – Next
Select On another system, Select the target V7000 – Next
If you are ready to add a relationship to this group select yes – Next
Select Global Mirror with Change Volumes – Next
Next
Select the Master and Auxiliary Volumes (Should be the same name) – Add
Select Yes to add a master Volume – Next
Select Create a new master volume – Finish
Click Next, unless you want to add more Volumes to the consistency group
Select No, the volumes are not synchronized – Next
Select No, do not start copying – Finish

On the target V7000
Goto – Copy Services
Remote Copy
Expand the new consistency group with the plus
Right Click on the new relationship (eg. rcrel22)
Select Global Mirror Changes Volumes – Click Create New
Close

On the source V7000
Right Click on the new consitency group – Click Start

Useful commands CLI:
lsrcconsistgrp – Mirrors marked cycling mode are your Global Mirror with Change Volumes
lsrcrelationship
lsrcrelationship 5 – Or the appropriate number of a Global Mirror with Change Volumes

V7000 and Directory Services

http://www.techpository.com/wp-content/uploads/2012/03/V7000-and-Directory-Services.pdf

You can use the command-line interface (CLI) to configure the Storwize® V7000 to authenticate users against servers implementing the Lightweight Directory Access Protocol (LDAP), including IBM Tivoli Directory Server (ITDS) and Active Directory (AD).

To enable user authentication with LDAP, follow these steps:

Configure LDAP by issuing the chldap command.
This command provides default settings for both IBM Tivoli Directory Server (ITDS) and Active Directory (AD). For example, to configure authentication with ITDS schema defaults and Transport Layer Security (TLS), issue the following command:

chldap -type itds -security tls

LDAP configuration can be inspected with the lsldap command.
Note: TLS is recommended because transmitted passwords are encrypted.
Specify the mkldapserver command to define up to six LDAP servers to use for authentication.
Multiple servers can be configured to provide access to different sets of users or for redundancy. All servers must share the settings configured with chldap. For example, to configure an LDAP server with a Secure Socket Layer (SSL) certificate and users in the cn=users,dc=company,dc=com subtree, issue:

mkldapserver -ip 9.71.45.108 -basedn cn=users,dc=company,dc=com -sslcert /tmp/sslcert.pem

You can also configure which servers are preferred to authenticate users.

Specify lsldapserver for LDAP server configuration information. Specify chldapserver and rmldapserver to make changes to the configured LDAP servers.
Configure user groups on the system by matching those that are used by the authentication service.
For each group of interest known to the authentication service, a Storwize V7000 user group must be created with the same name and with the remote setting enabled. For example, if members of a group called sysadmins require the Storwize V7000 Administrator (admin) role, issue the following command:

mkusergrp -name sysadmins -remote -role Administrator

If none of the user groups match a Storwize V7000 user group, the user cannot access the system.
Verify your LDAP configuration using the testldapserver command.
To test the connection to the LDAP servers, issue the command without any options. A username can be supplied with or without a password to test for configuration errors. To perform a full authentication attempt against each server, issue the following commands:

testldapserver -username username -password password

Issue the following command to enable LDAP authentication:

chauthservice -type ldap -enable yes

Configure users who do not require Secure Shell (SSH) key access.
Storwize V7000 users who must use the remote authentication service and do not require SSH key access should be deleted from the system.
Remember: A superuser cannot be deleted or use the remote authentication service.
Configure users who require SSH key access.

All Storwize V7000 users who use the remote authentication service and require SSH key access must have the remote settings enabled and a valid SSH key configured on the system.

If the management ip gets changed to something inaccessible you can fix this problem through the CLI

1) Log into the problem V7000 through the service ip using putty or another terminal application

2) Take a look at the current cluster IP configuration

svcinfo lsclusterip
cluster_id cluster_name location port_id IP_address subnet_mask gateway IP_address_6 prefix_6 gateway_6
00000200A0131313 v7000_B local 1 0.0.0.0 0.0.0.0 0.0.0.0
00000200A0131313 v7000_B local 2
00000200A0121212 v7000_A remote 1 192.168.1.10 255.255.255.0 192.168.1.1
00000200A0121212 v7000_A remote 2
3) Enter the correct  IP, Gateway, and Subnet Mask with the following commands:

svctask chclusterip -clusterip 192.168.1.20 -port 1
svctask chclusterip -gw 192.168.1.1 -port 1
svctask chclusterip -mask 255.255.255.0 -port 1

4) Verify your changes
svcinfo lsclusterip
cluster_id cluster_name location port_id IP_address subnet_mask gateway IP_address_6 prefix_6 gateway_6
00000200A0131313 v7000_B local 1 192.168.1.20 255.255.255.0 192.168.1.1
00000200A0131313 v7000_B local 2
00000200A0121212 v7000_A remote 1 192.168.1.10 255.255.255.0 192.168.1.1
00000200A0121212 v7000_A remote 2

There seems to be a bug in 6.2 and 6.3 of IBM’s V7000 code that when replacing a bad drive, the V7000 is not properly deleting the bad drive information from the system.
The end result is that you have a drive that shows up in the list,but you cannot do anything to it in the GUI.

Repair procedure:
Login through the CLI

If repairing drive ID 33 enter the following:
1) svctask chdrive -use failed 33
2) svctask chdrive -use unused 33

The GUI will need refreshed to reflect the changes properly.  You may need to log out then back in.