Swordfish Scalable Storage Management API User’s Guide

Version 1.2.7

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.

Last Updated 13 August 2024

USAGE

Copyright (c) 2016 - 2024 Storage Networking Industry Association. All rights reserved. All other trademarks or registered trademarks are the property of their respective owners.

Storage Networking Industry Association (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 SNIA copyright on that material, and must credit 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

Copyright (c) 2024, Storage Networking Industry Association.

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 Storage Networking Industry Association 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. SNIA makes no warranty of any kind with regard to this publication, 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/.

Current Revision

SNIA is actively engaged in expanding and refining the Swordfish documentation. 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

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 SNIA, 5201 Great America Parkway, Suite 320, Santa Clara, CA 95054, USA.

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.

Revision History

The evolution of this document is summarized in Table 8.

Table 8: Revision history

About SNIA

SNIA is a not-for-profit global organization made up of corporations, universities, startups, and individuals. The members collaborate to develop and promote vendor-neutral architectures, standards, and education for management, movement, and security for technologies related to handling and optimizing data. SNIA focuses on the transport, storage, acceleration, format, protection, and optimization of infrastructure for data. Learn more at www.snia.org.

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 following members listed in Table 9.

Table of Contents

1. Introduction
1.1. Audience
1.2. Documentation structure
1.3. Implementation scope assumptions
1.4. Base implementation assumptions
1.5. Knowledge assumptions
1.6. Related documents
2. General query syntax { .page_break_before }
2.1. Query method
2.2. Query Headers
2.2.1. Request headers
2.2.2. Response headers
2.3. Service root
2.4. Resource path
2.5. Query options
2.6. Filter expressions
2.7. HTTP status codes
3. Actors
3.1. Overview
3.2. CloudAdmin
3.2.1. Overview
3.2.2. Alphabetic List of Use Cases
3.3. DevOps
3.3.1. Overview
3.3.2. Alphabetic List of Use Cases
3.4. StorageAdmin
3.4.1. Overview
3.4.2. Alphabetic List of Use Cases
4. Management domains
4.1. Management Domain Overview
4.2. Application storage management domain
4.2.1. Overview
4.3. Block storage management domain
4.3.1. Overview
4.4. Service catalog management domain
4.4.1. Overview
4.4.2. Data protection
4.4.3. Data security
4.4.4. Data storage
4.4.5. IO connectivity
4.4.6. IO performance
4.5. File system storage management domain
4.5.1. Overview
5. User Guidance { .page_break_before }
6. Features
6.1. Overview
6.2. Block provisioning feature
6.2.1. Overview
6.3. Alphabetic List of Use Cases
6.4. Capacity management feature
6.4.1. Overview
6.5. Alphabetic List of Use Cases
6.6. Class of Service Features
6.6.1. Overview
6.7. Alphabetic List of Use Cases
6.8. Event notification feature
6.8.1. Overview
6.9. Alphabetic List of Use Cases
6.10. File provisioning feature
6.10.1. Overview
6.11. Alphabetic List of Use Cases
6.12. Block IO performance feature
6.12.1. Overview
6.13. Alphabetic List of Use Cases
6.14. Block mapping and masking feature
6.14.1. Overview
6.15. Alphabetic List of Use Cases
6.16. NVMe Support feature
6.16.1. Overview
6.17. Alphabetic List of Use Cases
6.18. Replication Feature
6.18.1. Overview
6.19. Alphabetic List of Use Cases
7. Use cases { .page_break_before }
7.1. Alphabetic list of use cases
7.1.1. Add Multiple Drives to an Existing Storage Pool
7.1.2. Apply an NVMe firmware image to a given controller
7.1.3. Attach a Namespace
7.1.4. Can a new Namespace be created?
7.1.5. Can a new Namespace be created?
7.1.6. Can a new Volume be created?
7.1.7. Change only the RAID Type of an Existing Volume
7.1.8. Create an on-demand snapshot of a Volume
7.1.9. Create class of service
7.1.10. Create ConsistencyGroup
7.1.11. Create file share
7.1.12. Create file system
7.1.13. Create line of service
7.1.14. Create storage pool and specify a pool type
7.1.15. Create storage pool using Specified Set of Drives and RAIDTypes
7.1.16. Create storage pool using specified set of drives
7.1.17. Create storage pool
7.1.18. Create Volume from an Existing Storage Pool
7.1.19. Create Volume specifying Class of Service
7.1.20. Create Volume using Default Class of Service
7.1.21. Delete an endpoint
7.1.22. Delete Multiple Drives from an Existing Storage Pool
7.1.23. Review Metrics Trends
7.1.24. Send Security Protocol Data
7.1.25. Split a Replica
7.1.26. Subscribe to Threshold Events
7.1.27. Suspend Replication Synchronization Activity between Consistency Groups
7.1.28. Update access rights on an existing volume
7.1.29. Use Features Registry to confirm functionality

1. Introduction

1.1. Audience

This guide is intended to provide a common repository of best practices, common tasks and education for the users of the Swordfish API. Each use case includes an indication of the classes of API users who are most likely to find the case useful.

1.2. Documentation structure

This document begins with a set of information intended to provide a solid foundation for readers new to restful APIs in general and Swordfish in particular. While this material is no replacement for a thorough understanding of the Swordfish specification and the material that it references, it is intended as a stand alone document that can provide a solid introduction to Swordfish.

Based on that foundational material, this document then presents a set of Use Cases intended to capture common tasks and best practices that can be used to exercise the breadth and strength of the Swordfish API. In general, the guide is structured to provide more basic use cases first, and examine common refinements and options at the same time. More advanced tasks are handled later in the guide, and assume the prior skills and assumptions have been mastered.

For each use case, this guide will use a common template. Table 10 lists each field of the template and its description.

Table 10: Guidelines for the Use Case Template

1.3. Implementation scope assumptions

The precise scope of a given Swordfish implementation can vary widely. Some installations will opt to deploy a basic level of the API that only extends the Redfish standard slightly. Others will decide to implement a number of features, providing a broader range of functionality. While this guide cannot provide examples of all possible configurations and situations, it does attempt to cover a range of possible functionality options. Use cases that assume functionality that correspond to specific features are clearly identified.

In the same vein, the example query responses are not intended to perfectly reproduce what would be returned from any given implementation. Rather, they focus on illustrating a particular functionality or approach, and include only the information that is essential to that end.

1.4. Base implementation assumptions

This document assumes that some fundamental configuration issues have been properly implemented, and will not need to be addressed in any detail. In particular, this document assumes:

• An appropriate security infrastructure (e.g., TLS 1.2)
• A functional Swordfish/Redfish installation, in either a standalone, aggregator, or distributed configuration
• Any required login credentials

1.5. Knowledge assumptions

The Swordfish API conforms to the standards defined in the Redfish API. More generally, it is provides a RESTful interface. The reader is assumed to be familiar with common conventions for RESTful APIs. Those readers who are interested in additional background information are encouraged to refer to the following sources:

• For RESTful APIs: Wikipedia
• For Redfish standards and related material: Redfish home page
• For HTTP standards: Wikipedia

1.6. Related documents

This User’s Guide is part of the documentation suite for the Swordfish API. Readers are encouraged to refer to the following for additional information: - Swordfish API Specification - Swordfish Tutorials - Swordfish NMVe Mapping Guide - Swordfish Profile Bundle - Redfish Specification

2. General query syntax

2.1. Query method

Swordfish queries support four query methods. Each query URL must include exactly one of of the query methods listed in Table 11.

Table 11: Query methods

2.2. Query Headers

All HTTP requests and responses in a compliant Swordfish implementation support the HTTP headers required by the Redfish Protocol Specification. The supported headers are reproduced here for convenience.

2.2.1. Request headers

HTTP request headers that are commonly used in Swordfish queries are summarized in Table 12.

Table 12: Request headers

2.2.2. Response headers

HTTP response headers that are commonly used in Swordfish queries are summarized in Table 13.

Table 13: Response headers

2.3. Service root

This is the base of all Swordfish URL’s. A GET request to the Service Root will return an overview of the services provided by a given Swordfish service. In addition, the Service Root will include versioning information.

All Service Root URLs that are compliant with the Swordfish specification will be of the form https://hostName/redfish/v1, where hostName specifies the system (and optionally port number), of the Swordfish service provider.

2.4. Resource path

The Resource Path identifies the specific object (or collection of objects) that is the target of the Swordfish query. Swordfish Resource Paths can identify:

• A singleton object (e.g., a specific storage LUN or Volume)
• A collection of objects (e.g., the list of all LUNs provided by a specific storage array)

At the highest level, Swordfish systems are discoverable in the Storage Systems collection in the ServiceRoot.

2.5. Query options

Swordfish queries can include arbitrary sets of query options to further refine the target of given query or the actions being requested of that target. These general query options are summarized in Table 14.

Note: Additional query options may be supported (or constrained) for a specific query target or resource path. These target-specific query options will be addressed in specific use case descriptions, as required.

Table 14: Query Options

2.6. Filter expressions

Simple example:

$filter=(age gt 30) A group of people never to trust.

For more information see Filter Expression in the OData specification.

2.7. HTTP status codes

Swordfish clients may receive any of the standard HTTP status codes. Both the Redfish specification and the Swordfish specification define a detailed mapping from the generic HTTP codes to domain-specific situations, and probable causes. In addition, the server can return extended status information as a simple JSON object to further clarify the handling and outcome of a particular API request. For more information, see the Swordfish Specification and the Redfish Specification.

3. Actors

3.1. Overview

This document covers a broad range of common use cases and storage management operations.

In an attempt to serve as both a introductory text and as a reference tool, the use cases have been grouped in a number of different ways:

• Alphabetically. Each use case is ordered according to a self-expanatory title, to make it easier for an experienced user to find a specifc piece of guidance.
• By management domain. While each organization will allocate responsibilities differently, there are general broad classes of storage management that share tasks. These are called management domains.
• By actor. Similarly, the precise titles and responsibilities within storage management organizations will differ from one organization to the next, but this guide has identified three broad functional roles, and identfied the use cases that are most applicable to those roles:
  • Cloud Admin: tasked with managing all aspects of cloud-based infrastructure including storage;
  • Storage Admin: tasked with operational storage tasks, such as storage lifecycle planning and day-to-day storage administration;
  • DevOps: tasked with leveraging storage configurations to automate and scale business operations.

3.2. CloudAdmin

3.2.1. Overview

A Cloud Administrator (CloudAdmin) is a converged infrastructure administrator, working with systems that are:

• Hyper-converged
• Rack-converged
• Hyper-scale

The CloudAdmin role in an enterprise or service provider is the individual or group primarily responsible for managing the operational lifecycle of a cloud, virtualization, converged environment that consists of the workloads, resource abstractions, storage, networking, and compute.

Also referred to as a “cloud architect”, this role:

• designates a group of people to build and maintain a virtualized, converged, and/or cloud environment
• spans compute, storage, and networking disciplines as their job is to manage the operational lifecycle of the entire environment
• focuses on automation that involves scripting and potentially formal programming
• This role’s value is to keep the environment that hosts applications available and responding. Deep subject matter expertise is less valuable unless it helps solve an issue.
• The focus for this role is to streamline the deployment of applications into the infrastructure including all the network and storage configuration.
• This role gets involved in the physical deployment of capacity in the datacenter.
• This role deals with software defined infrastructure deployment and management.
• Applications can span physical, virtual machine, container, PaaS building blocks. This role is expected to know how to best configure the “stack” to consume the underlying physical infrastructure.

3.2.2. Alphabetic List of Use Cases

• Create file share
• Create Volume specifying Class of Service
• Create an on-demand snapshot of a Volume
• Create Volume using Default Class of Service
• Create a new endpoint group
• Delete an endpoint
• Create a new connection to an existing volume
• Create a new endpoint
• Provision a Namespace from NVM Set
• Attach a Namespace
• Report Remaining Life for a Namespace
• Apply an NVMe firmware image to a given controller
• Provision a Namespace with a specific LBA format
• Provision a Namespace
• Can a new Namespace be created?
• Confirm valid LBA formats
• Detach a Namespace
• Deprovision a Namespace
• Update access rights on an existing volume
• Report Namespace Capacity
• Create ConsistencyGroup
• Create Volume from an Existing Storage Pool
• Can a new Volume be created?
• Can a new Namespace be created?
• Subscribe to Threshold Events

3.3. DevOps

3.3.1. Overview

A member of the DevOps group:

• Consumes infrastructure capacity offered as a service/building blocks.
• Develops and deploys programmatic requests for capacity (fully automated, no ticketing or human intervention)
• Provisions storage as a virtual appliance on-premises or in the cloud as part of a larger application deployment
• Deploys ‘cloud born apps’ to consume object storage APIs (S3, Swift)

This role is typically aligned with the business unit. Their focus is the delivery, deployment, and maintenance of apps on IaaS and PaaS resources. This role is not typically a deep subject matter expert in compute, storage, or networking. From a development perspective, their desire is to treat the infrastructure as a programmable subsystem that presents resources on-demand.

This role:

• does not get involved in the physical deployment of capacity in the datacenter
• is responsible for automating infrastructure provisioning as part of the E2E deployment and management of an application with minimal or no human intervention
• consumes higher level services and protocols from the infrastructure; understanding how the device works is not interesting
• expects to consume the programmable interfaces of a device using their existing tools (REST, Python, Ansible, Puppet, Chef, Ruby etc.)

3.3.2. Alphabetic List of Use Cases

• Create file share
• Create Volume specifying Class of Service
• Create an on-demand snapshot of a Volume
• Create Volume using Default Class of Service
• Resume the Replication Synchronization Activity for a Consistency Group
• Remove Replication Relationship
• Reverse a Replication Relationship for Consistency Groups
• Suspend Replication Synchronization Activity between Consistency Groups
• Split a Replica
• Remove Replication Relationship for a Consistency Group
• Create a New Replication Relationship by Assigning a Target Volume
• Resume the Replication Synchronization Activity
• Split a set of Replicas in Consistency Groups
• Make a New Replication Relationship by Creating a Target Consistency Group
• Suspend Replication Synchronization Activity
• Reverse a Replication Relationship
• Create a New Replication Relationship by Assigning an existing Target Consistency Group
• Make a New Replication Relationship by Creating a Target Volume
• Create Volume from an Existing Storage Pool
• Can a new Volume be created?
• Can a new Namespace be created?
• Subscribe to Threshold Events
• Retrieve latest instance of storage metrics information

3.4. StorageAdmin

3.4.1. Overview

A storage administrator designs storage solutions for modern environments, including:

• Virtualization (traditional virtualization VMware, Hyper-V)
• private cloud (self-service portal)
• hybrid cloud (can span private, colo, hosted, and public cloud)
• IaaS/PaaS stacks (modern app/devops)

The storage admin role in an enterprise or service provider can have responsibility for managing the operational lifcycle of storage in the datacenter. In particular:

• Organizations can have one or more people exclusively assigned to operating lifecycle of storage in the datacenter.
• The storage admin role is typically tasked with “figuring out” storage needs for the company
  
• The admin role can consist of level 2 operators and level 3 engineers and architects.
• The admin role deals with multiple storage devices from multiple vendors across one or more datacenters.
• Storage devices attached to multiple operating systems (Linux, Windows, Mainframe, Unix, virtualized, bare metal).
• The Admin role consists of deep storage subject matter expertise, may or may have general practitioners across all disciplines
• Members of this role are typically skilled at scripting and formal programming
• In a converged environment (storage, compute, and networking converged in to a rack), the storage admin role may choose to avoid/minimize involvement in the support of storage WITHIN the rack. (e.g. in virtualization, a single physical port can host 1000s of VMs).

3.4.2. Alphabetic List of Use Cases

• Create file share
• Create file system
• Create Volume specifying Class of Service
• Create an on-demand snapshot of a Volume
• Create storage pool
• Create line of service
• Create file system
• Create class of service
• Create Volume using Default Class of Service
• Expand capacity of a storage volume
• Create storage pool using Specified Set of Drives and RAIDTypes
• Create storage pool using specified set of drives
• Review Metrics Trends
• Create storage pool and specify a pool type
• Resume the Replication Synchronization Activity for a Consistency Group
• Remove Replication Relationship
• Reverse a Replication Relationship for Consistency Groups
• Suspend Replication Synchronization Activity between Consistency Groups
• Split a Replica
• Remove Replication Relationship for a Consistency Group
• Create a New Replication Relationship by Assigning a Target Volume
• Resume the Replication Synchronization Activity
• Split a set of Replicas in Consistency Groups
• Make a New Replication Relationship by Creating a Target Consistency Group
• Suspend Replication Synchronization Activity
• Reverse a Replication Relationship
• Create a New Replication Relationship by Assigning an existing Target Consistency Group
• Make a New Replication Relationship by Creating a Target Volume
• Send Security Protocol Data
• Receive Security Protocol Data
• Query Supported Security Protocols
• Create a new endpoint group
• Delete an endpoint
• Create a new connection to an existing volume
• Create a new endpoint
• Provision a Namespace from NVM Set
• Attach a Namespace
• Report Remaining Life for a Namespace
• Apply an NVMe firmware image to a given controller
• Provision a Namespace with a specific LBA format
• Provision a Namespace
• Can a new Namespace be created?
• Confirm valid LBA formats
• Detach a Namespace
• Deprovision a Namespace
• Update access rights on an existing volume
• Report Namespace Capacity
• Create ConsistencyGroup
• Add Multiple Drives to an Existing Storage Pool
• Delete Multiple Drives from an Existing Storage Pool
• Create Volume from an Existing Storage Pool
• Change only the span count of an existing volume
• Can a new Volume be created?
• Change only the RAID Type of an Existing Volume
• Delete Volume
• Can a new Namespace be created?
• Subscribe to Threshold Events

4. Management domains

4.1. Management Domain Overview

This document covers a broad range of common use cases and storage management operations.

In an attempt to serve as both a introductory text and as a reference tool, the use cases have been grouped in a number of different ways:

• Alphabetically. Each use case is ordered according to a self-expanatory title, to make it easier for an experienced user to find a specifc piece of guidance.

• By actor. While the precise titles and responsibilities within storage management organizations will differ from one organization to the next, this guide has identified three broad functional roles, known as actorsand identfied the use cases that are most applicable to those roles;

• By management domain. Similarly, while each organization will allocate responsibilities differently, there are general broad classes of storage management that share tasks. This guide has identified four management domains:

  • Application Storage Management: which manages the interface between applications and the storage that they rely upon;
  • Block Storage Management: focused on the management of resources that provide block-based access to storage;
  • Service Catalog Management: which supports access to, and management of, a catalog of service options;
  • File system storage management domain: which supports file system management and manipulation, and file-based access to storage.

4.2. Application storage management domain

4.2.1. Overview

This domain manages the interface between applications and the storage that they rely upon.

StorageGroups provide a means to collectively manage the Volumes and FileShares utilized by an Application. The StorageGroup specifies whether the collected resources are managed so that storage is updated or replicated consistently across all members. Additionally, the StorageGroup provides the means to atomically expose (or hide) the collected resources to (or from) host endpoints.

4.3. Block storage management domain

4.3.1. Overview

Many devices and services provide their storage capacity to external devices and applications through block-based protocols to storage devices. This domain includes the management of resources that provide block-based access to storage.

Block-based storage is represented by a Volume. This domain provides for the discovery and provisioning of Volumes and for maintaining relationships to Device, Endpoint, StorageService, StorageGroup, StoragePool, and ComputerSystem resources.

4.4. Service catalog management domain

4.4.1. Overview

Swordfish supports access to, and management of, a catalog of service options, (see ITIL glossary and abbreviations), supported by storage services.

When the Swordfish Class of Service Feature is implemented, the ClassOfService resource represents a service option that may be used to specify requirements for utility or warranty when provisioning a resource. Currently ClassOfService is defined for use in the Block Storage, File System, and ApplicationStorage domains.

The service catalog for each StorageService is represented by a collection of references to supported ClassOfService resources. Each ClassOfService is known minimally by a Name and a unique Identifier. When a ClassOfService is specified for a resource, the StorageService shall attempt to maintain that resource in compliance to the requirements of that ClassOfService. The requirements may be specified informally by text in the Description property or may be specified formally by the property values of embedded options related to specific lines of service.

The embedded service options are described by values of complex types representing lines of service.

Over time, as the service catalog is continually updated to match evolving user needs and service provider offerings, it is expected that the catalog will contain entries (one or more ClassOfSerice or LineOfService instances) that are not currently active.

4.4.2. Data protection

The primary storage is described by a ClassOfService resource. That ClassOfService may aggregate any number of data protection service options. Each instance of a data protection service option describes the characteristics a replication session that shall be maintained for the containing primary storage resource.

For additional information, see the definitions for DataProtectionLineOfService and DataProtectionLoSCapabilities.

4.4.3. Data security

An instance of a data security service option describes an optional set of data security requirements. A data security Service option is typically aggregated into a ClassOfService resource that is associated with storage. At most one data security service option may be aggregated into a ClassOfService resource. When storage is provisioned with that ClassOfService, it will provide the currently specified data security characteristics.

A data security service option may specify data security characteristics that 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. In this case, the names of the standard or standards can usefully be included in the user/admin-visible name of the instance. With the notable exception of FIPS-140, compliance requires measures well beyond the means of a storage system to provide (e.g., both HIPAA and PCI impose significant requirements on administration and operation of the data center), so this approach promises that the storage system will do its part in supporting compliance, but does not (and cannot) promise that the storage system will deliver full compliance by itself.

The description attribute value may include human readable information including:

• Whether encryption keys are drive or array resident or externally managed (e.g., via KMIP).

• Information on how the array supports compliance to a standard identified in the name of the Service option. (e.g., specific algorithms employed that are FIPS-140 compliant, information about the validated cryptographic module and its validation certificate, relationship of the security functionality to specific PCI or HIPAA requirements).

NOTE For comparable cryptographic strengths, (see NIST SP 800-57 part 1)

NOTE For symmetric encryption algorithm key sizes, 112 bits is the 3DES key size and 128, 192, and 256 bits are options for AES key sizes.`

NOTE MediaEncryptionStrength includes the case where metadata about the data must be encrypted. (e.g. data presence vs. absence in a thin volume, array filesystem metadata) The implementation may be self-encrypting drives or encryption in the storage system’s drive controller. Keys may be drive or array resident or externally managed (e.g., via KMIP).

For additional information, see the definitions for DataSecurityLineOfService and DataSecurityLoSCapabilities.

4.4.4. Data storage

Each data storage service option describes characteristics of the storage at a particular location. A class of service will have at most one data storage service option, which describes the storage specified by that class of Service.

For additional information, see the DataStorageLineOfService and DataProtectionLoSCapabilities.

4.4.5. IO connectivity

An IO connectivity service option specifies the characteristics of storage connectivity. For each value of AccessProtocol, at most one IO connectivity service option may be aggregated into a class of service.

NOTE: If used within a ClassOfService for Storage Provisioning, this value constrains the set of connections used to expose that storage.

For additional information, see the IOConnectivityLineOfService and IOConnectivityLoSCapabilities.

4.4.6. IO performance

An IO performance service option specifies a choice of performance characteristics as viewed through the data path to the storage. This is affected by choices of storage and connection technologies.
At most one IO performance service option may be aggregated into a ClassOfService for a storage resource. When storage is provisioned with that ClassOfService, it should provide at least the specified performance.

For additional information, see the IOConnectivityLineOfService and IOConnectivityLoSCapabilities.

4.5. File system storage management domain

4.5.1. Overview

FileSystems provide access to byte-accessible storage through file-based protocols. This domain includes the management of resources that provide file-based access to storage.

File-based storage is represented by a FileSystem resources. Remote access to portions of a FileSystem is provided by FileShare resources.

5. User Guidance

Swordfish supports a range of possible features. Clients use the Features registry to determine what SupportedFeatures a specific instance of an implementation is capable of. These range from discovery (read-only functionality), to event notification, to performance instrumentation, to multiple levels of block and file provisioning capabilities.

Supporting the granular feature definition is a detailed profile description that includes precise definitions of what functionality must be implemented in order to advertise support for each feature.

For use cases specified in this document, there is an expectation that specific features have been implemented to support the corresponding use case. For example, the “AssignReplicaTarget” use case highlights functionality for either local or remote replication, depending on the selected target volume’s system (either the same or different than the source volume). In either case, the client is working with the presumption that the feature has been advertised.

6. Features

6.1. Overview

This guide covers use cases for both installations that have opted to deploy a basic level of the API, and only extends the Redfish standard slightly, and those that implement a number of advanced features, providing a broader range of functionality. Use cases that assume functionality or features beyond a basic Swordfish implementation are clearly identified below, and are grouped with one another.

This version of the Users’ Guide incorporates the functionality defined in the Swordfish specification, which defines a number of features. In addition to basic use cases, this document includes cases that rely on the implementation of each of those features:

• Access management
• Block provisioning
• Capacity management
• Class of Service
• Event notification
• File provisioning
• IO performance
• Mapping and masking
• NVMe
• Registries
• Replication (both local and remote)
• Security Management

6.2. Block provisioning feature

6.2.1. Overview

This feature provides basic, block-based storage provisioning. The use cases cover a range of functionality for both traditional RAID storage as well as NVMe devices.

6.3. Alphabetic List of Use Cases

• Add Multiple Drives to an Existing Storage Pool
• Change only the RAID Type of an Existing Volume
• Change only the span count of an existing volume
• Create Volume from an Existing Storage Pool
• Delete Multiple Drives from an Existing Storage Pool
• Delete Volume
• Can a new Namespace be created?
• Can a new Volume be created?

6.4. Capacity management feature

6.4.1. Overview

This feature provides the management and alteration of storage once it has been allocated. Use cases cover multiple permutations for storage pool creation, online volume expansion, and capacity metrics review.

6.5. Alphabetic List of Use Cases

• Create storage pool and specify a pool type
• Create storage pool using specified set of drives
• Create storage pool using Specified Set of Drives and RAIDTypes
• Expand capacity of a storage volume
• Review Metrics Trends

6.6. Class of Service Features

6.6.1. Overview

This feature provides support for automated storage management based on ClassOfService and LineOfService modeling. Use cases in the section show create examples for various objects in a Class of Service based configuration.

If a pool, storage volume or other construct is created with no specified class of service when a class of service exists, the implementation will attempt to apply the DefaultClassOfService.

6.7. Alphabetic List of Use Cases

• Create class of service
• Create file system
• Create line of service
• Create storage pool
• Create Volume specifying Class of Service
• Create Volume using Default Class of Service
• Create an on-demand snapshot of a Volume

6.8. Event notification feature

6.8.1. Overview

This feature provides basic eventing.

The use cases defined here are limited to event functionality required for storage management with Swordfish, and do not attempt to cover the full breadth of eventing support provided by Redfish. That information can be found in the Redfish specification.

6.9. Alphabetic List of Use Cases

• Subscribe to Threshold Events

6.10. File provisioning feature

6.10.1. Overview

This feature provides file-based storage provisioning.

This section provides use cases highlighting examples creating file systems and file shares.

6.11. Alphabetic List of Use Cases

• Create file share
• Create file system

6.12. Block IO performance feature

6.12.1. Overview

This feature provides basic performance metrics.

The use cases in this section provide examples to access performance metrics. For additional information, including usage of the Redfish/Swordfish telemetry service, refer to the Swordfish Metrics White Paper.

6.13. Alphabetic List of Use Cases

• Retrieve latest instance of storage metrics information

6.14. Block mapping and masking feature

6.14.1. Overview

This feature provides block-based mapping and assignment of storage volumes.

6.15. Alphabetic List of Use Cases

• Create ConsistencyGroup

6.16. NVMe Support feature

6.16.1. Overview

This feature provides NVMe-specific use cases.

The detailed mapping between Swordfish objects and the NVMe object model can be found in Swordfish NVMe Model Overview and Mapping Guide.

6.17. Alphabetic List of Use Cases

• Apply an NVMe firmware image to a given controller
• Attach a Namespace
• Confirm valid LBA formats
• Deprovision a Namespace
• Detach a Namespace
• Can a new Namespace be created?
• Provision a Namespace
• Provision a Namespace with a specific LBA format
• Provision a Namespace from NVM Set
• Report Namespace Capacity
• Report Remaining Life for a Namespace
• Update access rights on an existing volume

6.18. Replication Feature

6.18.1. Overview

This set of features (local replication and remote replication) provides support for a broad range of storage redundancy protections.

Replication can be implemented many ways. The use cases defined for this feature illustrate two possible approaches, one using volumes and the other using consistency groups. Those use cases employing consistency groups will include “CG” in their titles, to avoid confusion, and are grouped separately in the table below.

6.19. Alphabetic List of Use Cases

• Create a New Replication Relationship by Assigning a Target Volume
• Make a New Replication Relationship by Creating a Target Volume
• Remove Replication Relationship
• Resume the Replication Synchronization Activity
• Reverse a Replication Relationship
• Split a Replica
• Suspend Replication Synchronization Activity
• Create a New Replication Relationship by Assigning an existing Target Consistency Group
• Make a New Replication Relationship by Creating a Target Consistency Group
• Remove Replication Relationship for a Consistency Group
• Resume the Replication Synchronization Activity for a Consistency Group
• Reverse a Replication Relationship for Consistency Groups
• Split a set of Replicas in Consistency Groups
• Suspend Replication Synchronization Activity between Consistency Groups

7. Use cases

7.1. Alphabetic list of use cases

7.1.1. Add Multiple Drives to an Existing Storage Pool

Summary: Add multiple drives to an Storage Pool.

Purpose: Add multiple drives to an Storage Pool to provide additional capacity.

Who: StorageAdmin

Management Domain: Block storage management

Triggers: Expand resources available to a pool; this could be performance, capacity or application triggered.

Detailed Context: The storage admin needs to increase the underlying available capacity within an existing pool. This use case makes the following assumptions about the “implementation” servicing the request:

• The implementation manages, or does not have any, constraints on the inclusion of multiple drives into the target storage pool.

Preconditions: User has already selected a Pool.

Feature(s): Block provisioning

Inputs:

• URL for Storage Pool: /redfish/v1/Storage/1/StoragePools/PrimaryPool

• Drives to add:

  [{"@odata.id": "/redfish/v1/Chassis/1/Drives/1"}, {"@odata.id": "/redfish/v1/Chassis/1/Drives/2"}]

Basic Course of Events:

1. Use the “AddDrives” Action on the PrimaryPool storage pool, passing the selected drives as input.

Request: POST /redfish/v1/Storage/1/StoragePools/PrimaryPool.AddDrives

• Headers: Content-type : application/json

• Body:

  {
  "Drives" : [
   {"@odata.id": "/redfish/v1/Chassis/1/Drives/1"},
   {"@odata.id": "/redfish/v1/Chassis/1/Drives/2"}
   ]
  }

Response: Response is dependent on implementation’s capability.

If the implementation is able to return immediately:

• HTTP Status: 200 (OK)

• Headers: None.

• Body: None.

If the implementation requires a background task (using the Redfish task service) to return status:

• HTTP Status: 202 (Accepted)

• Headers: Location : /redfish/v1/TaskService/Tasks/TaskID2

• Body: None.

Postconditions: The new drives have been added to a capacity source (chosen by the implementation) used by the selected storage pool.

Failure Scenario: None defined

See also: None defined.

7.1.2. Apply an NVMe firmware image to a given controller

Summary: Select a firmware image and upload to a selected NVMe Controller

Purpose: Upload a selected firmware image to an NVMe Controller, and request its activation on reset.

Who: StorageAdmin; CloudAdmin

Management Domain: Block storage management

Triggers: None defined.

Detailed Context: Locate a firmware image within the SoftwareInventory, and use the firmwareupdate service to apply it to a given Admin or IO controller. The command cannot be sent to a discovery controller. When sending the firmware image to the controller, use the “@Redfish.OperationApplyTime” parameter to specify that the firmware should be activated by the device on reset.

Preconditions: The SoftwareInventory collection must be populated with at least one firmware image.

Feature(s): NMVe

Inputs:

• None.

Basic Course of Events:

1. GET the list of available firmware images. Note: This is a well-known URI and query from the UpdateService; this example assumes an implementation supporting the $expand query parameter.

   Request:

   GET /redfish/v1/UpdateService/FirmwareInventory?$expand=.

   • Headers: Content-type : application/json

   • Body: None.

   Response:

   • HTTP Status: 200 (Success)

   • Headers: Content-type : application/json

   • Body

      {
        "@odata.context": "/redfish/v1/$metadata#SoftwareInventoryCollection.SoftwareInventoryCollection",
        "@odata.id": "/redfish/v1/UpdateService/FirmwareInventory",
        "@odata.type": "#SoftwareInventoryCollection.SoftwareInventoryCollection",
        "Description": "Collection of Firmware Inventory",
        "Members": [
          {
            "@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/Installed-0-20.06.05.11__SSD.1-1-1"
          },
          {
            "@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/Installed-0-20.06.05.11__SSD.1-2-1"
          }
        ],
        "Members@odata.count": 18,
        "Name": "Firmware Inventory Collection"
      }

2. GET the available controllers

   Request:

   GET /redfish/v1/Systems/Sys-1/Storage/SimplestNVMeSSD/Controllers

   • Headers: Content-type : application/json

   • Body: None.

   Response:

   • HTTP Status: 200 (Success)

   • Headers: Content-type : application/json

   • Body

   {
   "@odata.type": "#StorageControllerCollection.StorageControllerCollection",
   "Name": "Storage Controller Collection",
   "Description": "Storage Controller Collection",
   "Members@odata.count": 1,
   "Members": [
       {
           "@odata.id": "/redfish/v1/Systems/Sys-1/Storage/SimplestNVMeSSD/Controllers/NVMeIOController"
       }
   ],
   "@odata.id": "/redfish/v1/Systems/Sys-1/Storage/SimplestNVMeSSD/Controllers",
   "@Redfish.Copyright": "Copyright 2015-2023 SNIA. All rights reserved."
   }

3. Call the FirmwareUpdate service

   Request:

   POST /redfish/v1/Systems/Sys-1/Storage/SimplestNVMeSSD/Controllers/NVMeIOController/Actions/UpdateService.SimpleUpdate 

   • Headers: Content-type : application/json

   • Body: json { "ImageURI": "https://localhost/redfish/v1/UpdateService/FirmwareInventory/Installed-0-20.06.05.11__SSD.1-2-1", "@Redfish.OperationApplyTime": "OnTargetReset" }

   Response:

   • HTTP Status: 202 (Accepted)

   • Headers: Content-type : application/json Location: /redfish/v1/TaskService/TaskMonitors/1792

   • Body

     {
     "@odata.id": "/redfish/v1/TaskService/Tasks/1792",
     "@odata.type": "#Task.v1_5_0.Task",
     "Id": "1792",
     "Name": "Task 1792",
     "TaskState": "Running",
     "StartTime": "2023-06-03T14:44+06:00",
     "TargetUri": "/redfish/v1/UpdateService/Actions/SimpleUpdate",
     "TaskMonitor": "/redfish/v1/TaskService/TaskMonitors/1792",
     "TaskStatus": "OK",
     "Messages": [
       {
       "@odata.type": "#Message.v1_1_1.Message",
       "MessageId": "Update.1.0.AwaitToActivate",
       "Message": "Awaiting for an action to proceed with activating image 'Installed-0-20.06.05.11__SSD.1-2-1' on '/redfish/v1/Systems/Sys-1/Storage/SimplestNVMeSSD/Controllers/NVMeIOController'.",
       "Severity": "OK",
       "MessageSeverity": "OK",
       "Resolution": "None"
       },
     ],
     "Resolution": "None"
     }

4. Monitor the task, and task await completion or the transition to the JobService Since the installation of a new firmware image may be tied to device specific events or conditions (i.e., the image should be applied at the next device reset, or within a specific maintenance window), the stateless task may well be converted to a stateful Job.

   Request:

   GET /redfish/v1/TaskService/TaskMonitors/1792

   • Headers: Content-type : application/json

   • Body: None.

   Response:

   • HTTP Status: 200 (Success)

   • Headers: Content-type : application/json

   • Body

   {
   "error": {
      "code": "Update.1.0.OperationTransitionedToJob",
      "message": "The update operation has transitioned to the job at URI ...",
      "@Message.ExtendedInfo": [
         {
         "@odata.type": "#Message.v1_1_1.Message",
         "MessageId": "Update.1.0.OperationTransitionedToJob",
         "Message": "The update operation has transitioned to the job at URI ...",
         "Severity": "OK",
         "MessageSeverity": "OK",
         "MessageArgs": [
            "/redfish/v1/JobService/Jobs/1824"
         ],
         "Resolution": "None"
         }
         ]
      }
   }

5. Monitor the job, and await completion or the need for user intervention

   Request:

   GET /redfish/v1/JobService/Jobs/1824

   • Headers: Content-type : application/json

   • Body: None.

   Response:

   • HTTP Status: 200 (Success)

   • Headers: Content-type : application/json

   • Body

   {
   "@odata.id": "/redfish/v1/JobService/Jobs/1824",
   "@odata.type": "#Job.v1_0_5.Job",
   "Id": "1824",
   "Name": "Job 1824",
   "JobStatus": "OK",
   "JobState": "UserIntervention",
   "StartTime": "2020-10-15T14:44+06:00",
   "PercentComplete": 85,
   "CreatedBy": "admin",
   "Payload": {
      "TargetUri": "/redfish/v1/UpdateService/SimpleUpdate",
      },
   "Steps": {
      "@odata.id": "/redfish/v1/JobService/Jobs/1824/Steps"
      },
   "Messages": [
      {
      "@odata.type": "#Message.v1_1_1.Message",
      "MessageId": "Update.1.0.UpdateInProgress",
      "Message": "An update is in progress.",
      "Severity": "OK",
      "MessageSeverity": "OK",
      "Resolution": "None"
      },
      {
      "@odata.type": "#Message.v1_1_1.Message",
      "MessageId": "Update.1.0.TargetDetermined",
      "Message": "The target device 'NVMeIOController' will be updated with image ...",
      "Severity": "OK",
      "MessageSeverity": "OK",
      "MessageArgs": [
         "NVMeIOController",
         "Installed-0-20.06.05.11__SSD.1-2-1"
      ],
      "Resolution": "None"
      },
      {
      "@odata.type": "#Message.v1_1_1.Message",
      "MessageId": "Update.1.0.AwaitToActivate",
      "Message": "Awaiting for an action to proceed with activating image ...",
      "Severity": "OK",
      "MessageSeverity": "OK",
      "MessageArgs": [
         "NVMeIOController"
      ],
      "Resolution": "Perform the requested action to advance the update operation."
      },
      {
      "@odata.type": "#Message.v1_1_1.Message",
      "MessageId": "Base.1.10.ResetRequired",
      "Message": "In order to complete the operation, a component reset is required ...",
      "Severity": "Warning",
      "MessageSeverity": "Warning",
      "MessageArgs": [
         "/redfish/v1/Systems/1/Actions/ComputerSystem.Reset",
         "GracefulRestart"
         ],
      "Resolution": "Perform the required reset action on the specified component."
      }
      ]
    }

   Request:

   GET /redfish/v1/JobService/Jobs/1824/JobState

   • Headers: Content-type : application/json

   • Body:

   {
   "JobState": "Completed"
   }

Postconditions: The identified controller(s) are now using the select firmware image.

Failure Scenario: See https://www.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.1.pdf for a detailed discussion of task management and the proper parsing of error conditions during an update operation.

See also: None defined.

7.1.3. Attach a Namespace

Summary: Attach a Namespace

Purpose: Provide visibility to a namespace by attaching it to an IO Controller.

Who: StorageAdmin; CloudAdmin

Management Domain: Block storage management

Triggers: None defined.

Detailed Context: Attach a Namespace to an IO Controller to make it visible to the hosts that connect to that IO Conttoller, and accessible for block storage operations.

Preconditions: The IO Controller and Namespaces need to exist, and be fully defined.

Feature(s): NMVe

Inputs:

• URL for Namespace.

Basic Course of Events:

1. PATCH the AttachedVolumes array in the IO Controller with the Namespace.

Request:

PATCH /redfish/v1/Systems/Sys-1/Storage/SimplestNVMeSSD/
    Controllers/NVMeIOController/

• Headers: Content-type : application/json

• Body:

  {
    "Links": {
      "AttachedVolumes": [
        {
          "@odata.id": "/redfish/v1/Systems/Sys-1/Storage/SimplestNVMeSSD/Volumes/SimpleNamespace"
        }
      ]
    }
  }

Response:

• HTTP Status: 200 (Success)

• Headers: Content-type : application/json

• Body

  {
  "@Redfish.Copyright": "Copyright 2015-2021 SNIA. All rights reserved.",
  "@odata.id": "/redfish/v1/Systems/Sys-1/Storage/SimplestNVMeSSD/Controllers/NVMeIOController",
  "@odata.type": "#StorageController.v1_1_0.StorageController",
  "Id": "NVMeIOController",
  "Name": "NVMe I/O Controller",
  "Description": "An NVM IO controller is a general-purpose controller that provides access to logical block data and metadata stored on an NVM subsystem’s non-volatile storage medium. IO Controllers may also support management capabilities.",
  "Status": {
      "State": "Enabled",
      "Health": "OK"
  },
  "Manufacturer": "Best NVMe Vendor",
  "Model": "Simple NVMe Device",
  "SerialNumber": "NVME123456",
  "PartNumber": "NVM44",
  "FirmwareVersion": "1.0.0",
  "SupportedControllerProtocols": [
      "PCIe"
  ],
  "SupportedDeviceProtocols": [
      "NVMe"
  ],
  "NVMeControllerProperties": {
      "NVMeVersion": "1.3",
      "NVMeControllerAttributes": {
          "ReportsUUIDList": false,
          "SupportsSQAssociations": false,
          "ReportsNamespaceGranularity": false,
          "SupportsTrafficBasedKeepAlive": false,
          "SupportsPredictableLatencyMode": false,
          "SupportsEnduranceGroups": false,
          "SupportsReadRecoveryLevels": false,
          "SupportsNVMSets": false,
          "SupportsExceedingPowerOfNonOperationalState": false,
          "Supports128BitHostId": false
      }
  },
  "Links": {
      "AttachedVolumes": [
          {
              "@odata.id": "/redfish/v1/Systems/Sys-1/Storage/SimplestNVMeSSD/Volumes/SimpleNamespace"
          }
      ]
  }
  }

Postconditions: The Namespace has been configured as an AttachedVolume to the IO Controller. This means that the Namespace is visible to hosts connected to the IO Controller.

Failure Scenario: None defined.

See also: None defined.

7.1.4. Can a new Namespace be created?

Summary: Confirm that a new Namespace can be created.

Purpose: Check VolumeCollection settings before attempting to create a new entry.

Who: CloudAdmin, StorageAdmin, DevOps

Management Domain: Block storage management

Triggers: Need to create a new Namespace.

Detailed Context: Before attempting to create a new Namespace, the users wants to confirm that creation is allowed against a given StoragePool. The Allow header returned for the VolumeCollection will indicate whether Namespace creation is permitted or not.

Preconditions: None.

Feature(s): Block provisioning

Inputs:

• URL for Volumes collection: /redfish/v1/Storage/1/Volumes

Basic Course of Events:

1. Request the header information of the Volumes resource collection. > Note: This example use the HTTP verb HEAD, though a request using GET would also return the required headers.

Request:

HEAD /redfish/v1/Storage/1/Volumes

• Headers: No additional headers required.

• Body: None.

Response: Response contains the header.

• HTTP Status: 200 (OK)

• Headers: Allow : GET, POST, HEAD

• Body: None.

Postconditions: None defined.

Failure Scenario: None defined

See also: Can a new Volume be created?

7.1.5. Can a new Namespace be created?

Summary: Confirm that a new Namespace can be created.

Purpose: Check VolumeCollection settings before attempting to create a new entry.

Who: StorageAdmin CloudAdmin

Management Domain: Block storage management

Triggers: Need to create a new Namespace.

Detailed Context: Before attempting to create a new Namespace, the users wants to confirm that creation is allowed against a given StoragePool. The Allow header returned for the VolumeCollection will indicate whether Namespace creation is permitted or not.

Preconditions: None.

Feature(s): NVMe

Inputs:

• URL for Volumes collection: /redfish/v1/Storage/1/Volumes

Basic Course of Events:

1. Request the header information of the Volumes resource collection. > Note: This example use the HTTP verb HEAD, though a request using GET would also return the required headers.

Request:

HEAD /redfish/v1/Storage/1/Volumes

• Headers: No additional headers required.

• Body: None.

Response: Response contains the header.

• HTTP Status: 200 (OK)

• Headers: Allow : GET, POST, HEAD

• Body: None.

Postconditions: None defined.

Failure Scenario: None defined

See also: Can a new Volume be created?

7.1.6. Can a new Volume be created?

Summary: Confirm that a new Volume can be created.

Purpose: Check VolumeCollection settings before attempting to create a new Volume.

Who: CloudAdmin, StorageAdmin, DevOps

Management Domain: Block storage management

Triggers: Need to create a new Volumes.

Detailed Context: Before attempting to create a new Volume, the users wants to confirm that creation is allowed against a given StoragePool. The Allow header returned for the VolumeCollection will indicate whether Volume creation is permitted or not.

Preconditions: None.

Feature(s): Block provisioning

Inputs:

• URL for Volumes collection: /redfish/v1/Storage/1/Volumes

Basic Course of Events:

1. Request the header information of the Volumes resource collection. > Note: This example use the HTTP verb HEAD, though a request using GET would also return the required headers.

Request:

HEAD /redfish/v1/Storage/1/Volumes

• Headers: No additional headers required.

• Body: None.

Response: Response contains the header.

• HTTP Status: 200 (OK)

• Headers: Allow : GET, POST, HEAD

• Body: None.

Postconditions: None defined.

Failure Scenario: None defined

See also: Can a new Namespace be created?

7.1.7. Change only the RAID Type of an Existing Volume

Summary: Change only the RAID type of an existing Volume

Purpose: Change the RAID type of an existing Volume to meet new protection requirements, without a change to the underlying Drives collection.

Who: StorageAdmin

Management Domain: Block storage management

Triggers: Change the RAID protection level of a Volume; this could be performance, capacity or application triggered.

Detailed Context: The storage admin needs to alter the underlying RAID layout for an existing Volume.

Preconditions: Volume already exists, and employs drives sufficient to satisfy the requested RAID geometry.

Feature(s): Block provisioning

Inputs:

• URL for Volume: /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1

Basic Course of Events:

1. Use the ChangeRAIDLayout Action on the Volume, passing the requested RAIDType as input.

   Request:

   POST /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1/Actions
   /ChangeRAIDLayout

   • Headers: Content-type: application/json

   • Body:

   {
   "RAIDType" : "RAID5"
   }

   Response: Response is dependent on implementation’s capability.

   Case 1: If the implementation is able to return immediately:

   • HTTP Status: 204 (No Content)

   • Headers:

   Location :
       /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1

   • Body: None.

     A GET on volume will show the updated RAIDType.

     Request:

     GET /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1

     Response:

     • HTTP Status: 200 (OK)

     • Headers: Location : /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1 Content-type: application/json ETag: "FD87EC46239"

     • Body:

      {
      "@SSM.Copyright": "Copyright (c) 2014-2024 SNIA. All rights reserved.",
      "@odata.context": "/redfish/v1/$metadata#Volume.Volume",
      "@odata.id": "/redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1",
      "@odata.type": "#Volume_1_6_0.Volume",
      "Name": "MyVolume",
      "Id": "1",
      "Description": "Default Volume Description",
      "RAIDType": "RAID5",
      "Identifiers": [
        {
          "DurableNameFormat": "NAA",
          "DurableName": "65456765456761001234076100123487"
        }
      ],
      "Status": {
        "State": "Enabled",
        "Health": "OK"
      },
      "CapacityBytes": 1099511627776,
      "Links": {
          "StoragePool": "/redfish/v1/Storage/1/StoragePools/1"
      }
      }

   Case 2: If the implementation requires a background task (using the Redfish task service) to return status:

   • HTTP Status: 202 (Accepted)

   • Headers: Location : /redfish/v1/TaskService/Tasks/TaskID2 ETag: "FD87EC46239"

   • Body: None.

     A GET on volume while task is pending will indicate the in-process change to RAIDType, and that the transition to the new RAID layout is not complete, using Status.State and Status.Health:

     Request: GET /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1

     Response:

     • HTTP Status: 200 (OK)

     • Headers: Location : /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1 Content-type: application/json ETag: "FD87EC46239"

     • Body:

         {
         "@SSM.Copyright": "Copyright (c) 2014-2024 SNIA. All rights reserved.",
         "@odata.context": "/redfish/v1/$metadata#Volume.Volume",
         "@odata.id": "/redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1",
         "@odata.type": "#Volume_1_6_0.Volume",
         "Name": "MyVolume",
         "Id": "1",
         "Description": "Default Volume Description",
         "RAIDType": "RAID5",
         "Identifiers": [
         {
         "DurableNameFormat": "NAA",
         "DurableName": "65456765456761001234076100123487"
         }
         ],
         "Status": {
         "State": "Updating",
         "Health": "Warning"
         },
         "CapacityBytes": 1099511627776,
         "Links": {
         "StoragePool": "/redfish/v1/Storage/1/StoragePools/PrimaryPool"
         }
         }

     A subsequent GET on the Volume, once the task has completed, will reflect the new values:

     Request:

     GET /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1

     Response:

     • HTTP Status: 200 (OK)

     • Headers:

     Location : /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1 Content-type: application/json ETag: FD87EC46781

     • Body:

         {
         "@SSM.Copyright": "Copyright (c) 2014-2024 SNIA. All rights reserved.",
         "@odata.context": "/redfish/v1/$metadata#Volume.Volume",
         "@odata.id": "/redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1",
         "@odata.type": "#Volume_1_6_0.Volume",
         "Name": "MyVolume",
         "Id": "1",
         "Description": "Default Volume Description",
         "RAIDType": "RAID5",
         "Identifiers": [
           {
             "DurableNameFormat": "NAA",
             "DurableName": "65456765456761001234076100123487"
           }
         ],
         "Status": {
           "State": "Enabled",
           "Health": "OK"
         },
         "CapacityBytes": 1099511627776,
         "Links": {
             "StoragePool": "/redfish/v1/Storage/1/StoragePools/PrimaryPool"
         }
      }

Postconditions: None defined.

Failure Scenario: If the system is unable to complete the requrested change to the RAID layout for some reason (e.g., insufficient Drives in the underlying StoragePool to support the requested RAID type), the initial POST will result in an error. For example:

1. Use the ChangeRAIDLayout Action on the Volume, passing the requested RAIDType as input, as in the initial scenario.

   Request:

   POST /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1/
      Actions/ChangeRAIDLayout

   • Headers: Content-type : application/json

   • Body:

   {
   "RAIDType" : "RAID5"
   }

Response:

• HTTP Status: 400 (Bad Request)

• Headers:

Content-type: application/json

• Body:

   {
     "error": {
       "code": "Base.1.6.ActionParameterMissing",
       "message": "The action ChangeRAIDLayout requires the parameter Drives to be present in the request body.",
       "@Message.ExtendedInfo" : [
          {
            "MessageId" : "Base.1.6.ActionParameterMissing",
            "Message" : "The Drives paramter must be included in this request",
            "RelatedProperties" : "Drives"
          }
       ]
     }
   }

See also: None defined.

Change only the span count of an existing volume

Summary: Change only the span count of an existing Volume

Purpose: Change the span count RAID type of an existing Volume, without a change to the underlying Drives collection.

Who: StorageAdmin

Management Domain: Block storage management

Triggers: Change the span count of a Volume; this could be performance, capacity or application triggered.

Detailed Context: The storage admin needs to alter the underlying RAID layout for an existing Volume.

Preconditions: Volume already exists, and employs drives sufficient to satisfy the requested RAID geometry.

Feature(s): Block provisioning

Inputs:

• URL for Volume: /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1

Basic Course of Events:

1. Use the ChangeRAIDLayout Action on the Volume, passing the requested MediaSpanCount as input.

Request:

   POST /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1/
      Actions/ChangeRAIDLayout

• Headers: Content-type : application/json

• Body:

  {
  "MediaSpanCount" : 10
  }

Response:

Response is dependent on implementation’s capability.

If the implementation is able to return immediately:

• HTTP Status: 204 (No Content)

  • Headers:

    Location : /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1

  • Body: None.

  A GET on volume will show the updated RAIDType.

  Request:

  `GET /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1`

  • Response: 200 (OK)

  • Headers:

  Location : /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1 Content-type : application/json ETag: FD87EC46781

  • Body:

  
   {
   "@SSM.Copyright": "Copyright (c) 2014-2024 SNIA. All rights reserved.",
   "@odata.context": "/redfish/v1/$metadata#Volume.Volume",
   "@odata.id": "/redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1",
   "@odata.type": "#Volume_1_6_0.Volume",
   "Name": "MyVolume",
   "Id": "1",
   "Description": "Default Volume Description",
   "RAIDType": "RAID50",
   "MediaSpanCount": 10,
   "Identifiers": [
     {
       "DurableNameFormat": "NAA",
       "DurableName": "65456765456761001234076100123487"
     }
   ],
   "Status": {
     "State": "Enabled",
     "Health": "OK"
   },
   "CapacityBytes": 1099511627776,
   "Links": {
       "StoragePool": "/redfish/v1/Storage/1/StoragePools/PrimaryPool"
   }
  }

  If the implementation requires a background task (using the Redfish task service) to return status:

  Response:

  • HTTP Status: 202 (Accepted)

  • Headers:

    Location : /redfish/v1/TaskService/Tasks/TaskID2

  • Body: None.

  A GET on volume while task is pending will indicate the in-process change to RAIDType, and that the transition to the new RAID layout is not complete, using Status.State and Status.Health:

  Request:

   `GET /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1`

  Response:

  • HTTP Status: 200 (OK)

  • Headers: Location : /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1 Content-type : application/json ETag: FD87EC46781

  • Body:

    {
    "@SSM.Copyright": "Copyright (c) 2014-2024 SNIA. All rights reserved.",
    "@odata.context": "/redfish/v1/$metadata#Volume.Volume",
    "@odata.id": "/redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1",
    "@odata.type": "#Volume_1_6_0.Volume",
    "Name": "MyVolume",
    "Id": "1",
    "Description": "Default Volume Description",
    "RAIDType": "RAID50",
    "MediaSpanCount": 10,
    "Identifiers": [
    {
    "DurableNameFormat": "NAA",
    "DurableName": "65456765456761001234076100123487"
    }
    ],
    "Status": {
    "State": "Updating",
    "Health": "Warning"
    },
    "CapacityBytes": 1099511627776,
    "Links": {
    "StoragePool": "/redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1"
    }
    }

  A subsequent GET on the Volume, once the task has completed, will reflect the new values:

  Request:

  `GET /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1`

  Response:

  • HTTP Status: 200 (OK)

  • Headers: Location : /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1 Content-type : application/json ETag: FD87EC469AE

  • Body:

  
      {
      "@SSM.Copyright": "Copyright (c) 2014-2024 SNIA. All rights reserved.",
      "@odata.context": "/redfish/v1/$metadata#Volume.Volume",
      "@odata.id": "/redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1",
      "@odata.type": "#Volume_1_6_0.Volume",
      "Name": "MyVolume",
      "Id": "1",
      "Description": "Default Volume Description",
      "RAIDType": "RAID50",
      "MediaSpanCount": 10,
      "Identifiers": [
        {
          "DurableNameFormat": "NAA",
          "DurableName": "65456765456761001234076100123487"
        }
      ],
      "Status": {
        "State": "Enabled",
        "Health": "OK"
      },
      "CapacityBytes": 1099511627776,
      "Links": {
          "StoragePool": "/redfish/v1/Storage/1/StoragePools/PrimaryPool"
      }
   }

Postconditions: None defined.

Failure Scenario: If the system is unable to complete the requested change to the RAID layout for some reason (e.g., insufficient Drives in the underlying StoragePool to support the requested MediaSpanCount), the initial POST will result in an error. For example:

1. Use the ChangeRAIDLayout Action on the Volume, passing the requested MediaSpanCount as input, as in the initial scenario.

   Request:

   POST /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1/
      Actions/ChangeRAIDLayout

   • Headers: Content-type : application/json

   • Body:

   {
   "MediaSpanCount": 10
   }

Response:

• HTTP Status: 400 (Bad Request)

• Headers: Content-type : application/json

• Body:

  {
    "error": {
      "code": "Base.1.6.ActionParameterMissing",
      "message": "The action ChangeRAIDLayout requires the parameter Drives to be present in the request body.",
      "@Message.ExtendedInfo" : [
         "MessageId": "Base.1.6.ActionParameterMissing",
         "Message" : "The Drives paramter must be included in this request",
         "RelatedProperties" : "Drives"
      ]
    }
  }

See also: None defined.

Confirm valid LBA formats

Summary: Confirm valid LBA formats

Purpose: Verify that a given LBA format is supported by a Volume collection.

Who: StorageAdmin CloudAdmin

Management Domain: Block storage management

Triggers: None defined.

Detailed Context: Querying the CollectionCapabilities object defined within the Controllers collection, allows a user to confirm that a particulary LBA format is supported, even if the collection itself is empty due to the ephemeral nature of NVMe Controllers.

Preconditions: None defined.

Feature(s): NVMe

Inputs:

• URL for Controller collection: /redfish/v1/Systems/Sys-1/Storage/NVMeSSD-EG/Controllers

Basic Course of Events:

1. Get the ControllerCollection and find the CapabilitiesObject property within the returned JSON data:

Request:

GET /redfish/v1/Systems/Sys-1/Storage/NVMeSSD-EG/Controllers

• Headers: No additional headers required.

• Body: None.

Response:

• HTTP Status: 200 (OK)

• Headers:

  • Content-type : application/json
  • ETag : "97AED48652"

• Body:

{
  "@odata.type": "#StorageControllerCollection.StorageControllerCollection",
  "Name": "Storage Controller Collection",
  "Description": "Storage Controller Collection",
  "Members@odata.count": 0,
  "Members": [],
  "@Redfish.CollectionCapabilities": {
    "@odata.type": "#CollectionCapabilities.v1_3_0.CollectionCapabilities",
    "Capabilities": [{
      "CapabilitiesObject": {
        "@odata.id": "/redfish/v1/Systems/Sys-1/Storage/NVMeSSD-EG/Volumes/Capabilities"
      },
      "Links": {
        "TargetCollection": {
          "@odata.id": "/redfish/v1/Systems/Sys-1/Storage/NVMeSSD-EG/Controllers"
        }
      }
    }]
  },
  "@odata.id": "/redfish/v1/Systems/Sys-1/Storage/NVMeSSD-EG/Controllers",
  "@Redfish.Copyright": "Copyright 2022 SNIA. All rights reserved."
}

2. Get the CollectionCapabilities, and confirm that the desired LBA format is included in the collection of supported formats.

Request:

GET /redfish/v1/Systems/Sys-1/Storage/NVMeSSD-EG/Volumes/Capabilities

• Headers: No additional headers required.

• Body: None.

Response:

• HTTP Status: 200 (OK)

• Headers:

  • Content-type : application/json
  • ETag : "1AB7994D"

• Body:

  {
  "@odata.type": "#Volume.v1_9_0.Volume",
  "Id": "Capabilities",
  "Name": "Capabilities for the Volume",
  "Name@Redfish.RequiredOnCreate": true,
  "Name@Redfish.SetOnlyOnCreate": true,
  "Description@Redfish.OptionalOnCreate": true,
  "Description@Redfish.SetOnlyOnCreate": true,

  "NVMeNamespaceProperties": {
      "LBAFormatsSupported@Redfish.AllowableValues": [
          "LBAFormat0",
          "LBAFormat1",
      ],
      "LBAFormats": [
          {
              "LBAFormatType": "LBAFormat0",
              "RelativePerformance": "Best",
              "LBADataSizeBytes": 4096,
              "LBAMetadataSizeBytes": 0
          },
          {
              "LBAFormatType": "LBAFormat1",
              "RelativePerformance": "Good",
              "LBADataSizeBytes": 512,
              "LBAMetadataSizeBytes": 0
          }
      ]
  },

  "@odata.id": "/redfish/v1/Systems/Sys-1/Storage/NVMeSSD-EG/Volumes/Capabilities",
  "@Redfish.Copyright": "Copyright 2022 SNIA. All rights reserved."
}

Postconditions: None.

Failure Scenario: None defined.

See also: None defined.

Create a new connection to an existing volume

Summary: Create a new connection to an existing Volume, using a pre-existing Endpoint to grant read/write access to the Volume.

Purpose: Use existing Endpoints to provide a new access path to an existing volume.

Who: StorageAdmin, CloudAdmin

Management Domain: Block storage management

Triggers: None defined.

Detailed Context: Create a new connection to an existing Volume, to allow it to be accessed from a given host by way of the selected Endpoints.

Preconditions: User has already identified the Endpoints that will be used for the new Connection.

Feature(s): Access Management

Inputs:

• Name for new connection: “Connection info for host 1”

• Volume Id: “/redfish/v1/Storage/IPAttachedDrive1/Volumes/SimpleNamespace”

• Initiator endpoint: /redfish/v1/Fabrics/NVMeoF/Endpoints/Initiator1

• Target endpoint: /redfish/v1/Fabrics/NVMeoF/Endpoints/D1-E1

• Volume access information:

        {
            "AccessCapabilities": [
                "Read",
                "Write"
            ],
            "Volume": {
                "@odata.id": "/redfish/v1/Storage/IPAttachedDrive1/Volumes/SimpleNamespace"
            }
        }

Basic Course of Events:

1. Create the new Connection

   Request:

   POST /redfish/v1/Fabrics/NVMeoF/Connections

   • Headers: Content-type : application/json

   • Body:

   {
       "Name": "Connection info for host 1",
       "VolumeInfo": [
           {
           "AccessCapabilities": [
               "Read",
               "Write"
               ],
           "Volume": {
               "@odata.id": "/redfish/v1/Storage/IPAttachedDrive1/Volumes/SimpleNamespace"
               }
           },
       ],
       "Links": {
           "InitiatorEndpoints": [
               {
               "@odata.id": "/redfish/v1/Fabrics/NVMeoF/Endpoints/Initiator1"
               }
           ],
           "TargetEndpoints": [
               {
               "@odata.id": "/redfish/v1/Fabrics/NVMeoF/Endpoints/D1-E1"
               }
           ]
       }
   }

   Response:

   • HTTP Status: 201 (Created)

   • Headers:

     Content-type: application/json

     Location: /redfish/v1/Fabrics/NVMeoF/Connections/1

   • Body:

       {
      "Name": "Connection info for host 1",
      "VolumeInfo": [
           {
               "AccessCapabilities": [
                   "Read",
                   "Write"
                   ],
               "Volume": {
                   "@odata.id": "/redfish/v1/Storage/IPAttachedDrive1/Volumes/SimpleNamespace"
                   }
           },
       ],
       "Links": {
               "InitiatorEndpoints": [
                   {
                       "@odata.id": "/redfish/v1/Fabrics/NVMeoF/Endpoints/Initiator1"
                   }
               ],
               "TargetEndpoints": [
                   {
                       "@odata.id": "/redfish/v1/Fabrics/NVMeoF/Endpoints/D1-E1"
                   }
               ]
           }
       }

Postconditions: None defined.

Failure Scenario: None defined

See also: None defined.

Create a new endpoint group

Summary: Create a new EndpointGroup, using a pre-existing Endpoints.

Purpose: Create an EndpointGroup to simplify future management of a group of existing Endpoints.

Who: StorageAdmin CloudAdmin

Management Domain: Block storage management

Triggers: None defined.

Detailed Context: Grouping a set of existing Endpoints into a single EndpointGroup simplifies access management by allowing multiple Endpoints to be managed with a single API request.

Preconditions: User has already identified the Endpoints that will included in the new EndpointGroup.

Feature(s): Access Management

Inputs:

• A set of pre-existing Endpoints:

```
    [
        {
            "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint1"
        },
        {
            "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint2"
        },
        {
            "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint3"
        },
        {
            "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint4"
        }
    ]
```

• Name of new EndpointGroup: “TargetEndpoints”

• Type of Endpoints in new EndpointGroup: “Target”

Basic Course of Events:

1. Create the new EndpointGroup

   Request:

   POST /redfish/v1/Storage/MidrangeStorageSystem/EndpointGroups

   • Headers: Content-type : application/json

   • Body:

       {
      "Name": "TargetEndpoints"
      "GroupType": "Target"
      "Endpoints": [
       {
           "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint1"
       },
       {
           "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint2"
       },
       {
           "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint3"
       },
       {
           "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint4"
       }
      ]

   Response:

   • HTTP Status: 201 (Created)

   • Headers:

     Content-type: application/json

     Location: /redfish/v1/Storage/MidrangeStorageSystem/EndpointGroups/TargetEndpoints

   • Body:

       {
           "@odata.type": "#EndpointGroup.v1_2_0.EndpointGroup",
           "Name": "TargetEndpoints"
           "Id": "TargetEndpoints"
           "Description": "Group of target endpoints for the midrange storage system",
           "AccessState": "Optimized",
           "TargetEndpointGroupIdentifier": 3,
           "GroupType": "Server",
           "Endpoints": [
           {
               "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint1"
           },
           {
               "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint2"
           },
           {
               "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint3"
           },
           {
               "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/TargetEndpoint4"
           }
           ],
           "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/EndpointGroups/TargetEndpoints",
           "@Redfish.Copyright": "Copyright 2015-2024 SNIA. All rights reserved."
       }

Postconditions: None defined.

Failure Scenario: None defined

See also: None defined.

Create a new endpoint

Summary: Create a new Endpoint.

Purpose: Create an Endpoint to direct access to a system’s resources to a particular interface and protocol.

Who: StorageAdmin, CloudAdmin

Management Domain: Block storage management

Triggers: None defined.

Detailed Context: Create an Endpoint to direct access to a system’s resources to a particular interface and protocol.

Preconditions: None.

Feature(s): Access Management

Inputs:

• Endpoint role: “Initiator”
• Supported protocol: “iSCSI”,
• Related transport details: json { "IPv4Address": { "Address": "192.168.1.63" } }

Basic Course of Events:

1. Create the new Endpoint

   Request:

   POST /redfish/v1/Storage/MidrangeStorageSystem/Endpoints

   • Headers: Content-type : application/json

   • Body:

     {
     "Name": "InitiatorEndpoint1"
     "EntityRole": "Initiator"
     "EndpointProtocol": "iSCSI"
     "IPTransportDetails": 
     {
         "IPv4Address": {
         "Address": "192.168.1.63"
         }
     }
     }

   Response:

   • HTTP Status: 201 (Created)

   • Headers:

     Content-type: application/json

     Location: /redfish/v1/Storage/MidrangeStorageSystem/EndpointGroups/TargetEndpoints

   • Body:

   {
       "@odata.type": "#Endpoint.v1_7_0.Endpoint",
       "Id": "InitiatorEndpoint1",
       "Name": "InitiatorEndpoint1",
       "Description": "iSCSI target Endpoint 1",
       "Identifiers": [
           {
               "DurableName": "4289a3dd-ba52-41b8-9d3d-38de196e059c",
               "DurableNameFormat": "UUID"
           }
       ],
       "ConnectedEntities": [
       ],
       "EndpointProtocol": "iSCSI",
       "IPTransportDetails": [
           {
               "IPv4Address": {
                   "Address": "192.168.1.63"
               }
           }
       ],
       "Status": {
           "State": "Enabled",
           "Health": "OK"
       },
       "@odata.id": "/redfish/v1/Storage/MidrangeStorageSystem/Endpoints/InitiatorEndpoint1",
       "@Redfish.Copyright": "Copyright 2015-2024 SNIA. All rights reserved."
   }

Postconditions: None defined.

Failure Scenario: None defined

See also: None defined.

Create a New Replication Relationship by Assigning a Target Volume

Summary: Establish a replication relationship by assigning an existing volume to serve as a target replica for an existing source volume.

Purpose: Leverage an existing volume resource to provide expanded data protection through a replica relationship with the specified source volume.

Who: StorageAdmin, DevOps

Management Domain: Block storage management

Triggers: Need to provide expanded data protection through a replica relationship with the specified source volume.

Detailed Context: The admin needs to provide expanded data protection for the specified source volume, and the configuration includes pre-existing volume that can be repurposed as a replication target.

Preconditions: User has already identified an existing volume to use for the target replica (including the target system and storage pool properties), the type of replica, and the replica update mode (sync vs async).

Feature(s): Replication (both local and remote)

Inputs:

• URL for target volume: /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/650973452245

• Requested replica type: Mirror

• ReplicaUpdateMode: Synchronous

Basic Course of Events:

1. Post (as an Action) the request on the source Volume.

This instructs the service to use the identified Volume as the source Volume for the specified replication relationship. For any additional details required, the service will rely on default values.

Request:

POST /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1/
      Volume.AssignReplicaTarget

• Headers: Content-type : application/json

• Body:

{
 "ReplicaUpdateMode": "Synchronous",
 "TargetVolume": "/redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/650973452245",
 "ReplicaType": "Mirror"
 }

Response:

• HTTP Status: 204 (No Content)

• Headers: Location : /redfish/v1/Storage/1/StoragePools/PrimaryPool/AllocatedVolumes/1

• Body: None.

Postconditions: The selected volume has an updated ReplicaTargets entry for the new relationship. Elsewhere, there is a volume “650973452245” in the system that has a ReplicaInfo which points back to this volume and which contains all of the Replica configuration information.

Failure Scenario: None defined

See also: Assign Replica Target (CG).

Create a New Replication Relationship by Assigning an existing Target Consistency Group

Summary: Establish a replication relationship by assigning an existing consistency group to serve as the target in the replication relationship for an existing consistency group.

Purpose: Leverage an existing consistency group resource to provide expanded data protection by creating a replication relationship with the specified source consistency group.

Who: StorageAdmin, DevOps

Management Domain: Block storage management

Triggers: Need to provide expanded data protection through a replica relationship with the specified source consistency group.

Detailed Context: The admin needs to provide expanded data protection for the specified source consistency group, and the configuration includes a pre-existing consistency group that can be repurposed as the replication target.

Preconditions: User has already identified an existing consistency group to use for the target replicas (including the target system and storage pool properties), the type of replica(s), and the replica update mode (sync vs async).

Feature(s): Replication (both local and remote)

Inputs:

• URL for target volume: /redfish/v1/Storage/1/ConsistencyGroup/CG_DB2

• Requested replica type: Mirror

• ReplicaUpdateMode: Synchronous

Basic Course of Events:

1. Post (as an Action) the request on the source ConsistencyGroup.

   This instructs the service to use the identified ConsistencyGroup as the source ConsistencyGroup for the specified replication relationship. For any additional details required, the service will rely on default values.

Request:

POST
   /redfish/v1/Storage/1/ConsistencyGroup/CG_DB1/
      ConsistencyGroup.AssignReplicaTarget

• Headers: Content-type : application/json

• Body:

    {
     "ReplicaUpdateMode": "Synchronous",
     "TargetConsistencyGroup": "/redfish/v1/Storage/1/ConsistencyGroup/CG_DB2",
     "ReplicaType": "Mirror"
     }

Response:

• HTTP Status: 204 (No Content)

• Headers: Location : /redfish/v1/Storage/1/ConsistencyGroup/CG_DB1

• Body: None.

Postconditions: The selected ConsistencyGroup has an updated ReplicaTargets entry for the new relationship. Elsewhere, there is a ConsistencyGroup “CG_DB2” in the system that has a ReplicaInfo which points back to this ConsistencyGroup and which contains all of the Replica configuration information.

Failure Scenario: None defined

See also: Assign Replica Target.

7.1.8. Create an on-demand snapshot of a Volume

Summary: Create an on-demand snapshot of a volume

Purpose: Create a snapshot of an existing volume. The resulting snapshot can then be used either as a backup or as a separate copy to test against.

Who: CloudAdmin, StorageAdmin, DevOps

Management Domain: Block storage management

Triggers: Need an on-demand snapshot of a Volume

Detailed Context: To take a snapshot of a volume, we need to find a DataProtectionLineOfService that can describe the new Snapshot.

The DataProtectionLineOfService must have no schedule set to be able to provide on-demand behavior.

Preconditions: None.

Feature(s): Class of Service

Inputs:

• URL for storage service: /redfish/v1/StorageServices/1
• URL for the volume: /redfish/v1/StorageServices/1/StoragePools/BasePool/AllocatedVolumes/1

Basic Course of Events:

1. The first step is to get the current supported DataProtectionLineOfService entries, and find one that provides appropriate snapshot support (i.e., has no schedule set, and meets any other criteria the client may have).

Request:

GET /redfish/v1/StorageServices/1/Links/DataProtectionLoSCapabilities/
   SupportedLinesOfService

• Headers:
  No additional headers required.

• Body:
  None

Response:

• HTTP Status: 200 (Success)

• Headers:

  Content-type : application/json ETag : "97AED48652"

• Body:

  {  
      "SupportedLinesOfService": [  
          {   
              "@odata.id": "/redfish/v1/StorageServices/1/Links/DataProtectionLoSCapabilities/SupportedLinesOfService/OnDemandSnapshot",  
              "Name": "OnDemandSnapshot",  
              "RecoveryGeographicObjective": "Server",  
              "ReplicaType": "Snapshot",  
          }  
      ]  
  }

2. This looks like the right line of service for an on-demand snap. Note that since this is an on-demand snapshot, it has no schedule specified. So, let’s use this to create the snapshot. We’ll copy by value.

Request:

POST /redfish/v1/StorageServices/1/Links/DataProtectionLoSCapabilities/
      SupportedLinesOfService/OnDemandSnapshot.CreateReplicas

• Headers:

Content-type : application/json ETag : "97AED48652"

• Body:

  {
      "ReplicaRequests": [{
          "ReplicaSource": {"@odata.id": "/redfish/v1/StorageServices/1/StoragePools/BasePool/AllocatedVolumes/1"},
          "ReplicaName": "MySnapshot"
      }]
  }

Response:

• HTTP Status: 200 (Success)

• Headers:

  • Content-type : application/json
  • ETag : "97AED48881"

• Body:

    [ {  
        "ReplicaPriority": "Same",  
        "ReplicaReadOnlyAccess": "ReplicaElement",  
        "UndiscoveredElement": null,  
        "WhenSynced": "20171024T142000-00500",  
        "SyncMaintained": null,  
        "ReplicaRecoveryMode": null,  
        "ReplicaUpdateMode": "Synchronous",  
        "PercentSynced": 100,  
        "FailedCopyStopsHostIO": null,  
        "WhenActivated": "20171024T142000-00500",  
        "WhenDeactivated": null,  
        "WhenEstablished": "20171024T142000-00500",  
        "WhenSuspended": null,  
        "WhenSynchronized": null,  
        "ReplicaSkewBytes": null,  
        "ReplicaType": "Snapshot",  
        "ReplicaProgressStatus": "Completed",  
        "ReplicaState": "Synchronized",  
        "ConsistencyEnabled": false,  
        "ConsistencyType": null,  
        "ConsistencyState": null,  
        "ConsistencyStatus": null,  
        "ReplicaRole": "Target",  
        "Replica": {"odata.id": "/redfish/v1/StorageServices/1/StoragePools/BasePool/AllocatedVolumes/MySnapshot"},  
        "DataProtectionLineOfService": "/redfish/v1/StorageServices/1/Links/DataProtectionLoSCapabilities/SupportedLinesOfService/OnDemandSnapshot"}  
    ]      

Postconditions:
The original Volume (/redfish/v1/StorageServices/1/StoragePools/BasePool/AllocatedVolumes/1) now has a snapshot volume (/redfish/v1/StorageServices/1/StoragePools/BasePool/AllocatedVolumes/MySnapshot) that is available through its ReplicaTargets collection. All replication information (ReplicaInfo) is available on the snapshot (/redfish/v1/StorageServices/1/Volumes/MySnapshot) volume to describe the relationship.

Failure Scenario:
None defined.

See also:
None defined.

7.1.9. Create class of service

Summary: Create a class of service

Purpose: Create a new class of service in the service catalog to match a newly available type of storage

Who: StorageAdmin

Management Domain: Block storage management, Service catalog management

Triggers: The administrator has determined that a new class of service needs to be created to reflect a new class of SSD storage in the infrastructure.

Detailed Context: This is a simple scenario where the primary characteristic is the enhanced performance available from SSD drives.

Preconditions: None defined.

Feature(s): Class of Service

Inputs:

• URL for Storage Service: /redfish/v1/StorageServices(1)

• New class of service characteristics

  • Name: "SSD"

  • Description: "Minimal SSD class of service."

  • IOPerformanceLineOfService

    • “Name”: "SSDLoS"
    • “IOOperationsPerSecondIsLimited”: false
    • “MaxIOOperationsPerSecondPerTerabyte”: 100000
    • “AverageIOOperationLatencyMicroseconds”: 10

Basic Course of Events:

1. Create ClassOfService

   Request: POST /redfish/v1/StorageServices(1)/ClassesOfService/Members

   • Headers: Content-type : application/json

   • Body:

   {
     "Name": "SSD",
     "Description": "Minimal SSD class of service.",
     "LinesOfService": {
         "IOPerformanceLinesOfService": [ {
             "Name": "SSDLoS",
             "IOOperationsPerSecondIsLimited": false,
             "MaxIOOperationsPerSecondPerTerabyte": 100000,
             "AverageIOOperationLatencyMicroseconds": 10
       }]
     }
   }

   Response:

   • HTTP Status: 201 (Created)

   • Headers:

     Location : /redfish/v1/StorageServices(1)/ClassesOfService(SSD)

   • Body:

   {
   "@odata.type": "#ClassOfService.v1_2_0.ClassOfService",
   "Id": "SSD",
   "Name": "SSD",
   "Description": "Minimal SSD class of service.",
   "ClassOfServiceVersion": "01.20.00",
   "IOPerformanceLinesOfService": [
       {
             "IOOperationsPerSecondIsLimited": false,
             "MaxIOOperationsPerSecondPerTerabyte": 100000,
             "AverageIOOperationLatencyMicroseconds": 10
       }
   ],
   "@odata.id": "/redfish/v1/StorageServices/1/ClassesOfService/SSD",
   "@Redfish.Copyright": "Copyright 2015-2023 SNIA. All rights reserved."
   }

Postconditions: The requested class of service is added to the ClassesOfService collection.

Failure Scenario: None defined.

See also: None defined.

7.1.10. Create ConsistencyGroup

Summary: Create a ConsistencyGroup

Purpose: Create a ConsistencyGroup

Who: StorageAdmin, CloudAdmin

Management Domain: Block storage management

Triggers: None defined.

Detailed Context: Create a collection of application storage that is exposed to an application and managed as a unit.

Preconditions: None defined.

Feature(s): Mapping and masking

Inputs:

• URL for storage service: /redfish/v1/Storage
• The proposed name of the new ConsistencyGroup (string): “HillOfBeans1”
• A description of the new ConsistencyGroup (string): “New storage group to support accounting”
• A consistency requirement for the new ConsistencyGroup (boolean). When TRUE, all copies of data within a ConsistencyGroup must be kept in sync: true
• Pointers to the volumes that are members of this group.

Basic Course of Events:

1. Create ConsistencyGroup

Request:

POST /redfish/v1/StorageService/StorageGroups/Members

• Headers: Content-type : application/json

• Body:

    {
    "Name" : "HillOfBeans1",
    "Description" : "New consistency group to support accounting",
    "IsConsistent" : true,
    "ConsistencyType": "ApplicationConsistent",
    "ConsistencyMethod": "Other",
    "Volumes": [
      {
        "@odata.id": "/redfish/v1/Storage/MySystem/StoragePools/ConsistencyPool/AllocatedVolumes/Vol1"
      },
      {
        "@odata.id": "/redfish/v1/Storage/MySystem/StoragePools/ConsistencyPool/AllocatedVolumes/Vol2"
      },
      {
        "@odata.id": "/redfish/v1/Storage/MySystem/StoragePools/ConsistencyPool/AllocatedVolumes/Vol3"
      }
    ]
    }

Response:

{
  "Name" : "HillOfBeans1",
  "Description" : "New consistency group to support accounting",
  "IsConsistent" : true,
  "ConsistencyType": "ApplicationConsistent",
  "ConsistencyMethod": "Other",
  "Status": {
    "State": "Enabled"
  },
  "Volumes": [
    {
      "@odata.id": "/redfish/v1/Storage/MySystem/StoragePools/ConsistencyPool/AllocatedVolumes/Vol1"
    },
    {
      "@odata.id": "/redfish/v1/Storage/MySystem/StoragePools/ConsistencyPool/AllocatedVolumes/Vol2"
    },
    {
      "@odata.id": "/redfish/v1/Storage/MySystem/StoragePools/ConsistencyPool/AllocatedVolumes/Vol3"
    }
  ]
}

• HTTP Status: 200 (OK)

Postconditions: The requested ConsistencyGroup is added to the Storage instance.

Failure Scenario: None defined.

See also: None defined.

7.1.11. Create file share

Summary: Create a file share

Purpose: Share an existing file system as /Shares/MyShare

Who: CloudAdmin, StorageAdmin, DevOps

Management Domain: File system storage management

Triggers: None defined.

Detailed Context: Create a share starting at /Shares/MyShare.

Preconditions: None defined.

Feature(s): File provisioning

Inputs:

• URL for the filesystem: /redfish/v1/StorageServices/1/FileSystems/QuickFiles
• The path to the shared file: "/Shares/MyShare"
• Description: "Share of files under MyShare."

Basic Course of Events:

1. Create a file share

Request:

POST /redfish/v1/StorageServices/1/FileSystems/QuickFiles/ExportedShares

• Headers: Content-type : application/json

• Body:

    {
      "Name" : "MyShare",
      "Description" : "Share of files under MyShare.",
     "SharedFilePath" : "/Shares/MyShare"
    }

Response:

• HTTP Status: 201 (Created)

• Headers:

  Location : /redfish/v1/StorageServices/1/FileSystems/QuickFiles/ExportedShares/MyShare Content-type : application/json

• Body:

{
 "@Redfish.Copyright": "Copyright 2015-2021 SNIA. All rights reserved.",
 "@odata.id": "/redfish/v1/StorageServices/1/FileSystems/QuickFiles/ExportedShares/MyShare",
 "@odata.type": "#FileShare.v1_0_0.FileShare",
 "Id": "MyShare",
 "Name": "MyShare",
 "Description": "My File Share.",
 "FileSharePath": "/Shares/MyShare",
 "FileSharingProtocols": [
     "SMBv3_1_1"
 ],
 "Status": {
     "State": "Enabled",
     "Health": "OK",
     "HealthRollup": "OK"
 },
 "DefaultAccessCapabilities": [
     "Read",
     "Write",
     "Execute"
 ],
 "ExecuteSupport": true,
 "RootAccess": true,
 "CASupported": true,
 "EthernetInterfaces": {
     "@odata.id": "/redfish/v1/Systems/FileServer/EthernetInterfaces/1"
 },
 "Links": {
     "FileSystem": {
         "@odata.id": "/redfish/v1/StorageServices/1/FileSystems/QuickFiles"
     }
 }
}

Postconditions: The requested file share is added to the ExportedShares collection for the file system.

Failure Scenario: None defined.

See also: None defined.

Create file system

Summary: Create a file system

Purpose: Create a file system with a given capacity and performance level.

Who: StorageAdmin

Management Domain: File system storage management

Triggers: None defined.

Detailed Context: Create a 100 TB file system based on SSD class storage.

Preconditions: None defined.

Feature(s): Class of Service

Inputs:

• URL for storage service: /redfish/v1/StorageServices/1

• Name for the new file system: "QuickFiles"

• Description: "100 TB FileSystem having SSD class storage."

• URL for class of service: /redfish/v1/StorageServices/1/Links/ClassesOfService/SSD

• File system capacity:

  {
    "Data":
    {
        "ProvisionedBytes": 100000000000000,
        "IsThinProvisioned": true
      }
  }

Basic Course of Events:

1. Create FileSystem

Request: POST /redfish/v1/StorageServices/1/FileSystems

• Headers: Content-type : application/json

• Body:

  {
    "Name": "QuickFiles",
    "Description": "100 TB FileSystem having SSD class storage.",
    "Capacity": {
        "Data": {
            "ProvisionedBytes": 100000000000000
        },
        "IsThinProvisioned": true
    },
    "Links" : {
        "ClassOfService": {"odata.id":
            "/redfish/v1/StorageServices/1/Links/ClassesOfService/SSD"}
    }
  }

Response:

• HTTP Status: 201 (Created)

• Headers:

  Location : /redfish/v1/StorageServices/1/FileSystems/QuickFiles

• Body:

{
  "@odata.type": "#FileSystem.v1_2_2.FileSystem",
  "Id": "QuickFiles",
  "Name": "QuickFiles",
  "Description": "100 TB FileSystem having SSD class storage.",
  "BlockSizeBytes": 8192,
  "Capacity": {
      "Data": {
          "ConsumedBytes": 0,
          "AllocatedBytes": 0,
          "ProvisionedBytes": 100000000000000
      },
      "Metadata": {
          "ConsumedBytes": 0,
          "AllocatedBytes": 0,
          "ProvisionedBytes": 0
      },
      "Snapshot": {
          "ConsumedBytes": 0,
          "AllocatedBytes": 0,
          "ProvisionedBytes": 0
      }
  },
  "CapacitySources": [
      {
          "@odata.type": "#Capacity.v1_2_0.CapacitySource",
          "Id": "Source1",
          "Name": "Source1",
          "ProvidedCapacity": {
              "Data": {
                  "ConsumedBytes": 500000000000,
                  "AllocatedBytes": 1000000000000,
                  "ProvisionedBytes": 3000000000000
              },
              "Metadata": {
                  "ConsumedBytes": 0,
                  "AllocatedBytes": 0,
                  "ProvisionedBytes": 0
              },
              "Snapshot": {
                  "ConsumedBytes": 0,
                  "AllocatedBytes": 0,
                  "ProvisionedBytes": 0
              }
          },
          "ProvidedClassOfService": {
              "@odata.id": "/redfish/v1/StorageServices/FileService/ClassesOfService/GoldDallas"
          },
          "ProvidingPools": {
              "@odata.id": "/redfish/v1/StorageServices/1/FileSystems/QuickFiles/CapacitySources/Source1/ProvidingPools"
          },
          "@odata.id": "/redfish/v1/StorageServices/1/FileSystems/QuickFiles/CapacitySources/Source1"
      }
  ],
  "AccessCapabilities": [
      "Read",
      "Write"
  ],
  "Links": {
      "ClassOfService": {
          "@odata.id": "/redfish/v1/StorageServices/FileService/ClassesOfService/GoldDallas"
      }
  },
  "@odata.id": "/redfish/v1/StorageServices/1/FileSystems/QuickFiles",
  "@Redfish.Copyright": "Copyright 2015-2023 SNIA. All rights reserved."
}

Postconditions: The requested file system is added to the FileSystems collection for the Storage Service.

Failure Scenario: None defined.

See also: None defined.

7.1.12. Create file system

Summary: Create a file system

Purpose: Create a file system with a given capacity and performance level.

Who: StorageAdmin

Management Domain: File system storage management

Triggers: None defined.

Detailed Context: Create a 100 TB file system based on SSD class storage.

Preconditions: None defined.

Feature(s): File provisioning

Inputs:

• URL for storage service: /redfish/v1/StorageServices/1

• Name for the new file system: "QuickFiles"

• Description: "100 TB FileSystem having SSD class storage."

• URL for class of service: /redfish/v1/StorageServices/1/Links/ClassesOfService/SSD

• File system capacity:

  {
    "Data":
    {
        "ProvisionedBytes": 100000000000000;
        "IsThinProvisioned": true;
      }
  }

  Basic Course of Events:

  1. Create FileSystem

  Request: POST /redfish/v1/StorageServices/1/FileSystems

  • Headers: Content-type : application/json

  • Body:

    {
      "Name": "QuickFiles",
      "Description": "100 TB FileSystem having SSD class storage.",
      "Capacity": {
          "Data": {
              "ProvisionedBytes": 100000000000000
          },
          "IsThinProvisioned": true
      },
      "Links" : {
          "ClassOfService": {"odata.id":
              "/redfish/v1/StorageServices/1/Links/ClassesOfService/SSD"}
      }
    }

  Response:

  • HTTP Status: 201 (Created)

  • Headers:

    Location : /redfish/v1/StorageServices/1/FileSystems/QuickFiles Content-type : application/json

  • Body:

  {
   "@Redfish.Copyright": "Copyright 2015-2024 SNIA. All rights reserved.",
   "@odata.id": "/redfish/v1/StorageServices/FileService/FileSystems/QuickFiles",
   "@odata.type": "#FileSystem.v1_1_0.FileSystem",
   "Id": "QuickFiles",
   "Name": "QuickFiles",
   "Description": "QuickFiles FileSystem, not replicated.",
   "BlockSizeBytes": 8192,
   "Capacity": {
       "Data": {
           "ConsumedBytes": 0
           "AllocatedBytes": 0
           "ProvisionedBytes": 1000000000000
       },
       "Metadata": {
           "ConsumedBytes": 0,
           "AllocatedBytes": 0,
           "ProvisionedBytes": 0
       },
       "Snapshot": {
           "ConsumedBytes": 0,
           "AllocatedBytes": 0,
           "ProvisionedBytes": 0
       }
   },
   "CapacitySources": [
       {
           "@odata.id": "/redfish/v1/StorageServices/FileService/FileSystems/QuickFiles/CapacitySources/Source1"
       }
   ],
   "LowSpaceWarningThresholdPercents": [
       60,
       90
   ],
   "AccessCapabilities": [
       "Read",
       "Write"
   ],
   "CaseSensitive": false,
   "CasePreserved": false,
   "CharacterCodeSet": [
       "ASCII",
       "Unicode"
   ],
   "MaxFileNameLengthBytes": 256,
   "ClusterSizeBytes": 256,
   "Links": {
       "ClassOfService": {
           "@odata.id": "/redfish/v1/StorageServices/FileService/ClassesOfService/GoldDallas"
       }
   }
  }

Postconditions: The requested file system is added to the FileSystems collection for the Storage Service.

Failure Scenario: None defined.

See also: None defined.

7.1.13. Create line of service

Summary: Create a line of service to reflect the performance characteristics of SSD storage

Purpose: The definition is created here in preparation of creating ClassOfService instances that include a requirement for SSD storage performance.

Who: StorageAdmin

Management Domain: Block storage management, Service catalog management

Triggers: None defined.

Detailed Context: SSD storage is introduced and need a new performance line of service to reflect their capability.

Preconditions: None defined.

Feature(s): Class of Service

Inputs:

• URL for Storage Service: /redfish/v1/StorageServices/1

• New IO performance line of service

  {
  "Name": "NewSSDLoS",
  "IoOperationsPerSecondIsLimitedBoolean": false,
  "MaxIoOperationsPerSecondPerTerabyte": 100000,
  "AverageIoOperationLatencyMicroseconds": 10
  }

Basic Course of Events:

1. Get existing supported lines of service

Request:

GET /redfish/v1/StorageServices/1/Links/IOPerformanceLoSCapabilities/
    SupportedIOPerformanceLinesOfService

• Headers: No additional headers required.

Response:

• HTTP Status: 200 (OK)

• Headers:

ETag: "123-a" Content-type : application/json

• Body:

  {
  "Value": [{
     "Name": "LoS1",
     "IoOperationsPerSecondIsLimitedBoolean": false,
     "SamplePeriodSeconds": 60,
     "MaxIoOperationsPerSecondPerTerabyte": 83,
     "AverageIoOperationLatencyMicroseconds": 8000,
  },
  {
     "Name": "LoS2",
     "IoOperationsPerSecondIsLimitedBoolean": "false",
     "SamplePeriodSeconds": 60,
     "MaxIoOperationsPerSecondPerTerabyte": 133,
     "AverageIoOperationLatencyMicroseconds": 5000,
     "IOWorkload": {
        "Name": "Duplicon: OLTP"
     }
  }]
  }