Restrictions for Storwize V7000 Unified software versions 1.3.0.0 - 1.3.0.2 When running software versions
1.3.0.0, 1.3.0.1 or 1.3.0.2, the following functions are available for pre-production use only:

Use of asynchronous file replication between Storwize V7000 Unified systems. (Note: use of the Storwize V7000 6.3.0 Metro Mirror and Global Mirror functions, for replicating block volumes between Storwize V7000 systems, is not affected by this restriction)

Use of Network Data Management Protocol (NDMP) for file backup/restore functions. (Note: use of IBM Tivoli Storage Manager (TSM) client with an external TSM server for backup/restore operations is not affected by this restriction)

Use of the GPFS Information Lifecycle Management functions, for file placement, migration and deletion on internal or external disk.

Use of IBM Tivoli Storage Manager for Space Management as a Hierarchical Storage Manager (HSM), for migrating data to an external TSM server.

These restrictions were removed with Storwize V7000 Unified software version 1.3.0.3 and later, allowing use of all functions in production environments.

Restriction for Storwize V7000 Unified software versions 1.3.0.3 If Storwize V7000 Unified is configured for authentication with Microsoft Active Directory, then usage of SCP protocol for file I/O access is not supported.

This restriction was removed with Storwize V7000 Unified version 1.3.1.0 and later.

Hierarchical Storage Management (HSM) Use of file sets for hierarchical storage management (HSM) enabled file systems is not supported for Storwize V7000 Unified version 1.3.2.0 and below. Additional information is available in the following technote:
File Sets are Not Supported for HSM Managed File Systems

Asynchronous Replication behaviour with filesets File set definitions and associated information such as quotas are not replicated to the target system. The directory structure of the source file set, all files and extended attribute information contained within are replicated to the target, though they will be handled as a normal directory on the target.

When a file set within the source file system is unlinked, it is still held by the source file system but it disappears from the source directory tree. If a replication process is run during the time when a source file set is unlinked, the file tree will appear as if those files have been removed and they will therefore be removed from the target system, as to match the current state of the source. This may cause a significant amount of data to be removed from the target system and would result in this data being unavailable in the event of a disaster at the source location.

Upon re-linking the file set on the source, the file tree will appear again and the next replication cycle will behave as though the entire file tree was just created, resulting in those files being replicated to the target. This may cause a significant amount of data to be resent to the target to bring it back into synchronization with the source system.

Refer to the Storwize V7000 Unified Information Center for additional information on
managing asynchronous replication, including authentication and networking requirements.

Asynchronous Replication across Code Levels Asynchronous replication is not supported across different code levels. The source machine and the target machine should have the same code level.

Storwize V7000 Unified Software Upgrade

Storwize V7000 Unified software upgrades can be performed concurrently with the following methods of host access:

Block I/O access:

Fibre Channel

iSCSI

File I/O access:

NFS (using hard mounts)

Host systems using CIFS, HTTPS, SCP or FTP for file I/O access may experience brief interruptions during the upgrade process and subsequently need to reconnect after the upgrade has completed. It is recommended that any applications accessing file shares using these protocols be quiesced before starting a software upgrade.

Storwize V7000 Block Function Restrictions for File System Volumes

The table below shows which V7000 block functions can be used for file system volumes:

Note: volume migration within a storage pool, e.g. as a result of removing an mdisk or array, is supported.

Image-mode volumes

No

DS4000 Maintenance

Storwize V7000 Unified supports concurrent ESM firmware upgrades for those DS4000 models listed as such on the Storwize V7000 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.

Host Limitations for File I/O Access

CIFS access to file systems is supported only for volumes that are placed on Storwize V7000 internal storage.

Host Limitations for Block I/O Access

Windows SAN Boot Clusters (MSCS):

It is possible to SAN Boot a Microsoft Cluster subject to the following restrictions imposed by Microsoft:

On Windows 2003, clustered disks and boot disks can be presented on the same storage bus, but ONLY if the Storport driver is being used.

We have not tested, and therefore do not support, modifying the registry key as suggested on page 28 (which would allow boot disks and clustered disks on the same storage bus on Windows 2003 without the Storport driver).

Oracle

Oracle Version and OS

Restrictions that apply:

Oracle RAC 10g on Windows:

1

Oracle RAC 10g on AIX:

1, 2

Oracle RAC 11g on AIX:

2

Oracle RAC 10g on HP-UX11.31:

1, 2

Oracle RAC 11g on HP-UX11.31:

1, 2

Oracle RAC 10g on HP-UX11.23:

1, 2

Oracle RAC 11g on HP-UX11.23:

1, 2

Oracle RAC 10g on Linux Host:

1, 3

Restriction 1: ASM cannot recognise the size change of the disk when Storwize V7000 disk is resized unless the disk is removed from ASM and included again.

Restriction 2: After an ASM disk group has successfully dropped a disk, the disk cannot be deleted from the OS. The workaround to the OS restriction is to bring down the ASM instance, delete the disk from the OS, and bring up the ASM instance again.

Restriction 3: For RHEL4 set Oracle Clusterware 'misscount' parameter to a bigger one to allow SDD to do path failover first. The default miscount setting 60s is too short for SDD. We recommend to set it 90s or 120s. Command to use: crsctl set css misscount 90