## Native backend controller copy functions considerations 

As discussed in the above sections, the IBM Spectrum Virtualize/Storwize technology provides a widespread set of copy services functions that cover most of the clients requirements. 

However, some storage controllers can provide specific copy services capabilities not available with the current version of IBM Spectrum Virtualize software. The IBM Spectrum Virtualize/Storwize technology addresses these situations by using cache-disabled image mode volumes that virtualize LUN participating to the native backend controller’s copy services relationships. 

Keeping the cache disabled guarantees data consistency throughout the I/O stack, from the host to the backend controller. Otherwise, by leaving the cache enabled on a volume, the underlying controller does not receive any write I/Os as the host writes them. IBM Spectrum Virtualize caches them and processes them later. This process can have more ramifications if a target host depends on the write I/Os from the source host as they are written. 

Note:  Native copy services are not supported on all storage controllers. For more information about the known limitations, see Using Native Controller Copy Services, S1002852. 

As part of its copy services function, the storage controller might take a LUN offline or suspend reads or writes. As IBM Spectrum Virtualize/Storwize does not recognize why this happens; therefore, it might log errors when these events occur. For this reason, if the IBM Spectrum Virtualize/Storwize must detect the LUN, ensure that you keep that LUN in the unmanaged  state until full access is granted. 

Native backend controller copy services can also be used for LUNs not managed by the IBM Spectrum Virtualize/Storwize. Note that accidental incorrect configurations of the backend controller copy services involving IBM Spectrum Virtualize/Storwize attached LUN can produce unpredictable results. 

For example, if you accidentally use a LUN with IBM Spectrum Virtualize/Storwize data on it as a point-in-time target LUN, you can corrupt that data. Moreover, if that LUN was a managed disk in a managed disk group with striped or sequential volumes on it, the managed disk group might be brought offline. This situation, in turn, makes all of the volumes that belong to that group go offline, leading to a widespread host access disruption. 

## Remote Copy and code upgrade considerations 

When you upgrade system software where the system participates in one or more intersystem relationships, upgrade only one cluster at a time. That is, do not upgrade the systems concurrently. 

Attention:  Upgrading both systems concurrently is not monitored by the software upgrade process. 

Allow the software upgrade to complete one system before it is started on the other system. Upgrading both systems concurrently can lead to a loss of synchronization. In stress situations, it can further lead to a loss of availability. 

Usually, pre-existing remote copy relationships are unaffected by a software upgrade that is performed correctly. However, always check in the target code release notes for special considerations on the copy services. 

