Known issues

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 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.

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 Control Base DNS hostname can be resolved.

Currently there is no solution or workaround for this limitation.

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

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

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.

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 Control Base after the SVC software is re-installed and connect the storage system to Spectrum Control Base 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 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 avoid this issue, use the mkdir /opt/ibm and chmod 755 /opt/ibm commands to create the /opt/ibm folder and set correct permissions.

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).

To resolve this issue, restore the required service capabilities 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.

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

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

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

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.

Currently there is no solution or workaround for this limitation.

Currently there is no solution or workaround for this limitation.

• VM is created on a thin-provisioned disk.
• The disk is based on a VVol-based datastore.
• The VVol-based datastore is based on a storage space with a service without space efficiency.

Currently there is no solution or workaround for this limitation.

To avoid this situation, when you create a new storage policy, add a new VM based on this profile first, then add a disk to an existing VM.

Currently there is no solution or workaround for this limitation.

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 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 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.

To avoid this issue, restart the related Spectrum Control Base storage services.

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, 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 Control Base, and add the vCenter again, using valid administrator credentials.

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

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

To resolve this issue, restart the vSphere Web Client.

To avoid this issue, keep volume and snapshot names unique across all storage systems, connected to Spectrum Control Base.

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.

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.

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 Control Base 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.

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.

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 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 resolve this issue, restart the Spectrum Control Base 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.