No part of this publication may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including copying and recording, or stored in a database or retrieval
system for any purpose without the express written permission of Hitachi, Ltd., or Hitachi Data
Systems Corporation (collectively “Hitachi”). Licensee may make copies of the Materials provided
that any such copy is: (i) created as an essential step in utilization of the Software as licensed and
is used in no other manner; or (ii) used for archival purposes. Licensee may not make any other
copies of the Materials. “Materials” mean text, data, photographs, graphics, audio, video and
documents.
Hitachi reserves the right to make changes to this Material at any time without notice and assumes
no responsibility for its use. The Materials contain the most current information available at the time
of publication.
Some of the features described in the Materials might not be currently available. Refer to the most
recent product announcement for information about feature and product availability, or contact
Hitachi Data Systems Corporation at
Notice: Hitachi products and services can be ordered only under the terms and conditions of the
applicable Hitachi Data Systems Corporation agreements. The use of Hitachi products is governed
by the terms of your agreements with Hitachi Data Systems Corporation.
By using this software, you agree that you are responsible for:
1) Acquiring the relevant consents as may be required under local privacy laws or otherwise from
authorized employees and other individuals to access relevant data; and
https://support.hds.com/en_us/contact-us.html.
2) Verifying that data continues to be held, retrieved, deleted, or otherwise processed in accordance
with relevant laws.
Notice on Export Controls. The technical data and technology inherent in this Document may be
subject to U.S. export control laws, including the U.S. Export Administration Act and its associated
regulations, and may be subject to export or import regulations in other countries. Reader agrees to
comply strictly with all such regulations and acknowledges that Reader has the responsibility to
obtain licenses to export, re-export, or import the Document and any Compliant Products.
Hitachi is a registered trademark of Hitachi, Ltd., in the United States and other countries.
AIX, AS/400e, DB2, Domino, DS6000, DS8000, Enterprise Storage Server, eServer, FICON,
FlashCopy, IBM, Lotus, MVS, OS/390, PowerPC, RS/6000, S/390, System z9, System z10, Tivoli,
z/OS, z9, z10, z13, z/VM, and z/VSE are registered trademarks or trademarks of International
Business Machines Corporation.
Active Directory, ActiveX, Bing, Excel, Hyper-V, Internet Explorer, the Internet Explorer logo,
Microsoft, the Microsoft Corporate Logo, MS-DOS, Outlook, PowerPoint, SharePoint, Silverlight,
SmartScreen, SQL Server, Visual Basic, Visual C++, Visual Studio, Windows, the Windows logo,
Windows Azure, Windows PowerShell, Windows Server, the Windows start button, and Windows
Vista are registered trademarks or trademarks of Microsoft Corporation. Microsoft product screen
shots are reprinted with permission from Microsoft Corporation.
All other trademarks, service marks, and company names in this document or website are
properties of their respective owners.
ii
Command Control Interface User and Reference Guide
Contents
Preface.................................................................................................. xi
SSB codes returned by the replication commands.................................... 9-22
SSB codes returned by the configuration setting command (raidcom)........9-24
Other SSB codes indicating internal errors............................................. 9-197
Calling Hitachi Data Systems customer support..................................................... 9-199
Index
ix
Command Control Interface User and Reference Guide
x
Command Control Interface User and Reference Guide
Preface
This document describes and provides instructions for using the Command
Control Interface (CCI) software to configure and perform operations on the
Hitachi RAID storage systems.
Please read this document carefully to understand how to use this product,
and maintain a copy for reference purposes.
Intended audience
□
Product version
□
Release notes
□
Changes in this revision
□
Referenced documents
□
Document conventions
□
Convention for storage capacity values
□
Accessing product documentation
□
Getting help
□
Comments
□
Preface
Command Control Interface User and Reference Guide
xi
Intended audience
This document is intended for system administrators, Hitachi Data Systems
representatives, and authorized service providers who install, configure, and
operate the Hitachi RAID storage systems.
Readers of this document should be familiar with the following:
•Data processing and RAID storage systems and their basic functions.
•The Hitachi RAID storage system and the manual for the storage system
(for example, Hardware Guide, Hitachi Virtual Storage Platform User andReference Guide).
•The management software for the storage system (for example, Hitachi
Command Suite, Hitachi Device Manager - Storage Navigator) and the
applicable user manuals (for example, Hitachi Command Suite User
Guide, System Administrator Guide, Hitachi Storage Navigator User
Guide).
•The host systems attached to the Hitachi RAID storage systems.
Product version
This document revision applies to Command Control Interface software
version 01-41-03/xx or later.
Release notes
The CCI release notes are available on Hitachi Data Systems Support
Connect:
before installing and using this product. They may contain requirements or
restrictions that are not fully described in this document or updates or
corrections to this document.
https://knowledge.hds.com/Documents. Read the release notes
Changes in this revision
•Added instructions for configuring iSCSI virtual ports (
virtual port on page 5-44, Deleting an iSCSI virtual port on page 5-44).
•Added information about the raidcom get quorum, raidcom modify
quorum, and raidcom replace quorum commands (
depending on operation authorities on page 3-13, Operation target for
raidcom commands when specifying the virtual storage machine in
HORCM_VCMD on page 3-61).
•Added information about creating external volumes using iSCSI (Creating
external volumes (iSCSI) on page 5-47).
•Added information about moving a parity group by specifying the LDEV
numbers of virtual volumes of Dynamic Provisioning, Copy-on-Write
Snapshot, or Thin Image (
•Updated the error code tables.
Setting an iSCSI
Commands executed
Moving parity groups on page 5-54).
xii
Preface
Command Control Interface User and Reference Guide
Referenced documents
Command Control Interface:
•Command Control Interface Installation and Configuration Guide,
MK-90RD7008
•Command Control Interface User and Reference Guide, MK-90RD7010
Refers to all models of the Hitachi Virtual Storage Platform G200,
G400, G600, G800 storage systems, unless otherwise noted.
Refers to all models of the Hitachi Virtual Storage Platform F400,
F600, F800 storage systems, unless otherwise noted.
Refers to the Hitachi RAID storage systems except for the VSP
Gx00 models, VSP Fx00 models, and HUS VM.
This document uses the following typographic conventions:
ConventionDescription
Bold•Indicates text in a window, including window titles, menus,
menu options, buttons, fields, and labels. Example: Click OK.
•Indicates emphasized words in list items.
Italic•Indicates a document title or emphasized words in text.
•Indicates a variable, which is a placeholder for actual text
provided by the user or for output by the system. Example:
pairdisplay -g group
(For exceptions to this convention for variables, see the
entry for angle brackets.)
Monospace
< > (angle brackets)Indicates variables in the following scenarios:
[ ] (square brackets)Indicates optional values. Example: [ a | b ] indicates that you
{ } (braces)Indicates required or expected values. Example: { a | b }
| (vertical bar)Indicates that you have a choice between two or more options or
Indicates text that is displayed on screen or entered by the user.
Example: pairdisplay -g oradb
•Variables are not clearly separated from the surrounding text
or from other variables. Example:
Status-<report-name><file-version>.csv
•Variables in headings.
can choose a, b, or nothing.
indicates that you must choose either a or b.
arguments. Examples:
[ a | b ] indicates that you can choose a, b, or nothing.
{ a | b } indicates that you must choose either a or b.
↓value↓ floorFloor function (round down value to the next integer)
Preface
Command Control Interface User and Reference Guide
xv
ConventionDescription
floor(value)
↑value↑ ceiling
ceiling(value)
_ (underlined text)Default value
Ceiling function (round up value to the next integer)
This document uses the following icons to draw attention to information:
IconLabelDescription
NoteCalls attention to important or additional information.
TipProvides helpful information, guidelines, or suggestions for
performing tasks more effectively.
CautionWarns the user of adverse conditions or consequences (for
example, disruptive operations).
WARNINGWarns the user of severe conditions or consequences (for
example, destructive operations).
Convention for storage capacity values
Physical storage capacity values (for example, disk drive capacity) are
calculated based on the following values:
Physical capacity unitValue
1 KB
1 MB
1 GB
1 TB
1 PB
1 EB
1,000 (103) bytes
1,000 KB or 1,0002 bytes
1,000 MB or 1,0003 bytes
1,000 GB or 1,0004 bytes
1,000 TB or 1,0005 bytes
1,000 PB or 1,0006 bytes
Logical storage capacity values (for example, logical device capacity) are
calculated based on the following values:
Logical capacity unitValue
1 block512 bytes
1 cylinderMainframe: 870 KB
Open-systems:
•OPEN-V: 960 KB
xvi
Preface
Command Control Interface User and Reference Guide
Logical capacity unitValue
•Others: 720 KB
1 KB
1 MB
1 GB
1 TB
1 PB
1 EB
1,024 (210) bytes
1,024 KB or 1,0242 bytes
1,024 MB or 1,0243 bytes
1,024 GB or 1,0244 bytes
1,024 TB or 1,0245 bytes
1,024 PB or 1,0246 bytes
Accessing product documentation
Product documentation is available on Hitachi Data Systems Support
Connect:
https://knowledge.hds.com/Documents. Check this site for the
most current documentation, including important updates that may have
been made after the release of the product.
Getting help
Hitachi Data Systems Support Connect is the destination for technical
support of products and solutions sold by Hitachi Data Systems. To contact
technical support, log on to Hitachi Data Systems Support Connect for
contact information: https://support.hds.com/en_us/contact-us.html.
Hitachi Data Systems Community is a new global online community for
HDS customers, partners, independent software vendors, employees, and
prospects. It is the destination to get answers, discover insights, and make
connections. Join the conversation today! Go to community.hds.com,
register, and complete your profile.
Comments
Please send us your comments on this document: doc.comments@hds.com.
Include the document title and number, including the revision level (for
example, -07), and refer to specific sections and paragraphs whenever
possible. All comments become the property of Hitachi Data Systems
Corporation.
Thank you!
Preface
Command Control Interface User and Reference Guide
xvii
xviii
Preface
Command Control Interface User and Reference Guide
1
Overview
This chapter provides an overview of the Command Control Interface (CCI)
software and CCI operations on the Hitachi RAID storage systems.
About Command Control Interface
□
CCI functions
□
CCI functions available on all RAID storage systems
□
Overview
Command Control Interface User and Reference Guide
1-1
About Command Control Interface
The Command Control Interface software enables you to perform storage
system configuration and data management operations by issuing commands
to the Hitachi RAID storage systems:
CCI continues to provide the proven functionality that has been available for
the USP V/VM and previous storage system models, including in-system
replication, remote replication, and data protection operations.
In addition, CCI for VSP and later provides command-line access to the same
provisioning and storage management operations that are available in the
GUI software (for example, Hitachi Command Suite, Storage Navigator). CCI
commands can be used interactively or in scripts to automate and
standardize storage administration functions, thereby simplifying the job of
the storage administrator and reducing administration costs.
Note: If a storage system rejects CCI commands, verify the software licenses
for the storage system (for example, TrueCopy) and the status of the
software product and storage system.
CCI functions
CCI functions matrix
The following table lists and describes the CCI functions available on the
Hitachi storage systems.
1-2
Overview
Command Control Interface User and Reference Guide
Table 1-1 Available CCI functions on the storage system models
Storage system
VSP
Function
Local copy (open)YesYesYesYesYesYes
Local copy (mainframe)NoNoYes*NoYesNo
Remote copy (open)YesYesYesYesYesYes
TagmaStore
USP/NSC
USP V/VMVSPHUS VM
G1000,
VSP
G1500,
VSP
F1500
models, VSP
Fx00 models
VSP Gx00
Remote copy
(mainframe)
Data protectionYesYesYesYesYesYes
VSS configurationYesYesYesYesYesYes
SRM SRAYesYesYesYesYesYes
Provisioning (raidcom)NoNoYesYesYesYes
Out-of-band methodNoNoYesYesYesYes
User authenticationNoNoYesYesYesYes
LDEV nicknameNoNoYesYesYesYes
LDEV groupNoNoYesYesYesYes
Resource groupNoNoYesYesYesYes
Resource lockNoNoYesYesYesYes
*If DKCMAIN Microcode version of the VSP storage system is 70-03-3x-xx/xx or later, the operation of
TrueCopy for Mainframe, Universal Replicator for Mainframe, and ShadowImage for Mainframe can be
performed from Command Control Interface.
NoNoYes*NoYesNo
Provisioning functions
The raidcom configuration setting command enables you to perform
provisioning functions, such as setting commands or creating LDEVs, from
CCI. For information about the configuration setting command (raidcom
command), see
Chapter 5, Provisioning operations with CCI on page 5-1.
Asynchronous command processing
For the raidcom configuration setting commands, asynchronous command
processing is used for operations that take time to process on the storage
system. Once an asynchronous command has been issued, you can execute
additional commands without having to wait for the asynchronous command
to complete. You can also monitor the completion status of asynchronous
Overview
Command Control Interface User and Reference Guide
1-3
commands by using a status reference command (for example, raidcom get
command_status).
Command execution modes
CCI provides two command execution modes:
•Transaction mode, in which a script file is specified with the -zt option
•Line-by-line mode, in which commands are executed row-by-row for the
configuration setting (raidcom) commands
You can use transaction mode to execute the following checking:
•Context check: This check is executed when a script file is specified by zt option. It checks the context of preceding commands and determines
whether a subsequent command can be executed.
Specifying example:
raidcom -zt <script_file>
•Configuration check: This check verifies that the actual storage system
configuration is valid (implemented) for the resources specified in the
commands (for example, LDEVs, ports, pools).
CCI provides a precheck function for the configuration setting (raidcom)
commands that checks the command before it is executed.
In earlier versions of CCI, an error was returned when the syntax of a
command to be executed was not correct. The precheck function checks the
command syntax before the command is executed. To use the precheck
function, specify either the -checkmode precheck option or the -zt option.
1-4
Overview
Command Control Interface User and Reference Guide
The following table shows the checking function combinations between the
precheck function and the transaction mode.
Table 1-2 Summary of the checking functions
Command syntax
raidcom <command>
raidcom <command> -checkmode precheck
raidcom -zt <script file>
raidcom get ldev -ldev_id -cnt 65280
-store<work_file>
raidcom -zt <script_file> -load <work_file>
raidcom -zt <script file> -checkmode precheck
raidcom get ldev -ldev_id -cnt 65280
-store<work_file>
raidcom -zt <script_file> -load <work_file>
-checkmode precheck
Syntax
check
ExecutedNot
ExecutedNot
ExecutedExecutedNot
ExecutedExecutedExecutedExecuted
ExecutedExecutedNot
ExecutedExecutedExecutedNot
Context
check
executed
executed
Config
check
Not
executed
Not
executed
executed
executed
Command execution by the in-band and out-of-band methods
The two methods for issuing commands from a host are the in-band method
and the out-of-band method:
Execution
Executed
Not
executed
Executed
Not
executed
executed
•In-band method
The method issues a command from a UNIX/PC host connected directly to
a storage system via Fibre Channel or iSCSI. Older CCI versions (that do
not support VSP) can only issue commands by using the in-band method.
In this method, when a command is issued, it is sent to the dedicated
LDEV (command device) of the storage system selected by the user via
Fibre Channel or iSCSI from CCI on the host.
•Out-of-band method
This method issues commands from a UNIX/PC host connected to the
storage system via LAN. As shown in the following figure, CCI supporting
VSP and later models can issue commands using the out-of-band method.
Client PCs that are not connected directly to storage systems can execute
the same scripts as the in-band method.
When a command is issued by using the out-of-band method, the
command is sent to a virtual command device via LAN from CCI on the
host. Virtual command devices are created when a command is executed
using the out-of-band method. A virtual command device can be created
by specifying the location to create a virtual command device in the
configuration definition file. For details on how to create command
devices, see
HORCM_CMD (out-of-band method) on page 2-21. Note,
however, that the location you can create virtual command devices varies
Overview
Command Control Interface User and Reference Guide
1-5
depending on the storage system models. For details about the location,
see System configuration using CCI on page 3-2.
Note: If many commands are issued in a short period of time by using
the out-of-band method, for example issuing commands in a
configuration with VMware Site Recovery Manager (SRM), or from scripts,
the command response might slow. In this case, issuing commands by
using the in-band method is recommended.
Tip: For older versions of CCI that do not support VSP, if you want to
issue a command from a client PC which is not connected to a storage
system directly, you must write a remote shell script which is executed by
your logging in to the CCI server of the in-band method via Telnet or
SSH.
The following figure illustrates in-band and out-of-band CCI operations. For
details about the in-band and out-of-band system configurations, see System
configuration using CCI on page 3-2.
1-6
Overview
Command Control Interface User and Reference Guide
Figure 1-1 Overview of out-of-band and in-band operations
The following table provides a comparison of in-band and out-of-band
operations.
Table 1-3 Comparison of in-band and out-of-band operations
RouteCommandSpecification
In-bandReplicationThe requirement for user authentication depends on
the setting of user authentication.
ProvisioningUser authentication is required. User authentication
mode of the command device must be enabled.
Out-of-bandReplicationUser authentication is required. For virtual command
devices, user authentication mode is always enabled.
Overview
Command Control Interface User and Reference Guide
1-7
RouteCommandSpecification
ProvisioningUser authentication is required. For virtual command
User authentication mode
You must enable the user authentication mode on the CCI command device.
For the virtual command device the user authentication mode is always
enabled.
When user authentication mode is enabled, use the user ID and password
that you created using Device Manager - Storage Navigator or the
maintenance utility to log in to the storage system.
LDEV nickname function
You can assign a unique nickname of up to 32 characters to an LDEV.
LDEV grouping function
In CCI versions prior to the Hitachi Virtual Storage Platform, you needed to
define the copy groups in the CCI configuration definition file on each host.
When the copy group information changed, the configuration definition file
needed to be edited on each host. In CCI versions after the VSP, the
information registered in the storage system can be used. This LDEV grouping
function can minimize the description of the CCI configuration definition file
on each host. When the copy group information changes, you need to update
only one configuration definition file, saving time and eliminating the chance
for error due to mismatching edits.
devices, user authentication mode is always enabled.
1-8
The LDEV grouping functionality is implemented using device names, device
groups, and copy groups:
•Device name:
¢
A name that can be assigned to one LDEV per device group.
¢
Each name is associated with a device group to which the LDEV
belongs.
¢
An LDEV nickname can be assigned to the LDEV as a unique name for
the LDEV that is not related with a device group. Only one LDEV
nickname can be assigned to each LDEV.
•Device group:
¢
A group of one or more LDEVs. One LDEV can belong to multiple
device groups.
¢
A device group can belong to only one copy group.
¢
If you want to construct a mirror or cascade, you need to define a
different device group and a device name in each copy group.
Overview
Command Control Interface User and Reference Guide
•Copy group: A group that is defined by specifying two device groups: one
device group at the primary site and one device group at the secondary
site.
Resource group function
Using Resource Group function, the storage administrator for each resource
group can access only the resources in the resource group. The storage
administrator cannot access resources in other resource groups. This
prevents the risk of destroying the data by another storage administrator in
the other resource groups or of leaking out the data.
Resource locking function
The resource locking function prevents conflict among multiple users.
User scripts cannot be guaranteed to work correctly when multiple users are
using the following different interfaces:
•Storage Navigator
•Device Manager - Storage Navigator
•SVP
•Maintenance utility (VSP Gx00 models and VSP Fx00 models)
•Maintenance PC
You can use the lock command while the script is running to ensure
completion. To use the lock command, user authentication is required.
CCI functions available on all RAID storage systems
CCI provides the following functionality on all Hitachi Data Systems RAID
storage systems.
•In-system replication
•Remote replication
•Data protection
In-system replication
CCI provides command-line control for in-system (local) replication
operations, including ShadowImage, Thin Image, and Copy-on-Write
Snapshot. CCI displays local replication information and allows you to
perform operations by issuing commands or by executing script files.
Remote replication
CCI provides command-line control for remote replication operations,
including TrueCopy, Universal Replicator, and global-active device. CCI
Overview
Command Control Interface User and Reference Guide
1-9
displays remote replication information and allows you to perform operations
by issuing commands or by executing script files.
For remote copy operations, CCI interfaces with the system software and
high-availability (HA) software on the host as well as the software on the
RAID storage system. CCI provides failover operation commands that support
mutual hot standby in conjunction with industry-standard failover products
(for example, MC/ServiceGuard, HACMP, FirstWatch®). CCI also supports a
scripting function for defining multiple operations in a script (or text) file.
Using CCI scripting, you can set up and execute a large number of commands
in a short period of time while integrating host-based high-availability control
over copy operations.
Data protection
CCI supports data protection operations, including Hitachi Database Validator
and Hitachi Data Retention Utility.
•Database Validator. The CCI software provides commands to set and
verify parameters for volume-level validation checking of Oracle
database operations. Once validation checking is enabled, all write
operations to the specified volumes must have valid Oracle checksums.
CCI reports a validation check error to the syslog file each time an error is
detected. Database Validator requires the operation of CCI software
product but cannot be controlled via the Storage Navigator software.
•Data Retention Utility. The CCI software enables you to set and verify the
parameters for guarding at the volume level. Once guarding is enabled,
the RAID storage system conceals the target volumes from SCSI
commands such as SCSI Inquiry and SCSI Read Capacity, prevents
reading and writing to the volume, and protects the volume from being
used as a copy volume (the TrueCopy, Universal Replicator, global-active
device, or ShadowImage paircreate operation fails).
®
1-10
Overview
Command Control Interface User and Reference Guide
CCI software environment
This chapter describes the CCI software environment.
Overview of the CCI software environment
□
CCI components on the RAID storage system
□
CCI instance components on the host server
□
CCI software files
□
CCI log and trace files
□
2
User-created files
□
User environment variable
□
CCI software environment
Command Control Interface User and Reference Guide
2-1
Overview of the CCI software environment
The CCI software environment includes components on the Hitachi RAID
storage systems and the CCI software on the host servers and/or on the
Storage Navigator computer or management client. The CCI components on
the storage systems include the user data volumes and CCI command
devices.
Each CCI instance on a host server includes:
•CCI application files, referred to as HORC Manager (HORCM):
¢
Log and trace files
¢
A command server
¢
Error monitoring and event reporting files
¢
A configuration management feature
•Configuration definition file (user-defined)
•User execution environments for the HDS features, including the
commands, a command log, and a monitoring function.
The CCI commands also have interface considerations (see
command interface on page 2-7).
CCI components on the RAID storage system
Command device
CCI commands are issued by the CCI software to the RAID storage system
command device. The command device is a user-selected, dedicated logical
volume on the storage system that functions as the interface to the CCI
software on the host. The command device is dedicated to CCI
communications and cannot be used by any other applications. The command
device accepts CCI read and write commands that are issued by the storage
system. The command device also returns read requests to the host. The
volume designated as the command device is used only by the storage
system and is blocked from the user. The command device uses 32 MB, and
the remaining volume space is reserved for CCI and its utilities. The
command device can be any OPEN-x device (for example, OPEN-V) that is
accessible to the host. A LUN Expansion volume cannot be used as a
command device. A Virtual LVI/Virtual LUN volume as small as 36 MB (for
example, OPEN-3-CVS) can be used as a command device.
CCI and the SCSI
2-2
WARNING: Make sure the volume to be selected as the command device
does not contain any user data. The command device will be inaccessible to
the host.
The CCI software on the host issues read and write commands to the
command device. When CCI receives an error notification in reply to a read or
write request to the RAID storage system, the CCI software switches to an
alternate command device, if one is defined. If a command device is blocked
CCI software environment
Command Control Interface User and Reference Guide
(for example, for online maintenance), you can switch to an alternate
command device manually. If no alternate command device is defined or
available, all TrueCopy and ShadowImage commands terminate abnormally,
and the host will not be able to issue commands to the storage system.
Therefore, one or more alternate command devices (see Alternate command
device function on page 2-5) must be set to avoid data loss and storage
system downtime.
Each command device must be set using the LUN Manager software on
Storage Navigator. In addition, for using a Provisioning command, user
authentication is required. Set the security attribute of the command device
with user authentication. For information and instructions on setting a
command device, see the Provisioning Guide for the storage system.
Each command device must also be defined in the HORCM_CMD section of
the configuration definition file for the CCI instance on the attached host. If
an alternate command device is not defined in the configuration definition
file, the CCI software might not be able to use the device.
The CCI Data Protection Facility uses an enhanced command device that has
an attribute to indicate protection ON or OFF.
Note:
•For Solaris operations, the command device must be labeled.
To enable dual path of the command device, make sure to include all paths to
the command device on a single line in the HORCM_CMD section of the
configuration definition file. The following shows an example with two
controller paths to the command device. Putting the path information on
separate lines might cause parsing issues, and failover might not occur unless
the HORCM startup script is restarted.
In the customer environment, a command device might be attacked by the
maintenance program of the Solaris Server, after that usable instance will be
exhausted, and CCI instance would not start up on all servers (except
attacked server). This might happen due to incorrect operation of the
maintenance personnel for the UNIX Server. In this case, the command
device should be protected against operator error, as long as it can be seen
as the device file from the maintenance personnel.
Thus, the RAID microcode (for the command device) and CCI support this
protection in order to guard from similar access.
Guarding method
Currently, assignment of the instance via the command device is ONE phase.
Therefore, if the command device reads a special allocation area of the
instance through the maintenance tool and so on, then it causes a fault of full
CCI software environment
Command Control Interface User and Reference Guide
2-3
space of the instance, because the command device interprets as assignment
of the instance from CCI.
CCI has TWO phases that it reads to acquire usable LBA, and writes with the
acquired LBA in attaching sequence to the command device, so the command
device can confirm whether it was required as the assignment for CCI or not,
by detecting and adding two status bits to the instance assignment table.
Figure 2-1 Current assignment sequence
Figure 2-2 Improved assignment sequence
The command device performs the assignment of an instance through TWO
phases that have "temporary allocation (1 0)" and "actual allocation (1 1)" to
the instance assignment table.
If the command device is attacked, the instance assignment table is filled
with "temporary allocation (1 0)" status. After that, the command device will
detect a fault of full space as the instance assignment, clear up all
"temporary allocation (1 0)", and then reassign the required instance
automatically.
This does not require a service representative to switch the command device
"OFF/ON" to clear up the instance table.
Verifying the CCI instance number
CCI provides a way to verify the number of "temporary allocations (1 0)" and
"actual allocations (1 1)" on the instance table so that you can confirm
validity of the CCI instance number in use. The horcctl -DI command
shows the number of CCI instances since HORCM was started as follows.
Example without command device security:
2-4
CCI software environment
Command Control Interface User and Reference Guide
# horcctl -DI
Current control device = /dev/rdsk/c0t0d0 AI = 14 TI = 0 CI = 1
Example with command device security:
# horcctl -DI
Current control device = /dev/rdsk/c0t0d0*AI = 14 TI = 0 CI = 1
AI: NUM of actual instances in use
TI: NUM of temporary instances in RAID
CI: NUM of instances using current (own) instance
Alternate command device function
The CCI software issues commands to the command device via the UNIX/PC
raw I/O interface. If the command device fails in any way, all CCI commands
are terminated abnormally, and you cannot use any commands. Because the
use of alternate I/O path is platform dependent, restrictions are placed upon
it. For example, on HP-UX systems, only devices subject to the LVM can use
the alternate path PV-LINK. To avoid command device failure, CCI supports
an alternate command device function.
Note: When you set a redundant path to the command device by using
alternate path software, make sure that path switching occurs only in case of
a failure. For example, you cannot use round robin.
•Definition of alternate command devices. To use an alternate
command device, you must define two or more command devices for the
HORCM_CMD item in the configuration definition file. When two or more
devices are defined, they are recognized as alternate command devices.
Create all alternate command devices within the same resource group of
the same storage system.
•Timing of alternate command devices. When the HORCM receives an
error notification in reply from the operating system via the raw I/O
interface, the alternate command device is used. You can also change to
the alternate command device forcibly by using the horcct1 -C switch
command. However, if you specified HORCM_CMD for the volume
belonging to a virtual storage machine, you cannot use the horcct1 -C
switch command, and therefore you cannot switch to the alternate
command device forcibly.
•Operation of alternating command. If the command device is blocked
due to online maintenance, the switch command should be issued in
advance. If the switch command is issued again after completion of the
online maintenance, the previous command device is activated.
•Multiple command devices on HORCM startup. If at least one
command device is available during one or more command devices
described to the configuration definition file, then HORCM can start with a
warning message to the startup log by using the available command
device. Confirm that all command devices can be changed by using the
horcctl -C command option, or HORCM has been started without the
warning message to the HORCM startup log.
CCI software environment
Command Control Interface User and Reference Guide
2-5
Remote command device
A remote command device is a command device on an external (UVM)
storage system that is mapped as a command device of the local storage
system. When commands are issued to a remote command device, the
UR/URz journal operations are processed using the UVM FC path between the
arrays. Use of a remote command device provides improved performance for
3DC configurations by providing separate paths for UR/URz journal
processing and data replication.
RCD is required in 3DC TC/UR and URxUR configurations.
¢
RCD is not required in GAD 3DC delta resync (GAD+UR)
configurations.
•Virtual Storage Platform: RCD is recommended in 3DC TC/UR and 3DC
TCz/URz configurations. If there is intermix with VSP G1000, G1500 or
VSP F1500, RCD is required.
•Hitachi Unified Storage VM: RCD is recommended in 3DC TC/UR
configurations.
CCI software environment
Command Control Interface User and Reference Guide
The remote command device is defined using Device Manager - Storage
Navigator. For more information, see the Hitachi Universal Volume ManagerUser Guide.
CCI and the SCSI command interface
When CCI commands are converted into a special SCSI command format, a
SCSI through driver that can send specially formatted SCSI commands to the
RAID storage system is needed. As a result, OS support for CCI depends on
the OS capabilities. It is necessary to use a read/write command that can
easily be issued by many UNIX/PC server platforms. For example, ioctl() can
be used for the following platforms: HP-UX, Linux, Solaris, Windows, IRIX64,
OpenVMS and zLinux.
SCSI command format used. Use a RD/WR command that can be used
with special LDEVs, since they should be discriminated from the normal
RD/WR command.
Recognition of the control command area (LBA#). The host issues
control commands through the raw I/O special file of a special LDEV. Since
the specific LU (command device) receiving these commands is viewed as a
normal disk by the SCSI interface, the OS can access its local control area.
The RAID storage system must distinguish such accesses from the control
command accesses. Normally, several megabytes of the OS control area are
used starting at the initial LBA#. To avoid using this area, a specific LBA#
area is decided and control commands are issued within this area. The
command LBA# recognized by the storage system is shown below, provided
the maximum OS control area is 16 MB.
Figure 2-4 Relationship of the special file to the special LDEV
Acceptance of commands. A command is issued in the LBA area of the
special LDEV explained above. The RD/WR command meeting this
requirement should be received especially as a CCI command. A command is
CCI software environment
Command Control Interface User and Reference Guide
2-7
issued in the form of WR or WR-RD. When a command is issued in the form
of RD, it is regarded as an inquiry (equivalent to a SCSI inquiry), and a CCI
recognition character string is returned.
Command competition
The CCI commands are asynchronous commands issued via the SCSI
interface. As a result, if several processes issue these commands to a single
LDEV, the storage system cannot take the proper action. To avoid such a
problem, two or more write commands should not be issued to a single LDEV.
The command initiators should not issue two or more write commands to a
single LDEV unless the storage system can receive commands with
independent initiator number * LDEV number simultaneously.
Command flow
This figure shows the flow of read/write command control for a specified
LBA#.
Figure 2-5 HORCM and command issue process
2-8
Figure 2-6 Command flow
CCI software environment
Command Control Interface User and Reference Guide
Issuing commands for LDEVs within a LUSE device
A LUSE device is a group of LDEVs regarded as a single logical unit. Because
it is necessary to know the configuration of the LDEVs when issuing a
command, a new command is used to specify a target LU and acquire LDEV
configuration data, as shown in the following figure.
Figure 2-7 LUSE Device and Command Issue
CCI instance components on the host server
HORCM operational environment
The HORCM operates as a daemon process on the host server and is
activated either automatically when the server machine starts up or manually
by the startup script. HORCM reads the definitions specified in the
configuration file upon startup. The environment variable HORCM_CONF is
used to define the location of the configuration file to be referenced.
CCI software environment
Command Control Interface User and Reference Guide
2-9
Figure 2-8 HORCM operational environment
CCI instance configurations
The basic unit of the CCI software structure is the CCI instance. A CCI
instance consists of HORC manager (HORCM), CCI commands, the userdefined configuration definition file, and the log function for maintenance.
Each instance uses its own configuration definition file to manage volume
relationships while maintaining awareness of the other CCI instances. Each
CCI instance normally resides on separate servers (one node per instance). If
two or more instances are run on a single server (for example, for test
operations), it is possible to activate two or more instances using instance
numbers. The CCI commands to be used are selected by the environment
variable (HORCC_MRCF). The default command execution environment for
CCI is TrueCopy.
The CCI instance shown in the following figure has a remote execution link
and a connection to the RAID storage system. The remote execution link is a
network connection to another PC to allow you to execute CCI functions
remotely. The connection between the CCI instance and the storage system
illustrates the connection between the CCI software on the host and the
command device. The command device accepts CCI commands and
communicates read and write I/Os between the host and the volumes on the
storage system. The host does not communicate CCI commands directly to
the volumes on the storage system -- the CCI commands always go through
the command device.
2-10
CCI software environment
Command Control Interface User and Reference Guide
Figure 2-9 CCI instance configuration & components
The four possible CCI instance configurations are:
•One host connected to one storage system. Connecting one host to one
storage system allows you to maintain multiple copies of your data for
testing purposes or as an offline backup. Each CCI instance has its own
operation manager, server software, and scripts and commands, and
each CCI instance communicates independently with the command
device. The RAID storage system contains the command device that
communicates with the CCI instances as well as the primary and
secondary volumes of both CCI instances.
•One host connected to two storage systems. Connecting the host to two
storage systems enables you to migrate data or implement disaster
recovery by maintaining duplicate sets of data in two different storage
systems. You can implement disaster recovery solutions by placing the
CCI software environment
Command Control Interface User and Reference Guide
2-11
storage systems in different geographic areas. Each CCI instance has its
own operation manager, server software, and scripts and commands, and
each CCI instance communicates independently with the command
device. Each RAID storage system has a command device that
communicates with each CCI instance independently. Each storage
system contains the primary volumes of its connected CCI instance and
the secondary volumes of the other CCI instance (located on the same
host in this case).
•Two hosts connected to one storage system. Having two attached hosts
to one storage system, one host for the primary volume and the other
host for the secondary volume, allows you to maintain and administer the
primary volumes while the secondary volumes can be taken offline for
testing. The CCI instances of separate hosts are connected via the LAN so
that they can maintain awareness of each other. The RAID storage
system contains the command device that communicates with both CCI
instances (one on each host) and the primary and secondary volumes of
both CCI instances
•Two hosts connected to two storage systems. Two hosts connected to two
storage systems also allows the most flexible disaster recovery plan,
because both sets of data are administered by different hosts. This guards
against storage system failure as well as host failure.The CCI instances of
separate hosts are connected via the LAN so that they can maintain
awareness of each other. Each RAID storage system has a command
device that communicates with each CCI instance independently. Each
storage system contains the primary volumes of its connected CCI
instance and the secondary volumes of the other CCI instance (located on
a different host in this case).
Host machines that can be paired
When you perform a pair operation, the version of CCI should be the same on
the primary and secondary sites. As a particular application uses HORC, users
sometimes use a HORC volume as the data backup volume for the server. In
this case, CCI requires that the CCI instance correspond to each OS platform
that is located on the secondary site for the pair operation of data backup on
the primary servers of each OS platform.
However, it is possible to prepare only one server at a secondary site by
supporting CCI communications among different OSs (including the converter
for little-endian vs. big-endian).
Figure 2-10 CCI communication among different operating systems on page
2-13 represents CCI's communication among different OSs, and Table 2-1
Supported CCI (HORCM) communication on page 2-13 shows the supported
communication (32-bit, 64-bit) among different OSs. Please note the
following terms that are used in the example:
•RM-H: Value of HORCMFCTBL environment variable for an HP-UX CCI
instance on Windows
•RM-S: Value of HORCMFCTBL environment variable for a Solaris CCI
instance on Windows
2-12
CCI software environment
Command Control Interface User and Reference Guide
Restriction: CCI's communications among different operating systems is
supported on HP-UX, Solaris, AIX, Linux, and Windows (this is not supported
on Tru64 UNIX/Digital UNIX). Also, CCI does not require that the
HORCMFCTBL environment variable be set—except for RM-H and RM-S
instances (to ensure that the behavior of the operating system platform is
consistent across different operating systems).
Figure 2-10 CCI communication among different operating systems
Table 2-1 Supported CCI (HORCM) communication
HORCM
32 bitlittleAVAVAV-
bigAVAVAV-
64 bitlittleAVAVAV-
big----
Configuration definition file
The CCI configuration definition file is a text file that defines a CCI instance.
The connected hosts, volumes and groups known to the CCI instance are
defined in the configuration definition file. Physical volumes (special files)
used independently by the servers are combined when paired logical volume
names and group names are given to them. The configuration definition file
describes the correspondence between the physical volumes used by the
servers and the paired logical volumes and the names of the remote servers
connected to the volumes. See the Command Control Interface Installationand Configuration Guide for instructions on creating the CCI configuration
definition file.
HORCM 32 bitHORCM 64 bit
littlebiglittlebig
CCI software environment
Command Control Interface User and Reference Guide
2-13
Figure 2-11 Configuration definition of paired volumes on page 2-14
illustrates the configuration definition of paired volumes.
Figure 2-11 Configuration definition of paired volumes
Configuration file example — UNIX-based servers
Note that # at the beginning of a line indicates a comment.
HORCM_MON
#ip_address service poll(10ms) timeout(10ms)
HST1 horcm 1000 3000
The following table lists the parameters defined in the configuration file and
specifies the default value, type, and limit for each parameter.
Table 2-2 Configuration (HORCM_CONF) parameters
ParameterDefaultTypeLimit
ip_addressNoneCharacter string63 characters
ServiceNoneCharacter string or numeric
value
poll (10 ms)1000
timeout (10 ms)3000
dev_name for
HORCM_CMD
dev_name for
HORCM_DEV
NoneCharacter string63 characters
NoneCharacter string31 characters
Numeric value
Numeric value
1
1
CCI software environment
Command Control Interface User and Reference Guide
15 characters
None
None
Recommended value =
8 char. or fewer
2-15
ParameterDefaultTypeLimit
dev_groupNoneCharacter string31 characters
Recommended value =
8 char. or less
port #NoneCharacter string31 characters
target IDNone
LU#None
MU#0
Serial#
CU:LDEV(LDEV#)NoneNumeric value6 characters
2
NoneNumeric value12 characters
Numeric value
Numeric value
Numeric value
1
1
1
7 characters
7 characters
7 characters
dev_name for
HORCM_CMD
Notes:
1.Use decimal notation for numeric values (not hexadecimal).
2.For VSP G1000, G1500, and VSP F1500, add a “3” at the beginning of the serial
number. For example, for serial number 12345, enter 312345.
NoneCharacter string63 characters
Recommended value =
8 char. or less
Do not edit the configuration definition file while CCI is running. Shut down
CCI, edit the configuration file as needed, and then restart CCI.
When you change the system configuration, it is required to shut down CCI
once and rewrite the configuration definition file to match with the change
and then restart CCI.
When you change the storage system configuration (microprogram, cache
capacity, LU path, and so on), you need to restart CCI regardless of the
necessity of the configuration definition file editing.
When you restart CCI, confirm that there is no contradiction in the connection
configuration by using the "-c" option of pairdisplay command and raidqry
command. But you cannot confirm the consistency of the P-VOL and S-VOL
capacity with the "-c" option of pairdisplay command. Confirm the capacity of
each volume by using the raidcom command.
Do not mix pairs created with the "At-Time Split" option (-m grp) and pairs
created without this option in the same group defined in the CCI configuration
file. If you do, a pairsplit operation might end abnormally, or S-VOLs of the PVOLs in the same consistency group (CTG) might not be created correctly at
the time the pairsplit request is received.
Configuration definition file settings
This section describes the settings in the configuration definition file:
HORCM_MON on page 2-17
•
•HORCM_CMD (in-band method) on page 2-17
2-16
Command Control Interface User and Reference Guide
CCI software environment
•HORCM_CMD (out-of-band method) on page 2-21
•HORCM_DEV on page 2-23
•HORCM_INST on page 2-25
•
•
•HORCM_INSTP on page 2-28
•
HORCM_MON
The monitor parameter (HORCM_MON) defines the following values:
•Ip_address: Specifies the local host name or the IP address of the local
•Service: Specifies the UDP port name assigned to the HORCM
•Poll: The interval for monitoring paired volumes. To reduce the HORCM
•Timeout: The time-out period of communication with the remote server.
HORCM_LDEV on page 2-26
HORCM_LDEVG on page 2-27
HORCM_ALLOW_INST on page 2-28
host. When you specify the name of a local host that has multiple IP
addresses, one of the IP addresses is selected at random and used. If you
want to use all IP addresses, specify NONE for IPv4 or NONE6 for IPv6.
communication path, which is registered in "/etc/services" ("%windir%
\system32\drivers\etc\services" in Windows, "SYS$SYSROOT:
[000000.TCPIP$ETC]SERVICES.DAT" in OpenVMS). If a port number is
specified instead of a port name, the port number will be used.
daemon load, make this interval longer. If set to -1, the paired volumes
are not monitored. The value of -1 is specified when two or more CCI
instances run on a single machine.
If HORCM_MON is not specified, then the following are set as defaults.
HORCM_MON
#ip_address service poll(10ms) timeout(10ms)
NONE default_port 1000 3000H
Default_port:
For none specified HORCM instance: "31000 + 0"
For instance HORCM X : "31000 + X + 1"
HORCM_CMD (in-band method)
When using the in-band method, define the UNIX device path or Windows
physical device number and specify a command device that can be accessed
by CCI for HORCM_CMD. You can specify multiple command devices in
HORCM_CMD to provide failover in case the original command device
becomes unavailable.
Tip: To enhance redundancy, you can make multiple command devices
available for a single storage system. This configuration is called command
device alternative configuration. For this configuration, command devices are
listed horizontally in a line in the configuration definition file. CMD1 and CMD2
in the following example are command devices of the same storage system:
CCI software environment
Command Control Interface User and Reference Guide
2-17
HORCM_CMD
CMD1 CMD2
Aside from the command device alternative configuration, to control multiple
storage systems in one configuration definition file, you can list command
devices of each storage system in one configuration definition file. In this
case, command devices are listed vertically. CMD1 and CMD2 in the following
example are command devices of different storage systems:
HORCM_CMD
CMD1
CMD2
The command device must be mapped to the iSCSI/Fibre using LUN Manager
first. The mapped command devices can be identified by the "-CM" at the end
of product ID displayed by the inqraid command. The following are the
examples for the inqraid command.
Example for the inqraid command (UNIX host)
# ls /dev/rdsk/c1t0* | /HORCM/usr/bin/inqraid -CLI -sort
DEVICE_FILE PORT SERIAL LDEV CTG H/M/12 SSID R:Group PRODUCT_ID
Caution: To enable dual path of the command device under UNIX systems,
make sure to include all paths to the command device on a single line in the
HORCM_CMD section of the configuration definition file. Entering path
CCI software environment
Command Control Interface User and Reference Guide
information on separate lines might cause syntax parsing issues, and failover
might not occur unless the HORCM startup script is restarted on the UNIX
system.
When two or more storage systems are connected, CCI identifies each
storage system using unit IDs. The unit ID is assigned sequentially in the
order described in HORCM_CMD of the configuration definition file. For a
command device alternative configuration, a special file for multiple
command devices is written.
Caution: When storage systems are shared by two or more servers, unit IDs
and serial numbers must be consistent among the servers. List serial
numbers of the storage systems in HORCM_CMD of the configuration
definition file in the same order. The following figure illustrates unit IDs when
multiple servers share multiple storage systems.
Figure 2-12 Configuration and unit IDs for multiple storage systems
For Windows 2000, 2003, 2008, and 2012
Normally, physical drives are specified for command devices in storage
systems. However, CCI provides a method that is not affected by changes of
physical drives in Windows 2000, 2003, 2008, and 2012 by using the
following naming format to specify the serial number, LDEV number, and port
number in that order:
\\.\CMD-Ser#-ldev#-Port#
Note:
the serial number (for example, enter "312345" for serial number "12345").
The following example specifies 30095 for the storage system's serial
number, 250 for the LDEV number, and CL1-A for the port number:
For VSP G1000, G1500, and VSP F1500, add a "3" to the beginning of
CCI software environment
Command Control Interface User and Reference Guide
•Minimum specification
For the command device with serial number 30095, specify as follows:
\\.\CMD-30095
•Command devices in the multi-path environment
Specify serial number 30095, and LDEV number 250 as follows:
\\.\CMD-30095-250
•Other specifications
Specify serial number 30095, LDEV number 250, and port number CLI-A
as follows:
\\.\CMD-30095-250-CL1-A
or
\\.\CMD-30095-250-CL1
For UNIX
Device files are specified for command devices in UNIX. However, CCI
provides a method that is not affected by changes of device files in UNIX by
using the following naming format specifying the serial number, LDEV
number, and port number in that order:
\\.\CMD-Ser#-ldev#-Port#:HINT
Note: For VSP G1000, G1500, and VSP F1500, add a "3" to the beginning of
the serial number (for example, enter "312345" for serial number "12345").
The following example specifies 30095 for the storage system's serial
number, 250 for the LDEV number, and CL1-A for the port number:
HINT provides a path to scan and specifies a directory ending with a slash (/)
or a name pattern including the directory. Device files are searched via a
name filter similar to the inqraid command.
•To find command devices from /dev/rdsk/, enter: ' /dev/rdsk/*
•To find command devices from /dev/rdsk/c10, enter: ' /dev/rdsk/c10*
•To find command devices from /dev/rhdisk, enter: ' /dev/rhdisk*
For a command device alternative configuration , HINT of the second
command device can be omitted. In this case, command devices are
searched from the device file that was scanned first.
Note: If the hardware configuration is changed during the time an OS is
running in Linux, the name of a special file corresponding to the command
device might be changed. At this time, if HORCM was started by specifying
the special file name in the configuration definition file, HORCM cannot detect
the command device, and the communication with the storage system might
fail.
To prevent this failure, specify the path name allocated by udev to the
configuration definition file before booting HORCM. Use the following
procedure to specify the path name. In this example, the path name
for /dev/sdgh can be found.
1.Find the special file name of the command device by using inqraid
command. Command example:
When executing commands using the out-of-band method, use a virtual
command device instead of a command device. By specifying the location to
create a virtual command device in HORCM_CMD, you can create a virtual
command device.
The location where the virtual command device can be created is different
according to the type of the storage system. For details about locations, see
System configuration using CCI on page 3-2.
CCI software environment
Command Control Interface User and Reference Guide
2-21
To create a virtual command device on an SVP (VSP, HUS VM, VSP
G1000, G1500, and VSP F1500)
Specify the following to HORCM_CMD of the configuration definition file.
\\.\IPCMD-<SVP IP address>-<UDP communication port number>[-Unit ID]
•<SVP IP address>: Sets an IP address of SVP.
•<UDP communication port number>: Sets the UDP communication port
number. This value (31001) is fixed.
•[-Unit ID]: Sets the unit ID of the storage system for the multiple units
connection configuration. This can be omitted.
To create a virtual command device on the maintenance utility (VSP
Gx00 models, VSP Fx00 models)
Specify the following to HORCM_CMD of the configuration definition file:
\\.\IPCMD-<GUM IP address>-<UDP communication port number>[-Unit ID]
•<GUM IP address>: Sets an IP address of the maintenance utility (GUM).
•<UDP communication port number>: Sets the UDP communication port
number. These values (31001 and 31002) are fixed.
•[-Unit ID]: Sets the unit ID of the storage system for the multiple units
connection configuration. This can be omitted.
Note: To use the maintenance utility, we recommend that you set the
combination of all GUM IP addresses in the storage system and the UDP
communication port numbers by an alternative configuration. See the
following examples for how to set the combination.
To use a CCI server port as a virtual command device:
Specify the following in HORCM_CMD of the configuration definition file:
\\.\IPCMD-<CCI server IP address>-<CCI port number>[-Unit ID]
•<CCI server IP address>: Sets the IP address of the CCI server.
•<CCI port number>: Sets the CCI port number.
•[-Unit ID]: Sets the unit ID of the storage system for the multiple units
connection configuration. This can be omitted.
The following example shows the case of alternative configuration of the
combination of all GUM IP addresses in the storage system and the UDP
communication port numbers. In this case, enter the IP address without a
line feed.
An IP address and a port number can be expressed using a host name and a
service name.
The device parameter (HORCM_DEV) defines the RAID storage system device
addresses for the paired logical volume names. When the server is connected
to two or more storage systems, the unit ID is expressed by port# extension.
Each group name is a unique name discriminated by a server that uses the
volumes, the attributes of the volumes (such as database data, redo log file,
UNIX file), recovery level, etc. The group and paired logical volume names
described in this item must reside in the remote server. The hardware iSCSI/
Fibre port, target ID, and LUN as hardware components need not be the
same.
The following values are defined in the HORCM_DEV parameter:
•dev_group: Names a group of paired logical volumes. A command is
executed for all corresponding volumes according to this group name.
•dev_name: Names the paired logical volume within a group (that is,
name of the special file or unique logical volume). The name of paired
logical volume must be different to the dev name in another group.
•Port#: Defines the RAID storage system port number of the volume that
connects to the dev_name volume. The following "n" shows unit ID when
CCI software environment
Command Control Interface User and Reference Guide
2-23
the server is connected to two or more storage systems (for example,
CL1-A1 = CL1-A in unit ID 1). If the "n" option is omitted, the unit ID is
0. The port is not case sensitive (for example, CL1-A = cl1-a = CL1-a =
cl1-A).
-BasicOptionOptionOption
CL1An Bn Cn DnEnFnGn HnJnKn LnMnNnPn QnRn
CL2An Bn Cn DnEnFnGn HnJnKn LnMnNnPnQnRn
The following ports can be specified only for the 9900V:
-BasicOptionOptionOption
CL3anbn cndnenfngnhnjnkn lnmnnnpn qnrn
CL4anbn cndnenfngnhnjnkn lnmnnnpn qnrn
For 9900V, CCI supports four types of port names for host groups:
¢
Specifying the port name without a host group: CL1-A CL1-An, where
n is the unit ID if there are multiple RAID storage systems
¢
Specifying the port name with a host group: CL1-A-g, where g is the
host group CL1-An-g, where n-g is the host group g on CL1-A in unit
ID=n
The following ports can be specified for USP V/VM and TagmaStore USP/
TagmaStore NSC:
-BasicOptionOptionOption
CL5anbn cndnenfngnhnjnkn lnmnnnpn qn rn
CL6anbn cndnenfngnhnjnkn lnmnnnpn qn rn
CL7anbn cndnenfngnhnjnkn lnmnnnpn qn rn
CL8anbn cndnenfngnhnjnkn lnmnnnpn qn rn
CL9anbn cndnenfngnhnjnkn lnmnnnpn qn rn
CLAan bncndnenfngn hnjnknlnmnnnpn qnrn
CLBanbn cndnen fngn hnjnknlnmnnnpn qnrn
CLCanbn cndnenfngnhnjnknlnmnnnpnqnrn
CLDanbncndnenfngn hnjnknlnmnnnpn qnrn
CLEanbn cndnenfngnhnjnkn lnmnnnpnqn rn
CLFanbncndnenfngn hnjnknlnmnnnpn qnrn
CLGanbncndnenfngn hnjnknlnmnnnpn qnrn
•Target ID: Defines the iSCSI/Fibre target ID (TID) number of the physical
volume on the specified port.
2-24
CCI software environment
Command Control Interface User and Reference Guide
•LU#: Defines the iSCSI/Fibre logical unit number (LU#) of the physical
volume on the specified target ID and port.
Note: In case of fibre channel, if the TID and LU# displayed on the
system are different than the TID on the fibre address conversion table,
then you must use the TID and LU# indicated by the raidscan command
in the CCI configuration file.
•MU# for ShadowImage (HOMRCF): Defines the mirror unit number (0 - 2)
to use the redundant mirror for the identical LU on the ShadowImage. If
this number is omitted, it is assumed to be (MU#0). The cascaded
mirroring of the S-VOL is expressed as virtual volumes using the mirror
descriptors (MU#1-2) in the configuration definition file. The MU#0 of a
mirror descriptor is used for connection of the S-VOL. The mirror
descriptor (MU#0-2) can be used in ShadowImage and Copy-on-Write
Snapshot. MU#3-63 can be used in Copy-on-Write Snapshot only.
Note: When you enter the MU number for a ShadowImage/Copy-onWrite Snapshot pair into the configuration definition file, enter only the
number, for example, “0” or “1”.
•MU# for TrueCopy/Universal Replicator/global-active device: Defines the
mirror unit number (0 - 3) if using redundant mirror for the identical LU
on TC/UR/GAD. If this number is omitted, it is assumed to be (MU#0).
You can specify only MU#0 for TrueCopy, and 4 MU numbers (MU#0 - 3)
for Universal Replicator and global-active device.
Note: When you enter the MU number for a TC/UR/GAD pair into the
configuration definition file, add an "h" before the number, for example,
"h0" or "h1".
The instance parameter (HORCM_INST) defines the network address (IP
address) of the remote server (active or standby). It is used to view or
change the status of the paired volume in the remote server (active or
standby). When the primary volume is shared by two or more servers, there
CCI software environment
Command Control Interface User and Reference Guide
2-25
are two or more remote servers using the secondary volume. Thus, it is
necessary to describe the addresses of all of these servers.
The following values are defined in the HORCM_INST parameter:
•dev_group: The server name described in dev_group of HORC_DEV.
•ip_address: The network address of the specified remote server.
•service: The port name assigned to the HORCM communication path
(registered in the /etc/services file). If a port number is specified instead
of a port name, the port number will be used.
A configuration for multiple networks can be found using the raidqry -r<group> command on each host. The current HORCM network address can be
changed using horcctl -NC <group> on each host.
When you use all IP addresses of the local host in a configuration for multiple
networks, specify NONE (for IPv4) or NONE6 (for IPv6) to the ip_address of
the HORCM_MON parameter.
HORCM_LDEV
The HORCM_LDEV parameter is used for specifying stable LDEV# and Serial#
as the physical volumes corresponding to the paired logical volume names.
Each group name is unique and typically has a name fitting its use (for
example, database data, Redo log file, UNIX file). The group and paired
2-26
Figure 2-13 Configuration for multiple networks
CCI software environment
Command Control Interface User and Reference Guide
logical volume names described in this item must also be known to the
remote server.
•dev_group: This parameter is the same as HORCM_DEV parameter.
•dev_name: This parameter is the same as HORCM_DEV parameter.
•MU#: This parameter is the same as HORCM_DEV parameter.
•Serial#: This parameter is used to specify the serial number of RAID box.
For VSP G1000, G1500, and VSP F1500, add a “3” at the beginning of the
serial number. For example, for serial number 12345, enter 312345.
•CU:LDEV(LDEV#): This parameter is used to describe the LDEV number in
the RAID storage system and supports three types of format as LDEV#.
Specifying "CU:LDEV" in hex.
Example for LDEV# 260:
01:04
¢
Specifying "LDEV" in decimal used by the CCI inqraid command.
Example for LDEV# 260:
260
¢
Specifying "LDEV" in hex used by the CCI inqraid command.
Example for LDEV# 260:
0x104
HORCM_LDEVG
The HORCM_LDEVG parameter defines the device group information that the
CCI instance reads. For details about device group, see
function on page 3-35.
The following values are defined.
•Copy group: specifies a name of copy group. This is equivalent to the
•ldev_group: Specifies a name of device group that the CCI instance
•Serial#: Specifies a storage system serial number. For VSP G1000,
Note: The HORCM_LDEV format can only be used on the TagmaStore
USP/TagmaStore NSC. LDEV# will be converted to "Port#, Targ#,
Lun#" mapping to this LDEV internally, because the RAID storage
system needs to specify "Port#, Targ#, Lun#" for the target device.
This feature is TagmaStore USP/TagmaStore NSC microcode
dependent; if HORCM fails to start, HORCM_DEV needs to be used.
LDEV grouping
dev_group of HORCM_DEV and HORCM_LDEV parameters.
CCI operates by using the information defined here.
reads.
G1500, and VSP F1500, add a “3” at the beginning of the serial number.
For example, for serial number 12345, enter 312345.
CCI software environment
Command Control Interface User and Reference Guide
2-27
HORCM_LDEVG
#Copy_Group ldev_group Serial#
ora grp1 64034
HORCM_INSTP
The HORCM_INSTP parameter is used when specifying a path ID for the link
of TrueCopy/Universal Replicator/global-active device as well as
HORCM_INST parameter. You can specify from 1 to 255 for the path ID. If
you do not specify the Path ID, the behavior is the same as when
'HORCM_INST' is used.
Note: The path ID can be specified at TrueCopy, Universal Replicator,
Universal Replicator for Mainframe, and global-active device. However, the
path ID cannot be specified at UR/URz when connecting USP V/VM and USP/
NSC. The same path ID must be specified between the site of P-VOL and SVOL because the path ID is used at the paircreate command.
HORCM_ALLOW_INST
The HORCM_ALLOW_INST parameter is used to restrict the users using the
virtual command device. The allowed IP addresses and port numbers are as
follows.
For IPv4
HORCM_ALLOW_INST
#ip_address service
158.214.135.113 34000
158.214.135.114 34000
For IPv6
HORCM_ALLOW_INST
#ip_address service
fe80::209:6bff:febe:3c17 34000
Note: If CCI clients not defined HORCM_ALLOW_INST, HORCM instance
starting up is rejected by SCSI check condition (SKEY=0x05, ASX=0xfe) and
CCI cannot be started up.
Correspondence of the configuration definition file for cascading
volume and mirror descriptors
The CCI software (HORCM) is capable of keeping a record of the multiple pair
configurations per LDEV. CCI distinguishes the records of the each pair
configuration by MU#. You can assign 64 MU#s for local copy products and 4
MU#s for remote copy products as the following figure, you can define up to
68 device groups (records of pair configuration) in the configuration definition
file.
2-28
CCI software environment
Command Control Interface User and Reference Guide
Figure 2-14 Management of Pair configuration by Mirror Descriptors
Correspondence of configuration file and mirror descriptors
The group name and MU# that are noted in the HORCM_DEV section of the
configuration definition file are assigned to the corresponding mirror
descriptors. This outline is described in the following table. "Omission of
MU#" is handled as MU#0, and the specified group is registered to MU#0 on
ShadowImage/Copy-on-Write Snapshot and TrueCopy/Universal Replicator/
global-active device. Also, when you note the MU# in HORCM_DEV, the
sequence of the MU# can be random (for example, 2, 1, 0).
Table 2-3 Assignments of Group name and MU# to Mirror Descriptors
MU#0
HORCM_DEV Parameter in Configuration File
ShadowIma
ge (Copy-on-
Write
Snapshot)
Only
UR/GAD
HORCM_DEV
#dev_group dev_name port# TargetID LU# MU#
Oradb oradev1 CL1-D 2 1
HORCM_DEV
#dev_group dev_name port# TargetID LU# MU#
Oradb oradev1 CL1-D 2 1
Oradb1 oradev11 CL1-D 2 1 1
Oradb2 oradev21 CL1-D 2 1 2
HORCM_DEV
#dev_group dev_name port# TargetID LU# MU#
Oradb oradev1 CL1-D 2 1
Oradb1 oradev11 CL1-D 2 1 0
Oradb2 oradev21 CL1-D 2 1 1
Oradb3 oradev31 CL1-D 2 1 2
HORCM_DEV
#dev_group dev_name port# TargetID LU# MU#
CCI software environment
Command Control Interface User and Reference Guide
TC/
UR/GAD
oradev1oradev1--
oradev1oradev1oradev11
oradev1oradev11oradev21
-oradev1--
SI
MU#1-#2
(MU#3-#63)
oradev21
oradev31
MU#1-#3
-
-
2-29
HORCM_DEV Parameter in Configuration File
MU#0
ShadowIma
ge (Copy-on-
Write
Snapshot)
Only
UR/GAD
UR/GAD
Oradb oradev1 CL1-D 2 1 0
HORCM_DEV
#dev_group dev_name port# TargetID LU# MU#
Oradb oradev1 CL1-D 2 1 h0
HORCM_DEV
#dev_group dev_name port# TargetID LU# MU#
Oradb oradev1 CL1-D 2 1 0
Oradb1 oradev1 CL1-D 2 1 1
Oradb2 oradev21 CL1-D 2 1 2
HORCM_DEV
#dev_group dev_name port# TargetID LU# MU#
Oradb oradev1 CL1-D 2 1
Oradb1 oradev11 CL1-D 2 1 0
Oradb2 oradev21 CL1-D 2 1 h1
Oradb3 oradev31 CL1-D 2 1 h2
Oradb4 oradev41 CL1-D 2 1 h3
oradev1---
-oradev1oradev11
oradev1
Cascading connection and configuration files
A volume of the cascading connection describes entity in a configuration
definition file on the same instance, and classifies connection of volume
through the mirror descriptor. In case of TrueCopy/ShadowImage cascading
connection, too, the volume entity describes to a configuration definition file
on the same instance. The following figure shows an example of this.
TC/
SI
oradev11-oradev21
MU#1-#2
(MU#3-#63)
oradev21
MU#1-#3
-
oradev31
oradev41
2-30
CCI software environment
Command Control Interface User and Reference Guide
ShadowImage
Since ShadowImage is a mirrored configuration within one storage system, it
can be described as a volume of the cascading connection according to two
configuration definition files. For a ShadowImage-only cascading connection,
the specified group is assigned to the mirror descriptor (MU#) of
ShadowImage, specifically defining "0" as the MU# for ShadowImage.
2-16 Pairdisplay on HORCMINST0 on page 2-32 - Figure 2-18 Pairdisplay on
HORCMINST0 on page 2-32 show ShadowImage cascading configurations
and the pairdisplay information for each configuration.
Figure 2-15 ShadowImage cascade connection and configuration file
Figure
CCI software environment
Command Control Interface User and Reference Guide
2-31
Figure 2-16 Pairdisplay on HORCMINST0
Figure 2-17 Pairdisplay on HORCMINST1
2-32
Figure 2-18 Pairdisplay on HORCMINST0
CCI software environment
Command Control Interface User and Reference Guide
Cascading connections for TrueCopy and ShadowImage
The cascading connections for TrueCopy/ShadowImage can be set up by
using three configuration definition files that describe the cascading volume
entity in a configuration definition file on the same instance. The mirror
descriptor of ShadowImage and TrueCopy definitely describe "0" as MU#, and
the mirror descriptor of TrueCopy does not describe "0" as MU#.
Figure 2-19 TrueCopy/ShadowImage cascading connection and
configuration file
Figure 2-20 Pairdisplay for TrueCopy on HOST1 on page 2-34 through Figure
2-23 Pairdisplay for ShadowImage on HOST2 (HORCMINST0) on page 2-35
show TrueCopy/ShadowImage cascading configurations and the pairdisplay
information for each configuration.
CCI software environment
Command Control Interface User and Reference Guide
2-33
Figure 2-20 Pairdisplay for TrueCopy on HOST1
Figure 2-21 Pairdisplay for TrueCopy on HOST2 (HORCMINST)
2-34
CCI software environment
Command Control Interface User and Reference Guide
Figure 2-22 Pairdisplay for ShadowImage on HOST2 (HORCMINST)
Figure 2-23 Pairdisplay for ShadowImage on HOST2 (HORCMINST0)
CCI software files
The CCI software consists of files supplied with the software, log files created
internally, and files created by the user. These files are stored on the local
disk in the server machine.
CCI files supplied with the software on page 2-36
•
CCI log and trace files on page 2-40
•
•User environment variable on page 2-49
Command Control Interface User and Reference Guide
Text filtering/HORCM/usr/bin/rmawkrmawk0544rootsys
2-36
/usr/bin/pairsyncwaitpairsyncwait0544rootsys
/HORCM/usr/bin/raidcfgraidcfg0544rootsys
CCI software environment
Command Control Interface User and Reference Guide
TitleFile nameCommand nameModeUser*Group
DB Validator
setting
DB Validator
confirmation
DB Validator
confirmation
Storage
Replication
Adapter
Configuration
setting command
A file for
management
A file for
management
A file for
management
* For information and instructions for changing the UNIX user for the CCI software, see the CommandControl Interface Installation and Configuration Guide.
Sample file for horcmstart$ROOT:[HORCM]loginhorcm*.com-sys
Sample file for horcmstart$ROOT:[HORCM]runhorcm*.com-sys
Note:
•$ROOT is defined as SYS$POSIX_ROOT. $POSIX_ROOT is necessary when
using C RTL.
•The user name for OpenVMS is "System".
CCI log and trace files
The CCI software (HORCM) maintains internal startup log files, execution log
files, and trace files that can be used to identify the causes of errors and to
keep records of the status transition history of the paired volumes.
CCI log files on page 2-40
•
•CCI trace files on page 2-43
•CCI trace control command on page 2-43
•Command logging for audit on page 2-43
CCI log files
HORCM logs are classified into startup logs and execution logs.
•The startup logs contain data on errors that occur before HORCM
becomes ready to provide services. Thus, if HORCM fails to start up due
to improper environment setting, refer to the startup logs to resolve the
problem.
•The HORCM execution logs (error log, trace, and core files) contain data
on errors that are caused by software or hardware problems. These logs
contain internal error data that does not apply to any user settings,
therefore, you do not need to refer to the HORCM execution logs.
•When an error occurs in execution of a command, data on the error is
collected in the command log file. Refer to the command log file if a
command execution error occurs.
2-40
CCI software environment
Command Control Interface User and Reference Guide
The following figure shows a graphical representation of the CCI log and trace
files within the CCI configuration environment.
Figure 2-24 Logs and traces
The startup log, error log, trace, and core files are stored as shown in Table
2-4 Log file names and locations on page 2-41. Specify the directories for
the HORCM and command log files using the HORCM_LOG and HORCC_LOG
environment variables as shown in
Table 2-5 Environment variables for log
directories on page 2-42. If it is not possible to create the log files, or if an
error occurs before the log files are created, the error logs are output in the
system log file. If the HORCM activation fails, the system administrator
should check the system log file and activation log, identify the error cause,
and take the proper action. The system log file for UNIX-based systems is the
syslog file. The system log file for Windows-based systems is the event log
file.
Table 2-4 Log file names and locations
FileUNIX-based systemsWindows-based systems
Startup
log
HORCM startup log:
$HORCM_LOG/horcm_HOST.log
Command log: $HORCC_LOG/
horcc_HOST.log
$HORCC_LOG/horcc_HOST.oldlog
HORCM startup log:
$HORCM_LOG\horcm_HOST_log.txt
Command log: $HORCC_LOG\horcc_HOST_log.txt
$HORCC_LOG\horcc_HOST_oldlog.txt
CCI software environment
Command Control Interface User and Reference Guide
2-41
FileUNIX-based systemsWindows-based systems
Error
log
TraceHORCM trace:
CoreHORCM core:
HORCM error log:
$HORCM_LOG/horcmlog_HOST/
horcm.log
$HORCM_LOG/horcmlog_HOST/
horcm_PID.trc
Command trace:
$HORCM_LOG/horcmlog_HOST/
horcc_PID.trc
$HORCM_LOG/core_HOST_PID/core
Command core:
$HORCM_LOG/core_HOST_PID/core
Note: HOST denotes the host name of the corresponding machine. PID
denotes the process ID of that machine.
The location of the directory containing the log file depends on your
command execution environment and the HORCM execution environment.
The command trace file and core file reside together under the directory
specified in the HORCM execution environment. A directory specified using
the environment variable HORCM_LOG is used as the log directory in the
HORCM execution environment. If no directory is specified, the directory /tmp
is used. A directory specified using the environment variable HORCC_LOG is
used as the log directory in the command execution environment. If no
directory is specified, the directory /HORCM/log* is used (* = instance
number). A nonexistent directory can be specified as a log directory using the
environment variable.
HORCM error log:
$HORCM_LOG\horcmlog_HOST\horcm_log.txt
HORCM trace:
$HORCM_LOG\horcmlog_HOST\horcm_PID_trc.txt
Command trace:
$HORCM_LOG\horcmlog_HOST\horcc_PID_trc.txt
HORCM core: $HORCM_LOG\core_HOST_PID\core
Command core:
$HORCM_LOG\core_HOST_PID\core
Table 2-5 Environment variables for log directories
Directory nameDefinition
$HORCM_LOGA directory specified using the environment variable HORCM_LOG. The HORCM log
file, trace file, and core file as well as the command trace file and core file are stored
in this directory. If no environment variable is specified, "/HORCM/log/curlog" is used.
$HORCC_LOGA directory specified using the environment variable HORCC_LOG. The command log
file is stored in this directory. If no environment variable is specified, the directory "/
HORCM/log*" is used (* is the instance number). While the HORCM is running, the log
files are stored in the $HORCM_LOG directory shown in (a). When the HORCM starts
up, the log files created in the operation are stored automatically in the
$HORCM_LOGS directory shown in (b).
a. HORCM log file directory in operation
$HORCM_LOG = /HORCM/log*/curlog (* is instance number)
b. HORCM log file directory for automatic storing
$HORCM_LOGS = /HORCM/log*/tmplog (* is instance number)
2-42
Command Control Interface User and Reference Guide
CCI software environment
CCI trace files
The command trace file is used for maintenance aiming at troubleshooting. It
is not created normally. If a cause of an error cannot be identified using the
log file, the environment variables or trace control commands with trace
control parameters are issued to start tracing and the trace file is created.
The trace control parameters include trace level, file size, mode, etc. More
detailed tracing is enabled by increasing the trace level. Tracing is made in
wraparound within the range of the file size. HORCM makes the trace file
according to the trace level specified in the HORCM startup shell script set to
activate the HORCM.
CCI trace control command
The trace control command (one of the HORCM control commands) sets or
changes the trace control parameters. This command is used for
troubleshooting and maintenance. If no trace control parameters can be
specified using the environment variables in your command execution
environment, it is possible to change the trace control parameters into the
global parameters using this command.
parameters on page 2-43 lists and describes the parameters of the trace
control command.
Table 2-6 Trace command parameters
Table 2-6 Trace command
ParameterFunction
Trace level parameterSpecifies the trace level, range = 0 to 15.
Trace size parameterSpecifies the trace file size in KB.
Trace mode parameterSpecifies the buffer mode or non-buffer mode for writing data
in the trace file.
Trace type parameterSpecifies the trace type defined internally.
Trace change instruction Specifies the command or CCI instance for which the trace
control parameters are changed.
Command logging for audit
•Logging other than raidcom command on page 2-43
•Logging raidcom command on page 2-46
Logging other than raidcom command
This section explains the logging other than the raidcom command described
in Logging raidcom command on page 2-46.
CCI supports command logging, this logging function cannot be used for
auditing the script issuing the command. Thus, CCI supports the function
logging the result of the command executions by expanding the current
logging.
CCI software environment
Command Control Interface User and Reference Guide
2-43
This function has the following control parameters.
•$HORCC_LOGSZ variable
This variable is used to specify a maximum size (in units of KB) and
normal logging for the current command. /HORCM/log*/horcc_HOST.log
file is moved to /HORCM/log*/horcc_HOST.oldlog file when reaching in
the specified maximum size. If this variable is not specified or specified as
0, it is same as the current logging for only command error.
This variable is able to define to the environment variable and/or
horcc_HOST.conf as discussed below.
For example setting 2MB size: HORCC_LOGSZ=2048 Export
HORCC_LOGSZ
•/HORCM/log*/horcc_HOST.conf file
This file is used to describe HORCC_LOGSZ variable and the masking
variable for logging. If the HORCC_LOGSZ as the environment variable is
not specified, then HORCC_LOGSZ variable of this file is used. If both
variable is not specified, then it is same as the current logging for only
command error.
•HORCC_LOGSZ variable
This variable must be described as follows: HORCC_LOGSZ=2048
•The masking variable
This variable is used to mask (disable) the logging by specifying a
condition of the command and returned value (except inqraid or EX_xxx
error code). This variable is valid for NORMAL exit.
If executing the pairvolchk command repeatedly at every interval (30
seconds), logging of this command might not be wanted. Therefore, you
can mask it by specifying HORCC_LOGSZ=0 as shown below, and you
might need to change your scripts if tracing is ON.
Example of masking pairvolchk on a script:
Export HORCC_LOGSZ=0 Pairvolchk -g xxx -s Unset HORCC_LOGSZ
The masking feature is to enable the tracing without changing their
scripts. And this feature is available for all CCI commands (except
inqraid or EX_xxx error code).
For example, if you want to mask pairvolchk (returns 22) and raidqry,
specify the following:
pairvolchk=22 raidqry=0
You can track script performance, and then decide to mask by auditing
the command logging file, as needed.
2-44
•Relationship between an environment variable and
horcc_HOST.conf
Logging depends on the $HORCC_LOGSZ environment variable and/or the
HORCC_HOST.conf file as shown below.
$HORCC_LOGSZHORCC_HOST.confPerforming
=valueAny (does not matter) Tracing within this APP
=0NO tracing within this APP
CCI software environment
Command Control Interface User and Reference Guide
$HORCC_LOGSZHORCC_HOST.confPerforming
UnspecifiedHORCC_LOGSZ=value Global tracing within this CCI instance
HORCC_LOGSZ=0NO global tracing within this CCI
instance
Unspecified or
nonexistent
Use the default value (0) The same as
the current logging for only command
error
•Examples for execution
/HORCM/log* directory
[root@raidmanager log9]# ls l
total 16
drwxr-xr-x 3 root root 4096 Oct 27 17:33 curlog
-rw-r--r-- 1 root root 3936 Oct 27 17:36
horcc_raidmanager.log
-rw-r--r-- 1 root root 2097452 Oct 27 17:29
horcc_raidmanager.oldlog
-rw-r--r-- 1 root root 46 Oct 27 17:19
horcc_raidmanager.conf
drwxr-xr-x 3 root root 4096 Oct 27 17:19 tmplog
/HORCM/log*/horcc_HOST.log file
COMMAND NORMAL : EUserId for HORC : root (0) Tue Nov 1
12:21:53 2005
CMDLINE : pairvolchk ss g URA
12:21:54-2d27f-10090- [pairvolchk][exit(32)]
COMMAND NORMAL : EUserId for HORC : root (0) Thu Oct 27
17:36:32 2005
CMDLINE : raidqry l
17:36:32-3d83c-17539- [raidqry][exit(0)]
COMMAND ERROR : EUserId for HORC : root (0) Thu Oct 27
17:31:28 2005
CMDLINE : pairdisplay g UR
17:31:28-9a206-17514- ERROR:cm_sndrcv[rc < 0 from HORCM]
17:31:28-9b0a3-17514- [pairdisplay][exit(239)]
[EX_ENOGRP] No such group
[Cause ]:The group name which was designated or the device name
doesn't exist in the configuration file, or the network address
for remote communication doesn't exist.
[Action]:Please confirm if the group name exists in the
configuration file of the local and remote host
/HORCM/log*/horcc_HOST.conf file
# For Example
HORCC_LOGSZ=2048
#The masking variable
#This variable is used to disable the logging by the command and
exit code.
#For masking below log pairvolchk returned '32'(status is
SVOL_COPY)
#COMMAND NORMAL : EUserId for HORC : root (0) Tue Nov 1
12:21:53 2005
#CMDLINE : pairvolchk ss g URA
#12:21:54-2d27f-10090- [pairvolchk][exit(32)]
pairvolchk=32
pairvolchk=22
CCI software environment
Command Control Interface User and Reference Guide
2-45
Logging raidcom command
The history of performing raidcom command can be stored in syslog server
by outputting it to the syslog file. Since the information of what command
was performed by who and when are recorded on the syslog file, this is
available to use for audit log.
Output the syslog file by using syslog service on the host OS. For details,
refer to the host OS manual.
Caution:
•The packet loss occurs on the syslog because the syslog uses UDP
communication. The log is also lost when the server to be received the
syslog is down because the server does not have a function to store the
data until it recovered. If you want to record the same log at the client
side by considering the lost of syslog at the syslog server, refer to the
output setting of the syslog file.
•This syslog files are not deleted automatically. Delete unnecessary files
accordingly, or make run the log rotation by installing such as the
logrotate service separately.
The conditions to support the output of syslog file
The conditions to support this function are explained in the following:
Supported OS
This function is supported only when the OS of the host is one of the
following (Windows is out of support):
•Solaris 2.5
•Solaris 10/x86
•HP-UX 10.20/11.0/11.2x
•AIX 4.3
•Red Hat Linux 6.0, 7.0, 8.0 AS/ES 2.1, 3.0, 4.0, 5.0
•AS/ES 2.1, 3.0 Update2, 4.0, 5.0 on EM64T / IA641
Target command
The following shows the raidcom command that is target to be output on the
syslog file.
•Setting commands
•raidcom get command status
•Authentication commands (performing the authentication command at the
prompt also becomes the target.)
2-46
However, if the command is not issued to the DKC by detecting the raidcom
command execution error beforehand, the command becomes out of target
even if it falls under the above items.
CCI software environment
Command Control Interface User and Reference Guide
Output setting for the syslog file
A syslog file is output when "1" is set on the RAIDCOM_SYSLOG of
environment variables. The syslog file is not output at the stage of initial
setting.
How to set the syslog.conf
The contents that can be set on the syslog.conf for the environment setting
might vary in each OS. However, set basically according to the syslog.conf
described in the following:
You can record the same log at the client side by considering the lost of
syslog at the syslog server. In this case, add the following settings.
•facility:user
•level:info/err ("info" for the normal command operation; "err" for the
abnormal command operation.)
Syslog file display information
Three kinds of information for one raidcom command are output on the
syslog file.
•Title row (first row)
•Command row (second row)
•Result rows (3 - 132 rows): the number of rows changes depending on
the issuing command.
Table 2-7 Display information of the title row
ItemOutput example
Syslog fixed output
part (Including the
host name)
Process IDPID:1234
Command statusCOMMAND NORMAL or COMMAND ERROR
Jun 27 10:15:13 rmsolx86 raidcom: [ID 702911 user.info]
*It varies depending on the host OS.
Separation:
User name TitleEUserId for HORC :
CCI software environment
Command Control Interface User and Reference Guide
2-47
ItemOutput example
User name of the host root
(user ID)(0)
Time that performed
raidcom
Wed Jun 27 10:15:13 2012
Table 2-8 Display information of the command row
ItemOutput example
Syslog fixed output
part (Including the
host name)
Process IDPID:1234
Title for performed
command
Performed commandraidcom modify ldev -ldev_id 1234 -status nml
Jun 27 10:15:13 rmsolx86 raidcom: [ID 702911 user.info]
*It varies depending on the host OS.
CMDLINE:
Table 2-9 Display information of the result rows
ItemOutput example
Syslog fixed output
part (Including the
host name)
Process IDPID:1234
Jun 27 10:15:13 rmsolx86 raidcom: [ID 702911 user.info]
*It varies depending on the host OS.
[raidcom][raidcom]
Rows for the error
information
Result of
get_command_status
Rows for the returned
values of a command
[EX_CMDRJE] An order to the control/command device was
rejected It was rejected due to SKEY=0x05, ASC=0x26,
ASCQ=0x00, SSB=0x2E11,0x2205 on Serial#(64568)
Display example (It might vary depending on the host OS.)
•Logs when the normal operation
Aug 24 12:24:37 raidmanager raidcom: PID:06864 COMMAND NORMAL :
EUserID for HORC : root(0) Fri Aug 24 12:24:36 2012
Aug 24 12:24:37 raidmanager raidcom: PID:06864 CMDLINE : raidcom
get command_status -ldev_id 0001
Aug 24 12:24:37 raidmanager raidcom: PID:06864 [raidcom]
HANDLE SSB1 SSB2 ERR_CNT Serial# Description
Aug 24 12:24:37 raidmanager raidcom: PID:06864 [raidcom]
00c3 - - 0 64568 Aug 24 12:24:37 raidmanager raidcom: PID:06864 [raidcom]
[exit(0)]
2-48
CCI software environment
Command Control Interface User and Reference Guide
•Logs when the abnormal operation
Aug 24 12:24:27 raidmanager raidcom: PID:06857 COMMAND ERROR :
EUserID for HORC : root(0) Fri Aug 24 12:24:19 2012
Aug 24 12:24:27 raidmanager raidcom: PID:06857 CMDLINE : raidcom
get command_status
Aug 24 12:24:27 raidmanager raidcom: PID:06857 [raidcom] User
for Serial#[64568] : user1234
Aug 24 12:24:27 raidmanager raidcom: PID:06857 [raidcom] User
authentication has failed on Serial#(64568).
Aug 24 12:24:27 raidmanager raidcom: PID:06857 [raidcom]
[EX_ENAUTH] Authentication failed with User
Aug 24 12:24:27 raidmanager raidcom: PID:06857 [raidcom]
[exit(202)]
User-created files
CCI supports scripting to provide automated and unattended copy operations.
A CCI script contains a list of CCI commands that describes a series of
TrueCopy and/or ShadowImage operations. The scripted commands for
UNIX-based platforms are defined in a shell script file. The scripted
commands for Windows-based platforms are defined in a text file. The host
reads the script file and sends the commands to the command device to
execute the TrueCopy/ShadowImage operations automatically.
The CCI scripts are:
•HORCM startup script (horcmstart.sh, horcmstart.exe). A script that
starts HORCM (/etc/horcmgr), sets environment variables as needed (for
example, HORCM_CONF, HORCM_LOG, HORCM_LOGS), and starts
HORCM.
•HORCM shutdown script. (horcmshutdown.sh,horcmshutdown.exe): A script for stopping the HORCM (/etc/horcmgr).
•HA control script. A script for executing takeover processing
automatically when the cluster manager (CM) detects a server error.
When constructing the HORCM environment, the system administrator should
make a copy of the horcm.conf file. The copied file should be set according
to the system environment and registered as the following file (* is the
instance number):
UNIX systems: /etc/horcm.conf or /etc/horcm*.conf
Windows systems:%windir%\horcm.conf or %windir%\horcm*.conf
User environment variable
When HORCM or command is invoked, environment variable can be specified.
CCI software environment
Command Control Interface User and Reference Guide
2-49
2-50
CCI software environment
Command Control Interface User and Reference Guide
3
CCI functions
This chapter describes the CCI functions.
System configuration using CCI
□
Connecting to CCI server already connected by In-Band method using
□
Out-of-Band method
User authentication
□
Command operation authority and user authentication
□
Relation between resource groups and command operations
□
Resource lock function
□
Command execution modes
□
Resource location and parameter
□
LDEV grouping function
□
Pair operations with mainframe volumes
□
Global storage virtualization function
□
CCI functions
Command Control Interface User and Reference Guide
3-1
System configuration using CCI
This section describes system configurations using the in-band method or
out-of-band method. In addition, a system configuration for connecting to an
in-band CCI server by using the out-of-band method is also described. For an
overview of the in-band and out-of-band methods, see
by the in-band and out-of-band methods on page 1-5.
In-band system configurations and out-of-band system
configurations
Values to specify for HORCM_CMD in the configuration definition file are
different between in-band and out-of-band method system configurations.
•In-band method. This method specifies the device special file of
command device in the configuration definition file. For details about
contents to specify for HORCM_CMD, see
on page 2-17.
•Out-of-band method. This method specifies the SVP for creating virtual
command devices or IP addresses of GUM in the command definition file.
For details about contents to specify for HORCM_CMD, see HORCM_CMD
(out-of-band method) on page 2-21.
HORCM_CMD (in-band method)
Command execution
The location of the virtual command device depends on the type of storage
system. The following table lists the storage system types and indicates the
allowable locations of the virtual command device.
Location of virtual command device
Storage system type
VSP Gx00 models, VSP Fx00
models
VSP G1000, G1500, and VSP
F1500
HUS VMOKNot allowedOK
VSPOKNot allowedOK
1.A CCI server is a remote CCI server connected via LAN.
2.CCI on the SVP must be configured as a CCI server in advance.
OK
OKNot allowedOK
SVPGUM
2
OKOK
CCI server
1
The following figures show a system configuration example and a setting
example of a command device and a virtual command device using the inband and out-of-band methods.
Note: For the out-of-band method using the maintenance utility (GUM) of
VSP Gx00 models and VSP Fx00 models, the command might time out if a
controller with GUM is maintained. Before the maintenance, change command
devices so that you use a virtual command device of the other GUM. For
details about how to switch command devices, see
Alternate command device
function on page 2-5.
3-2
CCI functions
Command Control Interface User and Reference Guide
Figure 3-1 System configuration example of in-band and out-of-band
methods (VSP)
In the following figure, CCI B is the CCI server of CCI A. Users can issue a
command from CCI A to a storage system via a virtual command device of
CCI B. Commands can also be issued directly from CCI B without using CCI A.
CCI functions
Command Control Interface User and Reference Guide
3-3
Figure 3-2 System Configuration Example of In-Band and Out-of-Band
Methods (VSP G800, VSP F800)
Note: In the out-of-band method using SVP of VSP G1000, VSP G1500, VSP
F1500, VSP, or HUS VM, a command times out if the microcode of SVP is
changed. Execute the command again after the microcode change completes.
3-4
CCI functions
Command Control Interface User and Reference Guide
System configuration for connecting to a CCI server connected by
the in-band method using the out-of-band method
In the out-of-band method, CCI server ports can be specified as virtual
command devices. Specifying a CCI server port as a virtual command device
allows you to use the out-of-band method to connect to a CCI server
connected to a storage system using the in-band method. For details about
settings for HORCM_CMD in the configuration definition file of this
configuration, see
Tip: If you specify a CCI server port as a virtual command device, it achieves
better performance than the out-of-band method which specifies SVP or GUM
as a virtual command device.
The following figure shows a system configuration example when a CCI server
is connected to a storage system using the in-band method.
HORCM_CMD (out-of-band method) on page 2-21.
Figure 3-3 System configuration example when the CCI server is
connected to the storage system by in-band
Connecting to CCI server already connected by In-Band
method using Out-of-Band method
In Out-of-Band method, CCI server port can also be specified as a virtual
command device. For this reason, CCI server which connected to a storage
CCI functions
Command Control Interface User and Reference Guide
3-5
system in In-Band method can be connected in Out-of-Band method. If a CCI
server is specified as a virtual command device, it provides better
performance than the Out-of-Band method with specified SVP/GUM as a
virtual command device.
Hardware requirements
CCI uses SCSI path through driver to issue I/O for command device. To use
CCI server port as virtual command device, the virtual command device
interface needs to be converted to the actual SCSI path through interface.
Following is the environment for using CCI server port as a virtual command
device.
•CCI server which can set virtual command devices
CCI support platform except Tru64UNIX and the environment can be used
SCSI path through driver
•Client PC which can issue commands to virtual command devices
It must be CCI support platform.
•Initiator port
Initiator port is required on the following storage systems: Virtual Storage
Following is the default port number.
If not specified the instance number: 34000
If specified instance number (X): 34000 + X + 1
If you change the default port number, use following environment
variables.
$HORCM_IPSCPORT=<services>*
* <services>: port number or service name
For details about supported platforms, see the Command Control InterfaceInstallation and Configuration Guide.
I/O Traffic Control
Synchronized I/O is issued from a virtual command device. The queueing
time might occur because of the heavy I/O traffic because the virtual
command device has to relay the command to the next virtual command
device in the cascade configuration using the virtual command device. To
improve the response in this environment, define the configuration so that
asynchronous I/O is issued using the following environment variables.
$HORCM_IPSCPAIO=1
Security setting
Following security can be set.
•Specifying security of IP address and port number
By defining IP address and port number of the client PC that issues
command to virtual command device to HORCM_ALLOW_INST in the
3-6
CCI functions
Command Control Interface User and Reference Guide
configuration definition file, users who can use virtual command device
can be restricted. For the details about the settings to
HORCM_ALLOW_INST, please refer to "Configuration definition file".
•Security setting for virtual command device
By using the following environment variable, security can be set to virtual
command device.
$HORCM_IPCMDSEC=<value>
Specify the number (from 0 to 7) to <value> depending on the contents of
the security which you want, in reference with the following table.
Table 3-1 Security setting for virtual command device
Value
Command device setting
specified
for
<value>
0OFFOFFOFFNo security
1OFFOFFONOnly HORCM_DEV
2OFFONOFFUser authentication
3OFFONONUser authentication
4ONOFFOFFCMD security
5ONOFFONCMD security
6ONONOFFCMD security
Security
setting
User
authentication
Device group
definition
Security to be set
(see Notes)
allowed
required
required
Only HORCM_DEV
allowed
Only HORCM_DEV
allowed
User authentication
required
7ONONONCMD security
User authentication
required
Only HORCM_DEV
allowed
Notes:
•ON: Enabled
•OFF: Disabled
•Only HORCM_DEV allowed: the operation can be performed only for paired logical
volumes described in HORCM_DEV.
•User authentication required: only commands issued by authorized users can be
executed.
•CMD security: only devices recognizable from the host can be operated. For details
about CMD security, see
Data Protection facility on page 7-5.
CCI functions
Command Control Interface User and Reference Guide
3-7
User authentication
CCI allows user authentication by using the operation authority of a user set
by:
•Storage Navigator
•Device Manager - Storage Navigator
•Maintenance utility
User authentication is arbitrary in the Replication operation in the in-band
method while the operation by user authentication is mandatory in the
configuration information operation and in the out-of-band method.
To enable the user authentication function, the user authentication mode of
the command device accessed by CCI must be enabled.
The user authentication function inputs a login command from the client
(server) and, to authenticate the user ID and password sent from CCI and
the same types of information maintained by the storage system, issues an
authentication request to the authentication module (SVP/GUM).
If the user ID and password which are sent by CCI are authenticated, the
storage system generates the session information. The storage system stores
the session information, the user ID, and the client ID, and then sends back
the session information to CCI. CCI stores the session information with the
storage system ID. After that, the session information is added to all
commands which are issued by CCI to the storage system. If the session
information which is added to the command is valid, the storage system
permits the command execution.
When the user logs out, the session information which is stored by CCI, and
the user ID, the client ID, and the session information which are stored in the
storage system are deleted.
A storage system can store only one session information for the same user ID
and the same client ID at the same time. If the storage system received the
login command with the user ID and client ID, corresponding to the session
information which has already been stored, the storage system sends back
the stored session information to CCI without authentication. During
executing the login command, if another login command is input with the
same user ID from the same client, the authentication result of the
subsequent login command will be the same as the authentication result of
login command being executed.
Note:
•The only function that can be used if the user authentication function is
disabled is the Replication function (replication command). If the user
authentication function is disabled, the Provisioning function
(configuration setting command) cannot be used. If you use the global
storage virtualization function, see
groups and command devices on page 3-10. For details about global
storage virtualization, see the Provisioning Guide for Open Systems or
Table 3-2 Relations between resource
3-8
CCI functions
Command Control Interface User and Reference Guide
Provisioning Guide for Hitachi Virtual Storage Platform Gx00 and Fx00
Models.
•If the specific user information or authority information is changed,
perform the user authentication processing on CCI again.
•CCI stores the session information for each user ID (managed by OS)
which is used for login to the client OS. Therefore, if users having the
different user ID (managed by OS) use the same client, execute CCI login
command for each user ID (managed by OS).
Command operation authority and user authentication
When CCI is used with the user authentication function enabled, commands
are executed complying with the operation authority of a user set by:
•Storage Navigator
•Device Manager - Storage Navigator
•Maintenance utility (GUM)
Controlling User Role
CCI verifies whether or not the user executing the command on the host was
already authenticated by checking the command device being in the
authentication mode. After that, CCI obtains the execution authority of the
command that is configured on the user role, and then compares the relevant
command and the execution authority.
Checking the execution authority
If the configuring commands authenticated are compared with the execution
authorities of commands configured on the user role and they do not
correspond, CCI rejects the command with an error code "EX_EPPERM".
Normally, the user role needs to be the consistent and integrated authority
among the large storage systems. In case of HORCM instances that are
configured by the multiple large storage systems, the execution authorities
are obtained by the serial number of the storage systems. If the user role is
for the multiple storage systems and is not consistent among these storage
systems, CCI makes the integrated authority by performing the logical AND
of the execution authorities among the storage systems.
The target commands
CCI checks execution authorities on the following commands that use
command devices.
•horctakeover, horctakeoff
•paircreate, pairsplit, pairresync
•raidvchkset
CCI functions
Command Control Interface User and Reference Guide
3-9
Controlling user resources
CCI verifies the user who executes the command has been authenticated
already. After that, CCI obtains the access authority of the resource groups
that are configured on the user roles, and then compares the access authority
of the user and the specified resources.
Checking resource authorities
If the access is not permitted by comparing the access authorities of the
resource groups configured on the user roles and the specified resource, CCI
rejects the command with an error code "EX_EGPERM". If the resource
groups are defined among the large storage systems, the specified resource
is compared with the resource specified by obtaining the access authority
configured to each large storage system.
Target commands
CCI checks resource authorities on the following commands that use
command devices.
•raidcom commands (commands for setting configurations)
•raidscan (-find verify, -find inst, -find sync except for [d]), pairdisplay,
raidar, raidqry (except for -l and -r)
•raidvchkset, raidvchkscan, raidvchkdsp
Relation between user authentication and resource groups
In user authentication mode, CCI verifies the access authority of the target
resource based on the user authentication and the role of it. Also, on the user
authentication unnecessary mode and the undefined resource groups, CCI
checks the access authorities shown in the following table.
Table 3-2 Relations between resource groups and command devices
Commands
Resources
Undefined
resource
Defined
resource
3
pairXX
Not
authenticated
2
user
PermittedPermitted by the
EX_EGPERM
4
1
Authenticated
user
authority of
resource ID 0
Permitted by the
authority of the
target resource
ID
Not
authenticated
user
EX_EPPERM
EX_EGPERM
EX_EPPERM
raidcom
2
4
4
Authenticated
user
Permitted by the
authority of
resource ID 0
Permitted by the
authority of the
target resource
ID
3-10
CCI functions
Command Control Interface User and Reference Guide
Commands
pairXX
Resources
Not
authenticated
2
user
Virtual
storage
machine
Notes:
1.Above-described commands except for the raidcom command.
2.User who uses the mode without the command authentication.
3.Undefined as the resource group.
4.Command execution is rejected by the relevant error.
5.The resource group that is defined as the virtual storage machine by the global
storage virtualization function. For details about global storage virtualization, see the
Provisioning Guide for the storage system.
6.When you specify a volume that belongs to meta_resouce or a virtual command
device for HORCM_VCMD in the configuration definition file, the resource operation
for the entire resource group in the virtual storage machine which specifies
HORCM_VCMD is permitted. If you do not specify the virtual storage system for
HORCM_VCMD, EX_EGPERM is returned. When you specify a volume that belongs to
the virtual storage machine for HORCM_CMD in the configuration definition file, the
resource operation for the entire resource group in the virtual storage machine to
which the volume belongs is permitted. For details about specifying the virtual
storage machine to HORCM_VCMD, see
global storage virtualization on page 3-55.
Permitted
5
6
1
Authenticated
user
Permitted by the
authority of the
target resource
ID
Configuration definition file settings with
Not
authenticated
user
EX_EGPERM
EX_EPPERM
raidcom
2
4
Authenticated
user
Permitted by the
authority of the
target resource
ID
Check of the access authority when you operate a pair
When you use the commands other than raidcom commands, which are
described in "Target commands" above, whether the user who executes the
command has an access authority to the resource is checked. Usually, only
one resource in the volumes which configures a pair is checked, the resource
is managed by the instance which executes the pair operation command.
However, when you operate a pair of a local copy, if the
HOMRCF_CHECK_RSGID environment variable is defined, an access authority
of the command execution user to both volumes which configure a pair can
be checked.
The following figure shows an example of a pair operation when you do not
define the HOMRCF_CHECK_RSGID environment variable. The command
execution user can create a pair even if one of the volume which configures
the pair is a resource to which the user does not have an authority.
CCI functions
Command Control Interface User and Reference Guide
3-11
Figure 3-4 Example of a pair operation when you do not define the
HOMRCF_CHECK_RSGID environment variable
The following figure shows an example of a local copy pair operation when
you define the HOMRCF_CHECK_RSGID environment variable. You can avoid
creating a pair which includes the volume without authority, therefore
whether the both volumes which configure a pair are authenticated or not is
checked.
3-12
CCI functions
Command Control Interface User and Reference Guide
Figure 3-5 Example of a local copy pair operation when you define the
HOMRCF_CHECK_RSGID environment variable
Target resources
The following objects are arbitrarily defined as the resource groups by each
user.
•LDEV
•Physical port
•Host group
•RAID group
•External connection group
Commands executed depending on operation authorities
The following table lists the commands executed depending on operation
authority of a user set by:
•Storage Navigator
•Device Manager - Storage Navigator
•Maintenance utility
CCI functions
Command Control Interface User and Reference Guide
3-13
For information about creating the user accounts, registering user accounts to
user groups, and user group authorities, see the Hitachi Command Suite User
Guide or the System Administrator Guide or Hitachi Storage Navigator User
Guide for the storage system.
Table 3-3 Executable commands executed depending on operation
authority of a user set by Storage Navigator, Device Manager - Storage
Command Control Interface User and Reference Guide
Operation
Operation
target
Authority
Executable
command
Operation
authority (Role)
Quorum diskLDEV setting
authority
HAM/GAD pair
creation
authority
HAM/GAD pair
deletion
authority
raidcom modify
quorum
raidcom replace
quorum
Storage
Administrator
(Provisioning)
Storage
Administrator
(Provisioning)
Relation between resource groups and command operations
The operation for using resource groups are different by the command
devices (the In-Band method) or the Out-of-Band method that are used when
you start CCI.
You can create resource groups for each resource. And you can share them
with multiple users. When user 10 and user 20 share the port like the
following figure, the relation between the command devices and resource
groups that user can use is like
and command devices on page 3-22.
Table 3-4 Relation between resource groups
CCI functions
Command Control Interface User and Reference Guide
3-21
Login
user
Figure 3-6 Relation among user, command devices, and resource groups
Table 3-4 Relation between resource groups and command devices
Command
device
Operating rangeReference
Configuration
change
Command
operations
using the
out-of-
band
method
System
administra
tor
3-22
CM0Can operate all resource
groups after logging in.
CM10Can operate only in the
range of resource group 10,
and the shared ports after
logging in.
CM11Can operate only in the
range of resource group 11,
and the shared ports after
logging in.
CM20Can operate only in the
range of resource group 20,
CCI functions
Command Control Interface User and Reference Guide
OperableOperableOperable
OperableOperableInoperable
OperableOperableInoperable
OperableOperableInoperable
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.