Known issues

To resolve this issue, mount /tmp with exec option, then remount it with noexec after successful installation of the Spectrum Connect software.

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.

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 Connect and this situation occurs, it prevents the management of these volumes through Spectrum Connect.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

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

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

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

To resolve this issue, reconfigure the LDAP access after the Spectrum Connect is restored.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

To resolve this issue, change the default user credentials after system restore.

Currently there is no solution or workaround for this limitation.

To resolve this issue, log into Spectrum Connect CLI utility as ibmsc user and run the sc_setting modify -n CERTIFICATE_EXISTS -v TRUE command.

To resolve this issue, remove all vCenter interfaces from the Spectrum Connect, using its web UI; upgrade Spectrum Connect; add the interfaces back and delegate any storage service again to the reattached vCenter interfaces.

Use the Spectrum Virtualize UI or CLI to verify encryption status of the pool.

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 Connect 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 avoid this issue, before performing upgrade, verify that all storage arrays are connected to Spectrum Connect properly.

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

Editing the ldap.ini file manually may cause the Spectrum Connect 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.

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

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 Connect after the SVC software is re-installed and connect the storage system to Spectrum Connect again.

Currently there is no solution or workaround for this limitation.

To resolve this issue, change the over-provisioning ratio, using the XIV GUI, refresh the storage system in the Spectrum Connect 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 avoid this issue, use the mkdir /opt/ibm and chmod 755 /opt/ibm commands to create the /opt/ibm folder and set correct permissions.

To resolve this issue, change the local user to an LDAP user after upgrading Spectrum Connect to version 3.3.0.

Currently there is no solution or workaround for this limitation.

In such a case, use the Spectrum Connect 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).

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, replace the self-signed certificate as explained in the user guide.

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

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

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 Connect instances as storage providers for VASA 1.0 or VASA 2.0.

To resolve this issue, cancel registration of Spectrum Connect 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.

Currently there is no solution or workaround for this limitation.

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 Connect 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 Connect was identified as an active VASA provider.

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

Currently there is no solution or workaround for this limitation.

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, wait for the synchronization to complete on storage system side. You can use the SVC lsvdisksyncprogress command to monitor synchronization progress.

To avoid this issue, make sure that the storage resource for the VM datastore has sufficient free space to accommodate the VVol data disk.

Currently there is no solution or workaround for this limitation.

To resolve this issue, disconnect the inactive storage providers and connect them again to the vCenter server(s).

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

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

To resolve this issue, remove the vCenter interface from Spectrum Connect, and add the vCenter again, using valid administrator credentials.

To resolve this issue, restart the refresh vWC service by logging into the Spectrum Connect host as root and running the /etc/init.d/ibm_spectrum_control restart_vwc_refresh.

Removing a vCenter interface from Spectrum Connect may cause unstable behavior of the vWC plug-in.

To avoid this issue, connect all vCenter servers in the SSO to the same Spectrum Connect instance.

To resolve this issue, restart the web plug-in service on the relevant vCenter server.

To resolve this issue, resize the volume using the storage system web-based user interface or CLI.

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

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

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 Connect user with the storage array domain.

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

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

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 Connect belong to the domain as well.

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

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

To avoid this issue, wait for the synchronization to complete on storage system side. You can use the SVC lsvdisksyncprogress command to monitor synchronization progress.

To resolve this issue, rescan the host manually.

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.

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, do not map a specific volume to ESXi hosts that are not managed by the same vCenter server.

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

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.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

To avoid this issue, use local accounts to access vROps.

Currently there is no solution or workaround for this limitation.

To resolve this issue, restart the Spectrum Connect service.

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.

Currently there is no solution or workaround for this limitation.