Known issues

To avoid this issue, before performing upgrade, verify that all storage arrays are connected to Spectrum Control Base properly.

This occurs if the LUN number is already associated with a volume outside of the XIV domain.

Currently there is no solution or workaround for this limitation.

To resolve this issue, use IPv4 addressing, when configuring storage arrays.

During installation, Spectrum Control Base fails to acknowledge license agreement acceptance by the user.

To avoid this issue, mount the /tmp folder on the host with read/write permissions prior to the package installation.

Volumes that were migrated from an XIV storage array (A) to another XIV storage array (B) using Hyper-Scale Mobility (online volume migration) might not be manageable.

This specifically occurs if the volumes on the original XIV storage array (A) are deleted from the storage array (A), and then the same volume IDs are reused on that storage array (A).

If both XIV systems (A and B) are connected to the same Spectrum Control Base and this situation occurs, it prevents the management of these volumes through Spectrum Control Base.

Currently there is no solution or workaround for this limitation.

Editing the ldap.ini file manually may cause the Spectrum Control Base LDAP integration failure.

To avoid this issue, use the sc_ldap CLI command for LDAP configuration.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

To resolve this issue, terminate the Celery background process by using the Linux kill -9 command.

To avoid this issue, verify that the user performing the Spectrum Accelerate upgrade has sufficient access level for completing the task.

To resolve this issue, restore the required service capabilities manually.

To resolve this issue, remove the vCO server manually after the upgrade is completed.

Currently there is no solution or workaround for this limitation.

To avoid this issue, remove SVC from Spectrum Control Base, re-install the SVC software and connect the storage system to Spectrum Control Base again.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

To ensure proper Spectrum Control Base operation, verify that all required processes are running.

To avoid this issue, verify that the Spectrum Control Base DNS hostname can be resolved.

To avoid this situation, verify that the Linux server upon which IBM Spectrum Control Base Edition is installed meets the minimum hardware requirements, as detailed in see Minimum server hardware requirements.

To resolve this issue, change the over-provisioning ratio, using the XIV GUI, refresh the storage system in the Spectrum Control Base GUI and re-attach the resource to the service.

To resolve this issue, configure the required permission for the/tmp folder, using the chmod o+x /tmp command.

To resolve this issue, limit the traffic to the local host only, by adding RABBITMQ_NODE_IP_ADDRESS=127.0.0.1 to the /etc/rabbitmq/rabbitmq.conf file.

To avoid this issue, use the mkdir /opt/ibm and chmod 755 /opt/ibm commands to create the /opt/ibm folder and set correct permissions.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

To resolve this issue, replace the self-signed certificate as explained in the user guide.

This is to prevent repeated login attempt failures after which the directory server blocks that user account.

In such a case, update the storage admin credentials on the storage array with which the login has failed. Alternatively, you can remove that specific storage array from Spectrum Control Base and then reset the credentials.

You can find the relevant storage array by checking the events.log log file. For example:

Mar 26 13:50:01 ronend-sc1  ERROR ID:SC-0008 |
Severity:ERROR | Parameters:reason=Logging in to
array 2810-214-MN65025 has failed with the provided
credentials.
,user_name=ronenu | Message:Storage credentials for 
user ronenu were disabled. Reason: Logging in to
array 2810-214-MN65025 has failed with the provided
credentials.

To resolve this issue, use the Spectrum Control Base GUI or CLI to remove and then add back these storage arrays.

To resolve this issue, disable the Internet Explorer Enhanced Security Configuration option.

In such a case, use the Spectrum Control Base GUI to edit and update the IP address of the storage array (In the Arrays pane, move the mouse pointer over an array that you want to update, and then click the Edit button).

As a result, volumes that were mapped to an empty cluster must be manually unmapped.

To avoid this issue: before mapping volumes to an XIV array, delete all empty cluster configurations on that array, or add at least one host to each empty cluster.

Stopping Django service ... [OK]
Stopping Celery services ... [OK]
Stopping DS8K proxy.....[FAILED]

To resolve this issue, terminate all the Java background processes and then restart the Spectrum Control Base service.

Currently there is no solution or workaround for this limitation.

To resolve this issue, delete all hosts defined without domain, and add these hosts again with valid domain settings.

In such a case, determine whether the IBM Tivoli Storage Productivity Center capabilities are sufficient for replacing the IBM Storage Provider for VMware VASA. If the IBM Storage Provider for VMware VASA is still needed, IBM TPC 5.2 (or later) provides a method of excluding storage arrays from a specific storage provider, allowing you to remove the array association with the IBM TPC provider.

For more information, refer to the IBM Tivoli Storage Productivity Center documentation.

To avoid this issue, do not include spaces in the IP interface name of the XIV storage system.

Cloning of a virtual machine from a VVol to another VVol on the same IBM SAN Volume Controller (SVC) fails, when the user chooses to customize the VM hardware during the cloning procedure. Moreover, resizing of the source and target VMs fails, if the SVC background copy is in progress.

To avoid this issue, customize the virtual machine hardware only after the VM cloning and SVC background copy process are completed.

To avoid this issue, verify that Spectrum Control Base is registered as a VASA provider before adding the storage system after its removal. In addition, after the storage system is added, it is recommended to check the vCenter log whether Spectrum Control Base was identified as an active VASA provider.

To resolve this issue, delete the space and the service from the standby Spectrum Control Base manually.

XIV and Spectrum Accelerate storage systems can be differentiated in VMware VASA 1.0 only using the UUID field under Manage > Storage Providers > Storage System Details. The XIV storage system UUID includes the 900 code, and Spectrum Accelerate includes either 104 or 204code.

Currently there is no solution or workaround for this limitation.

To avoid this issue, resize the virtual disk only after the disk formatting process is finished.

To avoid this issue, make sure that at least one of the child pools has sufficient disk space to host the datastore vDisk.

To avoid this issue, register all Spectrum Control Base instances as storage providers for VASA 1.0 or VASA 2.0.

• Migration of a VM with more than one snapshot between two VVol-based datastores, residing on the same storage system.

  To avoid this issue, delete all VM snapshots before its migration.

• Taking a snapshot of a VM which was migrated between two VVol-based datastores, residing on the same storage system, if the VM had a snapshot before the migration.

Currently, Spectrum Control Base prevents these scenarios by failing this kind of VM migration. However, to avoid this issue, after VM migration, delete all existing snapshots, before taking any new snapshots.

Currently there is no solution or workaround for this limitation.

To resolve this issue, re-register Spectrum Control Base as VASA storage provider.

To resolve this issue, cancel registration of Spectrum Control Base as a VASA storage provider, and run the registration again.

To avoid this issue, create a VVol-enabled storage service that supports thick and thin provisioning. Then attach storage resources which will be able to support the correct destination VVol-based destination datastore.

To resolve this issue, wait for several minutes after the initial registration attempt, and run the registration again.

To avoid this issue, verify that all hosts to be mapped, share at least one storage resource on the same storage system.

To avoid this issue, share the destination VVol-based datastore between the two hosts. After the cloning is finishes, cancel the datastore sharing.

To avoid this issue, do not perform hot migration of a VM before all cloning/migrating operations on the current volume are finished.

To resolve this issue, remove and reattach the vCenter server on Spectrum Control Base.

To resolve this issue, log into vCenter Managed Object Browser (MOB) at https://<vCenter_server_IP>/mob., using your vCenter credentials.

Navigate to Content > ExtensionManager > UnregisterExtension.

Enter com.ibm.storage.vwc, when a pop-up window is displayed, and click Invoke Method twice.

Repeat registration of the vCenter server on the newly connected Spectrum Control Base.

To avoid this issue, delete the volume from the storage system directly.

Currently there is no solution or workaround for this limitation.

vWC volume creation and mapping task may fail, if a source pool that exists on an XIV storage system within a domain, has been attached to service created by the default Spectrum Control user.

To avoid this issue, associate the default Spectrum Control Base user with the storage array domain.

To resolve this issue, remove volume mapping using the XIV GUI.

Currently there is no solution or workaround for this limitation.

To avoid this situation, increase the storage pool size to be 103 GB or bigger.

Currently there is no solution or workaround for this limitation.

To avoid this issue, do not map a specific volume to ESXi hosts that are not managed by the same vCenter server.

To resolve this issue, restart the vSphere Web Client from the vCenter Administration panel.

To avoid this situation, verify that all the hosts defined on the vCenter are also defined on the storage systems and are associated with the domain. In addition, make sure that the default storage credentials defined in Spectrum Control Base belong to the domain as well.

To avoid this issue, a size of a volume, provisioned on a storage service with enabled compression, must be larger than 51 GB.

Ignore the erroneous volume size suggestion.

To avoid this situation, verify that volumes outside of a domain are not mapped to the target host.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

Use the DS8000 CLI or web GUI to display the correct field value.

Currently there is no solution or workaround for this limitation.

To avoid this situation, verify that the host is connected to the vCenter server. If a disconnected or non-responsive host is connected to a new server, remove it from the original server to allow proper volume performance.

To avoid this situation, verify that the shared LUN number is available for all hosts.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

To avoid this situation, verify that a new volume name is unique on the current storage system. In addition, make sure that ESXi hosts are not mapped to the volumes outside of the user domain.

Currently there is no solution or workaround for this limitation.

To resolve this issue, manually remove the redundant session via the vSphere Web Client (Manage > Sessions > Terminate Selected Sessions).

If a combination of both iSCSI and FC initiator port types is defined for an ESXi host, mapping volumes to that ESXi host causes both iSCSI and FC to be used for those volumes.

To avoid this situation, use the storage system management tools to define only one active protocol type (iSCSI or FC) for the initiators of each ESXi host.

To avoid this issue, always use the same LUN ID when mapping a volume to multiple ESXi hosts via the storage system management GUI.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

To resolve this issue, manually update to the thresholds in vROps to match the XIV microcode that you are using.

To resolve this issue, delete the duplicate thresholds.

Currently there is no solution or workaround for this limitation.

To resolve this issue, restart the Spectrum Control Base service.