Limitations

The topics in this section describe limitations related to Volume Shadow Copy Service and Virtual Disk Service support.

Ensuring that no shadow copy exists before you change settings that are related to FC/ISCSI initiators

If you configured Volume Shadow Copy Service and Virtual Disk Service to attach target LUN to the guest OS through the host FC/ISCSI when creating or importing a shadow copy, you must delete or mask the shadow copy with the same configuration.

Ensure that no shadow copy exists before you change settings that are related to FC/ISCSI initiators.

The ibmvss settings are as follows:
  • storageProtocol
  • VMHost
  • Vmusername
  • vmpassword
  • vmdomain
The hardware or OS settings are as follows:
  • enable/disable host FC/ISCSI HBA
  • enable/disable host software ISCSI
  • enable/disable guest OS software ISCSI

Incremental FlashCopy mapping persists

Incremental FlashCopy copies only the changes to either the source or target data since the last FlashCopy operation. It is designed to enable completion of point-in-time online backups much more quickly than using traditional FlashCopy.

In IBM VSS Hardware Provider, to enable incremental FlashCopy mapping, type: ibmvcfg.exe set incrementalFC Yes.

Once set to incremental, all FlashCopy created is incremental until you return to regular FlashCopy by typing ibmvcfg.exe set incrementalFC No.

Assume an Incremental FlashCopy mapping called "fcmap1" has been created, where F1 is the source volume mapped to host and F2 is the target volume. Then F1 can be used as a source volume in only one FlashCopy mapping. If the FlashCopy mapping is deleted from IBM VSS Hardware Provider, the target volume F2 returns to the free pool, but the FlashCopy mapping still exists in storage. When a new incremental FlashCopy using F1 as the source volume is created later, F2 and fcmap1 are reused.

Deleting and restoring cascaded FlashCopy mappings

SAN Volume Controller and Storwize 7000 can minimize the overhead required to maintain multiple snapshots of the same source volume by putting the target volumes into a cascade where each target is dependent on changes recorded in target volumes of subsequent snapshots.

For example, assume that four VSS snapshots are created of a source volume, where S is the source volume and T1 through T4 are the targets, T1 being first chronologically and T4 the last. The following cascade occurs: S > T4 > T3 > T2 > T1

With this type of cascade relationship, a copy-on-write process is needed only between the source volume and the latest FlashCopy target. Any blocks that remain unchanged on the source volume are not copied at all.

In IBM VSS Hardware Provider, to enable cascading FlashCopy mapping, type ibmvcfg.exe set backgroundCopy 0.

To disable cascading FlashCopy mapping, type ibmvcfg.exe set backgroundCopy <n> where <n> is a number in the range 1–100.

When enabling cascading, sequentially create the FlashCopy mappings: S > T1, S > T2, S > T3, and S > T4.

If you delete mapping S > T2, then S > T1 is also deleted, and only S > T3 and S > T4 exist.

If you later restore mapping S > T2, then S > T3 and S > T4 are deleted, and only S > T1 and S > T2 exist.