Unleash Your Potential - Namagunga Girls Coding Club
An introduction to storage provisioning with tivoli provisioning manager and total storage productivity center redp3900
1. Front cover
An Introduction to Storage
Provisioning
with Tivoli Provisioning Manager
and TotalStorage Productivity Center
Automate provisioning of SAN File
System
Simplify infrastructure
management
Eliminate human errors
Steve Strutt
ibm.com/redbooks Redpaper
2.
3. International Technical Support Organization
An Introduction to Storage Provisioning with Tivoli
Provisioning Manager and TotalStorage Productivity
Center
July 2005
8. Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® Eserver® Redbooks (logo) ™
BladeCenter™ HACMP™ Redbooks™
Enterprise Storage Server® ibm.com® Tivoli®
Eserver® IBM® TotalStorage®
The following terms are trademarks of other companies:
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of others.
vi An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
10. 1.1 Problems caused by human error
During December 2004, a large European commercial bank suffered two major server
outages during their busiest pre Christmas trading period due to human error while
configuring storage capacity. The problem was traced back to the bank’s documented
practices around configuring storage devices not being followed by an administrator. Had the
documented practices been followed while configuring the additional storage capacity, the
failures would not have occurred.
SAN storage environments are complex and require many skills and a good understanding of
the task being performed. Many storage arrays have limitations around the number of hosts
per adapter or LUNs per adapter. Additionally there are accepted rules around SAN zoning of
not mixing UNIX® and Windows® hosts in the same zones. As a consequence, over a
number of years, many organizations have developed policies and best practices that have
been adopted to avoid misconfiguration of storage subsystems and storage networks. These
should ensure that environments are configured correctly and avoid problems, but the
occasional human error can still occur.
In addition, manual storage provisioning can introduce undesirable delays and corresponding
dropoffs in service. The typical storage administrator has many demands on their time and
may not be able to immediately respond to an urgent (in the perspective of the client) storage
provisioning request.
Automated storage provisioning addresses these issues by enabling best practices to be
implemented through the idea of storage workflows. Workflows are reusable elements that
capture IT expert know-how, and represent the steps that must be followed in order to carry
out a particular operation. These are repeatable and eliminate the human element of the
process. This removes the possibility for error and allows for prompt and reliable execution, as
the workflows will consistently implement the rules and policies time after time.
1.2 Storage provisioning
Storage provisioning is the name given to all the tasks around the configuration of storage,
performed manually or via automation, as discussed here. Typically, storage provisioning of
SAN attached storage involves administrators in a significant number of relatively complex
tasks with little support from the devices and individual management tools. The assumption is
that the administrators are trained in each device and understand how to configure it. Also,
each storage device is configured in isolation, and several interfaces must be used to perform
the end-to-end task of, for example, adding a new file system on SAN attached storage to a
host. The three areas of servers, SAN switches, and subsystems that must be configured and
the generic tasks that have to be performed are shown in Figure 1-1 on page 3.
2 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
11. Server requiring SAN
attached storage
Volume Manager
And File system
updates
Host OS LUN
mapping updates
SAN
SAN SAN Zone configuration
change
LUN masking assignments
for volumes
SAN Volume Controller
volumes
Figure 1-1 Storage provisioning tasks
The following list gives more details on the tasks that a storage administrator might have to
perform to add additional storage:
Add a volume (storage subsystem).
– Select storage subsystem.
– Select or create new volume.
– Select host HBA ports (WWNs).
– Select subsystem controller ports (WWNs).
– Map volume to controller ports.
– Map volume to host HBA ports.
Set paths (SAN fabric switches).
– Determine if multiple paths are required.
– Create or update zones.
– Get active zone set.
– Add zone to zone set.
– Activate zone set.
Set up replication (if necessary).
Map the HBA LUNs to the operating system and file system.
Update volume group and file system (host server).
– Add physical volume to volume group.
– Add physical volume to logical volume.
– Create or extend file system.
Extend application to use additional space.
Reconfigure backup.
As well as the task itself, input values are needed, which require a detailed knowledge of the
storage environment, such as the WWNs of HBAs in the hosts and subsystems, existing
zones, etc. Reference to additional tools or documentation detailing the last known
Chapter 1. An introduction to storage provisioning 3
12. configuration of the environment might be necessary to determine these values. Best practice
rules for maintaining the environment must be applied consistently; this is complex and
requires a significant amount of skill to ensure any documentation of the environment is kept
up to date.
On the positive side, each of these tasks is well defined and usually can be quite simply
automated through scripting. However, scripting the end-to-end operation is barely feasible
due to the number of input values and the number of tasks. Also, the script would be host,
switch, and subsystem specific, requiring rewrites if changes occur in the environment, and
also requiring different scripts for each variation. A solution to this problem is to automate the
process using workflow automation.
1.2.1 Automating complex tasks with Tivoli Provisioning Manager
IBM Tivoli Provisioning Manager (TPM) provides an environment on which IT tasks can be
automated, such as the provisioning and configuring of servers, operating systems,
middleware, applications, storage, and network devices. This is an end-to-end approach to
provisioning. When a server is installed in a data center, applications must be installed on it,
along with its required network connectivity to access other resources, as well as the storage
the applications will use. This comprehensive approach to provisioning is shown in
Figure 1-2.
Applications Security
Middleware
Configure
Attach Storage Operating
Systems Networking
Hardware
Layer
Server Provisioning
Management Management
Applications Applications Security
Virtualization Virtualization
Security
Storage Routers,
Fabric / Network Switches, etc.
Devices
Fabric Protocols
Storage Provisioning Network Provisioning
Figure 1-2 End-to-end provisioning
This ability to perform and coordinate provisioning tasks across a range of components and
management disciplines makes TPM an ideal automation tool for performing file system and
volume management tasks and for the provisioning of SAN attached storage in general.
A clear benefit of using TPM to provision storage is that these tasks can be incorporated into
the wider server and application provisioning scenarios, significantly reducing the time and
administrative effort in delivering new applications and servers.
TPM’s storage provisioning capabilities utilize its workflow engine to automate and manage
the tasks associated with configuring storage. Provisioning of Network File System (NFS),
4 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
13. direct attached, and SAN attached storage is supported, along with management of volume
managers and file systems.
1.2.2 Tivoli Provisioning Manager and TotalStorage Productivity Center
Although TPM provides storage provisioning capabilities, it is not a storage management
solution. The IBM solution for storage management is IBM TotalStorage Productivity Center
(TPC), which is a comprehensive storage infrastructure management solution. TPC provides
heterogeneous device, fabric, and data management and reporting capabilities with
additional storage provisioning capabilities. These additional capabilities are provided by
combining TPM and TPC into a complete storage management and provisioning solution,
usually refered to as TPC with Advanced Provisioning. Table 1-1 shows the different roles in
which TPM and TPC might be used.
Table 1-1 Comparison of TPM and TPC
Attribute Tivoli Provisioning Manager TotalStorage Productivity Center
Product description Data center solution with Complete storage management
automated storage provisioning solution with additional automated
capabilities. storage provisioning capabilities
(through TPM)
Positioning (ITILa) Release Managementb. Availability Managementc
Capacity Managementd
User Server administrator (typically) Data center storage administrator
deploying a new server.
Device management Basic—TPM automation packages Advanced—complete,
(workflows) comprise a tool kit that comprehensive out-of-the-box
can be customized to meet client solution for storage management
requirements.
Device interfaces Interfaces directly to supported Exploits multiple standards-based
storage (Cisco, Brocade, McData) interfaces to provide
using CLIs. comprehensive management
(reporting and control) across
many vendors
Platform support Limited to only platforms supported Heterogeneous—supports multiple
with TPM automation packages. devices and vendors
a. IT Infrastructure Library: A process-based methodology that is used by IT departments to ensure that they can deliver IT
services to end users in a controlled and disciplined way.
b. Release Management: The process of managing the rollout of new applications, servers, and infrastructure.
c. Availability Management: Includes planning, implementation, management, and optimization of IT services so that they can
be used where and when the business requires.
d. Ensures that sufficient IT infrastructure resources are available cost-effectively when needed.
TPM and TPC are targeted at different user groups within the data center. TPM’s audience is
IT infrastructure and server administrators who need to manage the roll-out of new
applications, servers, and infrastructure. TPC is aimed at storage administrators who manage
storage capacity. In their own areas they deliver best-of-breed functionality, integrating into a
single solution that addresses a broad range of management requirements while retaining
their own unique differentiating features.
TPM is a comprehensive storage provisioning solution, providing the infrastructure and
facilities to provision storage capacity. However, its out-of-the-box device and platform
support is limited in comparison with TPC. TPC extends TPM’s storage provisioning
capabilities to provide broad standards-based device support, with a richer set of device
Chapter 1. An introduction to storage provisioning 5
14. management capabilities and with the potential to make intelligent choices based on other
metrics such as subsystem and fabric performance. These differences become more
significant with the introduction of new storage arrays such as the IBM TotalStorage DS6000
and DS8000, where there is much greater choice over volume selection criteria, including
RAID array sizes, underlying disk volume sizes, etc. Later in this paper the use of TPC to
enhance the basic device management capabilities of TPM is looked at in more detail.
6 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
16. Figure 2-1 View of a simple storage environment on TPM
This figure shows the physical connections from a number of storage hosts via a Cisco 9509
switch to an IBM TotalStorage SAN Volume Controller (SVC). The model is a direct
representation of the physical environment, which is kept in synchronization with the real
environment. Some benefits of this approach are that it allows TPM to track the usage state
of resources and determine whether resources are reserved to meet future requirements or
currently available for use. It also allows the logical grouping of resources together into pools,
enabling automation to select the most appropriate resource to fulfil a requirement. In a later
section we show how TPC can be used to automatically populate the TPM model with
storage information.
8 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
17. 2.1 Data center model
Representing the physical data center environment as a model within TPM enables it to
manage different types of devices from many vendors by abstracting the physical devices,
assets, and resources in the data center into generic classes of devices. The resulting data
center model (DCM) contains all the assets and resources of the data center, both physical
and logical, and their relationships and state. In TPM terminology these are logical devices,
which it understands how to manipulate. The IBM TotalStorage SAN Volume Controller
(SVC) and IBM TotalStorage Enterprise Storage Server® (ESS) are examples of storage
subsystems, of which the logical device in TPM is a storage subsystem. Operations are
performed against these logical devices (for example, a storage subsystem), and workflows
are written to use logical devices and hence are device independent. The same workflows
can be used against different devices of the same logical device type and do not require
rewriting if the environment changes or contains more than one device type.
Each device represented in the DCM is one of a number of logical device types modelled by
TPM (for example, storage subsystems, routers, firewalls, etc.). Logical assets and resources
comprised of a number of physical and logical components, such as monitoring applications
and SAN fabrics, are also represented by logical devices.
TPM defines four different logical device types for storage that represent the elements of a
storage environment. There are three device types related to the elements of a storage
environment that can be directly configured: SAN fabrics, storage subsystems, and
host-based volume managers and file systems (in TPM terminology, storage managers). The
fourth device type is a storage pool, which provides a logical grouping of storage subsystem
volumes. These logical devices and their relationships to the physical environment are shown
in Figure 2-2.
Storage Storage
environment Logical Devices
File system, Storage
Volume Manager Manager
SAN Fabric,
SAN
SAN SAN switches, SAN Fabric
Connectivity
Fibre Adapters
Storage
Subsystem
Storage
Subsystem
Volumes
Storage Pool
Figure 2-2 TPM logical storage devices
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 9
18. The storage pool logical device is a grouping of storage subsystem volumes from one or
more subsystems. Rather than directing an operation to get a new storage volume at a single
specific subsystem, the operation can be performed against a pool of pre-existing storage
volumes from multiple subsystems. The use of pools also enables the concept of tiered
storage to be modelled in TPM.
The next section looks at how TPM uses these logical devices to manage real devices.
2.1.1 Logical operations
For each Logical Device type, TPM defines a number of Logical Device Operations (LDOs)
that can be performed against that type of idealized device. Using an example of a Storage
Subsystem, some of the defined operations are Create Storage Volume, Mask Volume to
Host, and Remove Storage Volume. Associated with each device or resource modelled in the
DCM by a logical device is a Device Driver, which is a package of workflows that implement
the LDOs for a specific vendors device. Figure 2-3 shows the approach that TPM takes to
supporting devices and resources through the use of logical devices, and how these translate
to the device-specific operations.
Data Centre Model
contains devices Logical Operations are actions
‘Logical’ devices provide that can be executed on the
abstraction from physical logical device
devices - Create Storage Volume
- Storage Subsystem - Remove Storage Volume
Devices
Logical Devices Logical Operations Workflows deliver
sequential transitions
Device Driver Transitions can be Java
Workflows plugins, other workflows,
A device, represented by a simple commands etc..
A package of workflows to
logical device in the DCM is implement Logical Operations Transitions
associated with a Device Driver for a device is a Device Driver
to provide a set of capabilities - e.g. ESS Device Driver
Workflow
Simple
Command Java
Plugin
Figure 2-3 The TPM approach to device-specific support
Associated with TPM’s representation of a physical device or resource in the DCM as a
logical device is a Device Driver (also called a TPM automation package), which enables
TPM to perform device-specific actions against the real device or resource. As in the figure,
operations against an ESS storage subsystem represented as a logical device would execute
ESS-specific workflows from the ESS Device Driver. The workflows themselves are
comprised of transitions or steps. These can be other workflows, simple commands issued to
a device, or a Java™ plug-in to call a device API. Figure 2-4 on page 11 represents how an
LDO could be implemented and the flow.
10 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
19. Execute
Logical Operation
Logical
Workflow Transition Transition Transition
Operation
Device
Driver Workflow
Simple
Command
Logical
Transition Transition
Operation
Device
Driver
Java PlugIn
Simple Workflow
Command
Transition Transition
Java PlugIn
Data Centre Simple
Command
Figure 2-4 Logical Device Operation implementation
A combination of the operation being executed and the Device Driver associated with the
logical device determines which device-specific workflow will be called to perform the
operation. This then unfolds into transition steps. Conditional branching can occur depending
on input parameters or information retrieved from the DCM about the environment. Actions on
the physical devices are performed through Java plug-ins, which act on device APIs or simple
commands executed on a host or a device using Telnet or SSH1.
Interaction with devices is only handled through the device-specific workflows in the Device
Driver or automation packages, which must be implemented for each specific device or OS
platform that requires configuration in the storage environment. Interaction with a device is via
any of the external interfaces it supports, such as an API or command line interface.
At the host server, the Storage Manager LDOs provide support for configuration of the
storage via volume managers and file systems. On the storage network, SAN Fabric LDOs
manage the zone configuration to ensure secure access between the host and storage
subsystem. At the subsystem, Storage Subsystem LDOs create new volumes and configure
LUN masking to provide secure data access to storage volumes. Figure 2-5 on page 12
illustrates the implementation of the storage device drivers using command line interfaces.
1
SSH: Secure Shell, provides secure encrypted communications between two untrusted hosts over an insecure
network
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 11
20. Logical Operation
execution
File system
And OS
configuration
TPM
Server Telnet/SSH
Device Drivers Workflows
Zone
TPM Storage Configuration
Simple
Device Drivers Command SAN
SAN
Telnet
Telnet/SSH
Subsystem
Configuration
Figure 2-5 TPM storage logical operation implementation
Changes made to the physical environment by the operations, such as the mapping of
storage volumes to hosts, are reflected in the DCM to ensure that the DCM is an accurate
representation of the physical environment for input to future operations.
2.1.2 Storage templates
TPM implements a policy-based approach to storage provisioning. Rather than specifying the
input parameters to every operation, TPM uses templates of storage settings. Templates can
be defined once, and each operation will take its input values from the currently selected
template. Storage templates are specific to TPM’s support for storage and are used to define
the input parameters to the logical operations to perform operations against the physical
storage environment. This is represented in Figure 2-6 on page 13.
12 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
21. Storage Template Logical Operation
Environment
information Environment
Changes
SAN
SAN Physical
Environment
Updates
Data Centre Model
Figure 2-6 Storage templates
Policy information from the storage template and environment information from the DCM is
provided as input to operations. As changes are made to the physical environment, the
environment model is updated by the operation to reflect the new state.
Storage templates provide input parameters for all aspects of configuring storage for a host
server. These extend from the file system type and mount point, through to the volume size
on the subsystem and the adapter ports on the subsystem, through which a volume is
accessible. Templates can specify input parameters down to the last detail, such as volume
names and zone names, or it can be used to provide a template for a workflow to use as a
starting point, combining it with information retrieved from the DCM about the devices being
configured.
2.1.3 Administrative interface
To support the provisioning of storage capacity, the TPM user interface provides the ability to
visualize the storage configuration and perform provisioning actions. The data center model
is a live representation of the storage environment and can be visualized using the TPM
inventory view. Information can be presented in two ways, either via a detailed tabular listing
or a topology view. Users can initiate storage provisioning actions from these views.
The detailed view of storage components shows HBA configuration, volumes, file systems,
fibre connectivity, etc. The TPM inventory view, showing the detailed view of a server, is
shown in Figure 2-7 on page 14.
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 13
22. Figure 2-7 TPM administrative interface showing a host’s storage resources
The TPM inventory view is selected in the left hand pane, using the View tab. This gives
access to the inventory of all the devices represented in TPM. When a device is selected it is
shown in the right-hand pane, in a number of formats. For storage there are two
representations of the storage environment. The previous figure shows a detailed view,
where all the device components are displayed along with detailed configuration information.
Alternatively, there is a topology view or icon view, which shows the physical and logical
associations between components. Figure 2-8 on page 15 shows the storage icon view for
the same host server and its storage components, while Figure 2-1 on page 8 is an icon view
of the SAN topology.
14 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
23. Figure 2-8 Host storage topology view
When using TPM, there are two ways of initiating storage provisioning actions. Actions can
be initiated manually via the administrative interface by users, or initiated automatically as
steps in server or application provisioning workflows. Individual granular provisioning steps or
more complex end-to-end tasks can be initiated. Individual actions, such as masking a
volume to a host, can be invoked from the inventory views of each device, or end-to-end
storage provisioning actions can be initiated from the server inventory view, as shown in
Figure 2-9.
Figure 2-9 TPM administrative interface showing storage provisioning operations
From a server’s Edit menu tab, several storage provisioning actions can be initiated, as well
as server provisioning tasks. These perform end-to-end provisioning tasks of adding and
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 15
24. removing storage to and from a host. The Add Storage Volume to Host performs all the tasks
to make the volume visible at a host: Select a volume, mask it to a host, configure SAN
zoning, and OS configuration. The Add Storage to Host extends this to configure volume
managers and file systems to make the storage usable at the host without human
intervention. The Remove Storage/Storage Volume tasks deconfigure the file systems and
volume managers, and remove the storage. These end-to-end tasks are discussed in more
detail later in the paper. Other storage provisioning tasks can be performed from the
inventory views of servers, volumes, SAN fabrics, volume groups, and file systems.
2.2 Representing the storage environment on TPM
The four storage logical devices that enable a storage environment to be represented by
TPM. These are:
Storage Managers
SAN Fabrics
Storage Subsystems
Storage Pools
Using these four devices, the physical and logical components of a storage environment can
be represented in the DCM, and hence managed by TPM. Figure 2-10 describes the
relationship between the TPM storage devices and most of the physical and logical attributes
of the storage components that are modelled by them. A small number of attributes are
excluded to improve clarity. This model is very flexible for describing many variants of volume
managers, file systems, and storage subsystems.
TPM Object
S1 Host Server
Volume
VC1 VC2
Containers
Mount Points
Storage FS2 FS1 FS3 File systems
Manager
LV2 LV1 LV3 Logical Volumes
PV3 PV2 PV1 PV4 Physical Volumes
SAN Connections
Fabric SAN Switches
Storage On Port
Storage
Storage Volumes
Subsystem SV3 SV2 SV1 SV4
Storage Pool
Figure 2-10 TPM storage modelling using logical devices
The storage model is used to represent the current state of the real data center environment
within TPM. TPM can use this information directly without having to query the environment
16 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
25. every time to understand what resources are available and the connectivity between
components. As TPM operations make changes to the physical storage configuration and the
use state of volumes (available, reserved, in-use), TPM updates its model to reflect the latest
configuration. This saves TPM from having to query the environment each time it performs an
operation. The storage devices defined to TPM are accessible via the TPM inventory view,
under the Storage heading, as shown in Figure 2-11.
Figure 2-11 Storage logical devices in the TPM inventory view
This TPM inventory view in the above figure shows the expanded Storage heading, showing
the four storage logical device types in the left-hand window pane, with the Storage
Subsystems inventory view selected. To display the relevant devices defined to TPM, select
the entry in the inventory view. This view also shows a fifth storage construct, Storage
Templates, from where the inventory of Storage Templates can be listed. We will now look at
each of the four logical devices in detail.
2.2.1 Representing Storage Managers in TPM
The Storage Manager logical device in TPM is used to model file systems and volume
managers and their constituent components such as volume groups, logical volumes,
physical volumes, and relationships on a host server. Figure 2-12 on page 18 shows a
detailed view of the Storage Manager device.
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 17
26. TPM Object
S1 Host Server
Volume
VC1 Container
S3 S2 Access Servers
Storage Mount Points
Manager
FS2 File systems
LV2 Logical Volumes
PV3 PV2 Physical Volumes
Figure 2-12 Detailed view of the Storage Manager logical device
The Storage Manager represents both the file system manager and volume manager
components on a host (these are not represented separately in TPM). Within the Storage
Manager are defined the TPM Volume Containers; in a file system such as JFS on AIX®,
these are the Volume Groups. Within the Volume Container, the Physical Volumes are
defined into that container (group) and the Logical Volumes built from the Physical Volumes
using the volume manager software. Then the file systems are layered on top of the Logical
Volumes by the file system software.
The model also includes the concept of Access Servers. These allow TPM to represent other
servers, which might also be configured for access to the same file system, and logical and
physical volumes. This would be the case with clustered file systems or a file system
configured for failover with MSCS on Windows or HACMP™ on AIX.
Figure 2-13 shows the TPM inventory view of all the Storage Managers defined for servers
managed by TPM. There is one entry here for each host with a volume manager/file system
managed by TPM.
Figure 2-13 Storage Manager inventory view
The figure shows the volume group defined for this server, vg1. The name used for the
Storage Manager definition on a server is the same for each host with the same type of file
18 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
27. system and volume manager, for example, AIX_LVM for all AIX hosts. This facilitates the use
of Storage Templates to provide policy-based provisioning. When provisioning actions are
performed, the Storage Manager name is used to select only the templates that are
appropriate to a host and specify the same Storage Manager.
Figure 2-14 shows the corresponding host view of a Storage Manager for host ibmp660-1.
Figure 2-14 Host view of a Storage Manager definition
Selecting a Storage Manager shows the volume containers (volume groups) defined under it,
as in Figure 2-15.
Figure 2-15 Volume Containers defined under a Storage Manager
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 19
28. Under each Storage Manager is the list of Volume Containers (Volume Groups) that are
managed by TPM. Drilling down into a Volume Container shows the Logical and Physical
Volumes, and File Systems on the host server managed in this volume container. An
example is shown in Figure 2-16.
Figure 2-16 Host view of a Volume Container
The Logical Volumes represented here are created by TPM logical operations against the
Volume Manager on a host. Physical Volumes are created on a host when a storage volume
is masked from the storage subsystem to the host server and the OS device mapping has
been completed. The Physical Volume must be associated with a Volume Container before it
is shown by TPM in the Volume Container (volume group), as in Figure 2-26 on page 27.
2.2.2 Representing SAN Fabrics in TPM
TPM provides comprehensive support for representing SAN fabrics. Each item in the SAN
has effective coverage. The essential point is that this directly represents the physical
environment and the fibre connectivity between hosts, storage devices, and SAN switches.
The model is shown in Figure 2-17 on page 21. There are four physical elements: Servers,
SAN switches, storage subsystems, and the connections between them. The logical
configuration of zone sets and zones is also represented.
20 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
29. TPM Object
Server
Interface Cards (HBAs)
Ports
Physical Connections
ZoneSet
Zones WWNS
1 2 3 4 Ports
5 6 7 8 Interface Cards
SAN Switches
SAN Fabrics
SAN
SV3 SV2 SV1 Storage Subsystem
Figure 2-17 SAN Fabric model in TPM
The figure shows all the elements of TPM’s SAN Fabric model with a single SAN containing
two fabrics. The server and storage subsystem have ports connected to both fabrics in a dual
path configuration.
Servers
Host Bus Adapters (HBAs) in a server are modelled as interface cards, with a number of
ports. Figure 2-18 on page 22 is an example of the TPM representation of a host with one
HBA with two ports. On a port, the WWN of the port is defined, along with its physical
connection to a switch and any zones that the port is defined in. The information recorded
about host SAN connectivity is essential for automatically performing SAN zoning operations,
as it enables the SAN Fabrics the host is connected to, to be determined. Furthermore, it
determines the SAN Fabrics at which zoning operations need to be directed for this host.
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 21
30. Figure 2-18 Host fibre adapters
Storage subsystems
SAN connectivity for storage subsystems is represented similarly to host servers with
interface cards and ports. Figure 2-19 on page 23 shows an SVC with four HBAs connected
to two Cisco 9509 switches.
22 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
31. Figure 2-19 Storage subsystem view, HBA definitions
Switches
To support modelling of different types of SAN switches, a switch contains a number of
interface cards, with each card containing a number of ports. This enables TPM to model both
switches with a fixed number of ports (single card), as well as director class switches, which
have a number of card bays containing cards with varying numbers of ports.
Figure 2-20 shows a typical SAN fabric defined in TPM. The core of this fabric is a Cisco 9509
director, with a Cisco 9140 edge switch.
Figure 2-20 SAN Fabric view of switches and storage subsystems
The left-hand pane shows that two fabrics were defined: Fabric1 and Fabric2. These
represent the two fabrics that provide a fully redundant dual path configuration for disk
access.
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 23
32. In the properties for Fabric1, the World Wide Name field is used by TPM to identify the
principal switch in the fabric through which it will perform zoning operations. The same WWN
must also be defined on the principal switch. This name is largely symbolic within TPM—it is
only used to locate the principal switch in the fabric through which zoning operations are
performed, and does not have to be the real fabric WWN. A detailed view of a switch is shown
in Figure 2-21—its World Wide Name attribute being the same as for the SAN fabric.
Figure 2-21 SAN switch view
Back in Figure 2-20 on page 23, Active Zone Set is the name of the Active Zone Set in this
fabric. With the TPM workflows for switch management from the Orchestration and
Provisioning Automation Library (OPAL2), this is the Zone Set against which zoning actions
are performed. When using TPC for switch management, TPC can automatically determine
and update the currently active zoneset.
Visualizing SAN Fabric connectivity
As well as the detailed switch device views showing the switch ports, the overall fabric
connectivity can be visualized. Select the View menu item to show the switch environment on
a topology icon view, showing the connections between hosts, the switch, and connected
subsystems. The icon view is shown in Figure 2-22 on page 25.
2 OPAL Web site: http://www.developer.ibm.com/tivoli/workflow.html
24 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
33. Figure 2-22 SAN switch icon view
The icon view is currently in effect, as this menu item is grayed out on the View tab. This
shows all the hosts and storage devices connect to the switch 9509-1.
2.2.3 Representing Storage subsystems in TPM
Physical storage in storage arrays in TPM is represented by two logical devices: Storage
Subsystems, and also a logical grouping of storage volumes by type and capability into
Storage Pools. The two devices are shown in Figure 2-23.
Ports
Interface Cards
Storage On Port
Storage
Subsystem Storage Volumes
SV3 SV2 SV1 SV4
Storage Pools Pool 1 Pool 2
Pool 3
SV5 SV6 SV7 SV4
Figure 2-23 Storage Subsystem and Storage Pool logical devices
Storage Subsystems
Storage Subsystems are modelled similarly to servers with interface cards and ports defining
the HBAs on the subsystem. An example is shown in Figure 2-24 on page 26.
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 25
34. Figure 2-24 A Storage Subsystem represented in TPM
The volumes created on the subsystem are shown. Within TPM these are known as Storage
Volumes. When a volume is mapped to a host port, this association is represented in the
Fibre Channel Port field. Some array types require that storage volumes are mapped to
specific adapters on the subsystem for access by host servers. This mapping is known as the
Fibre Adapter Port mapping (sometimes abbreviated to FA Port in TPM). The TPM
terminology for this is Storage On Port and is used to support arrays that map volumes to
specific subsystem adapters (for example, EMC and HP arrays). During workflow execution,
this mapping can be used to determine which subsystem adapter should be zoned to a host
to give it access to a storage volume. This mapping is also represented in this view by an
entry in the Fibre Channel Port field. This is not shown in the figure, as the array represented
does not require it.
In the figure, there is a field for the ANSI T10 ID. This can be used to uniquely identify a
storage subsystem. T10 is the definition of the SCSI standard by the America National
Standards Institute (ANSI) and is the serial number of the storage subsystem. Specification of
this is not required in TPM.
Storage Pools
Storage Pools are used to group volumes of a similar type, that is, all RAID5 volumes, or all
RAID1 volumes or pools of tiered storage. The use of pools makes it easier to select volumes
of a particular type without having to specify all the detailed parameters such as RAID level or
volume type. Another use for storage pools is to implement the concept of volume
reservation. When there is a known future requirement for significant quantities of storage,
the volumes could be temporarily allocated to a reservation pool or pools until they are
required.
When a volume is created in TPM on the storage subsystem, it can also be assigned to a
storage pool. Alternatively, if volumes on the storage subsystem are pre-created outside of
TPM, they can be defined into the pools to make volume selection a simpler task in a
workflow.
26 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
35. Storage Pools in TPM can also be referred to as Storage Allocation Pools. Similarly, the
volumes within a pool are sometimes referred to as Storage Allocation Pool Elements
(SAPEs). The TPM Storage Pool inventory list is shown in Figure 2-25. In this example the
pool names used are the SVC managed disk group names. The naming convention includes
the RAID level and the volume size of the managed disks.
Figure 2-25 Storage Pool inventory
Figure 2-26 shows a list of volumes in Storage Pool F1_36_R5. A volume’s capabilities are
also shown, indicating RAID level and the subsystem it exists in. The State/Assignment field
indicates if a volume is Available for use, In Use (mapped to a host), Assigned (LUN masked
to a host, but not yet mapped), Reserved (being used by an executing workflow), or Unknown.
The use of volume states helps to determine the availability of volumes to satisfy requests for
additional volumes.
Figure 2-26 Volumes in a Storage Pool
The pool name reflects the type of disk storage in the pool; as this is a pool of SVC volumes,
the name reflects that the backing storage is 36-GB volumes in a RAID 5 configuration.
2.3 Specifying a server’s storage needs
TPM uses a policy-based approach to storage provisioning. Instead of an administrator
specifying the input parameters to every operation, TPM uses Storage Templates that can be
reused. A single template can be defined for a group of application servers and the same
storage configuration will automatically be used for each server. This approach of using
templates ensures that a consistent naming convention is enforced and that all server
components of an application are configured the same.
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 27
36. Within a storage template TPM implements settings for:
Volume Containers (Volume Group)
Physical Volumes
Disk Partitions
Logical Volumes
File Systems
File System Mount Points
Data Paths
Multipath Software
The settings are used as input to the Logical Device Operations and the workflows that
implement them. Though the settings define values, the workflow implementations are free to
use the values passed, modify them, or determine their own based on best practices coded
into the workflows. A typical usage might be to pass the prefix for a SAN fabric zone name,
and the workflow determines the unique full name of the zone based on the host being zoned
and the prefix.
Figure 2-27 is an example of the different storage settings that can be specified.
Figure 2-27 An example storage template
The logical and physical volume names to be used and the volume sizes and types can be
defined. Using templates in this fashion ensures that all servers added to the cluster are
configured by TPM with the same storage configuration.
Settings form a hierarchical structure under the Volume Container settings, dividing into
settings related to the physical storage and the logical storage environments. Physical
environment settings, including volume size, type, and storage subsystem are grouped under
the Physical Volume settings. Logical storage settings, such as file system type, capacity,
and block sizes are grouped under the Logical Volume settings. We will look at each of these
settings in more detail.
2.3.1 Volume Container Settings
The Volume Container settings are used as a template to create new Volume Containers
(Volume Groups) for servers in the application cluster. An example is shown in Figure 2-28 on
page 29.
28 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
37. Figure 2-28 Volume Container Settings
The Storage Manager field in the Volume Container settings defines which Storage
Managers the volume container is eligible to be created under, and hence which hosts this
template can be used on, based on a host’s Storage Manager definition. The field also
defines the Physical Partition size to be used by the volume manager for the volumes. The
settings for the Physical and Logical Volumes, and File Systems that will be created within the
container are under each Volume Container Settings object.
2.3.2 Logical Volume Settings
The Logical Volume Settings are provided as input for the volume manager on the host to
create new logical volumes. An example is shown in Figure 2-29.
Figure 2-29 Logical Volume Settings
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 29
38. At a logical level, these define how the volume manager will configure and carve up physical
volumes to make logical volumes. If the volume manager supports capabilities such as
software RAID, they can be specified here, though typically the volume type is more likely to
be of type simple or spanned. Simple implies that the logical volume exists on a single
physical volume only and spanned that it is made up of one or more physical volumes.
2.3.3 Disk Partition Settings
Disk partition settings, shown in Figure 2-30, are used to make the association between a
physical volume and the logical volumes that will be created on it. They also define how
physical volumes can be partitioned into smaller volumes for Intel®-based servers.
Figure 2-30 Disk Partition Settings
2.3.4 File System Settings
File system settings determine the type of file system to be created. Figure 2-31 on page 31
shows an example.
30 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
39. Figure 2-31 File System Settings
All the required attributes of the file system are defined here.
2.3.5 File system mount settings
File system mount settings, shown in Figure 2-32, determine where the created file system
will be mounted.
Figure 2-32 File system mount settings
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 31
40. 2.3.6 Physical Volume Settings
The physical volume settings are used by the Storage Subsystem and Storage Pool logical
operations as a template to select or create new Storage Volumes on a subsystem or in a
storage pool. An example is shown in Figure 2-33.
Figure 2-33 Physical Volume Settings
These policy parameters allow TPM to automatically select a volume from a storage pool, or
create a new volume on a subsystem meeting the specified RAID Level, Function Type, and
Consumable (minimum) size requirements. The Function Type is used for subsystems where
volumes are predefined and their usage is configured, such as EMC BCVs (Business
Continuance Volumes). The consumable size is the smallest size of volume that TPM will
use. When a volume is required it will either create a volume of the requested size or select
the smallest existing volume larger than the consumable size, which has the correct
attributes.
2.3.7 Multipath settings
The multipath settings enable use of the powerful concept of datapaths. These define the
explicit routes or paths between a host’s ports and a storage subsystems’ ports in the SAN
fabric. The settings contain all the attributes that allow zoning to be automatically set up
between a host and the storage subsystem, providing secure storage access. Figure 2-34 on
page 33 shows an example of multipath settings.
32 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
41. Figure 2-34 Multipath settings
When fully specified, multipath settings can be used to determine the LUN ID at the host, the
zone t be used, and the subsystem fibre ports and the host HBA ports to be included in the
zone. All parameters relating to connectivity between the host and the storage subsystem are
defined in one place, taking an end-to-end view of this operation, rather than looking at it from
the perspective of each device that needs configuring (that is, the hosts, SAN switch, and
storage subsystem). The parameters passed can be used directly by the zoning workflows, or
if a workflow determines, more appropriate values can take precedence.
2.4 Storage Operations
As well as modelling the storage environment and a server’s storage needs, TPM implements
a set of storage-related Logical Device Operations, which act on the physical storage
environment and update the model within TPM to reflect these changes. These operations
are grouped by the Logical Device type they operate on:
Storage Manager
Add/remove file system, logical volume, physical volume, volume container.
Storage Subsystem
Create/delete storage volume, mask/unmask storage volume.
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 33
42. Storage Pool
Create/delete storage volume in pool, mask/unmask storage volume.
SAN Switch
Create/delete zone, add/remove WWN/Port To/from Zone.
Operating System
Create physical disk, create SAN disk, delete physical disk.
Before these operations can be used, the device drivers or automation packages that
implement them have to be created for the specific switch, subsystem, volume manager, and
file system. A number of examples of TPM and TPC device drivers that implement these
operations for different platforms, switches, and storage subsystems can be found on OPAL.
Most operations are extremely granular and perform only a single specific task, such as
creating a storage volume or adding a SAN zone member. Usable workflows are then built up
from these smaller building block elements. This provides great flexibility and enables TPM to
be customized to meet a wide variety of requirements, and implement the best practices
related to specific environments; however, building a storage provisioning solution from
scratch using just these basic building blocks would be extremely time consuming.
In addition to providing the basic building blocks, TPM also provides operations that represent
end-to-end storage provisioning tasks such as creating file systems from scratch, adding
volumes to hosts, and extending file systems. These encapsulate all the sub-operations
required to perform the request task, such as creating a volume, then mapping it to the host,
and finally creating a file system on the new volume. These operations also exploit the
Storage Template approach to policy-based provisioning. The templates provide all the
necessary parameters required to perform the end-to-end operations. An example of one of
these operations is looked at in more detail later.
2.4.1 Storage Manager operations
Figure 2-35 on page 35 shows the Storage Manager operations that can be performed in
TPM. These relate to file system and Volume Manager tasks. The function of most operations
is evident from their names, although a few require further explanation.
34 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
43. Figure 2-35 Storage Manager operations
Most operations are extremely granular and perform only the single specific task as implied
by the Logical Device Operation’s (LDO’s) name. The AddStorageToHost and
RemoveStorageFromHost operations are examples of more complex operations discussed
previously, which can perform end-to-end configuration of storage to and from hosts. This
includes zoning, creation of storage volumes on the subsystem, LUN masking, volume
manager, and file system operations. An implementation of the AddStorageToHost operation
is looked at in 2.4.6, “End-to-end storage provisioning operations” on page 38.
2.4.2 SAN Fabric operations
Figure 2-36 shows the SAN Fabric operations that can be performed in TPM.
Figure 2-36 SAN Fabric operations
These include creating and deleting new zones, and adding and removing members from
zones. Here the capabilities of TPM as a provisioning tool are focusing on the routine
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 35
44. day-to-day tasks performed in a storage environment to provision storage. Tools such as
TPC are required to provide in-depth management functionality.
2.4.3 Storage Pool operations
Storage Pools offer a way to pool storage capacity. This can be within a single storage
subsystem or across several storage subsystems, and enables volume selection from any of
the subsystems that have volumes in the pool. This enables volumes to be grouped by type,
and also the creation of larger volume pools than would be possible by grouping volumes
from a single storage subsystem. Storage Pools do not implement operations against specific
volumes, such as masking and mapping, as these are performed on the subsystem where
the volume resides. Supported operations relate to volume selection from the pool, and
creation and deletion of volumes in the pool. These operations are interchangeable with the
same Storage Subsystem operations. The three pool-specific operations are shown in
Figure 2-37.
Figure 2-37 Storage Pool operations
The use of storage pools makes it easier to model tiered storage within TPM and also
accommodate the concept of volume reservation for specific future requirements. The
Storage Pool GetStorageVolumes LDO can search the entire pool for a volume meeting the
requirements rather than a single subsystem, as is the case for the Storage Subsystem
implementation of the GetStorageVolumes LDO. Once a volume has been created and
selected, subsequent operations are performed by the Storage Subsystem LDOs.
2.4.4 Storage Subsystem operations
Figure 2-38 on page 37 shows the Storage Subsystem operations that can be performed in
TPM.
36 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
45. Figure 2-38 Storage Subsystem operations
These operations include the same three operations supported for Storage Pools:
GetStorageVolume, CreateStorageVolume, and RemoveStorageVolume, and they can be
used interchangeably with the Storage Pool operations in workflows. The operations provide
effective management of many types and vendors of storage subsystems, and include
operations to support management of EMC arrays.
2.4.5 Operating system operations
In addition to the configuration of storage devices and file systems, a hosts' operating system
must also be configured to recognize that new storage volumes have been mapped to it.
Each operating system has its own methods and commands for discovering new devices and
assigning device names. Operating System Logical Operations therefore provide TPM with
the mechanism to support multiple OSs. The TPM operating system operations are shown in
Figure 2-39.
Figure 2-39 Operating System operations
Three of these operations relate to storage: CreateDASDPhysicalVolume,
CreateSANPhysicalVolume, and RemovePhysicalVolume. The first two relate to mapping of
internal disk and SAN disk to OS device names, and the latter allows removal of either type of
disk.
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 37
46. Where the OS supports it, implementation of these operations allows storage to be mapped
to a host while the host is online, without requiring a reboot. This reduces the time taken to
provision new storage and avoids having to schedule a system outage to attach additional
storage capacity.
2.4.6 End-to-end storage provisioning operations
Most of the operations looked at so far can be considered as building blocks to create an
end-to-end storage provisioning solution. TPM also provides a number of Storage Manager
logical operations that allow workflows that implement end-to-end operations to be invoked.
These are:
AddStorageToHost
RemoveStorageFromHost
AddStorageVolumetoHost
RemoveStorageVolumeFromHost
ExtendFileSystem
ExtendLogicalVolume
These operations form the basis for a complete storage provisioning solution for standard file
systems and devices. Alternatively, custom storage provisioning solutions can be developed
using the building blocks provided by TPM. Chapter 5, “A storage provisioning solution for
SAN File System” on page 61, presents a custom storage provisioning solution developed to
manage an IBM TotalStorage SAN File System.
As an example of a complete end-to-end provisioning task, Example 2-1 shows a simplified
version of the AddStorageToHost operation.
Example 2-1 AddStorageToHost operation
StorageManager.AddStorageToHost (xx)
{
StorageManager.createVolumeContainter (xx)
StorageManager.addServerToVolumeContainer (xx)
for each PhysicalVolumeSettings in VolumeContainerSettings {
find MultiPathSettings
find StorageSubsystem/StoragePool from MultiPathSettings
StorageVolume = StorageSubsystem.getStorageVolume (xx) or
StoragePool.getStorageVolume (xx)
get MultiPathSettings
install MultiPathSettings.software
StorageManager.addStorageVolumeToHost (xx) {
for each DathPathSettings in MultiPathSettings {
find faPortId
find hbaPortId by
find fabricId
find zoneSetId
find zoneId
if (zoneId = null) {
fabric.createZone (fabricId, zoneName, cPortId[])
}
StorageSubsystem.mapStorageVolumeToFA (xx)
StorageSubsystem.lunMasking (xx)
OperatingSystem.createSANPhysicalVolume (xx)
}
}
for each PhysicalVolume {
StorageManager.addPhysicalVolumeToVolumeContainer
}
38 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
47. }
for each LogicalVolumeSetting in VolumeContainerSettings {
StorageManager.createLogicalVolume (xx)
for each PhysicalVolume {
StorageManager.addPVToLV (xx)
}
}
}
StorageManager.createFS (xx)
}
The inputs to the workflow are the name of the server and the name of the storage template
to be used to create the volumes and file systems. A key subcomponent of this workflow is
the AddStorageVolumeToHost operation. This performs the volume-related tasks required,
and the AddStoragetoHost operation wraps this around with the file system and volume
manager tasks to create usable storage.
After creating the Volume Group on the host and the corresponding Volume Container object
in TPM, the Physical Volume Settings are used to determine the size and type of Storage
Volumes required. The AddStorageVolumeToHost operation is invoked to perform all the
tasks of creating and mapping the volume to the host. After creating the volume and mapping
it to the host OS, the physical volumes, logical volumes, and file system are created.
Chapter 2. Tivoli Provisioning Manager support for storage provisioning 39
48. 40 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
50. 3.1 Storage visualization
From the TPM inventory view, a host’s storage resources can be visualized in two ways:
Either as a detailed tabular style of storage components, or as a topology style icon view.
Figure 3-1 is an example of the icon view of a host's storage assets.
Figure 3-1 Icon view of host storage assets
This figure shows the logical and physical storage resources for host ibmp660-1. A single
HBA connects via two ports to port 2 on SAN switches 9509-1 and 9509-2. The physical
volumes on the host as well as the storage volumes mapped to the host are shown. Note that,
as the storage volumes are not explicitly mapped via an HBA on the subsystem, the
connectivity to the switch is not shown. The logical associations between the Storage
Volumes and Physical Volumes are also hidden in this view to improve clarity.
Hover the mouse over a physical volume or storage volume to show the logical relationships
between the resources, as shown in Figure 3-2 on page 43.
42 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center
51. Figure 3-2 Host storage asset relationships
The dotted lines in this figure show that storage volume AIX_vol3 in storage subsystem
SVC_TEC is mapped to HBA0:0 and HBA0:1 at the host, and is represented by physical
volume pv03 at the host. Right-click a resource to give more options such as the ability to
hide relationships or resources.
3.2 Performing storage operations
TPM can be used in a number of ways to provision storage: Provisioning actions can be
initiated either automatically as part of a server and application provisioning action, or
manually via the TPM user interface. Figure 3-3 on page 44 shows the provisioning actions
that can be performed directly from the TPM server inventory view.
Chapter 3. Provisioning Storage with Tivoli Provisioning Manager 43
52. Figure 3-3 Host storage provisioning operations
The figure shows the four storage operations that can be initiated from the server view, with
one highlighted. Two of these storage operations are looked at in detail here, “Add Storage
Volume To Host” and “Add Storage To Host.” Both of these operations use storage templates
as input. The Storage Manager task must be completed first to define the storage manager
type for the server before storage can be managed for the first time.
3.2.1 Add Storage To Host operation
Figure 3-4 shows the initial dialog for the operation Add Storage To Host with a storage
template selected. The eligible storage templates that can be selected to provide policy input
are determined by the Storage Manager defined on the host server. Only templates with the
same Storage Manager as the server are presented as options for input to the operation.
Figure 3-4 Add Storage To Host dialog window
44 An Introduction to Storage Provisioning with Tivoli Provisioning Manager and TotalStorage Productivity Center