Ibm v8.1.1.x configuration limits and restrictions for ibm storwize v7000 and v7000f – united states gas appliance manufacturers association

a. When a cloud account is created, it must continue to use the same encryption type, throughout the life of the data in that cloud account – even if the cloud account object is removed and remade on the system, the encryption type for that cloud account may not be changed while back up data for that system exists in the cloud provider.

b. When performing re-key operations on a system that has an encryption enabled cloud account, perform the commit operation immediately after the prepare operation. Remember to retain the previous system master key (on USB or in Keyserver) as this key may still be needed to retrieve your cloud backup data when performing a T4 recovery or an import.

d. Customers using TCT at 7.8.0.x that wish to perform the unusual command sequence of rmcloudacccount/mkcloudaccount using the same clusterid and container prefix should wait until they have upgraded to 8.1.0.0. Customers should perform the actions in e. below at 8.1.0.0 prior to performing any rmcloudaccount/mkcloudaccount sequence.

e. If you have configured TCT on your system and have created backup data in the cloud provider associated with your cloudaccount and you are upgrading from v7.8.0.x to v8.1.0.x:, then you should perform the following operations after an upgrade has completed:

There is an extremely small possibility that, on a system using both Encryption and Transparent Cloud Tiering, the system can enter a state where an encryption re-key operation is stuck in ‘prepared’ or ‘prepare_failed’ state, and a cloud account is stuck in ‘offline’ state.

5. The cloud account will now be offline as it can’t get the presumptive key. The cloud account can not be removed, and the encryption rekey can not be completed or cancelled. The system will remain stuck in these cloud and encryption states.

5. The cloud account will now be offline as it can’t get the presumptive key. The cloud account can not be removed, and the encryption rekey can not be completed or cancelled. The system will remain stuck in these cloud and encryption states.

SAN Volume Controller and Storwize Version 7.7 introduced support for NPIV ( N_Port ID Virtualization ) for Fibre Channel fabric attachment. FCoE is not supported with NPIV. The following recommendations and restrictions should be followed when implementing the NPIV feature.

When NPIV enters into Transitional state from Disabled, with all the SDDDSM paths in Non-Preferred state,the paths to the Virtual ports also become Non-Preferred. This path configuration might cause IO failures as soon as NPIV moves into "Enabled" state.

A Storwize V7000 system at version 7.8.0.0 and higher requires native Fibre Channel SAN or alternatively 8Gbps/16Gbps Direct Attach Fibre Channel connectivity for communication between all nodes in the local cluster. Fibre Channel over Ethernet ( FCoE ) connectivity for communication between all nodes in the local cluster is also supported.

Partnerships between systems for Metro Mirror or Global Mirror replication can be used with both Fibre Channel, Native Ethernet connectivity and FCoE connectivity, however direct FCoE links are only supported to a maximum of 300 metres. Distances greater than 300 metres are only supported when using an FCIP link or Fibre Channel between source and target.

Please see SSIC for supported 16Gbps Fibre Channel configurations supported with 16Gbps node hardware. Note 16Gbps Node hardware is supported when connected to Brocade and Cisco 8Gbps or 16Gbps fabrics only. Direct connections to 2Gbps or 4Gbps SAN or direct host attachment to 2Gbps or 4Gbps ports is not supported. Other configured switches which are not directly connected to the16Gbps Node hardware can be any supported fabric switch as currently listed in SSIC.

Using an Ethernet Switch to convert a 10Gbps IP partnership link to 1Gbps link and vice versa is not supported. Therefore, the IP infrastructure on the two partnership sites should both be 1Gbps or 10Gbps. However, bandwidth limiting on 10Gbps and 1Gbps IP partnership between sites is supported.

Storwize V7000 supports concurrent ESM firmware upgrades for those DS4000 models listed as such on the Supported Hardware List when they are running either 06.23.05.00 or later controller firmware. However, controllers running firmware levels earlier than 06.23.05.00 will not be supported for concurrent ESM upgrades. Customers in this situation, who wish to gain support for concurrent ESM upgrades, will need to first upgrade the DS4000 controller firmware level to 06.23.05.00. This action is a controller firmware upgrade, not an ESM upgrade and concurrent controller firmware upgrades are already supported in conjunction with Storwize V7000. Once the controller firmware is at 06.23.05.00 or later the ESM firmware can be upgraded concurrently.

Note: The DS4000 ESM firmware upgrade must be done on one disk expansion enclosure at a time. A 10 minute delay from when one enclosure is upgraded to the start of the upgrade of another enclosure is required. Confirm via the Storage Manager applications "Recovery Guru" that the DS4000 status is in an optimal state before upgrading the next enclosure. If it is not, then do not continue ESM firmware upgrades until the problem is resolved.

Storwize V7000 version 7.5.0 introduced support for Microsft ODX. In order to utilise this function all windows hosts accessing Storwize V7000 are required to be at a minimum SDDDSM version of 2.4.5.0. Earlier versions of SDDDSM are not supported when the ODX function is activated.