Hitachi Block Storage Driver For Openstack Queens: User Guide

Hitachi Block Storage Driver for OpenStack
Queens
User Guide
MK-92ADPTR136-03
August 2018
© 2015, 2018 Hitachi, Ltd. All rights reserved.
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 commercial purposes without the express written permission of Hitachi, Ltd., or
Hitachi Vantara 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 Vantara Corporation at https://support.hitachivantara.com/en_us/contact-
us.html.
Notice: Hitachi products and services can be ordered only under the terms and conditions of the applicable Hitachi agreements. The use of
Hitachi products is governed by the terms of your agreements with Hitachi Vantara 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; and
2. Verifying that your 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.
All other trademarks, service marks, and company names in this document or website are properties of their respective owners.
Hitachi Block Storage Driver for OpenStack Queens User Guide ii

Contents
Preface..................................................................................................... 7
Intended audience............................................................................................... 7
Software version.................................................................................................. 7
Document conventions........................................................................................ 7
Release notes......................................................................................................9
Changes made in this revision.............................................................................9
Referenced documents .......................................................................................9
Related documents ...........................................................................................10
Conventions for storage capacity values........................................................... 11
Getting help........................................................................................................12
Comments..........................................................................................................12
Chapter 1: Overview............................................................................. 13
System Configuration.........................................................................................13
Supported Cinder functions .............................................................................. 14
Support for additional OpenStack operations ................................................... 16
Backend storage management configuration.................................................... 16
Volume operations........................................................................................17
Copy operations .......................................................................................... 18
Volume attachment.......................................................................................21
Backup operations........................................................................................22
Manage and unmanage a volume................................................................23
Volume migration .........................................................................................23
Chapter 2: System requirements.........................................................24

Operating systems.............................................................................................24
OpenStack......................................................................................................... 24
Storage devices................................................................................................. 24
Contents
Hitachi Block Storage Driver for OpenStack Queens User Guide 3
Storage firmware versions................................................................................. 24
Software.............................................................................................................25
Prerequisite packages..................................................................................25
Storage management software ................................................................... 25
Storage software licenses............................................................................ 26
Software restrictions.....................................................................................26
Chapter 3: Installation and configuration.......................................... 27

Installation and setup workflow..........................................................................27
Supported configurations for Block Storage Driver for OpenStack....................28
Management software restrictions .................................................................... 29
Environment setup.............................................................................................29
Connect nodes............................................................................................. 30
Single node configuration.............................................................................30
Controller node without I/O data paths ........................................................31
Configure node setting................................................................................. 32
About the communication mode of the Configuration Manager REST
API server ....................................................................................................32
Configure storage resources........................................................................ 33
Common resources ................................................................................33
Fibre Channel connectivity .....................................................................34
iSCSI connectivity .................................................................................. 35
Configure Configuration Manager REST API server ................................... 37
Secure your storage system password........................................................ 38
Deploy Block Storage Driver for OpenStack (Red Hat)..................................... 38
Install Block Storage Driver for OpenStack (SUSE/Mirantis/Ubuntu)................ 41
Installation prerequisites ..............................................................................41
Block Storage Driver for OpenStack installation for SUSE ......................... 41
Block Storage Driver for OpenStack installation for Mirantis and Ubuntu.... 42
Initial setup.........................................................................................................43
Add a Block Storage Driver for OpenStack configuration (SUSE/
Mirantis/Ubuntu)........................................................................................... 43
Using Crowbar (SUSE OpenStack Cloud).............................................. 43
Using FUEL (Mirantis OpenStack).......................................................... 43
Contents
Using MAAS (Ubuntu OpenStack).......................................................... 43
Linking a volume type and a backend.......................................................... 43
Edit cinder.conf (SUSE/Mirantis/Ubuntu)..................................................... 44
Restart Cinder (SUSE/Mirantis/Ubuntu)............................................................ 45
Verify Block Storage Driver for OpenStack installation...................................... 46
Update the Block Storage Driver for OpenStack............................................... 47
Update the Block Storage Driver for OpenStack software for Red Hat ....... 47
Update the Block Storage Driver for OpenStack software for SUSE .......... 47
Update the Block Storage Driver for OpenStack software for Mirantis
and Ubuntu...................................................................................................48
Updating the management parameters in the cinder.conf file...................... 48
Uninstall Block Storage Driver for OpenStack (SUSE/Mirantis/Ubuntu)............49
Live migration ....................................................................................................50
Configure multipathing.......................................................................................50
Configure high availability..................................................................................51
High availability overview............................................................................. 51
Pacemaker configurations for Cinder volumes.............................................51
Build high availability environment of controller node ................................. 52
Recoverable failures.....................................................................................52
Handling HA post-failover ............................................................................52
Chapter 4: Hitachi extended functions............................................... 54

Copy methods ...................................................................................................54
Maximum number of copy pairs and consistency groups.................................. 57
Port assignment using extra specs....................................................................57
Port scheduler....................................................................................................58
Data deduplication and compression.................................................................59
Enabling deduplication and compression ....................................................60
Creating a volume with dedupe/comp enabled............................................ 60
Deleting a volume with dedupe/comp enabled.............................................61
Chapter 5: Parameters..........................................................................62
Block Storage Driver for OpenStack specific parameters .................................62
Cinder-specific parameters................................................................................75
Contents
Chapter 6: Troubleshooting................................................................ 80
Check the version of Block Storage Driver for OpenStack................................ 80
hbsdgetinfo command....................................................................................... 81
Configuration Manager logs...............................................................................85
Openstack-cinder-volume service does not start...............................................86
Volume (snapshot) cannot be created............................................................... 86
Volume (snapshot) cannot be attached............................................................. 86
Volume operations fail in a multi-controller node environment.......................... 86
Volume attach and detach operations fail..........................................................86
Volume detach operation fails............................................................................87
Volume attach performance issues after HBA replacement.............................. 87
Volume deletion causes error status..................................................................87
Contacting Hitachi Vantara Corporation customer support................................87
Chapter 7: Messages............................................................................ 88
Message output format...................................................................................... 88
List of messages ...............................................................................................89
Messages output by the command hbsdgetinfo......................................... 109
Messages output by the installer......................................................................110
Appendix A: OpenStack overview..................................................... 111

About OpenStack............................................................................................. 111
Cinder overview............................................................................................... 112
Cinder commands............................................................................................ 112
OpenStack commands.....................................................................................112
Appendix B: Block Storage Driver for OpenStack License............113
Glossary........................................................................................... 114
Contents
Preface
This guide provides overview of and technical information for installing, configuring, and
administering Hitachi Block Storage Driver for OpenStack.
Intended audience
This document is intended for operators and administrators who configure and operate
cloud systems using the software tools listed below.
■ Red Hat OpenStack Platform
■ SUSE OpenStack Cloud
■ Mirantis OpenStack
■ Ubuntu OpenStack
■ Configuration Manager REST API
This document assumes they have basic knowledge of Linux operating systems.
Software version
This document applies to Block Storage Driver for OpenStack version 6.1.0 or later for
Queens.
Document conventions
This document uses the following typographic conventions:
Convention Description
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.
Preface
Document conventions
Convention Description
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 Indicates text that is displayed on screen or entered by the user.

Example: pairdisplay -g oradb
< > angle Indicates variables in the following scenarios:

brackets ■ Variables are not clearly separated from the surrounding text or
from other variables. Example:
Status-<report-name><file-version>.csv
■ Variables in headings.
[ ] square Indicates optional values. Example: [ a | b ] indicates that you can

brackets choose a, b, or nothing.
{ } braces Indicates required or expected values. Example: { a | b } indicates

that you must choose either a or b.
| vertical bar Indicates that you have a choice between two or more options or
arguments. Examples:
[ a | b ] indicates that you can choose a, b, or nothing.
{ a | b } indicates that you must choose either a or b.
This document uses the following icons to draw attention to information:
Icon Label Description
Note Calls attention to important or additional information.
Tip Provides helpful information, guidelines, or suggestions for

performing tasks more effectively.
Caution Warns the user of adverse conditions and/or consequences

(for example, disruptive operations, data loss, or a system
crash).
Preface
Release notes
Icon Label Description
WARNING Warns the user of a hazardous situation which, if not

avoided, could result in death or serious injury.
Release notes
Read the release notes 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.
Changes made in this revision

The following changes have been made to this document:
■ The information about the port scheduler function was enhanced.
■ Red Hat OpenStack Platform 13 is now supported. For this reason, the deployment
procedure was added to the following chapter: Installation and configuration (on
page 27) .
Referenced documents
The documents below are referenced in this document or contain more information
about the features described in this document.
Hitachi Vantara documents
Hitachi Command Suite Configuration Manager REST API: REST API Reference Guide,
MK-92HC229
Hitachi Virtual Storage Platform F1500 and Hitachi Virtual Storage Platform G1000,
G1500: Provisioning Guide for Open Systems: Hitachi Virtual Storage Platform G1000, G1500,
and F1500, MK-92RD8014
Hitachi Virtual Storage Platform F400, F600, F800 and Hitachi Virtual Storage Platform
G400, G600, G800: Provisioning Guide: Hitachi Virtual Storage Platform Gx00 and Fx00
Models, MK-94HM8014
Hitachi Virtual Storage Platform F350, F370, F700, F900 and Hitachi Virtual Storage
Platform G350, G370, G700, G900: Provisioning Guide: Hitachi Virtual Storage Platform G/
F350, G/F370, G/F700, G/F900, MK-97HM85026
Hitachi Vantara Support Connect, https://knowledge.hitachivantara.com/Documents
Preface
Related documents
Related documents
The documents below are related to this document or contain more information about
features described in this document.
Hitachi Vantara documents
Common to all storage systems: Thin Image User Guide: Hitachi Virtual Storage Platform F
series and G series, MK-97HM85032
Hitachi Virtual Storage Platform F1500 and Hitachi Virtual Storage Platform G1000,
G1500:
■ System Administrator Guide: Hitachi Virtual Storage Platform G1x00 and F1500,
MK-92RD8016
■ Hardware Guide: Hitachi Virtual Storage Platform G1000,G1500, and Hitachi Virtual
Storage Platform F1500, MK-92RD8007
Hitachi Virtual Storage Platform F400, F600, F800 and Hitachi Virtual Storage Platform
G400, G600, G800:
■ System Administrator Guide: Hitachi Virtual Storage Platform Gx00 and Fx00,
MK-94HM8016
■ Hardware Reference Guide: Hitachi Virtual Storage Platform F400, F600, MK-94HM8045
■ Hardware Reference Guide: Hitachi Virtual Storage Platform F800, MK-94HM8046
■ Hardware Reference Guide: Hitachi Virtual Storage Platform G200, MK-94HM8020
■ Hardware Reference Guide: Hitachi Virtual Storage Platform G400, G600, MK-94HM8022
Hitachi Virtual Storage Platform F350, F370, F700, F900 and Hitachi Virtual Storage
Platform G350, G370, G700, G900:
■ System Administrator Guide: Hitachi Virtual Storage Platform G/F350, G/F370, G/F700, G/
F900, MK-97HM85028
■ Hardware Reference Guide: Hitachi Virtual Storage Platform F350 and F370,
MK-97HM85016
■ Hardware Reference Guide: Hitachi Virtual Storage Platform G350 and G370,
MK-97HM85012
OpenStack
■ OpenStack Cloud Administrator Guide
■ OpenStack Command-Line Interface Reference
■ OpenStack Configuration Reference
Preface
Conventions for storage capacity values
■ Red Hat OpenStack Platform Product Documentation

■ SUSE OpenStack Cloud Product Manual
■ Mirantis OpenStack Product Documentation
■ Ubuntu OpenStack Documentation
Conventions for storage capacity values

Physical storage capacity values (for example, disk drive capacity) are calculated based
on the following values:
Physical capacity unit Value
1 kilobyte (KB) 1,000 (103) bytes
1 megabyte (MB) 1,000 KB or 1,0002 bytes
1 gigabyte (GB) 1,000 MB or 1,0003 bytes
1 terabyte (TB) 1,000 GB or 1,0004 bytes
1 petabyte (PB) 1,000 TB or 1,0005 bytes
1 exabyte (EB) 1,000 PB or 1,0006 bytes
Logical capacity values (for example, logical device capacity, cache memory capacity) are
calculated based on the following values:
Logical capacity unit Value
1 block 512 bytes
1 cylinder Mainframe: 870 KB

Open-systems:
■ OPEN-V: 960 KB
■ Others: 720 KB
1 KB 1,024 (210) bytes
1 MB 1,024 KB or 1,0242 bytes
1 GB 1,024 MB or 1,0243 bytes
1 TB 1,024 GB or 1,0244 bytes
1 PB 1,024 TB or 1,0245 bytes
1 EB 1,024 PB or 1,0246 bytes
Preface
Getting help
Getting help
Hitachi Vantara Support Connect is the destination for technical support of products and
solutions sold by Hitachi Vantara. To contact technical support, log on to Hitachi Vantara
Support Connect for contact information: https://support.hitachivantara.com/en_us/
contact-us.html.
Hitachi Vantara Community is a global online community for Hitachi Vantara 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.hitachivantara.com, register, and complete your profile.
Comments
Please send us your comments on this document to
doc.comments@hitachivantara.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 Vantara Corporation.
Thank you!
Preface
Chapter 1: Overview
Block Storage Driver for OpenStack is based on the OpenStack Block Storage architecture
(Cinder) and it enables you to provide storage services that use high-performance and
high-reliability Hitachi storage systems to build and deliver Infrastructure as a Service
(IaaS).
System Configuration
A typical system configuration for Block Storage Driver for OpenStack contains the main
components shown in the figure below. This figure is an example of a multi-node
configuration where the controller node and the compute nodes are configured on
different nodes.
Controller node
A server that manages cloud systems. The cinder-volume services run on this node.
Install and use Block Storage Driver for OpenStack on this node.
Chapter 1: Overview
Supported Cinder functions
Compute node
A server managed by the controller node.
Configuration Manager REST API server
A server that receives REST API requests from Block Storage Driver for OpenStack, issues
commands to the storage system, and returns the execution results. The REST API server
can be installed independently or installed together as a part of the Hitachi Command
Suite.
Backend storage system
A storage system managed by Cinder. Block Storage Driver for OpenStack uses thin-
provisioned volumes (DP-VOLs) from Hitachi Dynamic Provisioning (DP) pools as backend
storage. To use multiple DP pools, register each DP pool as a separate backend storage
system.
LDEV
An individual logical data volume (on multiple drives in a RAID configuration) in a storage
system.
Volume
Data unit managed by Block Storage Driver for OpenStack.

The following table lists the Cinder operations supported by Block Storage Driver for
OpenStack.
Function Description
Create Volume Creates a volume.
Delete Volume1 Deletes a volume.
Attach Volume Connects a volume to a VM instance.
Detach Volume Disconnects a target volume from a VM instance.
Extend Volume Resizes a volume.
Create Snapshot2 Creates a snapshot that stores point-in-time

data.
Delete Snapshot Deletes a snapshot.
List Snapshot Lists snapshots.
Create Volume from Snapshot Creates a volume with the same content as that
of a snapshot.
Chapter 1: Overview
Create Volume from Image Retrieves image stored from Glance and loads it
into the specified volume. A VM can be started
based on the stored image.
Create Volume from Volume (Clone) Creates a volume and then stores the data from
the source volume.
Create Image from Volume Creates an image from a volume and uploads
the image (Glance).
Volume Migration (host assisted)1 Moves a volume to another DP pool managed by

another storage system.
Consistency Group Consistency groups are used to group volumes

together for the purpose of data protection
(snapshots, backups) and disaster recovery.
Over subscription Uses thin provisioning to manage the capacity of

the storage system.
Volume Migration (storage Moves a volume to another DP pool.

assisted)1
Backup using temp Snapshot Uses a temporary snapshot or volume to

perform non-disruptive backup. As a separate
feature, this function can be used to back up
snapshots. The Cinder backup service must be
running.
Multi-attach Support Simultaneously connects multiple hosts or

servers to a volume.
Caution: It is the responsibility of the

user to ensure that a multiattach or
clustered file system is used on the
volumes. Otherwise there may be a
high probability of data corruption.
Backup Volume Backs up a volume to Swift. The Cinder backup

service must be running.
Restore Backup Restores data to a specified volume from Swift.

The Cinder backup service must be running.
Revert to snapshot Reverts a volume to a previously taken snapshot.
Manage Volume Adds an LDEV created by a different OpenStack

system to the volumes managed by Cinder.
Unmanage Volume Removes a volume created by Cinder from

Cinder management.
Chapter 1: Overview
Support for additional OpenStack operations
Retype Volume1 Changes the volume type.
Notes:
1. This function is not supported for volumes in a group.
2. Snapshots are created using Thin Image (Snapshot).
Support for additional OpenStack operations

The following table lists the OpenStack operations supported by Block Storage Driver for
OpenStack.
Table 1 OpenStack operations supported by Block Storage Driver for OpenStack
OpenStack operation Description
Live Migration Moves a volume managed by Block Storage Driver

for OpenStack and attached to a running VM from
one compute node to another.
Multipath for I/O path Multipath enabled for volumes managed by Block
Storage Driver for OpenStack.
High availability for Cinder You can use the high availability cluster software to
volume services set the cinder-volume service in a redundant
active-standby configuration. High availability is not
supported for SUSE OpenStack Cloud or Mirantis
OpenStack.
Fibre Channel Zone Manager When a volume managed by Block Storage Driver
for OpenStack is attached to a VM via Fibre
Channel, Fibre Channel zoning can automatically
be created or deleted between the compute node
and the storage system during a volume attach or
detach operation, respectively. See https://
docs.openstack.org/mitaka/config-reference/block-
storage/fc-zoning.html for how to specify settings.
Backend storage management configuration

Block Storage Driver for OpenStack uses thin-provisioned volumes (DP-VOLs) from DP
pools as backend storage (a Hitachi storage feature that provides virtual volume
capability). To use multiple DP pools, register each DP pool as a separate backend
storage system. Each DP pool will be identified in the cinder.conf file.
Chapter 1: Overview
Volume operations
Volume operations
Block Storage Driver for OpenStack provides volume operation functions for managing
LDEVs (logical devices or logical units) in the backend storage (DP pools). The figure
below shows an overview of volume operations.
Figure 1 Overview of volume operations
Create and delete a volume

When Block Storage Driver for OpenStack receives the Cinder create volume request, it
creates a virtual volume (DP-VOL) as a logical device (LDEV) from the DP pool. DP-VOLs
allow the storage to be provisioned on an as-needed basis. Volumes can be deleted by
using the Cinder delete volume command.
Extend a volume
Block Storage Driver for OpenStack allows you to resize the DP-VOL, ensuring that the
volume can be expanded to meet changing business requirements.
Note: You cannot expand DP-VOLs created by using Thin Image (Clone)
during asynchronous copying or DP-VOLs that have pair volumes that were
created by using Thin Image (Snapshot).
Chapter 1: Overview
Copy operations
Copy operations
When Block Storage Driver for OpenStack receives a Cinder copy volume request, Block
Storage Driver for OpenStack copies the volume in full by using Thin Image (Clone), and
takes a point-in-time snapshot of the volume by using Thin Image (Snapshot). In
addition, snapshots for multiple volumes can be created by using a single command.
This group of snapshots either guarantees or does not guarantee consistency,
depending on the property of the group type to which the group belongs.
Figure 2 Snapshot operation example
Before you attempt to copy a volume attached to a VM, stop I/O on the VM.
The following table describes the copy methods available for Block Storage Driver for
OpenStack. To perform copy operations, you will need a license for the Thin Image
software product. A maximum of 1,024 clones and snapshots can be created for each
volume.
Copy method Description
Thin Image (Clone) All data in the copy source volume (DP-VOL) is
asynchronously copied to the destination volume. Both
volumes can be used during the asynchronous copy.
Chapter 1: Overview
Copy operations
Copy method Description
Thin Image (Snapshot) Differential data with the copy destination volume is
stored as needed in a virtual volume (V-VOLv2) as an
LDEV. Both volumes can be used. Consistency groups
can also be copied. The virtual volume (V-VOLv2) can
be used in a cascade configuration.
Create a snapshot
Upon receiving a Cinder create snapshot request, Block Storage Driver for OpenStack
creates an LDEV linked to the snapshot, and then copies the snapshot data from the
volume to the LDEV by using one of the available copy methods (see the previous table).
The snapshot cannot be attached to a VM, but it can be kept as a data backup.
Create a volume from a snapshot

Upon receiving a Cinder create volume from snapshot request, Block Storage Driver for
OpenStack creates an LDEV linked to the volume, and then stores the specified snapshot
data in the LDEV by using one of the available copy methods (see the previous table). You
can restore data by using the created snapshot.
Create a volume from a volume (clone)

Upon receiving a Cinder create volume from volume (clone) request, Block Storage Driver
for OpenStack creates an LDEV linked to the volume, and then stores the specified
volume data in the LDEV by using one of the available copy methods (see the previous
table). Volume cloning is useful when multiple users use the same data.
Restore a volume from a snapshot

If data in a volume is corrupted, the Cinder snapshot function restores the data by
creating a new volume from the snapshot. During this process, free space is temporarily
consumed by the new volume and you must change the VM from the corrupted volume
to the newly created volume. By using the snapshot or volume restore operation, you
can restore the corrupted volume without having to create a new one.
Chapter 1: Overview
Copy operations
Figure 3 Snapshot and volume restore operation
Create or delete a group

Block Storage Driver for OpenStack enables you to create or delete a group of volumes.
Deleting a group does not make changes to the backend storage if there are no volumes
in the group. If you try to delete a group that has volumes in it by using cinder
consisgroup-delete --force or cinder group-delete --delete-volumes, the
driver deletes the LDEVs allocated to the volumes in the group.
Create a group from another group

You can create a group from another group. Block Storage Driver for OpenStack creates
DP-VOLs in the backend storage and copies data from the volumes in the source group
to the volumes in the destination group. When data copy is complete, the driver updates
the status of the destination group.
Create a group from a snapshot of another group

You can create a group from a snapshot of another group. Block Storage Driver for
OpenStack creates DP-VOLs in the backend storage and copies data from the snapshots
of the source group to the volumes in the destination group. When data copy is
complete, the driver updates the status of the destination group.
Note: Data consistency between source and destination groups is not

maintained even for groups that are consistency groups.
Chapter 1: Overview
Volume attachment
Update a group
You can modify name and description of a group, as well as add or remove volumes to or
from a group.
Create a snapshot of a group

You can create snapshots of multiple volumes by using a single command (cinder
cgsnapshot-create or cinder group-snapshot-create). These snapshots are
created at the same point in time if the group is a consistency group. If the group is not a
consistency group, snapshots are created separately and the points in time at which the
data for each snapshot is created might differ.
Note:
■ There are two methods for creating a consistency group. A group created
by using cinder consisgroup-create command is always a consistency
group. A group created by using cinder group-create is a consistency
group only if the consistent_group_snapshot_enabled property of
the group type to which the group belongs is set to <is> True.
■ There are two types of group-related Cinder commands: CG commands
(commands that begin with cinder consisgroup- or cinder
cgsnapshot-) and GVG commands (commands that begin with cinder
group-). It is not recommended to use CG commands. In the future, CG
commands will become obsolete and will no longer be supported. In
addition, CG commands and GVG commands are not compatible with each
other. Snapshots created by using CG commands cannot be operated by
using GVG commands.
■ GVG-related commands require volume API version 3.20 or later (cinder
--os-volume-api-version 3.20 or export
OS_VOLUME_API_VERSION=3.20).
■ openstack commands support CG-related operations, but do not support
GVG-related operations yet.
Volume attachment
Block Storage Driver for OpenStack supports storage attachment capability for storage
systems that use the following protocols: Fibre Channel, iSCSI, and Fibre Channel over
Ethernet. Block Storage Driver for OpenStack supports multipath configurations. The
port scheduler function is also supported. If this function is used, then, when volumes
are attached, the active WWNs on the obtained compute nodes are distributed and
registered to the host groups of each port of the storage system. Volumes will be
assigned based on this attachment information. The following figure shows an overview
of the volume attachment operations.
Chapter 1: Overview
Backup operations
Figure 4 Volume attachment
Upon receiving a Cinder attach volume request, Block Storage Driver for OpenStack
attaches a volume to a VM in the specified compute node. Block Storage Driver for
OpenStack then directly connects the Hitachi storage system and the compute node.
This allows the VM to access the attached volume to store data. The volume can also be
detached from the VM. The volume can be attached again to another VM. Block Storage
Driver for OpenStack allows volume attach and detach operations in a multipath
configuration.
Backup operations
You can use standard Cinder functions to back up or restore volumes created by Block
Storage Driver for OpenStack. Note that, if you restore a volume from external storage
by using standard OpenStack functions, the metadata for the volume will be overwritten.
To prevent this, perform the following procedure to restore a volume from external
storage.
Procedure
1. Create a volume to which the data is to be restored. Note the LDEV metadata value,
which can be acquired by using the cinder metadata-show command.
2. Restore the volume from external storage. If the volume ID of the restore target is
not specified, or if the specified volume ID is different from the backed-up volume,
Chapter 1: Overview
Manage and unmanage a volume
the type and LDEV metadata for the restore target volume will not be consistent
with the actual LDEV number.
3. Remove the metadata by using the cinder metadata command. Use the same
command to restore the type and LDEV metadata values. For details about this
command, see the help messages or the Command-Line Interface Reference.
Manage and unmanage a volume
If you plan to move a volume from one OpenStack Cinder instance to another, you can
use the cinder manage and cinder unmanage commands. Specify source-id <LDEV
Number> in the --id-type option.
Volume migration
When Block Storage Driver for OpenStack receives a Cinder migrate volume request, a
virtual volume (DP-VOL) is created as a logical device (LDEV) in the pool specified as the
migration destination, and then the data on the source volume is copied.
When volumes are migrated within the same storage system, storage-assisted copy
processing is performed. When volumes are migrated between different storage
systems, host-assisted copy processing is performed.
Chapter 1: Overview
Chapter 2: System requirements
This chapter describes the hardware and software necessary for using Block Storage
Driver for OpenStack.
Operating systems
For details on the supported operating systems, see the Hitachi Block Storage OpenStack
driver support matrix at: https://support.HitachiVantara.com/en_us/interoperability.html.
OpenStack
For details on the supported OpenStack, see the Hitachi Block Storage OpenStack driver
support matrix at: https://support.HitachiVantara.com/en_us/interoperability.html.
Storage devices
For details on the supported storage systems, see the Hitachi Block Storage OpenStack
driver support matrix at: https://support.HitachiVantara.com/en_us/interoperability.html.
Storage firmware versions

The following table provides the Hitachi storage device firmware versions for each Block
Storage Driver for OpenStack version.
Table 2 Supported storage firmware versions
Storage model Firmware version
VSP F1500 80-05-43 or later

VSP G1000, VSP G1500
VSP F400, F600, F800 83-04-43 or later

VSP G200, G400, G600, G800
VSP F350, F370, F700, F900 88-01-04 or later

Software
Storage model Firmware version

VSP G350, G370, G700, G900
Software
This section describes the software required for each version of the Block Storage Driver
for OpenStack.
Prerequisite packages
The table below lists the prerequisite packages for Block Storage Driver for OpenStack.
Distribution Node Item Contents
SUSE Controller Linux sysfsutils 1, sg3_utils 1, open-iscsi 2,

node environment multipath-tools 3
Compute Linux sysfsutils1, sg3_utils1, open-iscsi2,

node environment multipath-tools3
Ubuntu and Controller Linux sysfsutils1, sg3-utils1, open-iscsi2,

Mirantis node environment multipath-tools3
Compute Linux sysfsutils1, sg3-utils1, open-iscsi2,

node environment multipath-tools3
Notes:
1. For configuring FC.
2. For configuring iSCSI.
3. For configuring multipath.
For other Hitachi driver specifications, see: https://www.HitachiVantara.com/en-us/

products-solutions/application-solutions/hitachi-and-openstack.html.
For the supported storage platforms and the distribution releases, see: https://
support.HitachiVantara.com/en_us/interoperability.html.
Storage management software
The following table shows the versions of Configuration Manager REST API that can be
used to manage Hitachi storage devices.

Storage software licenses
Table 3 Versions of Configuration Manager REST API
Storage model Version
VSP F1500 8.5.4-00 or later

VSP G1000, VSP G1500
VSP F400, F600, F800
VSP G200, G400, G600, G800
VSP F350, F370, F700, F900 8.5.6-00 or later

VSP G350, G370, G700, G900
Storage software licenses

The software licenses listed below are required on each storage device.
■ Hitachi Storage Virtualization Operating System (SVOS)
● Hitachi LUN Manager software
● Hitachi Dynamic Provisioning software
■ Hitachi Local Replication software (Hitachi Thin Image software)
■ Dedupe and compression (optional)
Software restrictions
Do not use Hitachi Dynamic Link Manager (HDLM) in controller nodes or compute nodes.
Use DM-Multipath instead.

Chapter 3: Installation and configuration
This chapter describes how to install and configure Block Storage Driver for OpenStack.
Installation and setup workflow

This topic describes the workflow for preparing, installing and configuring Block Storage
Driver for OpenStack.
Prepare for installation

1. Connect each nodes and the storage. See Connect nodes (on page 30) .
2. Configure the node settings. See Configure node setting (on page 32) .
3. Configure the node settings for storage resources used by Block Storage Driver for
OpenStack. See Configure storage resources (on page 33) .
4. Install and configure the Configuration Manager REST API server. See Configure
Configuration Manager REST API server (on page 37) .
Deploy Block Storage Driver for OpenStack (Red Hat)

1. Deploy Block Storage Driver for OpenStack. See Deploy Block Storage Driver for
OpenStack (Red Hat) (on page 38) .
2. Configure Block Storage Driver for OpenStack. See Initial setup (on page 43) .
3. Verify the installation. See Verify Block Storage Driver for OpenStack installation (on
page 46) .
Install Block Storage Driver for OpenStack (SUSE/Mirantis/Ubuntu)

1. Check the required memory size and disk space, and verify the OpenStack package
installation. See Installation prerequisites (on page 41) .
2. Install Block Storage Driver for OpenStack. See Install Block Storage Driver for
OpenStack (SUSE/Mirantis/Ubuntu) (on page 41) .
3. Configure Block Storage Driver for OpenStack. See Initial setup (on page 43) .
4. Restart Block Storage Driver for OpenStack. See Restart Cinder (SUSE/Mirantis/
Ubuntu) (on page 45) .
5. Verify the installation. See Verify Block Storage Driver for OpenStack installation (on
page 46) .

Supported configurations for Block Storage Driver for OpenStack
Supported configurations for Block Storage Driver for

OpenStack
Hitachi recommends an active-standby cluster configuration of OpenStack controller
nodes and the Configuration Manager REST API servers. The following figure illustrates
such a high-availability (HA) configuration.
The following table describes valid OpenStack system configurations.
Configuration Description
Single-controller This configuration has a single controller node.

configuration
Active-standby This configuration has multiple controller nodes. In this

configuration configuration, only one node on which the cinder-volume
service is running is an active node. The other nodes are
standby nodes. The storage system is shared amongst all
nodes.
Note: Services other than the cinder-volume service can be used in an active-active
configuration in accordance with OpenStack recommendations.
The following table describes the valid system configurations of the Configuration
Manager REST API when used with Block Storage Driver for OpenStack.

Management software restrictions
Configuration Description
Single-server This configuration has one Configuration Manager REST

configuration API server. You can install the Configuration Manager
REST API on a controller node. For the prerequisites for
installing the Configuration Manager REST API on a
controller node, see System Requirements for Hitachi
Command Suite.
Active-standby This configuration has multiple Configuration Manager

configuration REST API servers. Only one server is an active server, and
the other servers are standby servers.
For details about high-availability cluster configurations of the Configuration Manager

REST API, see the Hitachi Command Suite Configuration Manager REST API Reference
Guide.
Management software restrictions

Block Storage Driver for OpenStack does not lock storage systems. For this reason, if
storage resources are also registered with another management software, an error
might occur due to management conflicts. To avoid such errors, you can use the
following parameters to specify resources that can be used by Block Storage Driver for
OpenStack: hitachi_ldev_range to specify a range of LDEV IDs.
Do not use another management software to perform operations on the resources
specified by this parameter.
You can use Configuration Manager REST API to set up resource groups to configure
access control on resources managed by various management software. For details, see
the description of resource groups in the Hitachi Command Suite Configuration Manager
REST API Reference Guide.
Environment setup
It is necessary to configure the storage device to allow Block Storage Driver for
OpenStack to use it. Refer to the documentation provided with the storage device for
details.

Connect nodes
Connect nodes
Connect the controller nodes and compute nodes to the ports of the storage device. The
compute nodes use the ports of the storage device as data paths. You can use Block
Storage Driver for OpenStack to manage both configurations in which controller nodes
and compute nodes use the same ports of a storage device, and configurations in which
controller nodes and compute nodes use different ports. Design the connection
environment based on your operation policy.
The following figure shows a Fibre Channel (FC) connection example:
Figure 5 Connection example of node configuration
The ports of a storage device can be shared with other management software.
Single node configuration

Block Storage Driver for OpenStack allows single node configurations where a single
server is configured to serve the role of the controller node and the compute node.
There are a few operation restrictions to note for a single node environment. These
operations cause I/O disruptions and require you to detach a volume to perform the
operation, and reattach the volume.
■ If a DP-VOL is attached, you cannot copy the volume to images.
■ If a read-only volume is attached, you cannot create volumes for the original snapshot
for the volume.

Controller node without I/O data paths
Controller node without I/O data paths

You can use the configuration on the Controller node without I/O data paths, as shown in
the following image. This configuration is a viable solution if you do not want to give up
Fibre Channel ports for management.
Figure 6 Connection example without I/O data paths for controller node
Use the following settings to configure the controller node without I/O data path.
■ Specify the hitachi_compute_target_ports parameter.
■ Specify the hitachi_rest_pair_target_ports parameter.
■ Do not specify the hitachi_target_ports parameter for Block Storage Driver for
OpenStack.
The following operations are not supported by the controller node without I/O data
paths:
■ Perform a volume migration (host assisted)
■ Create a volume from an image
■ Create an image from a volume
■ Back up a volume
■ Restore a backup
■ Retype a volume

Configure node setting
Configure node setting

You can use the OpenStack configuration installer provided by each distribution to build
the controller node and compute nodes beforehand. It is recommended to use a multi-
node configuration in which the controller node and the compute node use separate
data paths. Some OpenStack configuration installers might require you to specify a
Cinder driver when deploying a Cinder component. When prompted, specify another
driver such as NFS (as you cannot select Block Storage Driver for OpenStack at this time)
and install the Cinder driver after the deployment. Refer to online resources for the
usage of OpenStack configuration installer provided by each distribution. After building
the controller node and the compute nodes, configure each node as described in the
following table.
Node Items Instruction
Controller my_ip for cinder service Specify a unique value for the IPv4
node address for the management LAN
(/etc/cinder/cinder.conf)
of the node.
Initiator IQN Specify a unique value for the

Initiator IQN. This item is for an
(/etc/iscsi/
iSCSI connection.
initiatorname.iscsi)
Compute my_ip for nova compute service Specify a unique value for the IPv4
node address for the management LAN
(/etc/nova/nova.conf)
of the node.
Initiator IQN Specify a unique value for the

Initiator IQN. This item is for an
(etc/iscsi/
iSCSI connection.
initiatorname.iscsi)
About the communication mode of the Configuration Manager REST

API server
The Block Storage Driver for OpenStack uses Configuration Manager REST API server for
storage operations. The Block Storage Driver for OpenStack supports both in-band and
out-of-band methods.
In the in-band management method, the Configuration Manager REST API server
connects to the storage system through a SAN.
In the out-of-band management method, the Configuration Manager REST API server
connects to the storage system through a LAN. This is the default communication mode
for the Configuration Manager REST API server.
If the out-of-band method is used to connect the Configuration Manager REST API server
and the storage system, set the isSecure property to True to encrypt communications
between the Configuration Manager REST API server and the storage system. For the
setting, see Changing the communication mode of the REST API server in Hitachi
Command Suite Configuration Manager REST API Reference Guide.

Configure storage resources
Note: The software used for internal processing has changed from Command
Control Interface (CCI) to Configuration Manager REST API in version 5. See
Updating the management parameters in the cinder.conf file (on page 48)
for updating cinder.conf.
Configure storage resources
Common resources
The following table describes resource requirements for storage systems:
Resource type Contents
All resources All storage resources, such as DP pools and host groups, must
have a name in order for the driver to use them (name fields
cannot be left blank).
Resource groups If using a new resource group for exclusive use by an OpenStack
system, create a new resource group, and assign the necessary
resources, such as LDEVs (including LDEVs for a command
device or pool), port, and host group (iSCSI target).
User accounts To access the storage system from the driver, you must create
an account and be assigned to a user group with the following
roles:
■ Storage Administrator (View Only)
■ Storage Administrator (Provisioning)
■ Storage Administrator (Local Copy)
■ Storage Administrator (Performance Management)
The user groups have management privileges for the created
Resource-Group. You can also use the built-in Storage
Administrator (View & Modify) user group.
DP Pool ■ Create a DP pool that is used by Block Storage Driver for

OpenStack backend. The driver manages virtual capacity
(capacity reserved for over-provisioning of the actual pool
capacity). However you can set the percentage of DP-VOL
capacity that can be created to the total capacity of the pool
as the subscription limit. This can help prevent DP-VOL
blocking caused by a full pool. For example, when the
subscription limit is set to 100%, the total DP-VOL capacity is
equal to the DP pool capacity.
■ Use a pool that is not assigned to a virtual storage machine.
You cannot use DP-VOLs that are assigned to a virtual storage
machine or volumes that have been migrated from another
system using nondisruptive migration.

Fibre Channel connectivity
TI pool If you want to create snapshots by using Thin Image (Snapshot)

in a TI pool, create a TI pool.
Fibre Channel connectivity
The following table describes several Fibre Channel (FC) storage configuration
requirements.
Ports ■ Enable Port Security for the port used by the driver.
■ To use the port scheduler function, enable fabric, and then
set Point to Point (P to P) for Connection Type.
■ If you change the port configuration used by the driver for
connection, restart the openstack-cinder-volume service.
If the volume is attached or detached without restarting the
service, the operation might fail.
Host group for I/O Manual configuration:

data path ■ Create a host group for the port that connects the controller
node and compute nodes. In a multipath configuration,
create host group for all connecting ports.
■ For a multipath configuration, the LDEV numbers and the
connection order (LUN) must match within each host group
of the target node. If they do not match, change each LDEV
connection accordingly to match each LUN.
■ The host group must to be named HBSD-<target host
WWPN> (for example, HBSD-0123456789ABCDEF).
■ Specify HBSD-<target host WWPN> using the WWN of the
smallest WWPN used for the connecting node.
■ Register the WWN of the connecting node in the newly
created host group.
■ If the host groups for a controller node and compute node
are created, reboot the nodes to recognize these paths. If a
new compute node is added and the host group for the node
is created, reboot is necessary for only this node.

iSCSI connectivity

Automatic configuration:
■ Automatically creating the host group requires the
hitachi_group_request parameter to be True. In
addition, to add LDEVs to a host group being created at the
same time, Fibre Channel switches must be used to connect
the storage and the node, and the Fibre Channel Zone
Manager must be enabled.
■ Upon a cinder volume attach request, the driver
automatically creates a host group for the VM port specified
in hitachi_target_ports or
hitachi_compute_target_ports if there is no host group
defined for the port.
■ In the absence of existing host groups, the driver
automatically creates one when copying a volume using copy
functions on the storage system. Do not manually create or
delete host names HBSD-pairXX (XX: number).
■ The driver creates host groups and registers all WWNs for all
ports specified in the hitachi_target_ports or
hitachi_compute_target_ports parameter. Deleting host
groups automatically requires the hitachi_group_delete
parameter to be set to True.
Fibre Channel Manual configuration:

zoning ■ For Fibre Channel switches between a node and the storage
device, manually configure zoning.
■ When the driver attaches a volume to the target VM, Fibre
Channel Zone Manager automatically creates zoning between
the target node and the port used by the driver.
■ Fibre Channel Zone Manager must be enabled, and
hitachi_zoning_request is True.
iSCSI connectivity
The following table describes several of the iSCSI storage configuration requirements.
Ports Enable port security for the ports used by the driver. Configure
the IP address and the TCP port number.

iSCSI connectivity

If you change the port configuration used by the driver for
connection, restart the openstack-cinder-volume service. If
the volume is attached or detached without restarting the
service, the operation might fail.
iSCSI target for I/O Manual configuration:

data path ■ Create an iSCSI target for the port that connects the
controller node and compute nodes. In a multipath
configuration, create host group for all connecting ports.
■ The iSCSI target must be named HBSD-<my_ip> (for example,
HBSD-10.20.30.40). Use the same IP address for my_ip
that you use for a cinder or nova compute service in each
node.
■ Register the Initiator IQN of the connecting node in the newly
created iSCSI target.
■ Register the Target IQN in the newly created iSCSI target. In a
multipath configuration, register the same target IQN in all
iSCSI targets connected to a node.
■ In a multipath configuration, make sure that the value
specified in the hitachi_group_request parameter takes
effect. If you want to manually create an iSCSI target, use the
storage system management software to set 83 for the host
mode option.
■ If CHAP authentication is used, register the CHAP user name
and password with the iSCSI target. Use the same CHAP user
and password for all iSCSI targets.
■ When the driver attaches a volume to a VM instance, the
driver automatically creates an iSCSI target for the VM ports
that are specified in hitachi_target_ports or
hitachi_compute_target_ports if no SCSI target exists
for the ports.
■ In the absence of existing iSCSI targets, the driver
automatically creates one when copying a volume using copy
functions on the storage. Do not manually create or delete
the iSCSI targets HBSD-pairXX (XX: number).

Configure Configuration Manager REST API server

■ Automatic creation of iSCSI targets requires that the
hitachi_group_request parameter is True. The driver
creates iSCSI targets and registers all Initiator IQNs for all
ports used by a node that are specified in the
hitachi_target_ports or
hitachi_compute_target_ports parameter. The driver
registers the target IQN "<Initiator IQN for the target
node>.target" with the iSCSI targets.
■ Deleting iSCSI targets automatically requires the parameter
hitachi_group_delete to be True.
Considerations for multipath configurations:
■ For a multipath configuration, the LDEV numbers and the
connection order (LUN) must match within each iSCSI target
of the target node. If they do not match, change each LDEV
connection accordingly to match each LUN.
■ If the settings are automatic, the driver will use the smallest
available iSCSI target number. Align the LUNs that are already
being used for each port to force the LUNs created by the
driver to match.
Configure Configuration Manager REST API server

Use the procedure below to configure the Configuration Manager REST API server.
Procedure
1. Install the Configuration Manager REST API server.
For details, see installing the REST API in Hitachi Command Suite Configuration
Manager REST API Reference Guide.
2. Register information about the storage system to the Configuration Manager REST
API server.
For details, see Registering a storage system in Hitachi Command Suite Configuration
Manager REST API Reference Guide.

Secure your storage system password
Secure your storage system password

Your password file should be kept out of the file directories that are subject to data
collection for logs. Follow the procedure below to keep your password from being shared
with unauthorized users.
Procedure
1. As a root user, create a password file using a text editor. For example:
File: /opt/hitachi/hbsd/rest_password
Password: !gh8M59Wz#
2. Confirm the password.
# cat /opt/hitachi/hbsd/rest_password
!gh8M59Wz#
3. Hide the password file from all users except the Cinder group.
# sudo chgrp cinder /opt/hitachi/hbsd/rest_password

# sudo chmod 640 /opt/hitachi/hbsd/rest_password
4. Specify the hitachi_rest_password_path parameter in the cinder.conf file

(/etc/cinder/cinder.conf). For example,
hitachi_rest_password_path=/opt/hitachi/hbsd/rest_password.
Note: Do not use the hitachi_rest_password parameter. The

hitachi_rest_password and hitachi_rest_password_path
parameters are mutually exclusive and using hitachi_rest_password
will conflict with the password file path you have added to the
cinder.conf file.

In Red Hat OpenStack Platform 13 and later versions, RPM packages are no longer
installed on controller nodes. Instead, Cinder components (including various drivers) are
deployed as a Docker image to create a virtual machine on which Cinder runs. As a
result, you can now use Block Storage Driver for OpenStack by deploying the container
image of Block Storage Driver for OpenStack.
Use the openstack overcloud deploy command to deploy Block Storage Driver for
OpenStack. For details on how to use this command, see the online documentation on
the Red Hat website.
Red Hat provides the following three deployment methods that acquire an image from
the registry.
■ Remote Registry
■ Satellite Server
■ Local Registry

The procedure for each deployment method is different. For information about each
registry (including how each registry is used), see the following Red Hat documentation:
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/
keeping_red_hat_openstack_platform_updated/
The following is a sample deployment procedure that uses Remote Registry.
Procedure
1. Specify the container image of Block Storage Driver for OpenStack on the Red Hat
website.
Create a new custom_overcloud_images.yaml and set the Block Storage Driver
for OpenStack container image.
File: /home/stack/templates/custom_overcloud_images.yaml
parameter_defaults:
DockerCinderVolumeImage: registry.connect.redhat.com/hitachi/
rhosp13-openstack-cinder-volume-hbsd
The container image of Block Storage Driver for OpenStack is registered in the
following registry.
registry.connect.redhat.com/hitachi/rhosp13-openstack-cinder-
volume-hbsd
2. Create an environment file for Block Storage Driver for OpenStack.

To apply the settings of Block Storage Driver for OpenStack to a Cinder component
during deployment, create a new environment file (for example,
custom_env.yaml) and then edit the file.
File: /home/stack/templates/custom_env.yaml
parameter_defaults:
ControllerExtraConfig:
cinder::config::cinder_config:
VSPG1000/volume_driver:
value:
cinder.volume.drivers.hitachi.hbsd.hbsd_fc.HBSDFCDriver
VSPG1000/hitachi_pool:
value: 13
VSPG1000/hitachi_rest_user:
value: HBSD_USER
VSPG1000/volume_backend_name:
value: VSPG1000
VSPG1000/hitachi_rest_password:
value: password
VSPG1000/hitachi_target_ports:
value: CL1-E, CL2-E
VSPG1000/hitachi_storage_id:
value: 834000400003
VSPG1000/hitachi_rest_api_ip:

value: 172.16.18.108
cinder_user_enabled_backends: ['VSPG1000']
For information on how to set the environment file, see the following Red Hat
documentation:
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/
html/custom_block_storage_back_end_deployment_guide/
3. Deploy the container image.

Run the openstack overcloud deploy command to deploy the components.
When you run the command, specify the following environment setting files:
custom_overcloud_images.yaml and the environment file that you created in
step 2.
# openstack overcloud deploy \

--template -e /home/stack/templates/overcloud_images.yaml \
-e /home/stack/templates/custom_overcloud_images.yaml \
-e /home/stack/templates/custom_env.yaml ...
For information on the specifications of the openstack overcloud deploy

command and information on the deployment methods, see the following Red Hat
documentation:
html/director_installation_and_usage/

Install Block Storage Driver for OpenStack (SUSE/Mirantis/Ubuntu)
Install Block Storage Driver for OpenStack (SUSE/Mirantis/

Ubuntu)
Installation prerequisites
The installation prerequisites for Block Storage Driver for OpenStack are listed below.
■ Verify that you have sufficient memory on the server. The physical memory size
required by the software is: 1 MB x the number of backends x 2.
■ Verify that you have sufficient disk space required to install the driver. The following
table describes the required disk space.
Item Size Location
Block Storage Driver for OpenStack file 1 MB <PATH> /usr/share/pyshared/

hitachi-hbsd
rootwrap file 1 MB /etc/cinder/rootwrap.d/
sudo file 1 MB /etc/sudoers.d
hbsdgetinfo 1 MB /opt/hitachi/hbsd/
Log files 1 MB <PATH> /var/log/hbsd/
■ Check the OpenStack package installation for any missing or invalid packages (see
Software (on page 25) ). Use the rpm command with the -V option specified (debsums
for Ubuntu) to confirm that these packages are installed and are in a normal state. If a
package is not installed or an invalid package is found, install the package again.
Block Storage Driver for OpenStack installation for SUSE

Use the rpm command to install Block Storage Driver for OpenStack. You must log in as a
superuser (root) on the controller node where you want to perform the installation. For
details about how to use the rpm command, see the online documentation on the Linux
website.
Procedure
1. Use the mount command to mount the CD file system when installing from a CD:
# /bin/mount -r -o mode=0544 /dev/cdrom /media
2. Before installing the driver, stop the Cinder volume service.
# /sbin/service openstack-cinder-volume stop
3. After the service is stopped, run the rpm command to install the driver. Install the
appropriate RPM package for your OpenStack environment. The following table

Block Storage Driver for OpenStack installation for Mirantis and Ubuntu
shows the Block Storage Driver for OpenStack RPM package for each supported
OpenStack distribution.
RPM package name RPM storage directory
hbsd.6.1.0-0_11.0.noarch.rpm RPMS/noarch
An example of installing Block Storage Driver for OpenStack:
# /bin/rpm -ivh /media/RPMS/noarch/<RPM package name>
4. After the installation is completed, use the umount command to unmount the CD.
# /bin/umount/media
Block Storage Driver for OpenStack installation for Mirantis and

Ubuntu
Use the dpkg command to install Block Storage Driver for OpenStack. You must log in as
a superuser (root) on the controller node where you want to perform the installation. For
details about how to use the dpkg command, see the Mirantis or Ubuntu online
documentation.
Procedure
1. Use the mount command to mount the CD file system when installing from a CD:
# /bin/mount -r -o mode=0544 /dev/cdrom /media
2. Before installing the driver, stop the cinder-volume service.
# /usr/sbin/service cinder-volume stop
3. After the service is stopped, run the dpkg command to install the driver. The
following table shows the DEB package for each supported OpenStack distribution.
DEB package name DEB storage directory
hbsd-6.1.0-0-11.0_all.deb DEBS/all
An example of installing Block Storage Driver for OpenStack:
# /usr/bin/dpkg -i /media/DEB/UBUNTU/all/<DEB package name>
4. After the installation is completed, use the umount command to unmount the CD.
# /bin/umount/media

Initial setup
Initial setup
Add a Block Storage Driver for OpenStack configuration (SUSE/

Mirantis/Ubuntu)
Normally, a Block Storage Driver for OpenStack configuration is added to the
configuration file /etc/cinder/cinder.conf provided by an openstack-cinder
package. However, some OpenStack configuration installers might automatically change
the configurations of cinder.conf by running configuration management software
such as Puppet. This topic describes additional necessary preparation steps and how to
add the Block Storage Driver for OpenStack configuration, which vary depending on
which OpenStack configuration installer you use.
Using Crowbar (SUSE OpenStack Cloud)

A Chef agent runs on the controller node when an OpenStack environment is built with
Crowbar. Chef resets cinder.conf for the controller node, and any configuration you
have built in the driver will be lost. To resolve this issue, follow the procedure below to
add your driver configuration to the Add New Cinder Backend page in the Crowbar
WebGUI.
Procedure
1. Launch the WebGUI of Crowbar, and select OpenStack in the Barclamps menu.
2. Select Edit in Cinder.
3. Select Other Driver in the Type of Volume menu in the Add new Cinder Backend
field. Click Add Backend to enter the name of the backend.
4. Enter the driver path in the Driver field and the parameters in the Options field for
the backend you have added.
5. In the Deployment field, specify the controller node (only one selectable) in the
cinder-controller field. And specify the backend(s) in the cinder-volume field.
6. Click Apply to save the configuration.
Using FUEL (Mirantis OpenStack)
To configure Block Storage Driver for OpenStack using Mirantis OpenStack, edit the
configuration file (/etc/cinder/cinder.conf) on the controller node.
Using MAAS (Ubuntu OpenStack)

To configure the driver using Ubuntu, edit the configuration file (/etc/cinder/
cinder.conf) on the controller node.
Linking a volume type and a backend

For creating an environment with multiple backends, you can create a volume type and
link it to a particular backend.

Edit cinder.conf (SUSE/Mirantis/Ubuntu)
You can configure the backend specification (volume_backend_name) during backend

setup by using the cinder command in the controller node where a Cinder client is
installed.
# /usr/bin/cinder type-create <volume type name>

# /usr/bin/cinder type-key <volume type name> set
volume_backend_name=<volume backend name>
The following commands show an example of creating a volume type called

HBSD_SAMPLE1 and linking it to the backend hbsd_backend1.
# /usr/bin/cinder type-create HBSD_SAMPLE1

# /usr/bin/cinder type-key HBSD_SAMPLE1 set
volume_backend_name=hbsd_backend1
Use the cinder extra-specs-list command to check the volume type you created
and the value registered for the volume_backend_name key.
Edit cinder.conf (SUSE/Mirantis/Ubuntu)

A driver configuration is added using the OpenStack configuration installer provided by
the distribution in use (see Add a Block Storage Driver for OpenStack configuration
(SUSE/Mirantis/Ubuntu) (on page 43) ). This topic describes how to edit the configuration
file /etc/cinder/cinder.conf provided by the openstack-cinder package.
Specify the driver settings in the configuration file /etc/cinder/cinder.conf. You
need to manually update the configuration file with values that reflect the latest storage
configuration. Specify "parameter=value" pair per line in the following format:
parameter=value

Restart Cinder (SUSE/Mirantis/Ubuntu)
Specify the driver-specific parameters and Cinder-provided parameters for each

backend. An example Block Storage Driver for OpenStack configuration is shown below,
followed by the description of each section of the file. For details about the parameters,
see Parameters (on page 62) .
# cinder.conf sample #
[DEFAULT]
: (Omitted)
enabled_backends=VSPG1000
logging_context_format_string=%(asctime)s.%(msecs)03d % (process)d %
(thread)s
%(levelname)s %(name)s [%(request_id)s %(user_identity)s] % (instance)s%
(message)s
: (Omitted)
[VSPG1000]
volume_driver=cinder.volume.drivers.hitachi.hbsd.hbsd_fc.HBSDFCDriver
volume_backend_name=hbsd_backend1
suppress_requests_ssl_warnings=True
hitachi_storage_id=800000054321
hitachi_pool=0
hitachi_thin_pool=1
hitachi_rest_api_ip=192.0.2.100
hitachi_rest_user=user
hitachi_rest_password_path=/opt/hitachi/hbsd/rest_password
hitachi_target_ports=CL1-A,CL2-A
hitachi_compute_target_ports=CL1-B,CL2-B
Note:
■ If you want to share a port between multiple backends in a multipath
configuration, specify the same port name for all the ports used by the
backends. If the same port name is specified for only some of the
backends, volume-connection operations might fail.
■ If you use the Configuration Manager REST API server's default server
authentication, set suppress_requests_ssl_warnings=True.
■ If you use attach operations for multiple volumes, it is recommended that
you set rpc_response_timeout to a larger value.
Restart Cinder (SUSE/Mirantis/Ubuntu)

To complete the configuration, use the cinder command to restart the cinder-volume
service.

Verify Block Storage Driver for OpenStack installation
Run the following commands to restart the cinder-volume service.

■ For SUSE, use the service command:
# /sbin/service openstack-cinder-volume restart

Currently stopped openstack-cinder-volume: [ OK ]
Currently starting openstack-cinder-volume: [ OK ]
■ For Ubuntu and Mirantis, use the service command:
# /usr/sbin/service cinder-volume restart

Currently stopped cinder-volume: [ OK ]
Currently starting cinder-volume: [ OK ]
Verify Block Storage Driver for OpenStack installation

This topic describes the methods that you can use to verify installation and configuration
of Block Storage Driver for OpenStack.
Procedure
1. After the Cinder service restarts, make sure that Block Storage Driver for OpenStack
is available for use by verifying the following.
■ The message MSGID0003-I is output to the following log file.
Red Hat OpenStack Platform: /var/log/cinder/volume.log
SUSE OpenStack Cloud, Mirantis OpenStack, and Ubuntu OpenStack, for each
backend that has been set: /var/log/cinder/cinder-volume.log
# /bin/grep MSGID0003-I /var/log/cinder/volume.log

2014-03-10 11:34:05.564 28060 WARNING
cinder.volume.drivers.hitachi.hitachi_common [req-c9c94628
-988a-4bcb-8c6d-ac48910e5052 None None] MSGID0003-I: The
storage backend can be used. (config group: VSP G1000)
■ The host status for the specified backend is up by using the cinder service-
list command as shown in the example. The verified backend(s) can be used
for volume operations. If the message is not output, review and update the
configuration file.

Update the Block Storage Driver for OpenStack
2. Verify that the following volume operations can be performed from the Horizon
portal:
■ Create a volume
■ Delete a volume
■ Attach a volume
■ Detach a volume
■ Create a Snapshot
■ Delete a Snapshot
■ Create a volume from Snapshot
If any of these volume operations fail, check the error messages output to the
OpenStack Cinder log file.
Update the Block Storage Driver for OpenStack
Update the Block Storage Driver for OpenStack software for Red Hat
You can update the container image by running the commands openstack overcloud
update prepare and run. In the same way as in the procedure to deploy Block Storage
Driver for OpenStack, run the following command with the environment file for Block
Storage Driver for OpenStack specified.
# openstack overcloud update prepare \

--templates -e /home/stack/templates/overcloud_images.yaml \
-e /home/stack/templates/custom_overcloud_images.yaml \
-e /home/stack/templates/custom_env.yaml
For a detailed update procedure, see the following Red Hat documentation:
keeping_red_hat_openstack_platform_updated/assembly-updating_the_overcloud
Update the Block Storage Driver for OpenStack software for SUSE
Use the procedure described below to update the driver software.
Procedure
1. Stop the cinder-volume service.

Update the Block Storage Driver for OpenStack software for Mirantis and Ubuntu
2. After the service has stopped, install a new version of the driver as shown below.
The following table provides the information about the RPM packages and
supported OpenStack versions.
# /bin/rpm -Uvh /media/RPM-storage-directory/RPM-package-name
For the RPM package name and RPM storage name, see Block Storage Driver for
OpenStack installation for SUSE (on page 41) .
Update the Block Storage Driver for OpenStack software for Mirantis
and Ubuntu
Use the procedure described below to update the driver software for Mirantis and
Ubuntu.
Procedure
2. After the service stops, run the dpkg command to install the driver.
For the DEB package name and DEB storage name, see Block Storage Driver for
OpenStack installation for Mirantis and Ubuntu (on page 42) .
Updating the management parameters in the cinder.conf file

The software used for internal processing was updated from CCI to Configuration
Manager REST API in Block Storage Driver for OpenStack version 5.0. If you are updating
from a version earlier than Block Storage Driver for OpenStack version 5.0, you must
update the parameters in the cinder.conf file.
Procedure
1. Uninstall the Command Control Interface.
2. Modify the parameters in the cinder.conf file according to the table below. For
details on editing the cinder.conf file, see Edit cinder.conf (SUSE/Mirantis/
Ubuntu) (on page 44) . For details on each parameter, see Parameters (on
page 62) .
Old Parameter New Parameter
hitachi_storage_id The format of this parameter value has

changed.
hitachi_horcm_numbers hitachi_rest_number
The format of this parameter value has
changed.

Uninstall Block Storage Driver for OpenStack (SUSE/Mirantis/Ubuntu)
Old Parameter New Parameter
hitachi_horcm_user hitachi_rest_user
hitachi_horcm_password or hitachi_rest_password or
hitachi_horcm_password_path hitachi_rest_password_path
hitachi_horcm_add_conf Delete this parameter.
hitachi_horcm_name_only_discove hitachi_rest_name_only_discover
ry y
hitachi_horcm_disable_io_wait hitachi_rest_disable_io_wait
hitachi_horcm_pair_target_ports hitachi_rest_pair_target_ports
None Add this parameter:

hitachi_rest_api_ip
3. Prepare the Configuration Manager REST API. See Configure Configuration Manager
REST API server (on page 37) .
4. Install the Block Storage Driver for OpenStack. See Update the Block Storage Driver
for OpenStack (on page 47) .
Uninstall Block Storage Driver for OpenStack (SUSE/Mirantis/

Ubuntu)
Follow the procedure below to uninstall the driver.
Procedure
■ For SUSE:
■ For Ubuntu and Mirantis:
2. Uninstall the driver.

■ For SUSE:
# /bin/rpm -e hbsd
# /usr/bin/dpkg -purge hbsd

Live migration
Live migration
The Cinder live migration capability allows you to migrate a VM to another host for
hardware maintenance and other purposes without disrupting workloads. See online
documentation such as OpenStack Cloud Administrator Guide for details about the live
migration function on Nova components and the usage of the OpenStack configuration
installer provided by the distribution in use.
When you perform live migration using Block Storage Driver for OpenStack, follow these
guidelines:
■ Configure DM-Multipath in compute node by editing the configuration file (for
example, /etc/multipath.conf) and then restarting the multipath daemon. See
Configure multipathing (on page 50) .
● user_friendly_names is set to "no"
● find_multipaths is set to "no"
DM-Multipath is required for performing live migration for both single and multipath
configurations.
Note: Volume migration finishes even if it fails to delete the LDEV of the
original volume. In this case, delete it manually because the LDEV of the
original volume remains in storage.
Configure multipathing
Redundant I/O data paths to the storage device enable continuous operations when one
of the paths fails. Device mapper multipathing (DM-Multipath) provides path redundancy
in OpenStack as illustrated in the figure in Connect nodes (on page 30) .
DM-Multipath creates and attaches a multi-path device (dm-X) to the VM.
The details of multipath configuration for controller and compute nodes are described
below. See Cinder-specific parameters (on page 75) for the parameter details. In
addition, see the Linux website for documentation on setting up DM-Multipath.
Controller nodes:
■ Set True for the use_multipath_for_image_xfer parameter.
■ Configure DM-Multipath for the port in the Block Storage Driver for OpenStack
parameter hitachi_target_ports and hitachi_compute_target_ports.
■ Start multipath daemon after configuring the DM-Multipath setting.
Compute nodes:
■ Set True for the volume_use_multipath parameter. List this parameter in the
libvirt section in the Nova configuration file.
■ Start the multipath daemon after configuring the DM-Multipath setting.

Configure high availability
Note:
■ The recommended value for the DM-Multipath varies depending on the
storage device. Refer to multipath configuration guidelines of your storage
device.
■ Configure the live-migration parameters to use live migration (see Live
migration (on page 50) ).
■ Attach or detach volume operation of the volume may fail when one of the
iSCSI paths fails. However, VMs that the volume is attached to can be used
with the other path.
Configure high availability
High availability overview

You can configure multiple controller nodes in a cluster to ensure high availability. If one
node fails, the system falls over to another node to continue operations without any
disruption to the workloads. Each service can select active-standby or active-active
configuration with Pacemaker.
However, active-standby is the only controller-node fail-over configuration supported by
Block Storage Driver for OpenStack.
Pacemaker configurations for Cinder volumes

Block Storage Driver for OpenStack supports only active-standby configuration for
Cinder volumes, and fencing actions reboot when the system fails over. To allow this,
configure Pacemaker parameters for cinder volumes as described in the following table.
Parameter Value
monitor fencing
stop fencing
start fencing
start-delay 10s
clone-set Delete this item
Configure the Pacemaker configuration using the pcs commands. You can reconfigure
node behaviors after the node has been rebooted.

Build high availability environment of controller node
Build high availability environment of controller node

For information on how to build high availability environment, see the following Red Hat
documentation:
understanding_red_hat_openstack_platform_high_availability/
Recoverable failures
When the system detects a storage control path failure that causes the Cinder volume
service to abend, it switches the failed component to the normal one to continue the
operations. Other types of failures might not be detected and as a result the Cinder
volume service becomes unavailable.
When the failed system switches over, the node associated with the failed system will
reboot. During the reboot, all services on the node will become unavailable. You can
reconfigure the node behaviors after it has been rebooted. If you reconfigure the node
to be added back to the cluster, the Active-Active services can be used as Active again.
Note:
If the failed node is recovered and you want to switch the service back to the
recovered node, make sure that there are no running snapshot volumes on
the failover node by using the cinder snapshot-list volume command
before you switch the node back.
Handling HA post-failover
When a controller node fails while storage operations are in progress, the operation
target volumes might be left unprocessed in the storage. This may cause other
operations that are involved with these resources to fail. Follow the procedure listed
below to determine the correct actions.
Procedure
1. Check Pacemaker logs for the failover status and the time it has occurred.
2. If the failover caused Cinder volume processing to stop, use the cinder list
command to find the volumes or snapshot being processed.
3. If the status of a volume is "creating" then go to step 4. Otherwise, perform the
following steps:
a. Get the metadata of the volume or the snapshot by using the cinder
metadata-show command and identify the LDEV number.
b. Find out the storage operation from the volume status.
c. Based on the obtained LDEV number, in the storage system management
software, ensure that the volume is restored to the status it was in before the
operation.
d. Change the status for the corresponding entry on CinderDB to "available" using
the cinder reset-state command.
e. Go to step 6.

Handling HA post-failover
4. Identify the incomplete volume processing from the file volume.log or debug.log
(for Red Hat, the file hbsd_debug.log) around the time when the failover occurred.
5. Check whether any LDEV is associated with the volume. If no LDEV is associated, go
to the following step d. If an LDEV is associated, perform the following steps:
a. Obtain the pair information from the LDEV ID by using the management
software. If a pair exists, delete it.
b. If the LDEV is mapped to a host group or an iSCSI target, disable the mapping.
c. Delete the LDEV by using the storage management software.
d. Change the state of the volume to "available" using the cinder reset-state
command and delete the corresponding entry on CinderDB using the cinder
delete command.
6. If there are any other volumes with incomplete processing, repeat steps 3 through
5.

Chapter 4: Hitachi extended functions
This section provides details and examples for using the extended storage operation
capabilities provided by Hitachi storage devices.
Copy methods
When cloning volumes or creating snapshots, you can choose from one of the two copy
methods, Thin Image (Clone) and Thin Image (Snapshot), provided by storage systems.
When creating snapshots, the copy method is set to Thin Image (Snapshot). The
following table describes which copy method is used under each setting. The copy
method is selected by the hitachi_default_copy_method parameter and the
copy_method metadata for the destination volume. For example, setting pattern 1
indicates that Thin Image (Clone) is used when you clone a volume if the
hitachi_default_copy_method parameter is set to FULL and the copy_method
metadata is not set.
Table 4 Copy methods used in volume data copy
Setting Pattern
Item Value 1 2 31 41 5 61 7 8 91 10
Settings Operation Create volume T T T T T T F T T F

from volume
(clone) or create
volume from
snapshot
Create F F F F F F T F F T
snapshot
Copy Volume or T T T T T T T F F F
source snapshot
Group or group F F F F F F F T T T
snapshot
hitachi_ FULL T T T F F F F T F F
default_
copy_met THIN F F F T T T F F T F
hod
FULL or THIN F F F F F F T F F T
parameter

Copy methods
Setting Pattern
Item Value 1 2 31 41 5 61 7 8 91 10
copy_met Not set T F F T F F F T2 T2 F

hod
metadata FULL F T F F T F F F F F
THIN F F T F F T F F F F
FULL or THIN F F F F F F T F F T
Selected copy Thin Image T T F F T F F T F F

method (Clone)
Thin Image F F T T F T T F T T
(Snapshot)
Legend:
■ T: True
■ F: False
Note:
1. Creating volumes by using Thin Image (Snapshot) is not recommended because of
the following: You cannot delete source volumes or snapshots without deleting
the destination volumes, and you cannot extend or unmanage source volumes,
source snapshots, or destination volumes.
2. You cannot set copy_method metadata because all processing (creation of the
destination volumes and data copy) takes place in the program before destination
volumes become available.

Copy methods
Note:
■ Do not set or change metadata other than copy_method.
■ You can use Thin Image (Snapshot) in cascade configurations. You can
connect up to 64 levels.
■ When using Thin Image (Snapshot) in a cascade configuration, you cannot
delete any intermediary volumes. To delete an intermediary volume, you
first must delete all volumes under the target volume.
■ For the following storage system models, if you use Thin Image (Clone) to
copy data to a volume of a different size, after asynchronous copy is
performed, the volume is expanded. For this reason, processing might
take longer than the time required to copy to a volume of the same size.
- VSP F1500
- VSP G1000
- VSP F400, F600, F800
- VSP G200, G400, G600, G800
The following describes the differences between the two types of
processing:
- Cloning volumes of the same size: (volume creation process) +
(initialization of asynchronous copy process)
- Cloning volumes of different sizes: (volume creation process) +
(initialization of asynchronous copy process) + (asynchronous copy
completion wait time) + (volume capacity extension process)
■ By using Thin Image (Clone), you can repeat the data copy operation for
the target volume while it is being copied. You can repeat the operation up
to three times. The fourth time will cause an error.

Maximum number of copy pairs and consistency groups
Maximum number of copy pairs and consistency groups

The maximum number of Thin Image pairs that can be created for each LDEV assigned
to a volume (or snapshot) is restricted as shown in the following table. If the number of
pairs exceeds the maximum, copy operations will not be executed successfully.
Max. consistency
Max. copy pairs per Max. copy pairs per Max. copy pairs per groups per storage
volume storage system consistency group system
1,024 The number of 8,192* 2,048*

ports used by the
driver x 1,024
Note:
* Including the number of pairs or consistency groups that are not created by using the
driver.
Port assignment using extra specs

Defining particular ports in the Hitachi-supported extra spec hbsd:target_ports
determines which of the ports specified in the hitachi_target_ports or the
hitachi_compute_target_ports parameters are used to create LUN paths during
volume attach operations for each volume type.
The following example shows how to use commands to specify ports in the extra specs.
If you want to add a new port, specify a different volume type.
Note: Use a comma to separate multiple ports.

Port scheduler
Port scheduler
You can use the port scheduler function to reduce the number of WWNs, which are
storage system resource.
In Block Storage Driver for OpenStack, if host groups are created automatically, host
groups are created for each compute node or VM (in an environment that has a WWN for
each VM). If you do not use the port scheduler function, host groups are created and the
same WWNs are registered in all of the ports that are specified for the parameter
hitachi_compute_target_ports or for the parameter hitachi_target_ports. For
Hitachi storage devices, a maximum of 255 host groups and 255 WWNs can be registered
for one port. When volumes are attached, the upper limit on the number of WWNs that
can be registered might be unexpectedly exceeded.
The figure below shows an example of automatically created host groups.
For the port scheduler function, when the cinder-volume service starts, the Fibre
Channel Zone Manager obtains the WWNs of active compute nodes and of active VMs.
When volumes are attached, the WWNs are registered in a round-robin procedure, in the
same order as the order of ports specified for the parameter
hitachi_compute_target_ports or for the parameter hitachi_target_ports.
If you want to use the port scheduler function, set the hitachi_port_scheduler
parameter. For details about the parameter, see Block Storage Driver for OpenStack
specific parameters (on page 62) .
The figure below shows an example of host groups created from the port scheduler.

Data deduplication and compression
Note:
■ Fibre Channel is supported. For details about ports, see Fibre Channel
connectivity (on page 34) .
■ If a host group already exists in any of the ports specified for the
parameter hitachi_compute_target_ports or for the parameter
hitachi_target_ports, no new host group will be created on those
ports.
■ Restarting the cinder-volume service re-initializes the round robin
scheduler as specified in the parameter
hitachi_compute_target_ports or for the parameter
hitachi_target_ports.
■ The port scheduler function divides up the active WWNs from each fabric
controller and registers them to each port. For this reason, the number of
WWNs registered may vary from port to port.
Data deduplication and compression

Deduplication and compression (dedupe/comp) is a method of improving storage
utilization by data reduction. Once your storage administrator has enabled dedupe/
comp for the DP pool, you can create or delete system data volumes for use with
deduplication and compression.

Enabling deduplication and compression
For details, see Capacity saving function: data deduplication and compression in the
Provisioning Guide for the applicable storage system, as listed in Referenced documents
(on page 9) .
Enabling deduplication and compression
Enabling dedupe/comp functionality

To use the dedupe/comp function, your storage administrator must first enable the
dedupe/comp function for the DP pool. For details on how to enable this setting, see the
description of pool management in the Hitachi Command Suite Configuration Manager
REST API Reference Guide.
Note:
Configure the virtualization-excess ratio to be unlimited. If you want to set
some other value for the virtualization-excess ratio, keep in mind that the
capacity of the system data volume is 40 TB.
Creating a volume with dedupe/comp enabled

To create a volume with the dedupe/comp setting enabled, you need to enable dedupe/
comp for the relevant volume type.
Procedure
1. To enable the dedupe/comp setting, specify deduplication_compression for
hbsd:capacity_saving in the extra specs for the volume type.
The example below shows how to enable the dedupe/comp function for volume
type VSP-G1500-1.
2. When creating a volume of the volume type created in the previous step, you can
create a volume with the dedupe/comp function enabled.
The example below shows how to create a volume (10 GB) with the dedupe/comp
function enabled, where the volume type is VSP-G1500-1.

Deleting a volume with dedupe/comp enabled
Deleting a volume with dedupe/comp enabled

The cinder delete command finishes when the storage system starts the LDEV
deletion process. The LDEV cannot be reused until the LDEV deletion process is
completed on the storage system.

Chapter 5: Parameters
This section provides syntax for both Block Storage Driver for OpenStack-specific
parameters and the Cinder-specific parameters. See the example configuration file in
Edit cinder.conf (SUSE/Mirantis/Ubuntu) (on page 44) .
Block Storage Driver for OpenStack specific parameters

The table below describes parameters specific to Block Storage Driver for OpenStack,
which are specified in the backend section of the following configuration file.
■ For Red Hat: The environment file for configuring Block Storage Driver for OpenStack
(example: custom_env.yaml)
documentation.
■ For SUSE/Mirantis/Ubuntu: cinder.conf
Required
or Default
Parameter optional value Description
hitachi_storage_id Required None Specifies the storage device

ID (12 digits) registered on
the REST API server.
Storage device ID: fixed value
per device type (6 digits) +
serial number (6 digits)
If the serial number has
fewer than 6 digits, add
zeroes (0) to the front of the
serial number.
hitachi_storage_cli Required REST If you specify REST, the

Configuration Manager REST
API is used for all storage-
system operations.
Required
or Default
If you are using a VSP F350,
F370, F700, F900 or VSP G350,
G370, G700, G900 storage
system, specify
SIMPLE_REST. API requests
that get information in a
simple format and those that
return responses at a high
speed are used when
volumes are attached or
when volumes are created (as
clones or snapshots). You
cannot specify the
hitachi_ldev_range
parameter.
hitachi_pool Required None Specifies the ID (integer) or

the name of the DP pool that
stores LDEVs for volumes (or
snapshots). Do not use the
DP pool specified for
hitachi_pool for other
purposes.
hitachi_thin_pool Optional None If you use the TI pool for

creating snapshots, specifies
the ID (integer) or the name
of the TI pool that stores
LDEVs for volumes or
snapshots. If you omit this
parameter, the snapshots
created by using Thin Image
(Snapshot) are stored in the
pool specified for
hitachi_pool.
Required
or Default
hitachi_ldev_range Optional None Specifies a range of usable

LDEV numbers in the
<integer-value-1> -
<integer-value-2> format.
The value of <integer-
value-1> must be equal to
or smaller than the value of
<integer-value-2>. If no
value is specified, one of the
following ranges applies: (1) If
no resource group is used,
the entire range permitted by
the storage system can be
used, or (2) The entire range
permitted in a resource group
for the user specified in the
hitachi_rest_user can be
used. You can specify integer
values by using a decimal
format or colon-separated
hexadecimal format
(xx:yy:zz).
hitachi_rest_number Optional 0 Specifies the number for

identifying the Cinder driver
instance. Created by adding
together the storage device
copy group name, device
group name, and snapshot
name. Integer value (0-255).
hitachi_rest_user Required None Specifies the user name used

for authentication to access
the storage device. If the
driver manages multiple
storage devices, use the same
user name, password,
resource group and
permission for all storage
systems.
Required
or Default
hitachi_rest_password or Required None Specifies the password used

hitachi_rest_password_path for authentication to access
the storage device. Only one
of the parameters should be
specified, not both. If neither
parameter is specified,
startup of the backend will
fail. For security reasons, it is
strongly recommended that
you use the
hitachi_rest_password_p
ath parameter. For more
information about how to
secure the password, see
Secure your storage system
password (on page 38) .
hitachi_rest_name_only_discovery Optional False Sets a search restriction on

host groups or iSCSI targets
when attaching and
detaching volumes. If True is
specified, the driver searches
only the host groups or the
iSCSI targets that are named
HBSD-<target host WWPN>
or HBSD-<IP Address of
the connecting host
(my_ip)>, and ignores the
rest. If host groups or iSCSI
targets are created under
different names, attaching
and detaching volumes will
result in an error.
If False is specified, the
driver searches the rest if it
does not find specific host
groups or iSCSI targets that
match these names. In this
case, a search might take
more time.
Required
or Default
hitachi_target_ports Optional None Specifies the controller port

name to search host groups
(iSCSI targets) when attaching
volumes. Specify the port
name in a format conforming
to the storage system that
uses it (for example, VSP
G1000: CL1-A). To use
multipath connection, specify
controller port names,
separated by a comma (for
example, CL1-A,CL2-A).
When attaching volumes to
the Controller node, the
controller port specified for
this parameter is used. When
attaching to the Compute
node, the controller port
specified for this parameter is
used if
hitachi_compute_target_
ports is None (default).
When this parameter is not
specified and
ports as well as
hitachi_rest_pair_targe
t_ports are specified, the
driver operates as the
environment without the I/O
data path of the Controller
node.
If you have a backend storage
system for which
SIMPLE_REST is specified for
the hitachi_storage_cli
parameter and a backend
storage system for which a
different value is specified for
the parameter, do not set the
same port number for those
backend storage systems.
Required
or Default
hitachi_compute_target_ports Optional None Specifies the controller port

name to search host groups
(iSCSI targets) when attaching
volumes to a compute node.
Specify the port name in a
format conforming to the
storage system that uses it
(for example, VSP G1000:
CL1-A). To use the multipath
connection, specify the
controller port names
separated by a comma. If
None (default) is specified,
the controller port specified
in hitachi_target_ports
is used.
If you have a backend storage
system for which
SIMPLE_REST is specified for
the hitachi_storage_cli
parameter and a backend
storage system for which a
different value is specified for
the parameter, do not set the
same port number for those
backend storage systems.
hitachi_rest_pair_target_ports Optional None Specifies a port name for

creating a host group (iSCSI
target) of the HBSD-pairXX (XX
is number) to register an
LDEV when the volume is
copied with storage function.
Specify the port name in a
format conforming to the
storage system that uses it
(for example, VSP G1000:
CL1-A). To specify more than
one port name, separate the
names with commas. If None
(default) is specified, the
controller port specified in
hitachi_target_ports is
used.
Required
or Default
hitachi_group_request Optional False Specifies True or False to

determine whether a host
group (iSCSI target) is created
automatically if a host group
(iSCSI target) corresponding
to the connection target node
does not exist for the port
specified in the
ports parameter. If False
(default) is specified, it does
not create the host group
automatically.
hitachi_group_delete Optional False Defines specifications for

automatically deleting empty
host groups or iSCSI targets
assigned to the target ports
specified in the
ports parameter. Set False
to not delete automatically.
Set True to delete
automatically. If you specify
True, you must also specify
True in the
hitachi_group_request
parameter. If the Fibre
Channel Zone Manager is
used (the
hitachi_zoning_request
parameter must be enabled),
Fibre Channel zones
configured for the host
groups or iSCSI targets will be
deleted.
Required
or Default
hitachi_zoning_request Optional False Specify this parameter if you

are using a Fibre Channel
connection. Specifies True or
False to determine whether
Fibre Channel zoning
between the storage system
and connection target node is
configured automatically by
collaborating with Fibre
Channel Zone Manager. To
configure automatically, you
need to enable Fibre Channel
Zone Manager. See the online
manual for the configuration
of Fibre Channel Zone
Manager. If False (default) is
specified, Fibre Channel
zoning is not configured
regardless of the availability
of Fibre Channel Zone
Manager.
hitachi_use_chap_auth Optional None Specify this parameter if you

are using an iSCSI connection.
When using CHAP
authentication of the iSCSI
targets, set this parameter to
True. For details, see CHAP
authentication in the
Provisioning Guide for the
applicable storage system, as
listed in Referenced
documents (on page 9) .
hitachi_auth_user Optional None Specify this parameter if you

Specifies the CHAP user
name used for authentication
of the iSCSI target. See the
relevant user documentation.
If nothing is specified, HBSD-
CHAP-user is set.
Required
or Default
If True is specified for the
hitachi_use_chap_auth
parameter, this parameter is
required.
hitachi_auth_password Optional None Specify this parameter if you

Specifies the password for
the hitachi_auth_user
setting. See the relevant user
documentation. If nothing is
specified, the HBSD-CHAP-
password is set.
hitachi_use_chap_auth
parameter, this parameter is
required.
hitachi_auth_password_path Optional None Specify this parameter if you

Specifies the file path that
contains the password hint
for hitachi_auth_user.
Either the
hitachi_auth_password or
the
hitachi_auth_password_p
ath parameter should be
specified if using CHAP
authentication. Block Storage
Driver for OpenStack returns
an error if both parameters
are specified. The file must be
placed in a directory where
the Cinder user or group can
access but outside the
directory in which the files
are collected for
troubleshooting purposes
(for example, /opt/
hitachi/hbsd/
rest_password).
hitachi_default_copy_method Optional FULL Specifies the default

copy_method for copying
Required
or Default
volumes. You can specify
FULL for Thin Image (Clone)
or THIN for Thin Image
(Snapshot). For details about
this parameter, see Volume
detach operation fails (on
page 87) .
hitachi_copy_speed Optional 3 Specifies the copy speed for

copying volumes by using
Thin Image (Clone) functions.
You can specify a value in the
range from 1 to 15. If nothing
is specified, 3 is set. Specify 1
or 2 to select slow copy
speed. Specify 3 to select
normal speed, and specify 4
or larger to specify high
speed (prior).
hitachi_copy_check_interval Optional 3 Specifies the interval

(seconds) at which pair
creation is confirmed during
a volume copy. You can
specify a value in the range
from 1 to 600. If nothing is
specified, 3 (seconds) is set.
hitachi_async_copy_check_interval Optional 10 Specifies the interval

(seconds) at which copy pair
synchronization is confirmed.
You can specify a value in the
range from 1 to 600. If
nothing is specified, 10
(seconds) is set.
Required
or Default
hitachi_rest_disable_io_wait Optional False Specifies whether to enable

the I/O check suppression
option for a host group when
the host group is created. If
this parameter is disabled,
before performing volume
detach operations, make sure
that no storage I/O
operations are being
performed. By enabling this
parameter, you can avoid the
problem described in Volume
detach operation fails (on
page 87) .
hitachi_rest_api_ip Required None Specifies the REST API server

hostname or IP address.
hitachi_rest_api_port Optional 23451 Specifies the REST API server

port number. For details
about the REST API server
port number, see the Hitachi
Command Suite
Configuration Manager REST
API Reference Guide.
hitachi_rest_tcp_keepalive Optional True True: Use TCP keepalive

functionality in the
communication with the REST
API server. With this setting,
REST API server failures are
detected in a short time.
False: Do not use TCP
keepalive functionality in the
communication with the REST
API server.
hitachi_over_subscription Optional False Enables the over-subscription

function for VSP F350, F370,
F700, F900 and VSP G350,
G370, G700, G900 storage
systems.
Required
or Default
hitachi_server_auto_create Optional True Enables automatic

connection between the
attached volume and the
server. If True is specified, the
object is automatically
created or updated every
time a Compute node
requests to connect to a
volume. This parameter is
enabled only if SIMPLE_REST
is specified for the
hitachi_storage_cli
parameter.
If False is specified, also
specify False for the
hitachi_server_auto_del
ete parameter.
hitachi_server_auto_delete Optional False Enables automatic disconnect

of the server from the
detached volume. If this
parameter is enabled, the
object is automatically
deleted if no volumes are
attached to the relevant host.
This parameter is enabled
only if SIMPLE_REST is
specified for the
hitachi_storage_cli
parameter.
hitachi_port_scheduler Optional False Specify this parameter to

enable or disable the port
scheduler function. If you
specify True, when an attach
request is received, the active
WWNs that are obtained by
Fibre Channel Zone Manager
will be distributed and
registered to the host groups
of each port of the storage
system. To use this function,
specify True for the
and
Required
or Default
hitachi_rest_name_only_
discovery parameter. If you
specify False for the
hitachi_rest_name_only_
discovery parameter, it will
take a long time to attach
volumes.
hitachi_discard_zero_page Optional True Enables discarding of discard

zero-data pages after a
volume is copied or a
snapshot is created by using
the DD command. If this
parameter is enabled, zero-
data pages are discarded.
hitachi_host_mode_options Optional None Specifies the host mode

options for the host group or
iSCSI target to be created. To
set multiple host mode
options, separate them by
using commas. This
parameter is enabled only if
True is specified for the
parameter.
For iSCSI targets, the host
mode option 83 (Report iSCSI
Full Portal List Mode) is
automatically set.
hitachi_rest_disable_io
_wait parameter, the host
mode option 91 (Disable I/O
wait for OpenStack Option) is
automatically set.
Cinder-specific parameters
Default section (SUSE/Mirantis/Ubuntu)
The table below describes details for the Cinder parameters set in the default section of
the cinder.conf file. Only the parameters relevant to Block Storage Driver for
OpenStack are described here.
Required
or
Parameter optional Default value Description
enabled_backends Optional None Specifies the backend

definition section to be
used. To specify
multiple labels,
separate them by a
comma (for example,
VSP G1000_1, VSP
G1000_2). Do not
specify more than 32
backends for the
enabled_backends
parameter.*
my_ip Optional 127.0.0.1 Specifies the IP address

of the local host (of the
management path). You
must use a unique
address that is not used
in other nodes.
logging_context_format_string Optional See the default Specifies the output

value given in format of logs.
Block Storage
Driver for
OpenStack log
output format.
Required
or
Parameter optional Default value Description
rpc_response_timeout Optional 60 Specifies the timeout

period for attach or
detach processing on a
VM. If attach or detach
processing times out,
the processing is
restarted. This
parameter is specified
in the DEFAULT section
on the controller node
that the cinder-api is
running. To reflect the
configuration, restart
the openstack-cinder-
api service.
host Optional None Specifies a common

host name for all
backends. In the HA
configuration for
controller nodes,
configure the same
value (for example,
ha_cluster) for each
controller node. This
parameter is not
required if the
backend_host
parameter is specified
in the backend
definition section.
Note:
* A maximum of 32 backends supported by Block Storage Driver for OpenStack can be used
concurrently.
Block Storage Driver for OpenStack log output format

For Block Storage Driver for OpenStack, add thread information after the process
information in the default format for log analysis.
Default:
%(asctime)s.%(msecs)03d %(process)d %(levelname)s

%(name)s [%(request_id)s %(user_identity)s]
%(instance)s%(message)s
Block Storage Driver for OpenStack:
%(asctime)s.%(msecs)03d %(process)d %(thread)s

%(levelname)s %(name)s[%(request_id)s %(user_identity)s]
%(instance)s%(message)s
Backend definition section

The table below describes details for the Cinder parameters set in the backend section of
the following configuration files.
■ For Red Hat: The environment file for configuring Block Storage Driver for OpenStack
(example: custom_env.yaml)
documentation.
■ For SUSE/Mirantis/Ubuntu: cinder.conf
Required
or Default
Name optional value Description
volume_driver Required None Specifies the path of the

driver to be used as follows:
To use the FC driver:
cinder.volume.drivers.h
itachi.hbsd.hbsd_fc.HBS
DFCDriver
To use the iSCSI driver:
cinder.volume.drivers.h
itachi.hbsd.hbsd_iscsi.
HBSDISCSIDriver
If no path is specified, startup
of the backend will fail.
volume_backend_name Optional None Specifies the name of the

backend associated with the
volume type.
Required
or Default
reserved_percentage Optional 0 Specifies the reserved area

size for the back-end storage,
using a value in the range
from 0 to 100 (%). To provide
no reserved area, specify 0
(default).
use_multipath_for_image_xfer Optional False When the controller node

and storage are connected
via multipath, specify True or
False to determine whether
to set up a redundant
configuration using a DM-
Multipath in the controller
node. To set up a redundant
configuration, you must start
the multipath daemon in
advance. If you do not want
to set up a redundant
configuration, specify False
(default).
backend_host Optional None Specifies a host name for a

target backend. In the HA
configuration for controller
nodes, configure the same
value (for example,
backend_ha_cluster) for
each backend of the
controller node. If this
parameter and the host
parameter are specified, this
parameter is used.
image_volume_cache_enabled Optional None This parameter is for Image

Volume Cache, which cannot
be used with Block Storage
Driver for OpenStack. Set the
value of this parameter to
False.
If you want to quickly create a
volume from an image, you
can use the Volume-backed
Image function.
Required
or Default
image_upload_use_cinder_backend Optional None This parameter is for the

Volume-backed Image, which
can be used if the parameter
below is set to the value
shown.
hitachi_default_copy_me
thod=FULL
To use this function, set the
value of this parameter to
True and set the parameter
listed above to the value
shown. To not use this
function, set the value of the
parameter to False.
suppress_requests_ssl_warnings Optional False Suppress SSL certificate

warnings.
driver_ssl_cert_path Optional None Can be used to specify a non-

default path to a CA_BUNDLE
file or directory with
certificates of trusted
Certificate Authorities.
driver_ssl_cert_verify Optional False If set to True, the SSL

certificate of the REST API
server will be enabled.
max_over_subscription_ratio Optional 20.0 Specify the maximum over-

subscription ratio of the pool
of the storage system by
specifying either a value of
1.0 or more, or auto (for
automatic expansion). This
parameter is enabled only if
True is specified for the
hitachi_over_subscripti
on parameter.
Chapter 6: Troubleshooting
This section describes troubleshooting procedures for Block Storage Driver for
OpenStack.
Check the version of Block Storage Driver for OpenStack

The first step in troubleshooting is to make sure you are running the desired version of
Block Storage Driver for OpenStack that provides the Cinder functions you want to use.
If you encounter a problem, perform the following procedure to check the version of the
driver and make sure the intended version is installed. If you are using an older version
of the driver, update the software and perform the operation to confirm that the update
has resolved the problem.
■ For Red Hat:
1. Run the docker ps command to obtain the container image ID for rhosp13-
openstack-cinder-volume-hbsd.
2. Run the following command:
# docker inspect <container-image-ID>
Check Config->Labels->version in the command execution result.

■ For SUSE:
Run the following command:
# /bin/rpm -qi hbsd

Run the following command:
# /usr/bin/dpkg -s hbsd
hbsdgetinfo command
hbsdgetinfo command
Function
The command hbsdgetinfo collects data needed to investigate driver errors and
outputs the data to hbsdgetinfo-aaa.bbb.ccc.ddd-yyyymmddhhmmss.tar.gz
(where aaa.bbb.ccc.ddd is the control node IP address and yyyymmddhhmmss is the
date and time of collection).
Format
/opt/hitachi/hbsd/sbin/hbsdgetinfo [-d directory] [-e cinder]
Parameter Description
-d directory Specify the directory to save the data to be collected. The

directory name can be a maximum of 512 bytes long. The
directory can be specified as an absolute or relative path. If you
omit this parameter, the /tmp directory will be used.
-e cinder Specify this parameter to remove data belonging to the Cinder

group (data to be collected by the data collection command
cinder) from the collection target.
Exit code
■ 0: Success
■ 1: Fail
Collected data
Data in the common group is always collected. You can remove data in the Cinder group
from the collection target by specifying the -e option.
Column Collected data Groups
Cinder (including Block All files below /etc/cinder/ Common

Storage Driver for
OpenStack) setting /etc/sudoers.d/cinder* Common
Cinder log All files below /var/log/cinder/ Common
Block Storage Driver for For Red Hat, all files below: Common
OpenStack log
/var/log/cinder/hbsd_*
For SUSE/Mirantis/Ubuntu, all files below:
hbsdgetinfo command
Column Collected data Groups

/var/log/hbsd/
Setting related to FC /etc/multipath.conf Common
All files below /etc/multipath.d/ Common
System log /var/log/messages* Common
Setup of FC-related1 /etc/multipath directory Common
Build date1 /opt/hitachi/hbsd/build_date/* Common
Note:
1. Ubuntu only.
Column Command Output file name Groups
Working cinder absolute-limits cinder_absolu Cinder

status of te-limits
Cinder
cinder availability-zone-list cinder_availa Cinder
bility-zone-
list
cinder backup-list cinder_backup Cinder

-list
cinder cgsnapshot-list cinder_cgsnap Cinder

shot-list
cinder consisgroup-list cinder_consis Cinder

group-list
cinder encryption-type-list cinder_encryp Cinder

tion-type-
list
cinder extra-specs-list cinder_extra- Cinder

specs-list
cinder group-list cinder_group- Cinder

list
cinder group-snapshot-list cinder_group- Cinder

snapshot-list
cinder group-specs-list cinder_group- Cinder

specs-list
hbsdgetinfo command
cinder group-type-list cinder_group- Cinder

type-list
cinder list cinder_list Cinder
cinder qos-list cinder_qos- Cinder

list
cinder rate-limits cinder_rate- Cinder

limits
cinder service-list cinder_servic Cinder

e-list
cinder snapshot-list cinder_snapsh Cinder

ot-list
cinder transfer-list cinder_transf Cinder

er-list
cinder type-list cinder_type- Cinder

list
cinder list-extensions cinder_list- Cinder

extensions
pip show cinder pip_show_cind Cinder

er
Main status of openstack-status openstack- Common

All status
component of
openstack
Working cat /proc/scsi/hfcldd/* cat_proc_scsi Common

status of _hfcldd
hfcldd
cat /sys/class/scsi_host/ cat_class_scs Common
host*/hfcldd_proc i_host_hfcldd
_proc
Working iscsiadm -m discovery -P 1 iscsiadm_- Common

status of iSCSI m_discovery_-
P_1
iscsiadm -m session -P 3 iscsiadm_- Common

m_session_-
P_3
hbsdgetinfo command
Working ls -l /dev/disk/by-path ls - Common

status related l_dev_disk_by
to FC -path
multipath -ll multipath_-ll Common
cat /sys/class/fc_host cat_sys_class Common

_fc_host_node
/host*/node_name
_name
cat /sys/class/fc_host cat_sys_class Common

_fc_host_port
host*/port_state
_state
System uname -a uname_-a Common

information
dmidecode dmidecode Common
rpm -qa 1 rpm_-qa Common
rpm -qi openstack-cinder 1 rpm_- Common

qi_openstack-
cinder
rpm -qi hbsd 1 rpm_-qi_hbsd Common
rpm -V python-cinder 1,4 rpm -V Common

python-cinder
rpm -V hbsd 1,4 rpm -V hbsd 4 Common
dpkg-l 2 dpkg_l Common
dpkg-s cinder-volume 2 dpkg_s_cinder Common

-volume
dpkg-s hbsd 2 dpkg_s_hbsd Common
ifconfig -a ifconfig_-a Common
ethtool_all 3 ethtool_all Common
System log journalctl journalctl Common
Notes:
1. SUSE only.
2. Ubuntu, Mirantis only.
3. Script that collects ethtool information about all network interfaces in a system.
4. The output format is SM5DLUGT c <file>. See the rpm online documentation
for more details about the output format.
Configuration Manager logs
Example
The following example shows how to use the command hbsdgetinfo to collect data.
# /opt/hitachi/hbsd/sbin/hbsdgetinfo
Output example
The command hbsdgetinfo outputs as follows:
# /opt/hitachi/hbsd/sbin/hbsdgetinfo
hbsdgetinfo command started.
creating directory ... succeeded.
copying "/etc/cinder" ... succeeded.
copying "/etc/sudoers.d/cinder" ... succeeded.
copying "/var/log/cinder" ... succeeded.
copying "/var/log/hbsd" ... succeeded.
: (Omitted)
executing "/usr/bin/cinder transfer-list" ... succeeded.
executing "/usr/bin/cinder type-list" ... succeeded.
executing "/usr/bin/cinder list-extensions" ... succeeded.
archiving files ... succeeded.
output to "/tmp/hbsdgetinfo-aaa.bbb.ccc.ddd-yyyymmddhhmmss.tar.gz"
hbsdgetinfo command completed successfully.
Note:
■ The data that can be collected varies depending on the environment. If
data collection fails, the command outputs error messages.
■ The command outputs the message "hbsdgetinfo command
completed successfully" to confirm successful completion of the
command.
■ To collect the data for the Cinder group, Keystone certification for the
administrator user must be kept in the environment variables. To change
settings for the environment variables, use the env command. If that is
not possible, specify the -e cinder option and delete the Cinder group
data from the output.
Configuration Manager logs

If error messages starting with KART- are output to /var/log/cinder/volume.log
and processing ends due to an error, Configuration Manager REST API log files might be
required to investigate the problem.
For details on getting the logs, see Collecting maintenance information about the REST API
in the Hitachi Command Suite Configuration Manager REST API Reference Guide.
Openstack-cinder-volume service does not start
Openstack-cinder-volume service does not start

If an error message for Block Storage Driver for OpenStack is output to /var/log/
cinder/volume.log, see Messages to troubleshoot the problem.
If no error message is output for Block Storage Driver for OpenStack, a Cinder error
message might be output to syslog.
Volume (snapshot) cannot be created

Check for an error message in volume.log, and see Messages (on page 88) to
troubleshoot problem.
Volume (snapshot) cannot be attached

For error messages of Block Storage Driver for OpenStack in volume.log, see Messages
(on page 88) to troubleshoot the problem.
Volume operations fail in a multi-controller node environment

Verify that your OpenStack configuration is valid. Refer to Supported configurations for
Block Storage Driver for OpenStack (on page 28) .
Volume attach and detach operations fail

Volume attach and detach operations might fail when multiple volume operations are
performed concurrently. This can be caused by time outs that occur during the
processing of the Cinder requests in the backends.
You can increase the timeout threshold for all the nodes by modifying the
rpc_response_timeout parameter to 3600 in the nova.conf (/etc/nova/
nova.conf) and the cinder.conf file (/etc/cinder/cinder.conf).
Note: Changing the value of the rpc_response_timeout parameter to a

larger value may increase the time needed to complete processing if an error
occurs during attach or detach operations.
Volume detach operation fails
Volume detach operation fails

If you are using a software that detaches volumes in which no data is written, when you
perform a volume detach operation, the target volume might have already been
detached. In such cases, the volume detach operation fails because of a timeout error.
To prevent this from occurring, set the I/O check suppression option (host mode option
91) for the host group. If the hitachi_group_request parameter is set to True, and if
new host groups are created automatically, specify this option by setting the
hitachi_rest_disable_io_wait parameter to True.
If setting host groups or iSCSI targets for manual configuration, use the storage system
management software to set 91 for the host mode option. For details on setting the host
mode option, see the Hitachi Command Suite Configuration Manager REST API
Reference Guide.
To set this option for host groups that already exist, follow the usage listed below.
Volume attach performance issues after HBA replacement

Replacing a host bus adapter (HBA) in a multipath configuration can impact processing of
volume attach requests in backend storage devices.
Make sure that the host group for the HBA has been updated after the replacement. If
you have not already updated the host group name, with Storage Navigator, change the
name to "HBSD-xxx" where xxx is the smallest WWPN number available for the server.
Volume deletion causes error status

When deleting many volumes in one operation, some of the volumes may result in an
error_deleting status. If this happens, enter the cinder reset-state command. Verify
volume status has returned to available, then retry deleting the volume(s).
Contacting Hitachi Vantara Corporation customer support

If you need to contact Hitachi Vantara customer support, provide as much information
about the problem as possible. Collect the files below and provide them along with the
actions you have taken to resolve the problem.
■ Use the sosreport (Red Hat, Ubuntu, Mirantis) or supportconfig (SUSE) command
to collect data on all nodes.
■ Use the hbsdgetinfo command to collect data on all controller nodes.
■ Copies of the operation logs of High Availability cluster software that collect data on
the controller node in the High Availability cluster. For example, /var/log/
pacemaker.
Chapter 7: Messages
Message output format

This topic describes the format of messages that are output to the volume.log file.
The following is Block Storage Driver for OpenStack message format:
yyyy-mm-dd hh:mm:ss.fff PID loglevel filepath [request_id user tenant]

message
Where:
■ yyyy-mm-dd hh:mm:ss.fff : Date and time of output
■ PID: Process ID
■ loglevel: Log level
■ filepath: File path of the output source
■ request_id: Request ID
■ user: User ID
■ tenant: Tenant ID
■ message: Message content
The actual message content (indicated by MSGID0000-t in the message format above) is
output as follow:
MSGIDn1n2n3n4-t: Message text
Where:
■ MSGID: Indicates that the message is a driver message
■ n1n2n3n4: The serial number of the message
■ t: The message type
The message type indicates the operation corresponding to the message. The message
types are as follows:
Type Description
E Error message indicating that processing cannot continue due to a

driver error or an incorrectly specified option.
Chapter 7: Messages
List of messages
Type Description
W Warning message indicating that a driver error occurred or that an

option was incorrectly specified, but that processing will continue.
I Message providing additional information about processing.

Messages that are neither error messages nor warning messages.
List of messages
Message
ID Message text Driver status Required actions
0000-I The method <method name> Continues None.

was called. (config group: processing the
<backend definition name>) request.
0001-I The parameter of the storage Continues None.

backend. (config_group: processing the
0002-I The method <method name> Continues None.

completed successfully. processing the
(config_group: <backend request.
definition name>)
0003-I The storage backend can be Continues None.

used. (config_group: processing the
0300-W Failed to configure the Continues Verify that the user has
internal logging. (ret: <return processing the sufficient permission
value>, stderr: <standard error request. for the directory.
output>).
0301-W A LUN (HLUN) was not found. Continues None.

(LDEV: <LDEV number>) processing the
request.
0302-W Failed to specify a logical Continues None.

device for the volume processing the
<volume ID> to be unmapped. request.
0303-W An iSCSI CHAP user could not Continues If the CHAP user is no
be deleted. (username: processing the longer needed, delete
<CHAP user name>) request. it using the storage
management software.
Chapter 7: Messages
List of messages
Message
0304-W Failed to specify a logical Continues Make sure that the

device to be deleted. processing the logical devices do not
(method: <method name>, id: request. exist for unnecessary
<volume ID | snapshot ID>) volumes.
0305-W The logical device for Continues Make sure that no

specified <volume|snapshot> processing the invalid volumes or
<volume ID | snapshot ID> request. snapshots exist.
was already deleted.
0306-W A host group could not be Continues Take the actions

deleted. (port: <port name>, processing the specified in the
gid: <group ID>) request. previous message.
0308-W A host group could not be Continues Take the actions

added. (port: <port name>) processing the specified in the
request for previous message.
other ports.
0309-W An iSCSI target could not be Continues Take the actions

added. (port: <port name>) processing the specified in the
request for previous message.
other ports.
0310-W Failed to unmap a logical Continues Make sure that the

device. (LDEV: <LDEV processing the logical devices do not
number>) request for exist for unnecessary
other ports. volumes.
0311-W A free LUN (HLUN) was not Continues None.

found. Add a different host processing the
group. (LDEV: <LDEV number>) request.
0312-W Failed to get a storage Continues None.

resource. The system will processing the
attempt to get the storage request.
resource again. (resource:
<resource>)
0313-W Failed to delete a logical Continues Make sure that the

device. (LDEV: <LDEV processing the logical devices do not
number>) request. exist for unnecessary
volumes or snapshots.
Chapter 7: Messages
List of messages
Message
0314-W Failed to map a logical device. Continues Take the actions

(LDEV: <LDEV>, LUN: <LUN processing the specified in the
number>, port: <port name>, request for the previous message.
id: <group ID>) other host
groups (iSCSI
targets).
0315-W Failed to perform a zero-page Continues None.

reclamation. (LDEV: <LDEV processing the
number>) request.
0317-W Failed to assign the WWN. Continues Take the actions

(port: <port name>, gid: processing the specified in the
<group ID>, wwn: <WWN>) request for the previous message.
other ports.
0318-W Failed to copy meta data of Continues None.

destination volume <volume processing the
ID> to source volume request.
<volume>. (reason: <detailed
message>)
0319-W The logical device does not Continues None.

exist in the storage system. processing the
(LDEV: <LDEV>) request.
0321-W Failed to perform user Continues Verify user

authentication of the REST processing the authentication
API server. (user: <user>) request. information. Enter the
correct values and
retry the operation.
0324-W Failed to delete full copy pair. Continues Take the actions
(P-VOL: <LDEV number>, S- processing the specified in the
VOL: <LDEV number>) request. previous message.
0325-W Failed to delete thin copy Continues Take the actions

pair. (P-VOL: <LDEV number>, processing the specified in the
S-VOL:<LDEV number>) request. previous message.
0326-W Failed to change the status of Continues Take the actions

full copy pair. (P-VOL: <LDEV processing the specified in the
number>, S-VOL:<LDEV request. previous message.
number>)
Chapter 7: Messages
List of messages
Message
0329-W Failed to detach the logical Continues Take the actions

device. (LDEV: <LDEV processing the specified in the
number>, reason: <detailed request for the previous message.
message>) other ports.
0330-W The port name specified for Continues Correct the port name
the extra spec key processing the for the extra spec key
"hbsd:target_ports" of the request. hbsd:target_ports.
volume type is not specified
for the hitachi_target_ports
or
hitachi_compute_target_ports
parameter in cinder.conf.
(port: <port>, volume type:
<volume type>)
0331-W Volume copy to a larger Continues Include the time

volume started. This process processing the required for data
waits until all data is copied request. copying to the
to the destination volume, estimated time until
and therefore it may take a the copy destination
long time before the volume can be used.
destination volume becomes For faster subsequent
available. Consider copying to copying of the volume,
a volume with the same size set the source volume
to save time because it and the destination
performs data copy in the volume to the same
background and therefore size.
ends much faster. (source
<volume | snapshot>:
<volume-ID | snapshot-ID>,
destination volume: <volume-
ID>, source size: <source-size>,
destination size: <destination-
size>)
0332-W Failed to change a volume Continues Check if the storage

type. The storage system processing the system supports
does not support request using deduplication. If it
deduplication, or standard Cinder does, enable it, and
deduplication is not enabled functions. then retry the
for the pool. (pool: <pool>) operation.
Chapter 7: Messages
List of messages
Message
0333-W Retyping the volume will be Continues To change volume type

performed using migration processing the quickly, do not change
because the specified volume request using volume types that
is being rehydrated. This standard Cinder enable the dedupe/
process may take a long time functions. compression function
depending on the data size. on volumes that just
(volume: <volume-ID>, volume had the function
type: <volume type>) disabled.
0334-W Retyping the volume will be Continues To resolve the

performed using migration processing the inconsistency in the
because inconsistency was request using system data volume,
found in the deduplication standard Cinder see your system
system data volume. This functions. administrator.
process may take a long time
depending on the data size.
(volume: <volume-ID>, volume
type: <volume type>)
0335-W Failed to create the host Continues Check whether the

group because the host processing by port has any
group maximum of the port using another unnecessary host
is exceeded. (port: <port>) port. groups, and then
delete those host
groups.
0600-E The Command <command> Stopped Remove the cause of

failed. (ret: <return value>, processing the the error by following
stdout:<standard output>, request. the message output by
stderr:<standard error the external
output>) command.
0336-W Failed to add the wwns to the Continues Check whether the
host group port because the processing by port has any
the WWN maximum of the using another unnecessary WWNs,
port is exceeded. (port: port. and then cancel the
<port>, WWN: <WWN>) assignment of those
WWNs.
0601-E A parameter is invalid. Stopped Check and, if

(<parameter name | detailed processing the necessary, revise the
message>) request. specified parameter
values, and then try
the operation again
with the correct values
specified.
Chapter 7: Messages
List of messages
Message
0602-E A parameter value is invalid. Stopped Check and, if

(<meta data name>) processing the necessary, revise the
request. specified parameter
values, and then try
the operation again
with the correct values
specified.
0603-E Failed to acquire a resource Stopped Remove the cause of

lock. (serial: <serial number>, processing the the error by following
inst: <HORCM instance request. the message output by
number>, ret: <return value>, the external
stderr: <standard error command.
output>)
0606-E The snapshot <snapshot ID> Stopped Make sure the

cannot be deleted, because a processing the snapshot operation
read-only volume for the request. target is correct.
snapshot exists. Alternatively, delete
the target snapshot
after deleting read-only
volume related to the
target snapshot.
0610-E The status change of full copy Stopped Take the actions
pair could not be completed. processing the specified in the
(S-VOL: <LDEV number>) request. previous message.
0611-E The status change of thin Stopped Take the actions

copy pair could not be processing the specified in the
completed. (S-VOL: <LDEV request. previous message.
number>)
0612-E The source logical device to Stopped Specify the correct

be replicated does not exist processing the volume and retry the
in the storage system. (LDEV: request. operation.
<LDEV number>)
0613-E The volume <volume ID> to be Stopped Specify the correct

extended was not found. processing the volume and retry the
request. operation.
0614-E No WWN is assigned. (port: Stopped Take the actions

<port name>, gid: <group ID>) processing the specified in the
request. previous message.
Chapter 7: Messages
List of messages
Message
0615-E A pair could not be created. Stopped If FULL is specified,

The maximum number of processing the wait for copying to
pair is exceeded. (copy request. finish, and then try the
method: <copy-method operation again. If
name>, P-VOL: <LDEV THIN is specified,
number>) delete the unnecessary
pairs, and then try the
operation again.
0616-E A pair cannot be deleted. (P- Stopped Wait until the pair can
VOL: <LDEV number>, S-VOL: processing the be deleted, and then
<LDEV number>(<pair status>) request. try the operation again.
[, <LDEV number>(<pair For Thin Image
status>)...]) (Snapshot), you cannot
delete only the P-VOL.
You must first delete
the S-VOL. If the pair
status is PSUE, resolve
the issue on the
storage system, and
then retry the
operation.
0617-E Failed to create a volume Stopped Set the size of the

from <volume | snapshot>. processing the destination volume
The size of the new volume request. equal to or greater
must be equal to or greater than the size of the
than the size of the original original volume or
<volume | snapshot>. (new snapshot.
volume: <volume-ID>)
0618-E The volume <volume-ID> Stopped Verify the target

could not be extended. The processing the volume is correct. If the
volume type must be Normal request. type metadata is
and the volume must not be Normal, after the copy
an S-VOL in a cascade pair. operation completes
and the pair is deleted,
retry the operation. If
otherwise, since the
volume cannot be
extended, set the
copy_method
metadata to FULL, and
then clone the volume.
Extend and use this
newly created volume.
Chapter 7: Messages
List of messages
Message
0619-E The volume <volume ID> to be Stopped Specify the correct

mapped was not found. processing the volume, and then try
request. the operation again. If
the volume is no
longer needed, delete
the volume.
0620-E Failed to provide information Stopped Take the actions

about a pool. (pool: <pool>) processing the specified in the
0621-E Failed to create a volume Stopped Set the size of the

from <volume | snapshot>. processing the destination volume
The size of the new volume request. equal to the size of the
must be equal to the size of original volume or
the original <volume | snapshot.
snapshot> when the new
volume is created by Thin
copy. (new volume: <volume-
ID>)
0624-E HBSD has stopped Stopped Specify the correct

processing the requests. processing the copy-source volume,
request. and then try the
operation again.
0631-E Failed to create a file. (file: Stopped Check that the user
<file name>, error: <error processing the has sufficient
number>, strerror: <error request. permission to perform
message>) the action on the
directory.
0633-E Permission denied. Stopped Check that the user

processing the has sufficient
request. permission to perform
the action on the file.
0634-E Failed to attach the logical Stopped Take the actions

number>, reason: <detailed request. previous message.
message>)
0636-E Failed to add the logical Stopped Take the actions

device. processing the specified in the
Chapter 7: Messages
List of messages
Message
0638-E Failed to add the pair target. Stopped Take the actions
processing the specified in the
0639-E Failed to map a logical device Stopped Take the actions

to any pair targets. (LDEV: processing the specified in the
<LDEV number>) request. previous message.
0640-E A pool could not be found. Stopped Check and, if

(pool: <pool>) processing the necessary, revise the
request. parameter, and then
restart the service.
0643-E The iSCSI CHAP user <CHAP Stopped Create the specified
user name> does not exist. processing the CHAP user.
request. Alternatively, enable
the parameter
hitachi_add_chap_u
ser to enable
automatic creation of a
CHAP user when
creating an iSCSI
target.
0648-E There are no resources Stopped Check and, if

available for use. (resource: processing the necessary, revise the
<resource>) request. storage device settings
and parameter settings
to secure the target
resources.
0649-E The host group or iSCSI target Stopped Create the host group
was not found. processing the or iSCSI target.
request. Alternatively, if you are
using iSCSI, enable the
parameter
hitachi_group_requ
est to enable
automatic creation of
an iSCSI target.
0650-E The resource <resource> was Stopped Check the setting for
not found. processing the the target resources.
request.
Chapter 7: Messages
List of messages
Message
0651-E The IP Address was not Stopped Make sure an IP

found. processing address has been set
requests. for the storage device
iSCSI port.
0652-E Failed to delete a logical Stopped Take the actions

number>) request. previous message.
0653-E The creation of a logical Stopped Take the actions

device could not be processing the specified in the
completed. (LDEV: <LDEV request. previous message.
number>)
0654-E A volume status is invalid. Stopped Make sure the

(status: <status>) processing the operation target
request. volume is correct.
Alternatively, wait until
the status of the target
volume becomes
Available, and then try
the operation again.
0655-E A snapshot status is invalid. Stopped Make sure the

(status: <status>) processing the snapshot operation
request. target is correct.
Alternatively, wait until
the status of the target
snapshot becomes
Available, and then try
0656-E The volume <volume ID> Stopped Make sure that the
could not be restored. processing the status and metadata
(reason: <detailed message>) request. for the specified
volume are correct.
1. Invalid input:<volume ID
| snapshot ID>
2. Status of target volume
<volume ID> is not
"available":<status of
volume>
3. Status of source volume
<volume ID | snapshot
ID> is not
"available":<status of
volume>
Chapter 7: Messages
List of messages
Message
0657-E A read-only volume cannot Stopped Make sure that the

be created from the snapshot processing the specified snapshot is
<snapshot ID>. A read-only request. correct.
volume already exists.
0658-E A new volume cannot be Stopped Make sure that the

created from the snapshot processing the specified snapshot is
<snapshot ID>. A read-only request. correct. Alternatively,
volume of the snapshot is detach the read-only
attached. volume from the
instance before
creating a new volume
from the specified
snapshot. After the
new volume is created,
reattach the read-only
volume.
0659-E A host group is invalid. (host Stopped Create a host group.

group: <host group name>) processing the
request.
0660-E The specified <volume | Stopped Make sure that the

snapshot> <volume ID | processing the specified volume or
snapshot ID> is busy. request. snapshot is correct.
Alternatively, wait for
the other processing to
finish, and then try the
operation again.
0700-E No valid value is specified for Stopped Make sure that the
"storage_id". A valid value processing the storage identifier
must be specified for request. information or the
"storage_id" to manage the command is correct,
volume. and then try the
operation again.
"ldev". A valid value must be processing the LDEV information or
specified for "ldev" to request. the command is
manage correct and retry the
operation.
Chapter 7: Messages
List of messages
Message
0702-E Failed to manage the Stopped Make sure that the

specified LDEV (<LDEV processing the target LDEV
number>). The LDEV must be request. information is correct.
an unpaired DP-VOL <volume Alternatively, if the
type>. target LDEV has a pair,
delete the pair and
The driver does not
manage LDEVs that are
not DP-VOL. Create a
DP-VOL, copy the data
from the LDEV, and
then retry the
operation.

number>). The LDEV size request. information is correct.
must be expressed in Extend the LDEV so
gigabytes. that it is expressed in
gigabytes, and then

number>). The LDEV must not request. information is correct.
be mapped. Unmap the LDEV and
try the operation.
0705-E Failed to manage the Stopped Make sure the target

specified LDEV (<LDEV processing the LDEV information is
number>). The LDEV must not request. correct. Clone the
be mapped. volume and retry the
operation.
Chapter 7: Messages
List of messages
Message
0706-E Failed to unmanage volume Stopped Verify the target

<volume ID>. The volume type processing the volume is correct. If the
must be Normal and the request. type metadata is
volume must not be an S-VOL Normal, retry the
in a cascade pair. operation after copy
completes and the pair
is deleted. If otherwise,
since the volume
cannot be removed
from Cinder
management, set the
copy_method
metadata to FULL, and
then clone the volume.
Remove the newly
created volume from
Cinder management.
"source-id". A valid LDEV processing the LDEV information or
number must be specified in request. the command is
"source-id" to manage the correct, and then try
volume. the operation again.
0710-E Failed to create a cloned Stopped Check the type

volume for the volume processing the metadata of the
<volume ID>. The volume type request. volume. If the type
must be Normal. metadata of the
volume is not Normal,
replication of the
volume might be in
progress. Retry the
operation after the
replication finishes.
0711-E A source volume for clone Stopped Specify the volume ID

was not found. (volume_uuid: processing the of an existing bootable
<volume ID>) request. volume in
volume_uuid.
Chapter 7: Messages
List of messages
Message
0712-E Failed to create a consistency Stopped Verify that the number

group snapshot. (copy processing the of pairs in the
method: <copy-method>) The request. consistency group is
number of pairs in the not exceeding the max
consistency group or the permitted (8,192). If
number of consistency group the copy method is
snapshots has reached the FULL, make sure there
limit. are no other
consistency snapshot
operations in progress,
and then retry the
operation. If the copy
method is THIN, delete
any unnecessary
snapshots for the
consistency group and
0713-E V-VOLs cannot be added to a Stopped Add only DP-VOLs to

consistency group. processing the the consistency group.
request. Change the copy
method so that DP-
VOLs are added to the
consistency group.
0714-E Failed to delete unused full Stopped Take the actions

copy pair. (Copy Group: <copy processing the specified in the
group >) request. previous message.
0716-E No logical device exists in the Stopped Wait for the LDEVs to
storage system for the processing the be created, and then
volume <volume-ID> to be request. retry the operation.
added to the consistency
group <consistencygroup-ID>.
0717-E Multiple mappings for Stopped Verify the volume using

volume <volume_id> found; processing the the storage
no host specified. request. management software.
Manually delete any
unnecessary
mappings.
0718-E Failed to create a thin or full Stopped Delete the clone or

copy pair because specified processing the snapshot cascade pair
volume (<volume-ID>) has request. for the specified LDEV,
cascade pair of clone or thin and then retry the
copy pair of snapshot. operation.
Chapter 7: Messages
List of messages
Message
0719-E Failed to create a cascade Stopped Update the micro

pair because the micro of processing the version of the storage
storage system does not request. system software, and
support the copy function then retry the
specified by the operation.
hitachi_copy_version
parameter.
(hitachi_storage_id:
<hitachi_storage_id>,hitachi_co
py_version:
<hitachi_copy_version>,
hitachi_thin_pool:
<hitachi_thin_pool>, P-VOL:
<pvol>, S-VOL:<svol>, Micro
version:<micro_version>)
0722-E Failed to unmanage the Stopped Use the cinder

snapshot <snapshot-ID>. This processing the snapshot-reset-
driver does not support request. state command as
unmanaging snapshots. necessary to modify
the status of the
snapshot.
0723-E Failed to create a volume. An Stopped Set the correct value

invalid value is specified for processing the for the extra spec key
extra spec key "<key>" of the request. for the volume type,
volume type. (value: <value>) and retry the
operation.
0724-E Failed to create a Stopped Verify the storage

deduplicated volume. The processing the system supports
storage system does not request. deduplication. If
support deduplication, or supported, enable
deduplication is not enabled deduplication of the
for the pool. (pool: <pool>) pool, and retry the
operation.
0725-E Failed to copy the volume. Stopped Take the actions

(copy method: <copy- processing the specified in the
method>, P-VOL: <pvol>, S- request. previous message.
VOL: <svol>)
Chapter 7: Messages
List of messages
Message
0726-E A volume or snapshot cannot Stopped After backing up any

be deleted. The logical device processing the required data, refer to
consistency for the volume or request. the storage user's
snapshot cannot be guide, and then
guaranteed. (LDEV: <LDEV>) initialize data
reduction.
0727-E Failed to change the volume Stopped Specify a valid value for
type. An invalid value is processing the extra spec key <key>
specified for extra spec key request. for the volume type
"<key>" of the volume type after the change, and
after change. (value: <value>) then retry the
operation.
0728-E The volume type change Stopped Take the actions

could not be completed. processing the specified in the
(LDEV: <LDEV>) request. previous message.
0730-E A newer version of the REST Stopped Update the REST API
API is required. processing the server to the required
(current:<current_version>, request. version.
required: <required_version>
or newer)
0731-E Failed to communicate with Stopped Remove the cause of

the REST API server. processing the the error by following
(exception: <exception>, request. the message output by
message: <message>, the HTTP library.
method: <method>, url: <url>,
params: <params>, body:
<body>)
0732-E The REST API failed. (source: Stopped Remove the cause of
<errorSource>, ID: processing the the error by following
<messageId>, message: request. the message output by
<message>, cause: <cause>, the REST API server. If
solution: <solution>, code: the "code" value in the
<errorCode>, method: message is {u'SSB1':
<method, url: <url>, params: u'2E13', u'SSB2':
<params>, body: <body>) u'6003'}, run the
cinder migrate
command with the --
force-host-copy
True option.
Chapter 7: Messages
List of messages
Message
0733-E The REST API timed out. (job Stopped Verify the REST API
ID: <job_id>, job status: processing the operation log and
<status>>, job state: <state>, request. storage log, and then
method: <method>, url: <url>, respond to the cause
params: <params>, body: of the timeout. Verify
<body>) volume status by using
the storage
management software.
If any unnecessary
volumes exist, remove
them manually.
0734-E The REST API failed. (HTTP Stopped Verify the REST API
status code: <status_code>, processing the server operation log.
response body: request.
<response_body>, method:
<method>, url: <url>, params:
<params>, body: <body>)
0735-E Failed to create a consistency Stopped Snapshots for volumes

group snapshot. V-VOLs exist processing the in the consistency
in the consistency group. request. group cannot be
(group: <group-ID>, group created because V-
snapshot: <group-snapshot- VOLs exist in the
ID>, group type: <group-type- consistency group.
ID>, volumes: <volume-ID>[, Delete the volumes
<volume-ID>...], snapshots: indicated in the
<snapshot-ID>[, <snapshot- message or delete the
ID>...]) consistent_group_snap
shot_enabled attribute
of the group type, and
then retry the
operation.
0736-E Failed to delete a {volume| Stopped Take the actions

snapshot} in a {group|group processing the specified in the
snapshot}. ({group|group request. previous message.
snapshot}: <{group|group-
snapshot}-ID>, {volume|
snapshot}: <{volume|
snapshot}-ID>, LDEV: <LDEV>,
reason: <reason>)
Chapter 7: Messages
List of messages
Message
0737-E Failed to create a volume Stopped Refer to previous

snapshot in a group snapshot processing the messages and
that does not guarantee request. eliminate the cause of
consistency. (group: <group- the failure. Then create
ID>, group snapshot: <group- a snapshot of the
snapshot-ID>, group type: volume specified in
<group-type-ID>, volume: this message.
<volume-ID>, snapshot:
<snapshot-ID>)
0738-E Failed to migrate a volume. Stopped Run the cinder

The volume status must be processing the migrate command
'available'. (volume: <volume- request. with the --force-
ID>, status: <status>) host-copy True
option.
0739-E The Simple REST API failed. Stopped Take the actions
(source: <error-source>, ID: processing the specified in the
<message-ID>, message: request. previous message. If
<message>, cause: <cause>, SIMPLE_REST is
solution: <solution>, code: specified for the
<error-code>) hitachi_storage_cl
i parameter, make
sure that the model of
the storage system
whose ID is specified in
hitachi_storage_id
is VSP F350, F370,
F700, F900 or VSP
G350, G370, G700,
G900. If the model is
neither VSP F350, F370,
F700, F900 nor VSP
G350, G370, G700,
G900, specify REST for
the
hitachi_storage_cl
i parameter or omit
the parameter value.
0740-E The Simple REST API timed Stopped Check the REST API
out. (request ID: <request-ID>, processing the server operation log or
command progress: request. the storage log to
<progress>, command result: address the cause of
<result>) the timeout.
Chapter 7: Messages
List of messages
Message
0741-E The Simple REST API failed. Stopped Check the REST API
(HTTP status code: <status- processing the server operation log.
code>, response body: request.
<response-body>)
0742-E Failed to attach the volume to Stopped Create a server

the host because the server processing the connection
connection management request. management object in
object corresponding to the the storage system.
host was not found in the Alternatively, specify
storage system. (server True for the
nickname: <server-nickname>, hitachi_server_aut
volume: <volume-ID>) o_create parameter.
0743-E Failed to initialize volume Stopped Delete the extra spec

connection because the extra processing the key
spec key "hbsd:target_ports" request. hbsd:target_ports,
is set for the volume type and then retry the
when hitachi_storage_cli operation.
parameter is set to
"SIMPLE_REST". (volume:
<volume-ID>, volume type:
<volume type>,
hbsd:target_ports:
<hbsd:target_ports>)
0744-E Failed to create a server Stopped Delete unnecessary

connection management processing the server connection
object in the storage system request. management objects
because the number of used in the storage system.
objects has reached the limit.
(server nickname: <server-
nickname>, protocol:
<protocol>, OS type: <OS-
type>, OS type option: <OS-
type-option>, iSCSI
authentication method:
<iSCSI-authentication-
method>, iSCSI mutual
setting: <iSCSI-mutual-
setting>)
Chapter 7: Messages
List of messages
Message
0745-E Failed to associate a server Stopped Delete unnecessary

connection management processing the server connection
object with a port in the request. management objects
storage system because the that are associated
number of objects that can with the port.
be associated with a port has
reached the limit. (server
nickname: <server-nickname>,
connector ID: <connector ID>,
ports: <ports>)
0746-E Failed to attach the volume to Stopped From the path setting
the host because the path processing the for the server
setting for the server request. connection
connection management management object,
object corresponding to the delete any ports that
host is invalid. (server are not specified for
nickname: <server-nickname>, the
volume: <volume-ID>, ports: hitachi_target_por
<port>[, <port>...]) ts parameter or for
the
hitachi_compute_ta
rget_ports
parameter.
Alternatively, specify
True for the
hitachi_server_aut
o_create parameter.
0747-E Failed to initialize volume Stopped Check the fabric

connection because no active processing the network configuration,
WWN was found for the request. and configure the
connector. (WWN: <WWN>[, network so that active
<WWN> ...], volume: <volume- WWNs can be found.
ID>)
0748-E Failed to initialize volume Stopped Check the fabric

connection because no port processing the network configuration,
with an active WWN was request. and configure the
found. (port, WWN: <port>, network so that the
<WWN>[, port, WWN: <port>, ports with an active
<WWN>...], volume: <volume- WWN can be found.
ID>)
Chapter 7: Messages
Messages output by the command hbsdgetinfo
Message
0749-E The Fibre Channel Zone Stopped Revise the settings of

Manager is not available. The processing the Fibre Channel Zone
Fibre Channel Zone Manager request. Manager so that it can
must be up and running run.
when hitachi_port_scheduler
parameter is set to True.
0750-E Failed to initialize volume Stopped Revise the host groups

connection because no processing the or WWNs assigned to
available resource of host request. the port to secure
group or wwn was found. available resources.
(ports: <port>)
Messages output by the command hbsdgetinfo
Message text Driver status Required actions
hbsdgetinfo command Continues processing the None.

started. request.
hbsdgetinfo command Continues processing the None.

completed successfully. request.
output to Continues processing the None.

pathDesignated/ request.
hbsdgetinfo-
yyyymmddhhmmss.tar.gz.
creating directory ... Continues processing the None.

{succeeded | failed} request.
"<list of collection files> | Has stopped processing Reinstall the driver.

<list of collection the requests.
commands>" is not found
"<collection relevant files> | Continues processing the None.

<collection commands>" is request.
not found
copying "<fileName>" ... Continues processing the None.

{succeeded | failed}. request.
Chapter 7: Messages
Messages output by the installer
Message text Driver status Required actions
executing Continues processing the None.

"<commandName>" ... request.
{succeeded | failed |
skipped}.
archiving files ... Continues processing the None.

{succeeded | failed}. request.
hbsdgetinfo is already Has stopped processing None.

running the requests.
hbsdgetinfo [-d Has stopped processing Check and, if necessary,

directory] [-e cinder] the requests. revise the specified
arguments, and then try
directory name is too long. Has stopped processing Check and, if necessary,
the requests. revise the specified
directory.
"<pass which you designated Has stopped processing Specify a directory.

in -d>" is not a directory the requests.
"<group name which you Has stopped processing Check and if necessary,
designated in -e>" is not a the requests. revise the specified group
group name name.
Messages output by the installer
Message text Driver installer status Required actions
---- <service name> service is Installer has stopped. Stop the Cinder service.
running
Chapter 7: Messages
Appendix A: OpenStack overview
This appendix provides overviews of OpenStack and Cinder.
About OpenStack
OpenStack is open source software for setting up a cloud environment of the IaaS layer.
By linking components, OpenStack automatically combines necessary resources from
the hardware resource pool that contains servers, storages, and network devices to
provide users or groups with a private-server environment.
The list of the main OpenStack components is shown in the following table.
Table 5 OpenStack main components
Component Feature Description
OpenStack Compute (Nova) Hypervisor control Manages virtual machines

in a multi-hypervisor
environment.
OpenStack Image (Glance) Image, Snapshot control Manages VM images.
OpenStack Network Virtual network control Manages L2/L3 networks.

(Neutron)
OpenStack Object Storage Object storage control Provides highly-available

(Swift) distributed object storage.
OpenStack Block Storage Block storage control Provides permanent block

(Cinder) storage to VM.
OpenStack Identity Integrated authentication Manages authentication

(Keystone) infrastructure and operation
authorization common to
each component.
OpenStack Dashboard Self-service WebUI Provides the self-service

(Horizon) Web portal.

Cinder overview
Cinder overview
Cinder is an OpenStack service component that provides persistent block device storage
to VM OpenStack Compute instances as a volume. Data in a Cinder volume persists
(remains undeleted) when the volume is detached from a VM instance. Since the data
remains on the block device corresponding to the volume, it can always be reattached by
changing the connection to other VM instances. In addition, high I/O performance is
expected because it has direct access to the block device corresponding to the volume
from the VM.
Storage providers include a Cinder driver for their storage devices so they can be used to
provide storage in an OpenStack environment.
Cinder commands
The OpenStack Cinder commands can operate backends through the OpenStack Cinder
API. Before using the commands, you must configure the available Keystone user
authentication for the environment variables.
The OpenStack configuration installer included in each distribution creates the file
containing the authentication information on the controller node. Load this file into the
environment variables using the source command. The following is an example of an
OpenStack environment configuration with the packstack command for the Red Hat
OpenStack Platform.
# source /root/keystonerc_admin
Authentication information for admin user is described in keystonerc_admin and

placed under /root.
For details about cinder command options, see the help message output by entering
the following:
# /usr/bin/cinder help
Cinder functions available via CLI vary according to the version of the API. Refer to an
online help, such as OpenStack Command-Line Interface Reference, for details about CLI
support for Cinder functions.
OpenStack commands
Commands of all OpenStack projects are being integrated into openstack commands.
For example, cinder create is being replaced by openstack volume create. Using
cinder commands is recommended because not all volume use cases are available in
the openstack commands, such as GVG functions.

Appendix B: Block Storage Driver for OpenStack
License
Apache License 2.0 is applied to Block Storage Driver for OpenStack.
# Copyright (C) 2014, 2018, Hitachi, Ltd.
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
Appendix B: Block Storage Driver for OpenStack License

Glossary
Cascade pair
A pair created by the Thin Image function.
Consistency group (CG)
A consistency group allows a storage device to take a snapshot of multiple volumes
simultaneously so that all of the snapshots have the same point-in-time data consistency.
DP pool
Area in which Dynamic Provisioning manages virtual volumes (DP-VOL).
DP-VOL
A virtual volume where physical storage space is only consumed when needed (thin
provisioning).
Dynamic Provisioning
Dynamic Provisioning is Hitachi's implementation of thin provisioning. Instead of reserving a
fixed amount of storage for a volume, capacity from an available pool (DP pool) is used at the
time data is written to the storage.
Generic volume group (GVG)
A group of volumes. This concept is an extension of consistency group. A GVG either
guarantees or does not guarantee consistency. A GVG that guarantees consistency is similar
to a consistency group, but is operated through different commands. A GVG is also simply
referred to as a group.
In-band
In the in-band management method, the Configuration Manager REST API server connects to
the storage system through a SAN.
Out-of-band
In the out-of-band management method, the Configuration Manager REST API server
connects to the storage system through a LAN. This is the default communication mode for
the Configuration Manager REST API server.
Snapshot
Data unit in which data of a volume at any point in time is stored.
Thin Image (Clone)
A copy method where the data on the source volume (DP-VOL) is copied asynchronously to
the destination volume (DP-VOL).
Thin Image (Snapshot)
A copy method where a snapshot of the data on the source volume (DP-VOL) is created on the
copy destination volume (DP-VOL).
TI pool
Thin Image pool used by Thin Image.
Glossary
Hitachi Vantara
Corporate Headquarters Contact Information
2845 Lafayette Street USA: 1-800-446-0744
Santa Clara, CA 95050-2639 USA Global: 1-858-5474526
HitachiVantara.com | community.HitachiVantara.com HitachiVantara.com/contact

Hitachi Block Storage Driver For Openstack Queens: User Guide

Uploaded by

Copyright:

Available Formats

Hitachi Block Storage Driver For Openstack Queens: User Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hitachi Block Storage Driver For Openstack Queens: User Guide

Uploaded by

Copyright:

Available Formats

Hitachi Block Storage Driver for OpenStack

Hitachi Block Storage Driver for OpenStack Queens User Guide ii

Chapter 2: System requirements.........................................................24

Chapter 3: Installation and configuration.......................................... 27

Chapter 4: Hitachi extended functions............................................... 54

Appendix A: OpenStack overview..................................................... 111

Appendix B: Block Storage Driver for OpenStack License............113

Bold ■ Indicates text in a window, including window titles, menus,

Italic ■ Indicates a document title or emphasized words in text.

Monospace Indicates text that is displayed on screen or entered by the user.

< > angle Indicates variables in the following scenarios:

[ ] square Indicates optional values. Example: [ a | b ] indicates that you can

{ } braces Indicates required or expected values. Example: { a | b } indicates

This document uses the following icons to draw attention to information:

Icon Label Description

Note Calls attention to important or additional information.

Tip Provides helpful information, guidelines, or suggestions for

Caution Warns the user of adverse conditions and/or consequences

Icon Label Description

WARNING Warns the user of a hazardous situation which, if not

Changes made in this revision

■ Red Hat OpenStack Platform Product Documentation

Conventions for storage capacity values

Physical capacity unit Value

1 kilobyte (KB) 1,000 (103) bytes

1 megabyte (MB) 1,000 KB or 1,0002 bytes

1 gigabyte (GB) 1,000 MB or 1,0003 bytes

1 terabyte (TB) 1,000 GB or 1,0004 bytes

1 petabyte (PB) 1,000 TB or 1,0005 bytes

1 exabyte (EB) 1,000 PB or 1,0006 bytes

Logical capacity unit Value

1 block 512 bytes

1 cylinder Mainframe: 870 KB

1 KB 1,024 (210) bytes

1 MB 1,024 KB or 1,0242 bytes

1 GB 1,024 MB or 1,0243 bytes

1 TB 1,024 GB or 1,0244 bytes

1 PB 1,024 TB or 1,0245 bytes

1 EB 1,024 PB or 1,0246 bytes

Supported Cinder functions

Create Volume Creates a volume.

Delete Volume1 Deletes a volume.

Attach Volume Connects a volume to a VM instance.

Detach Volume Disconnects a target volume from a VM instance.

Extend Volume Resizes a volume.

Create Snapshot2 Creates a snapshot that stores point-in-time

Delete Snapshot Deletes a snapshot.

List Snapshot Lists snapshots.

Volume Migration (host assisted)1 Moves a volume to another DP pool managed by

Consistency Group Consistency groups are used to group volumes

Over subscription Uses thin provisioning to manage the capacity of

Volume Migration (storage Moves a volume to another DP pool.

Backup using temp Snapshot Uses a temporary snapshot or volume to

Multi-attach Support Simultaneously connects multiple hosts or

Caution: It is the responsibility of the

Backup Volume Backs up a volume to Swift. The Cinder backup

Restore Backup Restores data to a specified volume from Swift.

Revert to snapshot Reverts a volume to a previously taken snapshot.

Manage Volume Adds an LDEV created by a different OpenStack