Skip to end of metadata
Go to start of metadata

 
CoprHD
Version 3.0
Release Notes

May 20, 2016


These release notes contain information on these topics:

 

Revision history

Revision date

Revision

Description of change

May, 2016

01

GA Release

 

Product description

CoprHD is a software-defined storage platform that abstracts, pools, and automates a data center's underlying physical storage infrastructure. It provides a single control plane for heterogeneous storage systems to data center administrators.
CoprHD enables software-defined data centers by providing the following features:

  • Storage automation capabilities for multi-vendor block and file storage environments (control plane, or CoprHD Controller)
  • Management of multiple data centers in different locations with single sign-on data access from any data center
  • Integration with VMware, and Microsoft compute systems, and non-native block storage systems through OpenStack via the CoprHD Third-Party Block Storage Provider. For more information, see Compute and Block Storage Integration
  • Migration of non-CoprHD volumes into the CoprHD environment through the CoprHD Migration Services Host Migration Utility, which leverages the capabilities of PowerPath Migration Enabler

 

New and changed features

To learn about the new features and changes introduced in CoprHD 3.0, go to 3.0 Release Features.

Known problems and limitations for version 3.0

CoprHD 3.0 has the following known problems and limitations.

Known problems and limitations in version 3.0

 

 

Key

Component

Description

COP-20136

Controllers-Block-Service-Openstack

Problem:
When using CoprHD in a Southbound Orchestration for OpenStack (SOFO), and VMAX storage is the block storage being used by OpenStack, creating a volume from a VMAX snapshot, which is managed through the CoprHD SOFO, from OpenStack is not supported.

If attempted, the following error message is returned: ***BadRequestException: Full copy is not supported on vmax snapshot***

COP-17664

Controllers-Cinder

Problem:
When CoprHD is configured with Cinder as southbound, deleting a source volume, using the CoprHD CLI, fails to detach the cloned volume.
Workaround:
Explicitly execute the volume detach operation using CoprHD CLI or Block Protection Services > Detach Full Copy from CoprHD UI, Service Catalog.

COP-21837

Controllers-File

Problem:
When using CoprHD to ingest unexported VNX file systems, not all of the file systems are ingested because during discovery of the VNX for File, the file systems were associated with the incorrect port. If that port is not part of the virtual array, then the file systems are not ingested.

Workaround:
Add all the ports to the virtual array and perform ingestion again.

COP-20752

Controllers-HDS

Problem: When multiple volumes are provisioned to an HDS host in CoprHD, and a new host initiator is added to the host, and then an attempt to add the new initiator into an export group, the operation fails with the following error message: "An error occurred while executing the job, Op: ADD INITIATOR TO EXPORT GROUP with message Error response received with error code 7,825 and message The specified nickname "z20671f86251d0044_1" is not available. This nickname is already used by another WWN/HostStorageDomain on the same port."

COP-17167

Controllers-Host

Problem:
Unmount and delete Windows volume fails after adding the failover host back. An error is generated stating the Windows host could not find volume.

Workaround:
When unmounting a volume from a Windows cluster, make sure you select a host that is in the cluster's export group. Otherwise, CoprHD cannot access the volume and the unmount fails.

COP-22253

Controllers-Host

Problem:
Creating manual clusters in CoprHD that are then discovered by vCenter is not supported.

Manually created clusters are not associated with any datacenters in the vCenter, so they are ignored during vCenter discovery. This causes the existing exports for the clusters to be removed.

COP-22339

Controllers-Host

Problem: When using CoprHD to discover an AIX host with a user name, that is not the root user, CoprHD will use sudo on the user to run the command which in term will fail.

COP-22250

Controllers-IBM-XIV

Problem:
The following tasks remain in a pending state when using CoprHD to manage IBM XIV devices in consistency groups:

  • When creating a snapshot of IBM XIV devices in a consistency group, the snapshot is created successfully, however the consistency group task is left in a pending state.
  • When using the CoprHD CLI to create an individual clone for IBM XIV devices in a consistency group, the consistency group task remains in the pending state. (Note: This operation cannot be performed through the CoprHD UI.)

    Workaround:
    Contact Customer Support and reference Knowledge Base article: 000482940.

COP-13717

Controllers-Misc, Controllers-VPLEX

Problem:
Snapshots and clones of backend VMAX meta volumes in consistency groups are not supported with SMI-S provider version 4.6.2.

Workaround:
There is no workaround when using SMI-S provider version 4.6.2. However, the functionality does work with SMI-S provider version 8.0.3.

COP-17516

Controllers-Misc

Problem:
If an unmanaged volume discovery order takes longer than expected to complete, the order may time out and report an error. However, the underlying discovery process will run to completion.

Monitor the controller service system logs for details.

COP-17858

Controllers-RecoverPoint

Problem:
After changing a VNX virtual pool configuration whose volumes are protected by RecoverPoint, CoprHD cannot find the RecoverPoint port even when configured correctly.

Workaround:
For each VNX volume that is protected by RecoverPoint, there must be at least one SP-A port and one SP-B port in each network.

COP-18177

Controllers-RecoverPoint

Problem:
Failure to create a mirror for a RecoverPoint-protected volume. When creating a VPLEX plus RecoverPoint volume, all volumes in the backend array will be in the same consistency group.

However, the volumes will not be in any backend consistency group if creating a RecoverPoint volume directly on the native array. When CoprHD tries to get the consistency group name from the backend array, the operation fails.

COP-19810

Controllers-RecoverPoint

Problem:
RecoverPoint protected volumes on XtremIO cannot be ingested into CoprHD. There are complications such as the following that prevent this from happening:

  • RecoverPoint returns a WWN for volumes different from the WWN that the array returns. This make mapping extremely difficult.
  • XtremIO with RecoverPoint creates RecoverPoint snapshot objects as part of its journaling. These snapshots get discovered by CoprHD as unmanaged snapshots that need to be ingested. These are not recognized as objects that need to be ingested.
  • XtremIO with RecoverPoint creates XtremIO consistency groups that conflict with consistency groups created by other operations.


    Note: The combination of VPLEX and RecoverPoint XtremIO volumes can be ingested by CoprHD.

COP-21343

Controllers-RecoverPoint

Problem:
When you restore a snapshot of a metropoint volume, CoprHD detaches the remote mirror before restoring the snapshot. You might see this error message: "Can't remove the mirror, as this would lead to a conflict with the existing loser settings." This error may occur after the ingestion process or if CoprHD is misaligned with the winning cluster on VPLEX.
Workaround:
Check the VPLEX UI and ensure the winning cluster is set correctly on the VPLEX consistency group. The winning cluster must be the cluster associated with the source virtual array. That is the one which contains the RecoverPoint source virtual pool.

COP-21531

Controllers-RecoverPoint

Problem:
Restore target snapshot fails after swapping source and target RecoverPoint-protected VMAX2 or VMAX3 volumes.

This issue can be observed with these steps:
1. Create RecoverPoint-protected volume (VMAX3 -> VMAX2)
2. Swap
3. Create local array snapshot on the source (former target)
4) Restore
This is not a supported configuration due to a RecoverPoint limitation. RecoverPoint will never let you create a replication set with the source volume larger than the target. In the case of a swap involving VMAX2 or VMAX3 volumes, the volume sizes are not equal, so the operation is not supported.

Note: This issue can also occur when using Application services.

Workaround:

  1. Create a RecoverPoint-protected volume (VPLEX + VMAX3 -> RecoverPoint Target VMA X2)
  2. Add the volume into an application sub group.
  3. Create application sub group snapshot for the RecoverPoint target (VMAX2).
  4. Swap the RecoverPoint link.
  5. Restore the snapshot for source subgroup (the original RecoverPoint Target VMAX2).Then it fails with an error.

COP-21662

Controllers-RecoverPoint

Problem:
Restore of a Metropoint volume may fail due to an issue in VPLEX (zeph 00040728).

COP-21969

Controllers-RecoverPoint

Problem:
Errors are returned when trying to perform any of the following CoprHD operations on newly ingested RecoverPoint volumes: Volume Delete, Snapshots, Mirrors, and Full Copies.
Workaround:
To fully ingest a RecoverPoint Consistency Group (CG) into CoprHD that has any volumes already provisioned in CoprHD, those existing CoprHD volumes will need to be CoprHD Inventory Only deleted before the RecoverPoint CG can be fully ingested into CoprHD.

If the existing CoprHD volumes to be ingested fall into the scope of KB article 000482649, then extra steps will need to be taken to clean up those volumes from back-end array Replication Groups.

COP-21976

Controllers-RecoverPoint

Problem:
When provisioning new RecoverPoint volumes into a new or existing consistency group with multiple lines in the order, each line is evaluated as a separate request. New journal provisioning is evaluated for each line in the order, so more journal space is can be allocated than is needed. There is no error, but this takes up unneeded disk space. Provisioning multiple volumes on the same line does not cause this issue.

COP-22011

Controllers-RecoverPoint

Problem:
If you disable the consistency group flag, Enable Array Consistency, and then try to remove a snapshot on a RecoverPoint source volume, you may see the IndexOutOfBoundsException error message.

Workaround
Before creating the snapshot, ensure the RecoverPoint consistency group volumes have been added into the application so that the backend consistency group exists (for example, a VMAX consistency group).

COP-13723

Controllers-SAN-Cisco, Documentation

Problem:
Array ports moved between networks before an export are not updated properly after the switch is discovered, resulting in the moved ports not being used for exports.

Workaround:
Use add storageport to varray to select and update the moved ports.

COP-13737

Controllers-VMAX

Problem:
When CoprHD assigns SRDF protection to multiple volumes, it indicates the order was a success when in fact only some of the volumes were moved into an SRDF group and consistency group. CoprHD does not support making multiple volume changes unless they are FAST policy changes.

COP-17460

Controllers-VMAX

Problem:
When volumes created in an SRDF group are ingested and then added to a consistency group, this error message is shown in the controller logs:

[957|performProtectionOperation|start|7bfca0d0-04eb-40b0-9293-1df476d44853] ERROR SRDFOperations.java (line 201) SMI-S error creating mirror group synchronization

WBEMException: CIM_ERR_FAILED (A general error occurred that is not covered by a more specific error code. (com..cmp.osls.se.symm.impl.SymapiCgT.cgControl:281 C:ERROR_CLASS_SOFTWARE F:ERROR_FAMILY_FAILED R:1026 file: SymStructBase.cpp line: 127 func: throwOnSymError errcode: 1026 sym err: Invalid RDF Consistency state for this operation message: SymapiCgT::cgControl fail))
This error is not generated in the UI and has no effect on the volumes in the consistency group. Ignore this error.

COP-17475

Controllers-VMAX, Documentation

Problem: VMAX does not support creating a consistency group snapshot on SRDF volumes that are failed over. If you attempt to do this in CoprHD, the following error messages appear:

ECOM log:
The size of the Source device is not equal to the size of the Target device message: CreateGroupReplica failed.

symapi log:
The device is not in a valid RDF state for this operation.

CoprHD UI:
The size of the Source device is not equal to the size of the Target device message: CreateGroupReplica failed.

COP-18240

Controllers-VMAX

Problem: Duplicate names are not identified and flagged during the early stages of a multi-volume block volume creation with CoprHD.
There is no roll-back operation triggered when the duplicate names are detected, leading to the task being abandoned.

Workaround
Do not use a duplicate name when creating block volumes from CoprHD.

COP-20262

Controllers-VMAX

Problem:
The relink operation fails when performed on ingested SnapVX linked targets in copy mode. This is not an issue when the mode is no copy.

Workaround:
If you experience this issue please contact Customer Support and reference Knowledge Base article: 000482944

COP-20529

Controllers-VMAX

Problem:
CoprHD allows you to ingest SRDF Metro volumes, but does not support SRDF Metro operations on ingested SRDF metro volumes.

Workaround:
Do not use CoprHD for SRDF Metro operations on unmanaged SRDF volumes.

COP-21857

Controllers-VMAX

Problem:
CoprHD will not allow you to delete all VMAX3 volumes in a consistency group with one operation, when the consistency group is linked with a snap session and target devices.

Workaround:
To delete all of the VMAX3 volumes from the consistency group:

  1. Use the Block Protection Services>Remove Block Snapshot service, to unlink the source from the target devices, and delete the target devices.
  2. Delete the all of the VMAX3 volumes in the consistency group using the single delete operation.

COP-22121

Controllers-VMAX

Problem: When using the CoprHD, Remove Block Volume service to delete all volumes in a consistency groups configured with VMAX3+ SRDF devices and snap session, the snap session does not delete and remains in the CoprHD database, which makes the consistency group to be non-deletable. Workaround:
To delete all of the SRDF VMAX3 volumes, with snapshot sessions from the consistency group, you must do the following:

  1. Use the "Block Protection Services>Remove Block Snapshot" service, to unlink the target devices from source, delete the target devices (if target devices available).
  2. Run the "Block Protection Services>Remove Block Snapshot" service again to delete the snap session.
  3. Then you can delete all of the SRDF VMAX3 volumes in the consistency group using single delete operation.

COP-16544

Controllers-VPLEX

Problem:
When a VPLEX FE port is down and is not part of a CoprHD virtual array, there is a possibility of seeing exceptions in the logs hindering the provisioning operations.

Workaround:
Create a dummy virtual array and add the offending ports to it.

COP-17868

Controllers-VPLEX

Problem:
The following could occur due to a known issue in the VPLEX code, which is being tracked by Bug ID: zeph-q38003

Full copy creation for VPLEX metro (distributed volumes) fails due to an error in the attach mirror phase.

COP-17087

Controllers-XtremIO

Problem: When you resynchronize a snapshot of an XtremIO volume, XtremIO creates a new synchronized snapshot. If you delete the new synchronized snapshot, it is deleted, but the parent snapshot still exists on the array. In addition, when the parent volume is deleted, the parent snapshot is not deleted.

Workaround:
Manually delete the parent snapshot on the XtremIO array.

COP-17122

Controllers-XtremIO

Problem:
When a volume, that is not in a consistency group is restored, a snapshot set instance is created on the XtremIO array and it indicates that the snapshot has been restored. However, when all volumes in a CG / CG snap are restored, there is no snapshot set instance created on the XtremIO array.

This behavior is due to an issue on the XtremIO array, which will be fixed in a future release. The actual restore functionality is working correctly

COP-20557

Controllers-XtremIO

Problem:CoprHD failed to create a new volume when managing two XtremIO arrays and a VPLEX local setup. When CoprHD executes "Create Block Volume," CoprHD tries to create a new Initiator Group in XtremIO so it can map volumes to the CoprHD initiators. This operation fails and the error, "port_address_not_unique" displays.

Workaround:
Rediscover the array in CoprHD and retry the operation.

COP-21964

Controllers-XtremIO

Problem:
XtremIO snapshots that are created with 2.3.x cannot be exported after upgrade to 2.4.1.x.

Workaround:
Contact Customer Support if this issue occurs.

COP-22260

Controllers-XtremIO

Problem.
The replicationGroupInstance is not set properly when an XtremIO consistency group snapshot is ingested last. As a result, post-ingestion operations (resync, restore, delete) fail.

Workaround:
Ingest the consistency group snapshot before ingesting the parent volume. Then all operations work fine post ingestion.

Note: Ingestion of RecoverPoint/VPLEX +XtremIO and VPLEX+XtremIO consistency group snapshots works fine no matter the order of ingestion.

COP-22571System-Management

Problem:

The CoprHD Dashboard and license APIs show that CoprHD is using a "trial" license and is limited to managing 300GB of storage.

Workaround:

None is required. Despite what the Dashboard and API claim, there are no license limitations enforced on CoprHD.

  • No labels