Swordfish Scalable Storage Management API Specification

Version 1.1.0d

ABSTRACT: The Swordfish Scalable Storage Management API defines a RESTful interface and a standardized data model to provide a scalable, customer-centric interface for managing storage and related data services.

This document has been released and approved by the SNIA. The SNIA believes that the ideas, methodologies and technologies described in this document accurately represent the SNIA goals and are appropriate for widespread distribution. Suggestions for revision should be directed to http://www.snia.org/feedback/.

Technical Position

Last Updated 29 September 2020

USAGE

Copyright (c) 2016 - 2020 SNIA. All rights reserved. All other trademarks or registered trademarks are the property of their respective owners.

The SNIA hereby grants permission for individuals to use this document for personal use only, and for corporations and other business entities to use this document for internal use only (including internal copying, distribution, and display) provided that:

1. Any text, diagram, chart, table or definition reproduced must be reproduced in its entirety with no alteration, and,

2. Any document, printed or electronic, in which material from this document (or any portion hereof) is reproduced must acknowledge the SNIA copyright on that material, and must credit the SNIA for granting permission for its reuse.

Other than as explicitly provided above, you may not make any commercial use of this document, or any portion thereof, or distribute this document to third parties. All rights not explicitly granted are expressly reserved to SNIA.

Permission to use this document for purposes other than those enumerated above may be requested by emailing tcmd@snia.org. Please include the identity of the requesting individual and/or company and a brief description of the purpose, nature, and scope of the requested use.

All code fragments, scripts, data tables, and sample code in this SNIA document are made available under the following license:

BSD 3-Clause Software License

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

• Neither the name of The Storage Networking Industry Association (SNIA) nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

DISCLAIMER

The information contained in this publication is subject to change without notice. The SNIA makes no warranty of any kind with regard to this specification, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The SNIA shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use.

Suggestions for revisions should be directed to http://www.snia.org/feedback/.

Revision History

The revision history for this specification can be found in Table 1.

Current Revision

SNIA is actively engaged in expanding and refining the Swordfish specification. The most current revision can be found on the SNIA web site at https://www.snia.org/tech_activities/standards/curr_standards/swordfish.

Contact SNIA

SNIA Web Site

Current SNIA practice is to make updates and other information available through their web site at http://www.snia.org.

FEEDBACK AND INTERPRETATIONS

Requests for interpretation, suggestions for improvement and addenda, or defect reports are welcome. They should be sent via the SNIA Feedback Portal at http://www.snia.org/feedback/ or by mail to the Storage Networking Industry Association, 4360 ArrowsWest Drive, Colorado Springs, Colorado 80907, U.S.A.

INTENDED AUDIENCE

This document is intended for use by individuals and companies engaged in storage management.

VERSIONING POLICY

This document is versioned material. Versioned material shall have a three-level revision identifier, comprised of a version number ‘v’, a release number ‘r’ and an errata number ‘e’. Future publications of this document are subject to specific constraints on the scope of change that is permissible from one revision to the next and the degree of interoperability and backward compatibility that should be assumed between products designed to this standard. This versioning policy applies to all SNIA Swordfish versioned materials.

Version Number: Versioned material having version number ‘v’ shall be backwards compatible with all of revisions of that material that have the same version number ‘v’. There is no assurance of interoperability or backward compatibility between revisions of a versioned material with different version numbers.

Release Number: Versioned material with a version number ‘v’ and release number ‘r’ shall be backwards compatible with previous revisions of the material with the same version number, and a lower release number. A minor revision represents a technical change to existing content or an adjustment to the scope of the versioned material. Each minor revision causes the release number to be increased by one.

Errata Number: Versioned material having version number ‘v’, a release number ‘r’, and an errata number ‘e’ should be backwards compatible with previous revisions of the material with the same version number and release number (“errata versions”). An errata revision of versioned material is limited to minor corrections or clarifications of existing versioned material. An errata revision may be backwards incompatible, if the incompatibility is necessary for correct operation of implementations of the versioned material.

About SNIA

The Storage Networking Industry Association (SNIA) is a non-profit organization made up of member companies spanning information technology. A globally recognized and trusted authority, SNIA’s mission is to lead the storage industry in developing and promoting vendor-neutral architectures, standards and educational services that facilitate the efficient management, movement and security of information.

Acknowledgements

The SNIA Scalable Storage Management Technical Work Group, which developed and reviewed this work in progress, would like to recognize the significant contributions made by the members listed in Table 2:

Table of Contents

1. Abstract
2. Scope { .page_break_before }
2.1. Audience Assumptions { .page_break_before }
3. Normative References { .page_break_before }
3.1. Overview
3.2. Approved references
3.3. References under development
3.4. Other references
4. Terms and Definitions { .page_break_before }
4.1. Overview
4.2. Swordfish-specific Terms
4.2.1. Definitions
4.2.2. Symbols and abbreviated terms
4.3. Reference to Redfish terms
4.4. Keywords (normative language terms) { .page_break_before }
5. Swordfish Overview { .page_break_before }
5.1. Introduction
5.2. Relation to Redfish
5.3. Storage System Models
5.4. The ServiceRoot and ServiceContainer entities
5.4.1. Overview
5.4.2. The Systems resource collection
5.4.3. The Chassis resource collection
5.4.4. The StorageSystems resource collection
5.5. Swordfish model overview
5.5.1. The Storage resource
6. Features and Profiles { .page_break_before }
6.1. Overview
6.2. Requirement for SupportedFeatures
6.3. EnergyStar for Storage Feature
6.4. Class of Service Feature
6.4.1. Overview
6.4.2. Class of Service Model
6.4.3. ServiceRoot Additions
6.4.4. The StorageService resource
7. Schema Considerations { .page_break_before }
7.1. Schema Introduction
7.1.1. Overview
7.1.2. Swordfish Extension of the Redfish ServiceRoot
7.2. Default values and NULLABLE attributes
7.3. Common schema annotations
7.4. Property implementation requirements
7.5. Schema repository { .page_break_before }
7.6. Referencing other schemas
8. Implementation requirements { .page_break_before }
8.1. Security
8.2. General constraints
8.2.1. Redfish elements
8.2.2. Storage Events
8.3. Discovering Swordfish resources
8.4. ClassOfService requirements
8.5. StorageSystems requirements
8.6. Entity Sets
8.7. Addressing entities within a collection
8.8. Addressing members of a ResourceCollection
8.9. HTTP status codes
8.9.1. Overview
8.9.2. Create
8.9.3. Update, Replace, Delete
8.9.4. Actions
9. Swordfish type definitions
9.1. Overview
9.2. Common properties
9.2.1. Properties defined for all Redfish schemas
9.2.2. Links
9.2.3. Actions
9.2.4. OEM
9.2.5. RelatedItem
9.2.6. Status
9.2.7. Location { .page_break_before }
9.3. Complex Types
9.4. CapacitySource 1.1.2
9.4.1. Decription
9.4.2. Properties
9.5. ClassOfServiceCollection
9.5.1. URIs
9.5.2. Properties
9.6. ConsistencyGroup 1.0.1
9.6.1. Decription
9.6.2. URIs
9.6.3. Properties
9.6.4. Actions
9.6.5. Property details
9.7. ConsistencyGroupCollection
9.7.1. URIs
9.7.2. Properties
9.8. DataProtectionLoSCapabilities 1.1.3 { .page_break_before }
9.8.1. Decription
9.8.2. URIs
9.8.3. Properties
9.8.4. Property details
9.9. DataSecurityLoSCapabilities 1.1.3
9.9.1. Decription
9.9.2. URIs
9.9.3. Properties
9.9.4. Property details
9.10. DataStorageLoSCapabilities 1.2.1
9.10.1. Decription
9.10.2. URIs
9.10.3. Properties
9.10.4. Property details
9.11. DriveCollection
9.11.1. URIs
9.11.2. Properties
9.12. EndpointGroup 1.2.0
9.12.1. Decription
9.12.2. URIs
9.12.3. Properties
9.12.4. Property details
9.13. EndpointGroupCollection
9.13.1. URIs
9.13.2. Properties
9.14. FeaturesRegistry 1.0.0
9.14.1. Decription
9.14.2. Properties
9.15. FileShare 1.1.3
9.15.1. Decription
9.15.2. Properties
9.15.3. Property details
9.16. FileShareCollection
9.16.1. URIs
9.16.2. Properties
9.17. FileSystem 1.2.2
9.17.1. Decription
9.17.2. URIs
9.17.3. Properties
9.17.4. Property details
9.18. FileSystemCollection
9.18.1. URIs
9.18.2. Properties
9.19. HostedStorageServices
9.19.1. URIs
9.19.2. Properties
9.20. IOConnectivityLoSCapabilities 1.1.3
9.20.1. Decription
9.20.2. URIs
9.20.3. Properties
9.20.4. Property details
9.21. IOPerformanceLoSCapabilities 1.1.3
9.21.1. Decription
9.21.2. URIs
9.21.3. Properties
9.21.4. Property details
9.22. LineOfService 1.0.0
9.22.1. Decription
9.22.2. Properties
9.23. LineOfServiceCollection
9.23.1. URIs
9.23.2. Properties
9.24. SpareResourceSet 1.0.1
9.24.1. Decription
9.24.2. Properties
9.25. StorageGroup 1.2.1
9.25.1. Decription
9.25.2. URIs
9.25.3. Properties
9.25.4. Actions
9.25.5. Property details
9.26. StorageGroupCollection
9.26.1. URIs
9.26.2. Properties
9.27. StoragePool 1.3.1
9.27.1. Decription
9.27.2. URIs
9.27.3. Properties
9.27.4. Property details
9.28. StoragePoolCollection
9.28.1. URIs
9.28.2. Properties
9.29. StorageReplicaInfo 1.3.0
9.29.1. Decription
9.29.2. Properties
9.30. StorageService 1.4.0 { .page_break_before }
9.30.1. Decription
9.30.2. URIs
9.30.3. Properties
9.30.4. Actions
9.31. StorageServiceCollection
9.31.1. URIs
9.31.2. Properties
9.32. StorageSystemCollection
9.32.1. URIs
9.32.2. Properties
9.33. Volume 1.4.1
9.33.1. Decription
9.33.2. URIs
9.33.3. Properties
9.33.4. Actions
9.33.5. Property details
9.34. VolumeCollection
9.34.1. URIs
9.34.2. Properties
10. Annex A: Bibliography {-}
10.1. A.1 Overview {-}
10.2. A.2 Informational references {-}

1. Abstract

The Swordfish Scalable Storage Management API (“Swordfish”) defines a RESTful interface and a standardized data model to provide a scalable, customer-centric interface for managing storage and related data services. It extends the Redfish Scalable Platforms Management API Specification (DSP0266) from the DMTF.

2. Scope

Swordfish extends the Redfish Scalable Platforms Management API Specification, as defined by ISO 30115 It defines a comprehensive, RESTful API for storage management that addresses block storage, file systems, object storage, and storage network infrastructure. It is centered around common operational and business concerns of storage management, including:

• Configuration and provisioning
• Monitoring
• Event and log management
• Performance assessment
• Diagnostics
• Fault detection and remediation
• Security
• Accounting and resource consumption

Swordfish’s storage model is built around well-defined classes of service, which provide a means to map high-level business goals and objectives to specific, storage-based actions and requirements, in a clear and consistent way that can be applied uniformly across a broad spectrum of storage configurations and storage types (e.g., block storage, file systems, object stores). Common storage management functionality covered by class of service includes snapshots, replication, mapping and masking, and provisioning.

The Redfish specification provides the protocols and a core set of data models and behaviors for the management of systems. It defines the elements and behaviors that are mandatory for all Redfish implementations. Additionally it defines additional elements and behaviors that can be chosen by system vendors or manufacturers. The specifications also defines points at which OEM (system vendor) extensions can be provided by a given implementation. The specifications specifies normative requirements for Redfish Services and associated materials, such as Redfish Schema files. The Redfish specifications does not set requirements for Redfish clients, but will indicate what a Redfish client should do in order to access and utilize a Redfish Service successfully and effectively.

The Swordfish specification defines additional data models and behaviors for the management of storage systems and storage infrastructure. A Swordfish implementation shall conform to all requirements specified in the Redfish specifications.

Swordfish is suitable for a wide range of storage, from small-scale object drives, integrated RAID cards or RBODs providing storage services, to external disk arrays or file servers, to infrastructure providing storage services for converged, hyperscale and large scale cloud environments.

This document defines the Swordfish Scalable Storage Management API.

2.1. Audience Assumptions

As Swordfish is designed as an extension of the Redfish specification, this document is written with the presumption that the reader has a detailed understanding of ISO 30115 and any updates or clarifications introduced by the DMTF. This document cannot be fully understood without that context.

3. Normative References

3.1. Overview

The documents listed in Table 3 is indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

3.2. Approved references

3.3. References under development

None defined in this document.

3.4. Other references

None defined in this document.

4. Terms and Definitions

4.1. Overview

In this document, some terms have a specific meaning beyond the normal English meaning. Those terms are defined in this clause. New terms, frequently used Redfish terms.

4.2. Swordfish-specific Terms

4.2.1. Definitions

Table 4 summarizes the terms are used in this document.

4.2.2. Symbols and abbreviated terms

None in this document.

4.3. Reference to Redfish terms

Many terms in this document were originally defined in the Redfish Specification. Some of the more common terms and definitions are reproduced in Table 5, as an aid to the reader.

4.4. Keywords (normative language terms)

This document conforms to ISO/IEC Directives, Part 2 for keyword usage. The most common terms and their intended meanings are summarized in Table 6.

5. Swordfish Overview

5.1. Introduction

The Swordfish Scalable Storage Management API (“Swordfish”) defines a RESTful interface and a standardized data model to provide a scalable, customer-centric interface for managing storage and related data services. It extends the Redfish Scalable Platforms Management API Specification (DSP0266) from the DMTF.

5.2. Relation to Redfish

The Swordfish service interface extends the Redfish service interface, as illustrated in Figure 1. As such, a Swordfish service is a Redfish service and includes all required elements of the Redfish model.

Storage systems managed by the Swordfish service are located in the ServiceRoot via the StorageSystems resource collection. They are modeled using Redfish ComputerSystems. The physical infrastructure is modeled using Redfish Chassis.

As modeling for storage systems may cover both logical and physical constructs, Swordfish management clients that are focused on logical storage management use cases may choose to manage functionality entirely by way of logical resources.

Each Swordfish service is accessed via well known URLs on the system supporting the Swordfish Service. Since Swordfish is an extension of Redfish, these URLs are the same as for accessing the Redfish defined aspects of the service.

5.3. Storage System Models

Swordfish has been designed to support a broad range of configurations, requirements, size and complexity, as well as logical and physical architectures. As a result, there are two primary methods of modelling the storage system for a Swordfish implementation:

1. Swordfish Integrated Configuration

The SIC uses the same ComputerSystem model instantiation as the server where the physical element resides.

The logical storage controller is modeled using the Redfish Storage and StorageController resources. The Storage resource is located in the Redfish hierarchy contained by ComputerSystems, typically running as ApplicationServers. The physical infrastructure is modeled using Redfish Chassis. Managed resources are connected to the Storage resource, including Volumes the StoragePools. These relationships are illustrated in Figure 2.

This configuration works well when the storage system can be modeled by simply instantiating a new Storage object within an existing computer system. An example of a Storage System for an integrated configuration is shown in Figure 3.

2. Swordfish Standalone Configuration

The SSC uses separate ComputerSystem/StorageSystem model instantiation(s) to represent/model the logical controller(s) for the system.

The logical storage controller is modeled using Redfish a ComputerSystems with properties set as a StorageSystem. The physical infrastructure is modeled using Redfish Chassis. Managed resources are then connected to the Storage resource, including Volumes, StoragePools, ConsistencyGroups, and StorageGroups. These relationships are illustrated in Figure 4.

This configuration works well when the storage system needs a new ComputerSystem instance to model the logical controller. An example of a Storage System for a hosted service configuration is shown in Figure 5.

5.4. The ServiceRoot and ServiceContainer entities

5.4.1. Overview

A GET of /redfish/v1 will return the ServiceRoot entity. A GET of /redfish/v1/odata will return the ServiceContainer instances that represents the OData service document. Each of these instances provides links to the remainder of the system.

The following are the elements utilized for Swordfish management.

• Systems: A reference to a Systems resource collection;
• Chassis: A reference to a Chassis resource collection;
• StorageSystems: A reference to a StorageSystems resource collection.

5.4.2. The Systems resource collection

A resource collection that references a set of ComputerSystem resources that each represents a general purpose application server. Each ComputerSystem resource will have an entry with the value of “ApplicationServer” in its HostingRoles property. A particular ComputerSystem resource can be in both the StorageSystems collection and the Systems collection.

5.4.3. The Chassis resource collection

A resource collection that references a set of Chassis resources. Each Chassis resource represents physical containers, (i.e. sheet-metal confined spaces and logical zones like racks, enclosures, chassis and all other containers). Subsystems (like sensors), which operate outside of a system’s data plane (meaning the resources are not accessible to software running on the system) are linked either directly or indirectly through this resource.

5.4.4. The StorageSystems resource collection

A reference to a ComputerSystemCollection with members of type ComputerSystem that support storage services. These ComputerSystem resources represent systems that support Swordfish storage management services. They will have an entry with the value of “StorageServer” in their HostingRoles property.A resource collection that references a set of ComputerSystem resources that each represents a storage server. Each ComputerSystem resource will have an entry with the value of “StorageServer” in its HostingRoles property. A particular ComputerSystem resource can be a member of both the StorageSystems resource collection and the Systems resource collection.

5.5. Swordfish model overview

5.5.1. The Storage resource

The storage system exposes logical storage, associated resources and related functionality. Storage service resources can be found in the service root or service container via the StorageSystem resource collection, and are attached to the Storage object within the StorageSystem (ComputerSystem).

The following are the principal properties of Storage that point to resources managed or defined by the storage system:

• Drives: A reference to a collection that collects Drive resources used for storage.
• Enclosures: A reference to a resource collection that collects Chassis resources that contain storage related resources.
• Endpoints: A reference to a resource collection that collects Endpoint resources used to access storage.
• EndpointGroups: A reference to a resource collection that collects EndpointGroups resources.
• FileSystems: A reference to a resource collection that collects FileSystem resources.
• StorageGroups: A reference to a resource collection that collects StorageGroup resources.
• ConsistencyGroups: A reference to a resource collection that collects ConsistencyGroup resources.
• StoragePools: A reference to a resource collection that collects StorageGroup resources.
• Volumes: A reference to a resource collection that collects Volume resources.

The Endpoint resource

Endpoints represent one end of a protocol specific connection that supports sending or receiving messages according to a particular protocol.

The Endpoint Collection resource

The Endpoint Group is resource collection that references a set of Endpoint resources.

The ConsistencyGroup resource

ConsistencyGroups represent a set of volumes that are managed consistently and collectively as a group, to allow system and application level activities to be performed on a set of data that spans volumes. This activities include device-level replication activities as well as system level functions, such as reset.

When ConsistencyGroups are implemented, they are attached to a Storage resource and its internal Volumes collection is constructed from a subset of the Volumes collection of the Storage resource.

The ConsistencyGroup Collection resource

The ConsistencyGroupCollection is a resource collection that references a set of ConsistencyGroup resources.

The StorageGroup resource

StorageGroups represent a set of volumes that are managed as a group in order to facilitate mapping and masking, in which the volumes of a storage group are collectively exposed or hidden to a set of clients.

The set of volumes is specified by the Mapped Volumes attribute. MappedVolumes is a resource collection of the Mapped Volume construct (a tuple of a pointer to a volume and a corresponding Logical Unit Number for that volume).

The set of client endpoints to which the volumes can be exposed is specified by the ClientEndpointGroupsattribute. The ClientEndpointGroup resource specifies a collection of EndpointGroup resources.

The set of server endpoints to which the volumes can be exposed is specified by the ServerEndpointGroupsattribute. The ServerEndpointGroup resource specifies a collection of EndpointGroup resources.

The StoragePool resource

The StoragePool resource represents unassigned storage capacity that can be used to produce storage volumes or other storage pools.

The following are the principal properties of StoragePool that are used to identify resources provisioned or supported by the storage pool:

• AllocatedVolumes: A reference to a resource collection that collects Volume resources that have been provisioned from the storage pool.
• AllocatedPools: A reference to a resource collection that collects StoragePool resources that have been provisioned from the storage pool.

The Volume resource

Volume resource represents a block-addressable container of storage, sometimes referred to as a “Logical Unit”, “LU”, “LUN”, or “StorageVolume” in the storage industry.

The FileSystem resource

This FileSystem resource represents a file system. Each FileSystem may contain a collection of FileShares that can be presented to hosts.

6. Features and Profiles

6.1. Overview

Features are high-level descriptions of functionality which an implementation uses to advertise what functionality it currently supports, and for some features, is capable of supporting.

The detailed definitions required to describe to implementers how to implement a feature are written in profile definition files. A feature is generally represented in one (but may be more) profile definition file, or profile.

Profiles are detailed descriptions that describe down to the individual property level what functionality is required in order to advertise features. Different profile definitions can exist for the same feature type but for various types of storage configurations: Swordfish.Block.Provisioning, Swordfish.File.Provisioning

The Swordfish Features Registry shall be used to advertise what standard and Oem Features an implementation supports.

6.2. Requirement for SupportedFeatures

SupportedFeatures entries in the Features registry represent the client’s primary initial runtime view of the capabilities of a Swordfish implementation. Without properly formed entries in this registry, there is no visibility to an implementation’s functionality.

Swordfish implementations shall implement the Features registry and advertise at least the SNIA.Swordfish.Discovery supported feature in order to be considered a Swordfish implementation.

Features define coarse-grained sets of functionality. In order to advertise a feature (using the SupportedFeature mechanism in the SupportedFeatures Registry), the implementation must support the complete set of functionality as defined in the corresponding profile.

The Swordfish Features Registry publishes the official list of supported SNIA Features, and provides a high-level description of their functionality. Many of those features are self-explanatory (e.g., local replication, remote replication), but there are some features where additional context is appropriate:

• Class of Service
• Energy Star for Storage

6.3. EnergyStar for Storage Feature

The EnergyStar for Storage Feature and profile has been created to formalize the requirements from the ENERGY STAR Data Center Storage Program Requirements on storage products. The profile indicates what properties Swordfish implementations need to support in order to properly instrument EnergyStar reporting capability. This functionality is intended to support EnergyStar data gathering requirements as part of the EnergyStar certification process.

6.4. Class of Service Feature

6.4.1. Overview

Swordfish supports a ClassOfService feature. The ClassOfService functionality supports systems that are capable of providing a greater level of management automation, where a higher-level set of goals is provided as direction rather than requiring parameterized inputs for all configuration actions.

The Class of Service feature uses a combination of device-defined capabilities to structure LinesOfService, which are sets of available functionality in a given system, that can then be grouped together to provide classes of service.

When Class of service functionality is implemented, the Swordfish functionality may be entirely exposed through the StorageService resource. Each Swordfish StorageService is located in the ServiceRoot (and ServiceContainer) via the StorageServices resource collection.

6.4.2. Class of Service Model

For Swordfish with a class of service interface, the following two models apply. Either model choice results in the same storage service, regardless of the storage system model.

1. Integrated Service Configuration

The storage systems managed by the Swordfish storage service are modeled using the Redfish Storage resource and StorageController resource collections. The Storage resource is located in the Redfish hierarchy contained by ComputerSystems, typically running as ApplicationServers. The physical infrastructure is modeled using Redfish Chassis. These relationships are shown in Figure 6.

This configuration works well when the storage service is hosted by a storage resource within a computer system. An example of a Storage Service for an integrated service configuration is shown in Figure 7.

Note: This diagram and the discussion of the configuration description have been simplified slightly to avoid confusion. A full implementation would likely include additional links to the logical storage controller resources.

2. Hosted Service Configuration

The storage systems managed by the Swordfish storage service are located in the ServiceRoot (and ServiceContainer) via the StorageSystems resource collection. They are modeled using Redfish ComputerSystems. The physical infrastructure is modeled using Redfish Chassis. These relationships are shown in Figure 8.

This configuration works well when the storage system hosts the storage service directly. An example of a Storage Service for a hosted service configuration is shown in Figure 9.

Note: This diagram and the discussion of the configuration description have been simplified slightly to avoid confusion. A full implementation would likely include additional links to the logical storage controller resources.

6.4.3. ServiceRoot Additions

When the StorageService feature is implemented, the following is added to the ServiceRoot:

• StorageServices: A resource collection that references a set of StorageService resources. Each StorageService resource represents the resources and behaviors supported by that storage service.

6.4.4. The StorageService resource

Principal Properties

The storage service is hosted on a storage system and exposes logical storage, associated resources and related functionality. Storage service resources can be found in the service root or service container via the StorageServices resource collection.

The following are the principal properties of StorageService that point to resources managed or defined by the storage service:

• ClassesOfService: A reference to a resource collection that specifies the supported ClassOfService resources.
• Drives: A reference to a resource collection that collects Drive resources used for storage.
• Enclosures: A reference to a resource collection that collects Chassis resources that contain storage related resources.
• Endpoints: A reference to a resource collection that collectsEndpoint resources used to access storage.
• FileSystems: A reference to a resource collection that collects FileSystem resources.
• EndpointGroups: A reference to a resource collection that collects EndpointGroups resources.
• StorageGroups: A reference to a resource collection that collects StorageGroup resources.
• StoragePools: A reference to a resource collection that collects StorageGroup resources.
• Volumes: A reference to a resource collection that collects Volume resources.
• HostingSystem: A reference to the ComputerSystem instance that hosts this StorageService.

Capabilities and Lines of ServiceRoot

The following properties each define a set of attributes, which describe capabilities that the storage service may support:

• DataProtectionLoSCapabilities: Replicas that protects data from loss.
• DataSecurityLoSCapabilities: Data security service level requirements. The data security characteristics enable the storage system to be used in an environment where compliance with an externally-specified security standard or standards is required. Examples of such standards include FIPS-140, HIPAA and PCI.
• DataStorageLoSCapabilities: Provisioning and access characteristics for storage of the data.
• IOConnectivityLoSCapabilities: IO connectivity requirements for access to the data.
• IOPerformanceLoSCapabilities: IO performance requirements for access to the data.

In each of the above, not all combinations of attribute values defined within a capability are likely to be supported by the storage service.

Known, supported combinations of attribute values are used to construct entries in the LinesOfService array property. Not all attributes of a line of service entry need be specified (i.e. some may be Null). If an attribute has no value, the storage service may choose any supported values when provisioning for that entry. Otherwise, the line of service attribute values specifies the kind or level of service to be provided.

The ClassOfService resource

A class of service represents a choice of utility or warranty offered to customers by a service. (ITIL uses the term service option. See the Normative References.)

Each ClassOfService resource is a uniquely named description of the characteristics of one choice of utility or warranty for a service. Each ClassOfService is a description of the kind and quality of service to provide and is not intended to describe how the service provides that service.

Each ClassOfService is defined by an aggregation of lines of service. Supported lines of service are listed in the corresponding capabilities attributes of the storage service, (see above).

Currently defined lines of service are:

• Data Protection: Describes the characteristics of a replica that protects data from loss.
• Data Security: Describe data security service level requirements. The data security characteristics enable the storage system to be used in an environment where compliance with an externally-specified security standard or standards is required. Examples of such standards include FIPS-140, HIPAA and PCI.
• Data Storage: Describes provisioning and access characteristics for storage of the data.
• IO Connectivity: Describes IO connectivity requirements for access to the data.
• IO Performance: Describes the IO performance requirements for access to the data under a particular workload.

Some advertised ClassOfService resources are created by the service implementation. These are generally not changeable and are intrinsic to the implementation.

A service may support creation or modification of ClassOfService resources. All must be consistent with the capabilities of the service.

The StoragePool resource

When a Swordfish implementation advertises support for the Class of Service feature, the StoragePool resource now presents a new method to the client to allocate unassigned storage capacity. This is automated by the system as conformance to one or more classes of service. Requests to StoragePool shall automatically allocate capacity based on the constraints of the selected class of service and any other selected parameters, with priority given to the class of service constraints.

The following are the principal properties of StoragePool that are used to identify resources provisioned or supported by the storage pool related to Class of Storage:

• ClassesOfService: A reference to a resource collection that specifies the set ClassOfService resources that can be specified when provisioning resources from the storage pool.
• DefaultClassOfService: A reference to the default ClassOfService resources used for provisioning from the storage pool.

The Volume resource

Volume resource represents a block-addressable container of storage, sometimes referred to as a “Logical Unit”, “LU”, “LUN”, or “StorageVolume” in the storage industry. Volumes optionally adhere to a ClassOfService, which defines added functionality. Examples include:

• Access capabilities
• Capacity and capacity sources
• Consumption tracking (e.g., LowSpaceWarningThresholdPercents)
• Replication details
• StorageGroup Information

The FileSystem resource

In a Swordfish implementation that advertises support for the Class of Service feature, File systems represent file-addressable capacity that are conformant to a ClassOfService.

7. Schema Considerations

7.1. Schema Introduction

7.1.1. Overview

A Swordfish implementation is a Redfish implementation, and as such it minimally includes support for some Redfish-defined schema, including ServiceRoot and ComputerSystem. Swordfish implementations include support for Swordfish-defined schema. The Swordfish model focuses primarily on the logical model of a storage system and does not require full representation of a physical instantiation. This is left to the implementer to complete from available Redfish schema models.

Swordfish schema is conformant with the rules used to define Redfish schema. Redfish schema is conformant with the Common Schema Definition Language, see CSDL. This section provides additional definition and context for the CSDL elements used to define Swordfish schema.

7.1.2. Swordfish Extension of the Redfish ServiceRoot

The Redfish ServiceRoot has properties that provide access to Swordfish resources.

The first is StorageSystems. This property references a collection of ComputerSystem resources that each support Swordfish functionality. Each such ComputerSystem shall have an entry in its HostingRoles property with the value of StorageServer.

For implementations that advertise support for the ClassOfService feature, the implementation shall instantiate a collection of StorageServicesat the ServiceRoot with at least one member. The collection provides the client an efficient means to search across all StorageService resources, regardless of which ComputerSystem is supporting the service.

7.2. Default values and NULLABLE attributes

The interaction of Nullable and DefaultValue needs to be clearly understood by both implementers and client developers. The possible combinations of are summarized in Table 7. The table contains:

• Nullable: True, if a given property may be NULL
• DefaultValue: True, if a default value is provided for a given property
• Client: True, if a client value is supplied for a given property in a query or response
• Result: The resultant value of the given property. One of:
  • C: The client-provided value
  • D: The default value
  • Null: Null
  • I: Implementation defined
  • Error: Error state

7.3. Common schema annotations

Table 8 lists common annotation used in the definition of Swordfish, for details see OData Capabilities Vocabulary, OData Core Vocabulary, OData Measures Vocabulary, and Redfish Extensions,

7.4. Property implementation requirements

The client and the implementer should understand that, regardless of the schema declaration, an implementer may choose to not implement a property. If not implemented, a representation of the property will not be present in a reply. This should not be confused with a response that indicates that a property has been implemented, but has no value (i.e. propertyName = null).

There are several factors that could affect the implementation choice. Implementation requirements can be defined in many documents. At a minimum, a developer should review, in order: 1. the Redfish specification, 2. this document, and 3. associated profile specifications.

7.5. Schema repository

The primary online source for the Swordfish schema shall be co-located on the DMTF schema site with the Redfish schema: http://redfish.dmtf.org/schemas/swordfish Developers may also download the schema as part of the Swordfish bundle from snia.org (refer to snia.org/swordfish for pointers to the bundle locations).

Implementations should refer either to the versions available on the dmtf.org site or to locally provided instances of the schema.

7.6. Referencing other schemas

Swordfish directly references many Redfish schemas when functionality is already defined and can be leveraged. Other Redfish schema may be added by inference or directly to implementations. Examples are available in the Swordfish mockups.

8. Implementation requirements

8.1. Security

This document generally adheres to the security requirements defined in the Redfish Specification. It extends the Redfish security model in one important way:

• Swordfish implementations shall implement TLS as per the guidance in ISO/IEC 20648 and the TLS Specification for Storage Systems.

8.2. General constraints

8.2.1. Redfish elements

The Swordfish service interface extends the Redfish service interface. As such, a Swordfish service is a Redfish service and all required elements of the Redfish model shall be present in a Swordfish model.

Swordfish functionality shall not conflict with any previously defined Redfish functionality but it may add to or extend it, and it may add additional constraints on Redfish functionality.

Additionally, any functionality desired in a Swordfish implementation that is specified in Redfish shall follow the requirements as specified in the Redfish specification.

8.2.2. Storage Events

Overview

A Swordfish implementation should implement an event service. Redfish defines the Event Service framework, client subscription model, event delivery mechanism, as well as standard message registries. Swordfish extends the standard message registries to provide additional message registries that correspond to Swordfish-specific services and properties.

The Redfish event service publishes a list of event types supported, and maintains a list of clients that have subscribed. Each subscription maps clients, subscribed events, and the resources that generate them.

Message Registry Selection and Management

Swordfish constrains the existing event model to provide a more consistent handling of event notifications and the related messages, in order to assure that client systems can easily and consistently parse and respond to system-level events.

Required Usage

• The Resource Event Message Registry defines the underlying messaging model, and shall be used to map messages to resources for storage implementations.
• The Redfish Base Message Registry shall be used to support HTTP connection/error/protocol issues, and general errors.
• The Swordfish Message Registry shall be used as a supplement for the resource event message registry.
• If the Swordfish service implements Redfish tasks (i.e., long-running operations), the implementation shall use the messages defined in the Task Event Message Registry to report status.

Recommended Usage

• Standard Messages should be used, wherever possible.
• OEM messages should be avoided. Suggestions for clarification or expansion of the existing registries are encouraged. (submissions should be sent to the SNIA Feedback Portal)

8.3. Discovering Swordfish resources

Each Swordfish implementation supports the following well-known URLs, as defined in Redfish. Specifically:

• /Redfish, which contains one or more version properties for the integrated Swordfish and Redfish implementation, starting with v1.
• /Redfish/v1, which addresses a ServiceRoot instance, which defines the Redfish default principal starting information for version 1 implementation of an integrated Redfish and Swordfish service. A GET operation to it shall retrieve the value of an instance of a ServiceRoot EntityType as defined in the ServiceRoot_v1.xml file.
• /Redfish/v1/odata, which addresses a ServiceContainer instance, which defines OData conformant principal starting information for the same version 1 implementation of an integrated Redfish and Swordfish service. A GET operation shall retrieve the value of an instance of a ServiceContainer EntityContainer as defined in the ServiceRoot_v1.xml file.

Note: Since the ServiceContainer is required to return an @odata.context value of /redfish/v1, all other elements accessed via it will be the same elements found via the ServiceRoot.

Note: A Swordfish service is a Redfish service with extensions to support storage management. No additional service entry-points are necessary.

Both the ServiceRoot and ServiceContainer contain a resource collection named Systems that lists ComputerSystem instances. A ComputerSystem instance that supports Swordfish defined services will have a value of “StorageServer” in an entry of its HostingRoles property.

The ServiceContainer additionally has a Service attribute that references the ServiceRoot resource.

Regardless of starting point, the property values of the ServiceRoot instance enable navigation to all other resources exposed by the Swordfish service.

8.4. ClassOfService requirements

Each ClassOfService shall include at least one line of service. The providing server shall assure that the line of service values of a ClassOfService collectively represent a supported choice of service.

8.5. StorageSystems requirements

For Hosted Service Configurations, this property of the ServiceRoot references a collection of ComputerSystem resources that each support Swordfish functionality. Each ComputerSystem included in the StorageSystems entry in the ServiceRoot shall have:

• an entry in its HostingRoles property with the value of StorageServer
• at least one entry in its StorageServices.Members property.

For Integrated Service Configurations, the StorageSystems concept is realized through the StorageController resource. Each StorageController instantiated as a Swordfish StorageSystem shall have:

• at least one entry in its StorageController.Links property StorageServices collection identifying related StorageServices

8.6. Entity Sets

The Swordfish model does not currently expose any explicitly defined entity sets. OData specifies that an entity set is defined for each NavigationProperty that is defined as a collection and that has the ContainsTarget attribute set to true. In all other cases, Swordfish assumes that an entity set is defined globally within the implementation for each entity type. This is effectively the same as if the entity sets were explicitly defined in the ServiceRoot entity container.

8.7. Addressing entities within a collection

An instance (entity) of an EntityType is uniquely identified within its entity set by its key. The URI for the reference may specify the key using one of two general strategies

1. OData recommends specifying the key value within parenthesis following the path segment that identifies the referencing entity set. (See clause “Canonical URL” in in OData)

2. Redfish common practice is to use an alternative form that adds a path segment having the value of the key following the path segment that identifies the referencing collection. (See clause “Alternate Key-as-Segment Syntax” in OData.)

A Swordfish implementation shall support both strategies.

8.8. Addressing members of a ResourceCollection

Redfish specifies that subclasses of ResourceCollection shall include a Members collection property (See clause “Collection resource response” in DSP0266)

Redfish allows a POST request to a ResourceCollection to be equivalent to the same POST request to the Members property of that ResourceCollection. For a particular ResourceCollection, if a Swordfish implementation supports either form, it shall support both.

It is common practice in Redfish to also eliminate the Members property from any request URI that navigates through a type hierarchy that includes a Member within a ResourceCollection. Care should be taken when defining and using a ResourceCollection subclass to not introduce ambiguities when an explicit reference to a Members property is dropped from a request URI.

8.9. HTTP status codes

8.9.1. Overview

Status codes are generally defined as part of the general HTTP protocol definition. In addition, the Redfish specification calls out general usage for HTTP status codes. This section provides additional usage guidance and constraints for Swordfish implementations.

In some instances, Redfish and Swordfish expand the standard use of HTTP status codes by associating additional system status with specific status codes. In addition, error response data may be included via standardized message registry entries. The specific messaging requirements will be defined in the following sections.

In cases where Swordfish adds additional constraints or expands on the Redfish handling of a given issue, this document will include both a clause reference (relative to the 1.7.0 version of the Redfish specification), and a small wording extract for additional context. For example:

Swordfish refines the requirements in x.y.z of the Redfish Specification: Redfish has no constraint on external storage functionality to require that all references to external storage functionality shall be compliant with the current release of Swordfish.

8.9.2. Create

If a request to create a resource can be completed successfully without additional time, the Redfish service shall return a status code of 201, and the body of the response shall contain the JSON representation of the newly created resource.

If the create resource request has been accepted, but no information about the resource can be returned at this point, the Redfish service shall return a status code of 204. The payload of the response shall be empty, but the Location header shall contain the resource URI. The client will be required to poll the appropriate resource to determine both when and if the operation is complete.

Swordfish refines the requirements in clauses 7.5.1 and 12.2 of the Redfish Specification.

If a request to create a resource cannot be completed without additional time, the implementation shall:

• Populate an initial object. It shall contain, at a minimum, a valid URI, required properties (e.g., ID, name), and Status.State;

• Set Status.State of the partially populated resource to “Creating”;

• Return the appropriate status code, based on the following guidance:

  • If a Task Service has been implemented, the Redfish service shall return a status code of 202, with the Location header set to the URI of the Task Monitor. Once the provider has returned a Task Monitor to the client, the Client can then query the provided task URI to track the task completion status. Upon task completion, a GET against the task monitor may return a status code of 201, and the body of the message shall contain the created resource, provided the task monitor URI remains valid . Refer to the Redfish Task Manager documentation for the lifecycle of the task monitor URI.

  • If a Task Service has not been implemented, the Redfish service shall return a status code of 201, and the body of the response shall contain the URI of the skeletal resource created as part of accepting the request. The client will be required to poll the URI provided to determine when the operation is complete.

• Update Status.State for the object, once the create operation completes.

8.9.3. Update, Replace, Delete

If a request to modify or delete a resource can be completed without additional time, the Redfish service shall return a status code of 200, and the body of the response shall contain the JSON representation of the modified (or deleted) resource.

If the resource modification or deletion request has been accepted, but no information about the resource can be returned at this point, the Redfish service shall return a status code of 204. The payload of the response shall be empty. The client will be required to poll the appropriate collection to determine both when and if the operation is complete.

If a request to modify a resource cannot be completed without additional time, the implementation shall:

• Set Status.State of the partially populated resource to “Updating” or “Deleting”, as appropriate;

• Return the appropriate status code, based on the following guidance:

• If a Task Service has been implemented, the Redfish service shall return a status code of 202, with the Location header set to the URI of the Task Monitor. Once the provider has returned a Task Monitor to the client, the Client can then query the provided task URI to track the task completion status. Upon task completion, a GET against the task monitor may return a status code of 201, and the body of the message shall contain the created resource, provided the task monitor URI remains valid . Refer to the Redfish Task Manager documentation for the lifecycle of the task monitor URI.

• If a Task Service has not been implemented, the Redfish service shall return a status code of 200, and the body of the response shall contain the URI of the skeletal resource created as part of accepting the request. The client will be required to poll the URI provided to determine when the operation is complete.

• For an update or replace request, the implementation shall update Status.State for the resource, once the modify operation completes.

8.9.4. Actions

Swordfish supports the approach to Actions in 5.6.3 of the Redfish Specification: Actions are Redfish operations that do not easily map to RESTful interface semantics. These types of operations may not directly affect properties in the Redfish Resources.

Swordfish refines the requirements in 7.10 of the Redfish Specification: Services shall support the POST method to send actions to Resources.

If a Task Service has been implemented, the Redfish service shall return a status code of 202, with the Location header set to the URI of the Task Monitor. Once the provider has returned a Task Monitor to the client, the Client can then query the provided task URI to track the task completion status. Once the task has completed successfully, a GET against the task monitor shall return the created object.

If a Task Service has not been implemented, the Redfish service shall return a status code of 200, and the body of the response shall contain the URI of the skeletal resource created as part of accepting the request. The client will be required to poll the URI provided to determine when the operation is complete. When processing ACTIONS, the handling of HTTP status codes is slightly different than that seen when processing CREATE or MODIFY requests. The HTTP status code is used to reflect the acceptance and formatting of the request. The outcome of any requested processing is reflected in the body of the returned message and its associated Error response structure. For example, a properly formatted request to execute a system reset may return an HTTP status code of 200 (OK), to reflect that the request has been received, was validly formatted, and has been accepted for processing, while the reset of the system may not complete successfully. The Error response structure would contain further detail of the success of failure of the system reset. The implementation must check both the HTTP status code and the underlying Error response message structure to confirm the successful execution of the ACTION.

9. Swordfish type definitions

9.1. Overview

The following sections define the schema and type definitions that make up a Swordfish implementation. Each data type or entity within the schema includes a description that defines its implementation requirements and their interaction

9.2. Common properties

9.2.1. Properties defined for all Redfish schemas

The properties summarized in Table 9 are included in every Redfish schema, and therefore may be encountered in any Response payload. They are documented here to avoid repetition in the Resource Guide tables for each schema.

9.2.2. Links

The Links property represents the links associated with the resource, as defined by that resource’s schema definition. All associated reference properties defined for a resource are nested under the Links property. All directly referenced (subordinate) properties defined for a resource can be found from the root of the resource.

9.2.3. Actions

The Actions property contains the actions supported by a resource.

9.2.4. OEM

The OEM property is used for OEM extensions.

9.2.5. RelatedItem

The RelatedItem property is represented as a set of links. The links point to a resource, or part of a resource, as defined by that resource’s schema definition.

This representation is not intended to be a strong linking methodology like other references. Instead it is used to show a relationship between elements or sub-elements in disparate parts of the service. For example, Fans may be in one area of the system and Processors in another area of the system. It could be that the relationship between the two is not obvious. The RelatedItem property can be used to show that one is related to the other. In this example, it might indicate that a specific fan is cooling a specific processor.

9.2.6. Status

Overview

The Status property is common to many Redfish schema. Its attributes are summarized in Table 10.

Property details

Health:

This represents the health state of this resource in the absence of its dependent resources. Its possible values are summarized in Table 11.

HealthRollup:

This represents the overall health state from the view of this resource. Its possible values are summarized in Table 12.

State:

This indicates the known state of the resource, such as if it is enabled. Its possible values are summarized in Table 13.

9.2.7. Location

Location properties overview

The properties of a Location object are summarized in Table 14.

Property details

LocationType:

The type of location of the part, such as slot, bay, socket and slot. The enum’s potential values are sumamrized in Table 15.

Orientation:

The orientation for the ordering of the slot enumeration used by the LocationOrdinalValue property. The enum’s potential values are sumamrized in Table 16.

RackOffsetUnits:

The type of Rack Units in use. The enum’s potential values are sumamrized in Table 17.

Reference:

The reference point for the part location. This is used to give guidance as to the general location of the part. The enum’s potential values are sumamrized in Table 18.

9.3. Complex Types

The Table 19 defines a number of complex types that are used frequently in Swordfish schema. Multiple references to each complex type may be seen in later sections. For detailed definitions and properties contained in each complex type, refer to the schema definitions as referenced in the table.

9.4. CapacitySource 1.1.2

9.4.1. Decription

This composition may be used to represent the source and type of storage capacity. At most one of the ProvidingDrives, ProvidingVolumes, ProvidingMemoryChunks, ProvidingMemory or ProvidingPools properties may have a value. If any of ProvidingDrives, ProvidingVolumes, ProvidingMemory or ProvidingPools reference more than one resource, allocation of capacity across those resources is implementation dependent.

9.4.2. Properties

The properties defined for the CapacitySource 1.1.2 object are summarized in Table 20.

9.5. ClassOfServiceCollection

9.5.1. URIs

/redfish/v1/StorageServices/{StorageServiceId}/ClassesOfService /redfish/v1/StorageServices/{StorageServiceId}/StoragePools/{StoragePoolId}/ClassesOfService

9.5.2. Properties

The properties defined for the ClassOfServiceCollection object are summarized in Table 21.

9.6. ConsistencyGroup 1.0.1

9.6.1. Decription

A collection of volumes grouped together to ensure write order consistency across all those volumes. A management operation on a consistency group, such as configuring replication properties, applies to all the volumes within the consistency group.

9.6.2. URIs

/redfish/v1/StorageServices/{StorageServiceId}/ConsistencyGroups/{ConsistencyGroupId} /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/ConsistencyGroups/{ConsistencyGroupId} /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/ConsistencyGroups/{ConsistencyGroupId}

9.6.3. Properties

The properties defined for the ConsistencyGroup 1.0.1 object are summarized in Table 22.

9.6.4. Actions

AssignReplicaTarget

This action shall be used to establish a replication relationship by assigning an existing consistency group to serve as a target replica for an existing source consistency group.

URIs:

/redfish/v1/StorageServices/{StorageServiceId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.AssignReplicaTarget /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.AssignReplicaTarget /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.AssignReplicaTarget

Parameters

The parameters for the action (which can be included in the POST body to the URI shown in the ‘target’ property of the action) are summarized in Table 23.

CreateReplicaTarget

This action shall be used to create a new consistency group resource to provide expanded data protection through a replica relationship with the specified source consistency group.

URIs:

/redfish/v1/StorageServices/{StorageServiceId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.CreateReplicaTarget /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.CreateReplicaTarget /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.CreateReplicaTarget

Parameters

The parameters for the action (which can be included in the POST body to the URI shown in the ‘target’ property of the action) are summarized in Table 24.

RemoveReplicaRelationship

This action shall be used to disable data synchronization between a source and target consistency group, remove the replication relationship, and optionally delete the target consistency group.

URIs:

/redfish/v1/StorageServices/{StorageServiceId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.RemoveReplicaRelationship /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.RemoveReplicaRelationship /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.RemoveReplicaRelationship

Parameters

The parameters for the action (which can be included in the POST body to the URI shown in the ‘target’ property of the action) are summarized in Table 25.

ResumeReplication

This action shall be used to resume the active data synchronization between a source and target consistency group, without otherwise altering the replication relationship.

URIs:

/redfish/v1/StorageServices/{StorageServiceId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.ResumeReplication /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.ResumeReplication /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.ResumeReplication

Parameters

The parameters for the action (which can be included in the POST body to the URI shown in the ‘target’ property of the action) are summarized in Table 26.

ReverseReplicationRelationship

This action shall be used to reverse the replication relationship between a source and target consistency group.

URIs:

/redfish/v1/StorageServices/{StorageServiceId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.ReverseReplicationRelationship /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.ReverseReplicationRelationship /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.ReverseReplicationRelationship

Parameters

The parameters for the action (which can be included in the POST body to the URI shown in the ‘target’ property of the action) are summarized in Table 27.

SplitReplication

This action shall be used to split the replication relationship and suspend data synchronization between a source and target consistency group.

URIs:

/redfish/v1/StorageServices/{StorageServiceId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.SplitReplication /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.SplitReplication /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.SplitReplication

Parameters

The parameters for the action (which can be included in the POST body to the URI shown in the ‘target’ property of the action) are summarized in Table 28.

SuspendReplication

This action shall be used to suspend active data synchronization between a source and target consistency group, without otherwise altering the replication relationship.

URIs:

/redfish/v1/StorageServices/{StorageServiceId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.SuspendReplication /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.SuspendReplication /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/ConsistencyGroups/{ConsistencyGroupId}/Actions/ConsistencyGroup.SuspendReplication

Parameters

The parameters for the action (which can be included in the POST body to the URI shown in the ‘target’ property of the action) are summarized in Table 29.

9.6.5. Property details

ConsistencyMethod

The property shall set the consistency method used by this group.

The values defined for the ConsistencyMethod ENUM are summarized in Table 30.

ConsistencyType

The property shall set the consistency type used by this group.

The values defined for the ConsistencyType ENUM are summarized in Table 31.

ReplicaType

This parameter shall contain the type of replica relationship to be created.

The values defined for the ReplicaType ENUM are summarized in Table 32.

ReplicaUpdateMode

This parameter shall specify the replica update mode.

The values defined for the ReplicaUpdateMode ENUM are summarized in Table 33.

9.7. ConsistencyGroupCollection

9.7.1. URIs

/redfish/v1/StorageServices/{StorageServiceId}/ConsistencyGroups /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/ConsistencyGroups /redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/ConsistencyGroups

9.7.2. Properties

The properties defined for the ConsistencyGroupCollection object are summarized in Table 34.

9.8. DataProtectionLoSCapabilities 1.1.3

9.8.1. Decription

The capabilities to protect data from loss by the use of a replica. The requirements shall be met collectively by the communication path and the replica. There should be one instance associated to a class of service for each replica. Each replica independently should have a class of service that describes its characteristics.

9.8.2. URIs

/redfish/v1/StorageServices/{StorageServiceId}/DataProtectionLoSCapabilities

9.8.3. Properties

The properties defined for the DataProtectionLoSCapabilities 1.1.3 object are summarized in Table 35.

9.8.4. Property details

SupportedRecoveryGeographicObjectives

The value of each entry shall specify a supported failure domain. The enumeration literals of this enumeration shall represent a geographic scope in which all components within that scope have similar vulnerabilities.

The values defined for the SupportedRecoveryGeographicObjectives ENUM are summarized in Table 36.

SupportedRecoveryTimeObjectives

The value of each entry shall specify an enumerated value that indicates a supported expectation for the time required to access an alternate replica. In the case that IsIsolated = false, failure of the domain is not a consideration. The enumeration literals shall represent the relative time required to make a replica available as a source.

The values defined for the SupportedRecoveryTimeObjectives ENUM are summarized in Table 37.

SupportedReplicaTypes

The value of each entry shall specify a supported replica type. The enumeration literals may be used to specify the intended outcome of the replication.

The values defined for the SupportedReplicaTypes ENUM are summarized in Table 38.

9.9. DataSecurityLoSCapabilities 1.1.3

9.9.1. Decription

This resource may be used to describe data security capabilities.

9.9.2. URIs

/redfish/v1/StorageServices/{StorageServiceId}/DataSecurityLoSCapabilities

9.9.3. Properties

The properties defined for the DataSecurityLoSCapabilities 1.1.3 object are summarized in Table 39.

9.9.4. Property details

SupportedAntivirusScanPolicies

The enumeration literal shall specify supported policies that trigger an AntiVirus scan. The enumberation literals shall specify types of antivirus scan triggers.

The values defined for the SupportedAntivirusScanPolicies ENUM are summarized in Table 40.

SupportedChannelEncryptionStrengths

The enumeration literal shall specify supported key sizes in a symmetric encryption algorithm (AES) for transport channel encryption. The enumeration literals shall specify Key sizes in a symmetric encryption algorithm, (see NIST SP 800-57 part 1 (http:/csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf).

The values defined for the SupportedChannelEncryptionStrengths ENUM are summarized in Table 41.

SupportedDataSanitizationPolicies

The enumeration literal shall specify supported data sanitization policies. The enumberation literals shall specify types of data sanitization policies.

The values defined for the SupportedDataSanitizationPolicies ENUM are summarized in Table 42.

SupportedHostAuthenticationTypes

The enumeration literal shall specify supported authentication types for hosts (servers) or initiator endpoints. The enumeration literals shall specify authentication algorithms.

The values defined for the SupportedHostAuthenticationTypes ENUM are summarized in Table 43.

SupportedMediaEncryptionStrengths

The enumeration literal shall specify supported key sizes in a symmetric encryption algorithm (AES) for media encryption. The enumeration literals shall specify Key sizes in a symmetric encryption algorithm, (see NIST SP 800-57 part 1 (http:/csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf).

The values defined for the SupportedMediaEncryptionStrengths ENUM are summarized in Table 44.

SupportedSecureChannelProtocols

The enumeration literal shall specify supported protocols that provide encrypted communication. The enumeration literals shall specify types of Secure channel protocols.

The values defined for the SupportedSecureChannelProtocols ENUM are summarized in Table 45.

SupportedUserAuthenticationTypes

The enumeration literal shall specify supported authentication types for users (or programs). The enumeration literals shall specify authentication algorithms.

The values defined for the SupportedUserAuthenticationTypes ENUM are summarized in Table 46.

9.10. DataStorageLoSCapabilities 1.2.1

9.10.1. Decription

Each instance of DataStorageLoSCapabilities describes capabilities of the system to support various data storage service options.

9.10.2. URIs

/redfish/v1/StorageServices/{StorageServiceId}/DataStorageLoSCapabilities

9.10.3. Properties

The properties defined for the DataStorageLoSCapabilities 1.2.1 object are summarized in Table 47.

9.10.4. Property details

SupportedAccessCapabilities

Each entry specifies a storage access capability. StorageAccessCapability enumeration literals may be used to describe abilities to read or write storage.

The values defined for the SupportedAccessCapabilities ENUM are summarized in Table 48.

SupportedProvisioningPolicies

This collection specifies supported storage allocation policies. The enumeration literals may be used to specify space provisioning policy.

The values defined for the SupportedProvisioningPolicies ENUM are summarized in Table 49.

SupportedRecoveryTimeObjectives

This collection specifies supported expectations for time to access the primary store after recovery. The enumeration literals shall represent the relative time required to make a replica available as a source.

The values defined for the SupportedRecoveryTimeObjectives ENUM are summarized in Table 50.

9.11. DriveCollection

9.11.1. URIs

/redfish/v1/StorageServices/{StorageServiceId}/Drives /redfish/v1/StorageServices/{StorageServiceId}/FileSystems/{FileSystemId}/CapacitySources/{CapacitySourceId}/ProvidingDrives /redfish/v1/StorageServices/{StorageServiceId}/StoragePools/{StoragePoolId}/CapacitySources/{CapacitySourceId}/ProvidingDrives /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/CapacitySources/{CapacitySourceId}/ProvidingDrives

9.11.2. Properties

The properties defined for the DriveCollection object are summarized in Table 51.

9.12. EndpointGroup 1.2.0

9.12.1. Decription

An EndpointGroup represents a collection of endpoints that are managed as a unit. By grouping together a collection of Endpoints, the EndpointGroup allows a collection of entities from differing sources or hosts to be manipulated uniformly and efficiently.

For any given EndpointGroup, all of its endpoints act exclusively as either server endpoints or client endpoints, as indicated by the value of the EndpointType property. Similarly, each Endpoint within a group has the same AccessState.

A server or client may define multiple EndpointGroup entities that access the same set of resources or functionality. A group may be designated as preferred, which signifies that access should be directed through its members in preference to the Endpoints listed in other EndpointGroups. If the value of EndpointType is Server, an EndpointGroup entity can be used to represent target port group as defined by SCSI. In that mode, the value of the TargetEndpointGroupIdentifier should correspond to the target port group number. (See clause “Device Identification VPD page” as defined in the SCSI Primary Commands specification.)

9.12.2. URIs

/redfish/v1/StorageServices/{StorageServiceId}/EndpointGroups/{EndpointGroupId}

9.12.3. Properties

The properties defined for the EndpointGroup 1.2.0 object are summarized in Table 52.

9.12.4. Property details

AccessState

Access to all associated resources through all aggregated endpoints shall share this access state.

The values defined for the AccessState ENUM are summarized in Table 53.

GroupType

The group contains only endpoints of a given type Client/Initiator or Server/Target. If this endpoint group represents a SCSI target group, the value of GroupType shall be Server.

The values defined for the GroupType ENUM are summarized in Table 54.

9.13. EndpointGroupCollection

9.13.1. URIs

/redfish/v1/StorageServices/{StorageServiceId}/EndpointGroups

9.13.2. Properties

The properties defined for the EndpointGroupCollection object are summarized in Table 55.

9.14. FeaturesRegistry 1.0.0

9.14.1. Decription

This resource shall be used to represent a Feature registry for a Redfish implementation.

9.14.2. Properties

The properties defined for the FeaturesRegistry 1.0.0 object are summarized in Table 56.

9.15. FileShare 1.1.3

9.15.1. Decription

This resource shall be used to represent a shared set of files with a common directory structure.

9.15.2. Properties

The properties defined for the FileShare 1.1.3 object are summarized in Table 57.

9.15.3. Property details

DefaultAccessCapabilities

The value of this property shall be an array containing entries for the default access capabilities for the file share. Each entry shall specify a defaul access privilege. The types of default access can include Read, Write, and/or Execute. StorageAccessCapability enumeration literals may be used to describe abilities to read or write storage.

The values defined for the DefaultAccessCapabilities ENUM are summarized in Table 58.

FileShareQuotaType

If FileShareQuotaType is present, a value of Soft shall specify that quotas are not enforced, and a value of Hard shall specify that writes shall fail if the space consumed would exceed the value of the FileShareTotalQuotaBytes property.

The values defined for the FileShareQuotaType ENUM are summarized in Table 59.

FileSharingProtocols

This property shall be an array containing entries for the file sharing protocols supported by this file share. Each entry shall specify a file sharing protocol supported by the file system. The values shall indicate the file sharing protocols supported by the file system. At least one value shall be present.

The values defined for the FileSharingProtocols ENUM are summarized in Table 60.

WritePolicy

The value of this property shall define how writes are replicated to the shared source.

The values defined for the WritePolicy ENUM are summarized in Table 61.

9.16. FileShareCollection

9.16.1. URIs

/redfish/v1/Storage/{StorageId}/FileSystems/{FileSystemsId}/ExportedShares /redfish/v1/StorageServices/{StorageServiceId}/FileSystems/{FileSystemsId}/ExportedShares

9.16.2. Properties

The properties defined for the FileShareCollection object are summarized in Table 62.

9.17. FileSystem 1.2.2

9.17.1. Decription

This resource shall be used to represent an instance of a hierarchical namespace of files.

9.17.2. URIs

/redfish/v1/Storage/{StorageId}/FileSystems/{FileSystemId} /redfish/v1/StorageServices/{StorageServiceId}/FileSystems/{FileSystemId}

9.17.3. Properties

The properties defined for the FileSystem 1.2.2 object are summarized in Table 63.

9.17.4. Property details

AccessCapabilities

This property shall be an array containing entries for the supported IO access capabilities. Each entry shall specify a current storage access capability. StorageAccessCapability enumeration literals may be used to describe abilities to read or write storage.

The values defined for the AccessCapabilities ENUM are summarized in Table 64.

CharacterCodeSet

This property shall be an array containing entries for the character sets or encodings supported by the file system. Each entry shall specify a character set encoding supported by the file system. The values shall indicate the character code standards supported by the file system.

The values defined for the CharacterCodeSet ENUM are summarized in Table 65.

9.18. FileSystemCollection

9.18.1. URIs

/redfish/v1/Storage/{StorageId}/FileSystems/{FileSystemsId}/ExportedShares/{FileShareId} /redfish/v1/StorageServices/{StorageServiceId}/FileSystems/{FileSystemsId}/ExportedShares/{FileShareId}

9.18.2. Properties

The properties defined for the FileSystemCollection object are summarized in Table 66.

9.19. HostedStorageServices

9.19.1. URIs

/redfish/v1/Systems/{ComputerSystemId}/HostedServices/StorageServices

9.19.2. Properties

The properties defined for the HostedStorageServices object are summarized in Table 67.

9.20. IOConnectivityLoSCapabilities 1.1.3

9.20.1. Decription

Each instance of IOConnectivityLoSCapabilities describes capabilities of the system to support various IO Connectivity service options.

9.20.2. URIs

/redfish/v1/StorageServices/{StorageServiceId}/IOConnectivityLoSCapabilities

9.20.3. Properties

The properties defined for the IOConnectivityLoSCapabilities 1.1.3 object are summarized in Table 68.

9.20.4. Property details

SupportedAccessProtocols

Access protocols supported by this service option. NOTE: SMB+NFS* requires that SMB and at least one of NFSv3 or NFXv4 are also selected, (i.e. {‘SMB’, ‘NFSv4’, ‘SMB+NFS*’}).

The values defined for the SupportedAccessProtocols ENUM are summarized in Table 69.

9.21. IOPerformanceLoSCapabilities 1.1.3

9.21.1. Decription

Each instance of IOPerformanceLoSCapabilities shall describe the capabilities of the system to support various IO performance service options.

9.21.2. URIs

/redfish/v1/StorageServices/{StorageServiceId}/IOPerformanceLoSCapabilities

9.21.3. Properties

The properties defined for the IOPerformanceLoSCapabilities 1.1.3 object are summarized in Table 70.

9.21.4. Property details

IOAccessPattern

The enumeration literal shall be the expected access pattern.

The values defined for the IOAccessPattern ENUM are summarized in Table 71.

9.22. LineOfService 1.0.0

9.22.1. Decription

This service option is the abstract base class for other ClassOfService and concrete lines of service.

9.22.2. Properties

The properties defined for the LineOfService 1.0.0 object are summarized in Table 72.

9.23. LineOfServiceCollection

9.23.1. URIs

/redfish/v1/StorageServices/{StorageServiceId}/ClassesOfService/{ClassOfServiceId}/DataProtectionLinesOfService /redfish/v1/StorageServices/{StorageServiceId}/ClassesOfService/{ClassOfServiceId}/DataSecurityLinesOfService /redfish/v1/StorageServices/{StorageServiceId}/ClassesOfService/{ClassOfServiceId}/DataStorageLinesOfService /redfish/v1/StorageServices/{StorageServiceId}/ClassesOfService/{ClassOfServiceId}/IOConnectivityLinesOfService /redfish/v1/StorageServices/{StorageServiceId}/ClassesOfService/{ClassOfServiceId}/IOPerformanceLinesOfService /redfish/v1/StorageServices/{StorageServiceId}/LinesOfService/DataProtectionLinesOfService /redfish/v1/StorageServices/{StorageServiceId}/LinesOfService/DataSecurityLinesOfService /redfish/v1/StorageServices/{StorageServiceId}/LinesOfService/DataStorageLinesOfService /redfish/v1/StorageServices/{StorageServiceId}/LinesOfService/IOConnectivityLinesOfService /redfish/v1/StorageServices/{StorageServiceId}/LinesOfService/IOPerformanceLinesOfService

9.23.2. Properties

The properties defined for the LineOfServiceCollection object are summarized in Table 73.

9.24. SpareResourceSet 1.0.1

9.24.1. Decription

The values define a set of spares of a particular type.

9.24.2. Properties

The properties defined for the SpareResourceSet 1.0.1 object are summarized in Table 74.

9.25. StorageGroup 1.2.1

9.25.1. Decription

The primary purposes of the collection shall be to govern access to the storage by clients or to add service requirements for the members of the collection. Access to the collected storage by a specified set of hosts shall be made available or unavailable atomically. Requirements specified by the class of service shall be satisfied by each collected element to which they apply. The storage group may contain: block, file, or object storage; local storage system access points through which the collection is made available; and hosts, or host access points to which the collection is made available.

9.25.2. URIs

/redfish/v1/Storage/{StorageId}/StorageGroups/{StorageGroupId} /redfish/v1/Storage/{StorageId}/Volumes/{VolumeId}/StorageGroups/{StorageGroupId} /redfish/v1/StorageServices/{StorageServiceId}/StorageGroups/{StorageGroupId} /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/StorageGroups/{StorageGroupId}

9.25.3. Properties

The properties defined for the StorageGroup 1.2.1 object are summarized in Table 75.

9.25.4. Actions

ExposeVolumes

Exposes the storage of this group via the target endpoints named in the ServerEndpointGroups to the initiator endpoints named in the ClientEndpointGroups. The property VolumesAreExposed shall be set to true when this action is completed.

URIs:

/redfish/v1/Storage/{StorageId}/StorageGroups/{StorageGroupId}/Actions/StorageGroup.ExposeVolumes /redfish/v1/Storage/{StorageId}/Volumes/{VolumeId}/StorageGroups/{StorageGroupId}/Actions/StorageGroup.ExposeVolumes /redfish/v1/StorageServices/{StorageServiceId}/StorageGroups/{StorageGroupId}/Actions/StorageGroup.ExposeVolumes /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/StorageGroups/{StorageGroupId}/Actions/StorageGroup.ExposeVolumes

Parameters

(This action takes no parameters.)

HideVolumes

Hide the storage of this group from the initiator endpoints named in the ClientEndpointGroups. The property VolumesAreExposed shall be set to false when this action is completed.

URIs:

/redfish/v1/Storage/{StorageId}/StorageGroups/{StorageGroupId}/Actions/StorageGroup.HideVolumes /redfish/v1/Storage/{StorageId}/Volumes/{VolumeId}/StorageGroups/{StorageGroupId}/Actions/StorageGroup.HideVolumes /redfish/v1/StorageServices/{StorageServiceId}/StorageGroups/{StorageGroupId}/Actions/StorageGroup.HideVolumes /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/StorageGroups/{StorageGroupId}/Actions/StorageGroup.HideVolumes

Parameters

(This action takes no parameters.)

9.25.5. Property details

AccessState

The value of this property shall describe the access characteristics of this storage group. All associated logical units through all aggregated ports shall share this access state.

The values defined for the AccessState ENUM are summarized in Table 76.

AuthenticationMethod

The value of this property must be what kind of authentication that the endpoints in this StorageGroup understands.

The values defined for the AuthenticationMethod ENUM are summarized in Table 77.

9.26. StorageGroupCollection

9.26.1. URIs

/redfish/v1/Storage/{StorageId}/StorageGroups /redfish/v1/Storage/{StorageId}/Volumes/{VolumeId}/StorageGroups /redfish/v1/StorageServices/{StorageServiceId}/StorageGroups /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/StorageGroups

9.26.2. Properties

The properties defined for the StorageGroupCollection object are summarized in Table 78.

9.27. StoragePool 1.3.1

9.27.1. Decription

A container of data storage capable of providing capacity conforming to one of its supported classes of service. The storage pool does not support IO to its data storage.

9.27.2. URIs

/redfish/v1/Storage/{StorageId}/FileSystems/{FileSystemId}/CapacitySources/{CapacitySourceId}/ProvidingPools/{StoragePoolId} /redfish/v1/Storage/{StorageId}/StoragePools/{StoragePoolId} /redfish/v1/Storage/{StorageId}/StoragePools/{StoragePoolId}/AllocatedPools/{AllocatedPoolId} /redfish/v1/Storage/{StorageId}/StoragePools/{StoragePoolId}/CapacitySources/{CapacitySourceId}/ProvidingPools/{ProvidingPoolId} /redfish/v1/Storage/{StorageId}/Volumes/{VolumeId}/AllocatedPools/{StoragePoolId} /redfish/v1/Storage/{StorageId}/Volumes/{VolumeId}/CapacitySources/{CapacitySourceId}/ProvidingPools/{StoragePoolId} /redfish/v1/StorageServices/{StorageServiceId}/FileSystems/{FileSystemId}/CapacitySources/{CapacitySourceId}/ProvidingPools/{StoragePoolId} /redfish/v1/StorageServices/{StorageServiceId}/StoragePools/{StoragePoolId} /redfish/v1/StorageServices/{StorageServiceId}/StoragePools/{StoragePoolId}/AllocatedPools/{AllocatedPoolId} /redfish/v1/StorageServices/{StorageServiceId}/StoragePools/{StoragePoolId}/CapacitySources/{CapacitySourceId}/ProvidingPools/{ProvidingPoolId} /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/AllocatedPools/{StoragePoolId} /redfish/v1/StorageServices/{StorageServiceId}/Volumes/{VolumeId}/CapacitySources/{CapacitySourceId}/ProvidingPools/{StoragePoolId}

9.27.3. Properties

The properties defined for the StoragePool 1.3.1 object are summarized in Table 79.