Installing PowerPath software on a Windows 2003 host

Overview This procedure describes how to install PowerPath on Windows Server 2003. Note:This procedure is specific to the installation of PowerPath versions 4.5 to 5.0, which is the current shipping version for Windows 2003 hosts.  For instructions on installing older versions of PowerPath, refer to the applicable PowerPath installation manual available on PowerLink. This procedure is based on content from the following EMC manual: PowerPath for Windows Installation and Administration Guide This document can be obtained from the EMC Powerlink website at: http://Powerlink.EMC.com You must be logged in as the Local System Administrator to proceed. Verify the following prior to the installation of PowerPath: ·        Review the patch ReadMe files to determine which patches (if any) you want to install after PowerPath, and whether those patches have any added prerequisites that must be met before you install PowerPath. ·        Determine if the PowerPath software you are installing requires the removal or presence of a previous version of PowerPath.  Some full versions require the previous version to be removed while others do not.  Also, some patches require the full version to be present while others require it to be removed.  Refer to the PowerPath Release Notes and/or PowerPath patch readme files for your specific version to determine what needs to be present/removed and if and when a reboot is necessary in order to install your specific PowerPath software version and/or patch. These documents are available on http://Powerlink.EMC.com. Note:A “failed redundancy” state can occur if PowerPath is installedon a host with mirrored disks. This state only happens if diskmanagement applications (that use the dmadmin service) arerunning when PowerPath is installed. To prevent this, close all disk management applications(including diskmgmt.msc and diskpart.exe) and stop thedmadmin service before installing PowerPath. If applicable, stop all I/O and close all applications that access storage devices.

MPIO framework considerations: Note that PowerPath 4.6.x requires Microsoft MPIO framework 1.16 or later. ·        If the MPIO framework is not installed on the host, the PowerPath 4.6.1 installer installs MPIO framework 1.16.; PowerPath 5.0.0 will install 1.17 ·        If a version of the MPIO framework less than 1.16 is installed on the host, the PowerPath installer prompts you to upgrade to version 1.16. If you do not upgrade, PowerPath installation aborts. If a version of the MPIO framework is greater than 1.16 is installed on the host, the PowerPath installer notifies you and then continues with the installation.

Verify single device paths: Ensure that there is only one logical connection per logical device. If necessary, disconnect all additional HBAs/NICs, hubs, switches other than the primary channels.  Note: Doing this prevents the host from seeing the same LUN twice before PowerPath is configured.

Insert the PowerPath CD-ROM: Insert the PowerPath installation CD in the CD-ROM drive and begin the installation. If autoplay is enabled, your browser launches and displays the Getting Started page. You can install the software from the Installation section by clicking the appropriate link for your operating system. Then either: Select Run this program from its current location and click OK to proceed with the installation. Select Run from the Start menu if autoplay is not enabled.

Begin Install: In the Run window, either browse to or enter the name of the PowerPath installation program and click OK.

Continue Install: Complete the information as prompted on the next four screens.

Select your options: Use the Destination Folder screen to installPowerPath in a directory other than the default directory (ifdesired). Note: It’s best to install PowerPath in the default directory as no additional action is required to install in the default directory. ·        If you are going to install PowerPath in itsdefault directory (recommended), clickNext and skip the remainder of this step to continue with the next step below. ·        To install PowerPath in a different (non-default) directory,click Change. The setup wizard prompts you to browse toyour destination folder. Select the destination folder, and clickOK. Caution:Do not specify the Windows System directory for yoursystem (specified by the %SYSTEMROOT% environmentvariable). PowerPath will not function correctly if it isinstalled in this directory.  Click Next.

Continue Install: In the Ready to Install the Program dialog box, click Install. Note:If you do not already have a license in the registry, the EMCLicensing Tool displays.

Register PowerPath When prompted by the EMC Licensing Tool, enter your PowerPath registration number in the License Key field.  Click Add and then OK. Note: The PowerPath registration numberis printed on the License Key Card, which was delivered with the PowerPath media kit. You may enter multiple registration numbers as PowerPath is supported on different storage systems. If you are upgrading from a previous version, PowerPath saves the existing license key, and no input is required. Caution: Failing to enter a registration number will result in the installation of PowerPath SE, which is the default policy without a valid PowerPath license. If you fail to enter the registration number during installation, it can be entered at a later point.

Finish: Click Finish in the next dialog box and when prompted to reboot the host,click No. Instead, from the Start menu, select Shut Down and then click OK.

Reconnect other I/O interfaces: Reconnect the additional HBAs/NICs, hubs, switches, etc. that you disconnected earlier.

Power up boot: Power up the system. PowerPath is fully configured with multiple paths to logical devices at boot up.

Check for patches If necessary, install any PowerPath patches from the following URL: http://powerlink.emc.com Note: A readme file that explains how to install the patch that accompanies every patch release.  This file will also state whether you need to reboot the host after the installation of the patch.

Verify PowerPath sees new paths The operating system must recognize new paths before PowerPath can do so. Normally, no action is needed; the operating system detects new paths automatically. Depending on the type of HBA installed, you may have to scan for hardware changes in the device manager.  Alternately, reboot. To verify that PowerPath sees all new HBAs and paths to storage devices, use the following command in the PowerPath utility: powermt display dev=all To test and validate any new path(s) with PowerPath functionality, enter: powermt restore

Installing Emulex HBA(s) on a Windows host

1.	Set jumpers on old models only: For older HBA models only, jumpers may need to be set: Set the HBA jumpers as shown in the diagram below to program it for use with the Windows host.  This step does not need to be performed on newer HBAs.  Note:  The LP850-EMC has no user-configurable jumpers.	£
2.	Install Adapter in card slot With host system power removed, install the HBA(s) by following the instructions included with your adapter. The adapter installs into a single slot and has no user-configurable jumpers or switches. When choosing an HBA for your host computer, it is important to know which HBA is compatible with its PCI/PCI-X/PCI Express slots.  Certain HBA models have specific voltage requirements or physical limitations that allow them to only work in specific slots. Computers today have several different bus slot types for accepting HBAs.  PCI, PCI-X, PCI-X 2.0, and PCI-Express. PCI slots can be 32-bit and 64-bit (denoted by their 124-pin or 188-pin connectors.)  These slots have plastic “keys” that prevent certain HBAs from fitting into them.  These keys work with the cut-out notches in the HBA edge connecter so that only compatible HBAs will fit into them.  This is done because of the voltage characteristics of the HBA. Inserting a 3.3v HBA into a 5v slot would cause severe damage to both the HBA and the server.  Therefore, the slot keys denote the type of voltage provided by the slot and effectively prevent a voltage incompatible HBA from being inserted.  The following figure shows how PCI slots will appear with their keys and what type of voltage is provided for each slot type. The figure below shows the HBA edge connecters compatible with the PCI slots shown in the figure above.  Note HBA #5 which shows a universal HBA edge connecter.  Universal HBAs are compatible with both 3.3v and 5v PCI slots. Emulex offers HBAs for each bus/slot type available. The following table shows each of the EMC-supported Emulex HBAs, and their respective slot requirements. Be sure to consult both your server user guide and Emulex to ensure that the HBA you want to use is compatible with your server's bus. HBA PCI spec BUS length Power Slot key LP7000 PCI 2.2 32-bit 5V Universal LP8000 PCI 2.2 (2.1 listed?) 64-bit 5V Universal LP850 PCI 2.2 64-bit 5V Universal LP9002L PCI 2.2  64-bit 3.3V Universal LP9002DC PCI 2.2 64-bit 3.3V Universal LP982 PCI-X 1.0a & PCI 2.2 64-bit 3.3V Universal LP9802 PCI-X 1.0a & PCI 2.2 64-bit 3.3V Universal LP9802DC PCI-X 1.0a & PCI 2.2 64-bit 3.3V, 5V 3.3V LP1050/LP1050DC PCI-X 1.0a & PCI 2.3 64-bit 3.3V, 5V Universal LP10000/LP10000DC PCI-X 1.0a & PCI 2.3 64-bit 3.3V, 5V Universal LP1050Ex/LP10000ExDC PCI Express x4 lane 3.3v n/a LP1150/LP11002 PCI-X 2.0 & PCI 3.0 64-bit 3.3v 3.3v LPe1150/LPe11002 PCI Express x4 lane 3.3v n/a Note that a few HBAs are keyed universally, but require 5 V power (LP7000, LP8000, LP850.) They will fit into a 3.3 V PCI/PCI-X slot, but will not work unless the slot is capable of universal (3.3 V and 5 V) signaling.  Consult your server user guide or manufacturer.  Also, the LP9802DC, while capable of 3.3 V or 5 V signaling operation, fits only into a 3.3 V PCI/PCI-X slot. Remember, some of the older HBAs are tall (also referred to as full-height) and may not fit into a server with a low-profile chassis.  These factors must be considered before implementing your configuration to avoid unnecessary delays and possible equipment swaps or returns.	£
3.	Apply power and boot Reapply power and allow the system to boot normally.	£

LUN Migration in CLARiiON

LUN Migration

The process of a LUN Migration has been available in Navisphere as of Flare Code or Release 16. The LUN Migration is a move of a LUN within a Clariion from one location to another location. It is a two step process. First it is a block by block copy of a “Source LUN” to its new location “Destination LUN”. After the copy is complete, it then moves the “Source” LUNs location to its new place in the Clariion.

The Process of the Migration.

Again, this type of LUN Migration is an internal move of a LUN, not like a SANCopy where a Data Migration occurs between a Clariion and another storage device. In the illustration above, we are showing that we are moving Exchange off of the Vault drives onto Raid Group 10 on another Enclosure in the Clariion. We will first discuss the process of the Migration, and then the Rules of the Migration.

1. Create a Destination LUN. This is going to be the Source LUN’s new location in the Clariion on the disks. The Destination LUN is a LUN which can be on a different Raid Group, on a different BUS, on a different Enclosure. The reason for a LUN Migration might be an instance where we may want to offload a LUN from a busy Raid Group for performance issues. Or, we want to move a LUN from Fibre Drives to ATA Drives. This we will discuss in the RULES portion.

2. Start the Migration from the Source LUN. From the LUN in Navisphere, we simply right-click and select Migrate. Navisphere gives us a window that displays the current information about the Source LUN, and a selection window of the Destination LUN. Once we select the Destination LUN and click Apply, the migration begins. The migration process is actually a two step process. It is a copy first, then a move. Once the migration begins, it is a block for block copy from the Source LUN (Original Location) to the Destination LUN (New Location). This is important to know because the Source LUN does not have to be offline while this process is running. The host will continue to read and write to the Source LUN, which will write to Cache, then Cache writing out to the disk. Because it is a copy, any new write to the source lun will also write to the destination lun. At any time during this process, you may cancel the Migration if the wrong LUN was selected, or to wait until a later time. A priority level is also available to speed up or slow down the process.

3. Migration Completes. When the migration completes, the Source LUN will then MOVE to it’s new location in the Clariion. Again, there is nothing that needs to be done from the host, as it is still the same LUN as it was to begin with, just in a new space on the Clariion. The host doesn’t even know that the LUN is on a Clariion. It thinks the LUN is a local disk. The Destination LUN ID that you give a LUN when creating, will disappear. To the Clariion, that LUN never existed. The Source LUN will occupy the space of the Destination LUN, taking with it the same LUN ID, SP Ownership, and host connectivity. The only things that may or may not change based on your selection of the Destination might be the Raid type, Raid Group, size of the LUN, or Drive Type. The original space that the Source LUN once occupied is going to show as FREE Space in Navisphere on the Clariion. If you were to look at the Raid Group where the Source LUN used to live, under the Partitions tab, you will see the space the original LUN occupied as a Free. The Source LUN is still in the same Storage Group, assigned to the Host as it was before.
Migration Rules

The rules of a Migration as illustrated above are as follows.

The Destination LUN can be:
1. Equal to in size or larger. You can migrate a LUN to a LUN that is the exact same block count size, or to a LUN that is larger in size, so long as the host has the ability to see the additional space once the migration has completed. Windows would need a rescan, reboot of the disks to see the additional space, then using Diskpart, extend the Volume on the host. A host that doesn’t haven’t the ability to extend a volume, would need a Volume Manager software to grow a filesystem, etc.

2. The same or a different drive type. A destination LUN can be on the same type of drives as the source, or a different type of drive. For instance, you can migrate a LUN from Fibre Drives to ATA Drives when the Source LUN no longer needs the faster type drives. This is a LUN to LUN copy/move, so again, disk types will not stop a migration from happening, although it may slow the process from completing.

3. The same or a different raid type. Again, because it is a LUN to LUN copy, raid types don’t matter. You can move a LUN from Raid 1_0 to Raid 5 and reclaim some of the space on the Raid 1_0 disks. Or find that Raid 1_0 better suits your needs for performance and redundancy than Raid 5.

4. A Regular LUN or MetaLUN. The destination LUN only has to be equal in size, so whether it is a regular LUN on a 5 disk Raid 5 group or a Striped MetaLUN spread across multiple enclosures, buses, raid groups for performance is completely up to you.

However, the Destination LUN cannot be:

1. Smaller in size. There is no way on a Clariion to shrink a LUN to allow a user to reclaim space that is not being used.
2. A SnapView, MirrorView, or SanCopy LUN. Because these LUNs are being used by the Clariion to replicate data for local recoveries, replicate data to another Clariion for Disaster Recovery, or to move the data to/from another storage device, they are not available as a Destination LUN.
3. In a Storage Group. If a LUN is in a Storage Group, it is believed to belong to a Host. Therefore, the Clariion will not let you write over a LUN that potentially belongs to another host.

LUN Expansion - TDEV

In The Below Example

<XXXX> - Symmetrix SID

0eb4 - Existing TDEV

Steps to expand a TDEV which is already provisioned:

• symconfigure -cmd "configure 1 devices copying dev 0eb4 overriding size=200GB;" commit -sid <xxxx> 

|| This will create a new device with same attributes as exiting TDEV. We’ll use this newly created TDEV to add to meta as member.

• Unbind tdev SymDevName[:SymDevName] from pool PoolName.

|| Or unbind the device from GUI. || Unbind the newly created device so that it can be added as member to the meta we are creating.

• symconfigure -sid 6404 -cmd "form meta from dev 0eb4, config=concatenated; add dev 112e to meta 0eb4;" preview –v

|| 0eb4 is provisioned TDEV and 112e is the new member being added to meta 0eb4.

• symconfigure -sid 6404 -cmd "form meta from dev 0eb4, config=concatenated; add dev 112e to meta 0eb4;" commit -v

Striping cannot be done for TDEVs which are already provisioned. They can be converted though later:
convert meta config=[, stripe_ size=[cyl]],[, protect_data=[TRUE | FALSE], bcv_meta_head=];

LUN Expansion - Striped R5 Meta

In the below Example

046d - exiting meta members

<xxxx> - Symmetric SID

16d9:16da -  Newly Created members

041c - Existing member Meta Head

Steps to expand a striped R5 Meta:

• Ensure the members to add are copied from the exiting members of the meta we are expanding. Size, DG, Disk type and all other attributes should be same as exiting meta members. You can ensure this by just copying one of the meta members: 

symconfigure -cmd "configure 2 devices copying dev 046d;” commit -sid <xxxx>

• Create a BCV that will be used by Enginuity to copy the data from exiting meta to BCV during the meta expansion.

symconfigure -cmd "configure 1 devices copying dev 046c overriding config=bcv;" commit -sid <xxxx>

• Add members to exiting Meta:

symconfigure -sid <xxxx> -cmd "add dev 16d9:16da to meta 046c, protect_data=TRUE, bcv_meta_head=041c;" preview –v
symconfigure -sid <xxxx> -cmd "add dev 16d9:16da to meta 046c, protect_data=TRUE, bcv_meta_head=041c;" commit –v

If The Expansion was failing because of inconsistent SCSI_3 PER FLAG.

• Check SYMAPI logs for the exact error.

07/07/2015 21:05:49.771 2664 18992 EMC:SYMCONFIGURE cfgLogSymmwinError cfgSwSubmit call to silsw_DoSymmWinService for SWS_CONFIG_SUBMIT_CHANGE failed with code: SWRS_INVALID_SERVICE_DATA
07/07/2015 21:05:50.651 2664 18992 EMC:SYMCONFIGURE cfgSwSubmit SID 000xxxxxxxxx: config server msg: 0x4000224f: Meta group of Volume 46C contains volumes that have the flag vf3_scsi_persistent set on and off.

The flag should be the same for all the volumes in the meta group.
07/07/2015 21:05:52.204 2664 18992 A change definition record is in error, Undefine it or Abort the session
07/07/2015 21:05:52.204 2664 18992 Submitting configuration changes..........................Failed.
07/07/2015 21:05:56.282 2664 18992 Terminating session with configuration server.............Done.

• I ensured all the meta head/members and BCV head/members have SCSI_3 Persistence enabled and enabled SCSI_3 for members I was adding:

Symconfigure –sid <xxxx> –cmd “set device 16d9 attribute=SCSI3_persist_reserv;” commit –v
Symconfigure –sid <xxxx> –cmd “set device 16da attribute=SCSI3_persist_reserv;” commit -v

• Also when the devices and the bcv that you’ve created is compatible with existing meta it will be show in GUI to expand:

New Switch Insatallation Requirement

Prompt	Setting
Switch Name:
IP address:
Gateway:
Subnet Mask:

VNX Backend Looks Like

Brocade Switch Type map to Switch Model Matrix

1.x = Brocade SilkWorm 1000 series
2.x = DS-16B / Brocade SilkWorm 2800 series
3.x = DS-8B / Brocade SilkWorm 2400 series
4.x = Brocade SilkWorm 20×0;
5.x = Brocade SilkWorm 22×0;
6.x = DS-16B / Brocade SilkWorm 3800 Series (Includes parity checking on all paths)
7.x = SCB
9.x = DS-16B2 / Brocade SilkWorm 3800 series
10.x = ED-12000B / Brocade SilkWorm 12000 switch blade
12.x = DS-32B2 / Brocade SilkWorm 3900 series
16.x = DS-8B2 / Brocade SilkWorm 3200 series
17.x = Brocade SilkWorm 3800VL series
18.x = Brocade SilkWorm 3000 series
21.x = ED-24000B / Brocade 24000 switch blade
22.x= Brocade SilkWorm 3016 2GB Embedded Switch for IBM and Intel Blade Servers
26.x = DS-16B3 / Brocade 3850 series
27.x = DS-8B3 / Brocade 3250 series
29.x= Brocade SilkWorm 4012 4GB Embedded Switch for HP Blade Servers
32.x = DS-4100B / Brocade Silkworm 4100 series
33.x = Brocade SilkWorm 3014 2GB Embedded Switch for Dell, Fujitsu-Siemens and Hitachi Blade Servers
34.x = DS-220B / Brocade 200E
36.x = PB-48000-18i / Brocade SilkWorm FR4-18i 48000 Director Blade
37.x = Brocade SilkWorm 4020 4GB Embedded Switch for IBM and Intel Blade Servers
38.0 = AP-7420
40.x= Fibre Channel Routing (FCR) Front Domain
41.x= Fibre Channel Routing (FCR) Xlate Domain
42.2 = ED-48000B / Brocade Silkworm 48000 series
43.x = Brocade SilkWorm 4024 4GB Embedded Switch for NEC Blade Servers
44.x = DS-4900 / Brocade SilkWorm 4900 series
45.x = Brocade SilkWorm 4016 4GB Embedded Switch for Hitachi Blade Servers
46.x = MP-7500B / Brocade SilkWorm 7500 series
47.x = PB-48K-16IP / Brocade SilkWorm FC4-16IP 48000 Director Blade
51.x = Brocade SilkWorm 4018 4GB Embedded Switch for Blade Servers
55.x = Brocade SilkWorm FA4-18 48000 Director Blade
55.2 = AP7600B / Brocade SilkWorm 7600 series
58.x = DS-5000B / Brocade SilkWorm 5000 series

How to collect logs for RecoverPoint

RecoverPoint Management GUI version 4.x
1. Select Admin > System Analysis Tools > Collect System Information.
2. If this is your first time collecting system information, click Start. Otherwise, click Start New Collection Process.
3. The Collect System Information wizard is displayed, to guide you through the collection process.
4. Define the “Collect system information settings”
5. Click Next Test Connectivity. The Test Connectivity screen is displayed.

In The Test Connectivity screen, review the displayed information to verify that your configuration settings are correct, and the system can access all RPAs and splitters:

Verify that the Collection Settings are configured as intended. If required, click Back to Define Settings to edit your settings.

Verify that a green check mark exists in the Status column of all listed splitters and RPAs, and that the text Action succeeded exists in the Details column of all listed splitters and RPAs.

If all splitters and RPAs do not have green check marks in their Status columns, you can collect the information directly from individual hosts on which the feature is enabled:

For Windows-based hosts; from the Program Files\KDriver\hic directory on the host, run:

host_info_collector


For Solaris or AIX-based hosts; from the kdriver/info_collector directory on the host, run:

info_collect.sh


1. Click the Finish button to initiate the collection process. A progress bar is displayed, and the collection process begins

2. If you have chosen not to FTP the files directly to EMC using the wizard option, the files can be downloaded off of the RPA using a web browser:

http://<rpa_ip_address>/info - user webdownload, password webdownload

This will download the RPA logs to the local PC where they can be transferred to EMC FTP site or attached to a Service Request. Please contact EMC support for an FTP upload location.

RecoverPoint Appliance
1. Log in to RPA using SSH as user "boxmgmt". This will automatically bring up Main Menu.
2. Select [3] Diagnostics.
3. Select [4] Collect system info.
4. Enter the start date, start time, end date, end time.
5. Select y if you want to gather logs from remote site. Select n if you want to gather logs from local site. a. Enter name of FTP site, port number, user name, location, name of logs, password
b. Select NO to FTP and continue (Upload to FTP later)
6. Select [1] Collect logs from RPA only. [2] Collect logs from hosts only.
[3] Collect logs from RPA and hosts.

Warning! When collecting the RPA logs and include host collection, you will also retrieve all the necessary switch logs. After the log collection is run, download the output file using a web browser upon choose NO to FTP logs:

http://<rpa_ip_address>/info - user webdownload, password webdownload

This will download the RPA logs to the local PC where they can be transferred to EMC FTP site or attached to Service Request

Microsoft Windows Host Using RecoverPoint Driver

Run C:\Program Files\Kdriver\hic\host_info_collector.exe. This will create a file called Kashya_host_info_hostname_date_time.tar.gz in same directory.

Solaris/AIX Host Using RecoverPoint Driver

As root run ./info_collect.sh from the /kdriver/info_collector/ path. Warning! You MUST run the collector script from the path it resides in, or it will not collect all the necessary information.
This will create a file call EMC_host_info_(hostname)_datestamp.tar.gz in the same directory (/kdriver/info_collector).

Authentication Issue for RecoveryPoint on Symmetrix Array

If using Symmetrix splitter and User and Group Authorization is enabled on the Symmetrix array, configure the Symmetrix array to allow the RPAs to manage the splitter. Use the following procedure.

1. Use a text editor to create the following command file:

assign user H:RecoverPoint_<RP cluster name>_RPA1\root to role StorageAdmin;

assign user H:RecoverPoint_<RP cluster name>_RPA2\root to role StorageAdmin;


For example:

assign user H:RecoverPoint_NewYork_RPA1\root to role StorageAdmin;

assign user H:RecoverPoint_NewYork_RPA2\root to role StorageAdmin;


2. Using Solutions Enabler, run the following command:

symauth -sid <Symmetrix ID> -file <command file name> commit




For More troubleshoot - follow the below EMC Technical Notes

EMC RecoverPoint Deploying with Symmetrix Arrays and Splitter Technical Notes


Post your comments for more detail.