Release Notes P/N REV A04 July 7, 2006

Transcription

1 cre EMC CX-Series SnapView For FLARE OE Version yyy Release Notes P/N REV A04 July 7, 2006 These release notes contain supplemental information about the following EMC products: SnapView version xxx software. Topics include: Product description... 2 New features and changes... 4 Environment and system requirements... 5 Fixed problems... 6 Known problems and limitations Technical notes Documentation Software media, organization, and files Installation Troubleshooting and getting help

2 Product description Product description SnapView Admsnap EMC SnapView is a storage-system-based software application that allows you to create a copy of a LUN by using either clones or snapshots. You can use the clone or snapshot for data backups, decision support, data modeling, software application testing, or as a base for temporary operations on the production data without damaging the original data on the source LUN. A clone is an actual copy of a LUN and it takes time to create. A snapshot is a virtual point-in-time copy of a LUN and takes only seconds to create. Depending on your application needs, you can create clones, snapshots, and snapshots of clones. The admsnap program runs on host systems in conjunction with SnapView running on the CLARiiON storage processors (SPs), and lets you start, activate, deactivate, and stop SnapView sessions. All admsnap commands are sent to the storage system through the Fibre Channel bus. The admsnap utility is an executable program that you can run interactively or via script. For all Microsoft Windows and UNIX platforms, flush cached data from the production host before you start a snapshot session, and before you fracture the clone; likewise, flush cached data on the secondary host before you commence a synchronization or reverse-synchronization operation. Failure to do this may result in an inconsistent or unusable point-in-time copy. Refer to the EMC Admsnap Release Notes (P/N ) for detailed information related to the admsnap command and the CLARiiON VSS Hardware Provider. SnapView rollback SnapView rollback is a feature that allows the system administrator to unsnap a SnapView source LUN, instantly restoring its contents from a different point-in-time version. Any persistent SnapView session can be rolled back in a way that appears instantaneous to host computers, without destroying any of the source LUN sessions or snapshots. The production host's view of source LUN contents changes immediately, though actual data copying back to source LUNs runs invisibly in the background at a user-controllable speed. 2

3 Product description The source LUNs that are the target of a rollback operation remain accessible and accept host I/O during and after the rollback; any new data written from the host supersedes data being rolled back from the session. A rollback operation is non-destructive: the source LUNs other sessions are unaffected by the rollback and can still be accessed with their snapshot LUNs. The session being rolled back is also unaffected, except that any snapshot associated with it becomes temporarily inaccessible to host I/O for the duration of the rollback operation. CLARiiON VSS Hardware Provider Included with this software is the CLARiiON Hardware Provider for Microsoft s Volume Shadow Copy Service on Microsoft Windows Server The implementation of this hardware provider allows a Windows Server 2003 application, using the VSS API, to create/manage SnapView snapshots and SnapView clones on CLARiiON Fibre Channel storage systems without the explicit use of traditional CLARiiON user interfaces such as SnapView admsnap and/or Navisphere software. VSS is part of Microsoft s storage initiative for Windows Server VSS provides coordination between writers, requestors, and providers. Writers are applications that can write to volumes and participate in the shadow copy synchronization process. Requestors initiate the creation and destruction of shadow copies. Providers own the shadow copy data and enable host access to the shadow copies. Refer to the EMC Admsnap Release Notes (P/N ) for detailed information related to the admsnap command and the CLARiiON VSS Hardware Provider. 3

4 New features and changes New features and changes This release contains cumulative changes to the SnapView x.xxx software release. These changes include the following: Clones Increased limits The maximum number of clone groups per storage system has been increased to 100 for the CX700 platform and 50 for the CX300 and CX500 platforms. The maximum number of clones per storage system has been increased to 200 for the CX700 platform and to 100 for the CX300 and CX500 platforms. Although the number of MirrorView primary and secondary images still count against the total clone limit per storage system, the number of clone sources (clone groups) no longer count toward this limit. Clones Consistent fracture This feature allows the user the ability to fracture a set of clones as a group atomically, without regard to SP ownership, while maintaining host ordered write dependencies across the source LUNs for which the clones are associated. SnapView Consistent start This feature allows the user the ability to start a SnapView session as a consistent session on a set of source LUNs atomically, without regard to SP ownership, while maintaining host ordered write dependencies across the set of source LUNs. Admsnap Consistent start This feature allows users of admsnap to perform a SnapView consistent start operation on a heterogeneous, comma (, ) separate list, of operating system objects. 4

5 Environment and system requirements Environment and system requirements Hardware Storage-system software Operating systems This section identifies the hardware and software supported by SnapView x.xxx. SnapView software is supported on CX300, CX300i, CX400, CX500, CX500i, CX600, and CX700 storage systems. This version of EMC SnapView requires FLARE Operating Environment Version In addition, the Access Logix and SnapView enablers must be installed. Refer to the EMC Support Matrix for a complete listing of operating systems supported by SnapView, VSS, and admsnap. Navisphere Management Software SnapView is compatible with the following minimum revisions of EMC Navisphere Management Software: Navisphere Host Agent 6.19.x.x.x Navisphere CLI 6.19.x.x.x Navisphere Manager 6.19.x.x.x Navisphere SP Agent 6.19.x.x.x 5

6 Fixed problems Fixed problems Visit the EMC Powerlink Issue Tracker website at for the most recent updates and information on previous SnapView releases. Problems fixed in this update xxx.034 SnapView clones. Initial synchronization of a newly added clone may appear to complete instantly without copying any data to the clone. [141667] Frequency: Infrequently under a specific set of circumstances. Effect: The clone appears to be synchronized but no data was copied from the source. Only occurs if the source is trespassed while the initial clone synchronization is queued to be synchronized. Prevention/resolution: Fixed in this update. SnapView clones. During a shutdown, an internal operation may not complete on time, causing a single SP panic. [138901, ] ly during a specific event. Effect: One of the storage processors may panic and reboot. Prevention/resolution: Fixed in this update. SnapView clones. A single SP panic may occur under heavy I/O load. [134606] ly during a specific event. Effect: One of the storage processors may panic and reboot. Prevention/resolution: Fixed in this update. Problems fixed in update xxx.030 SnapView. MirrorView/A and incremental SAN Copy did not work properly on LUNs larger then 2 TB. [129383] SnapView. System performance would decrease over time due to a memory leak. [136860] SnapView clones. During a storage system shutdown, an internal operation may fail and cause an SP to bugcheck. [130165, ] Frequency of occurrence: Frequent Effect: The storage system would become unmanaged. Prevention/resolution: Fixed in this update. Frequency of occurrence: Frequent. Effect: The storage system will log an error notifying that the Navisphere agent has exceeded the resource threshold affecting the system performance. Prevention/resolution: Fixed in this update. Effect: One of the storage processors may panic during a scheduled reboot operation. Prevention/resolution: Fixed in this update. 6

7 Fixed problems SnapView clones. If an error occurs accessing the clone private LUN (CPL) during host I/O processing for the source LUN, the host write requests may fail. [134177] Effect: This error may result in the clone source LUN being inaccessible. Prevention/resolution: Fixed in this update. Problems fixed in update x.016 SnapView clones: If soft logical sector data errors (bad blocks) are encountered while performing a clone synchronization or reverse-synchronization operation, these bad blocks will not be replicated to the source LUN. [129763] Effect: Soft logical sector data errors (bad blocks) indicate that the data redundancy information for a sector stored on a redundant LUN is not valid. These errors occur because a power failure or FRU failure interrupted a write in progress. If bad blocks are encountered while performing a clones synchronization or reverse-synchronization operation, these bad blocks will not be replicated to the source LUN. Prevention/resolution: Fixed in update x.016. The new software replicates bad blocks to the source LUN during synchronization and reverse-synchronization operations. Problems fixed in initial release SnapView clones. An error will be returned while committing the storage-system software package if a clone source LUN or clone LUN is doublefaulted. [112814] SnapView clones. In-flight host writes to a clone s source LUN are not persistently tracked while processing a clone synchronization. [113813] SnapView clones. Panic while cleaning up staged data on peer SP during clone operations. [116087] Effect: If this error occurs during a commit operation, various storage-system features associated with the newly loaded storage-system software package may not be available. Effect: If an SP reboots while processing a synchronization with in-flight host writes to the source LUN, a subsequent synchronization or reverse synchronization operation may not copy all the necessary data to the destination LUN. Effect: If an error occurs during a clones operation that requires coordination with the peer SP, a single SP panic may occur while cleaning up from this failed operation. 7

8 Fixed problems SnapView clones. Panic while enabling the protected restore feature on a storage system [116316] SnapView clones. Memory leak while disabling the protected restore feature on a storage system. [116734] SnapView clones. Clones feature is left in the device stack after SP panic. [116803] SnapView clones. Panic occurs when clone group is trespassed. [117172] SnapView clones. Reverse synchronization operation remains in the synchronization queue indefinitely. [117685] SnapView clones. Clones are stuck in the stack of a LUN after a create clone group operation fails because of limited memory resources. [117843] SnapView clones. The bit reference count for the protected restore log is incremented before being flushed to persistent storage. [118099] Effect: If there are not enough memory resources available when the protected restore feature is enabled on the storage system, a single SP panic may occur. Frequency of occurrence: Frequent (when disabling protected restore) Effect: While disabling the protected restore feature on a storage system a very small amount of memory is lost. Effect: If an SP reboots while a create clone group or add clone operation is in progress, the LUN may become unusable by layered features. This may also cause a device stack corruption problem that may render the SP unmanageable after an SP reboot. Effect: If clone groups are being trespassed to a single or dual SP, a panic may occur. Effect: If an SP reboots while a clone reverse synchronization operation is queued, the reverse synchronization operation may remain in the synchronization queue indefinitely. Effect: If there are not enough resources available during the creation of a clone group, clones may become stuck in the stack of the source LUN. This LUN cannot be unbound or used by clones, MirrorView/Asynchronous, or MirrorView/Synchronous. Effect: If an SP reboots during a protected restore operation with in-flight host writes to the source LUN, all the necessary data may not be copied to the source LUN once the protected restore operation resumes. 8

9 Fixed problems SnapView clones. A single SP panic occurs while creating a clone group. [118348] SnapView clones. If an error occurs while reading clone data from disk, the error code may become corrupted causing Navisphere to go into degraded mode. [118411] SnapView clones. During a reverse synchronization operation, changes to the fractured clones in the clone group may not be tracked persistently. [119151] SnapView clones. If a clone synchronization operation completes, the persistent fracture logs bits for another synchronizing clone within the same clone group may be lost. [120533] SnapView clones. The last 32 bits of the protected restore log may become corrupted during a protected restore operation. [120585] SnapView clones. Storage system goes into degraded mode after trespassing a clone LUN. [120827] SnapView clones. Single SP panic may occur if a clone is unable to read from persistent storage (PSM).[121692] Effect: A single SP panic may occur while creating a clone group if the protected restore feature has been recently enabled or disabled. Effect: If an error occurs while reading clone data from disk, the error code may be corrupted before it is returned. This may cause Navisphere to go into degraded mode making the SP unmanageable. Frequency of occurrence: Frequent (during reverse synchronization) Effect: If an SP reboots after a reverse synchronization has been performed, a subsequent synchronization or reverse synchronization operation may not copy all the necessary data to the destination LUN. Effect: If an SP reboots after a synchronization operation has completed to a clone while another synchronization operation is still in progress to another clone in the clone group, the synchronization operation, when continued, may not copy all the necessary data to the destination LUN. Effect: If an SP reboots during a protected restore operation, the last 32 bits of the protected restore log may become corrupted causing writes sent to the source LUN during the protected restore operation (before the reboot) to be lost. Effect: If an SP panics causing a clone LUN to be trespassed to the peer SP, one or both SPs may go into degraded mode after multiple panics. Effect: If an error is returned to a clone while reading from persistent storage (PSM), a single SP panic may occur. 9

10 Fixed problems SnapView clones. During an SP boot, the communications path between SPs is established before the fracture log bits are populated from persistent storage. [121710] SnapView clones. Clones added to an unowned clone group do not synchronize.[121799, ] SnapView clones. If a clone private LUN becomes unavailable for I/O, clone fracture logs and/or protected restore logs cannot be stored persistently. A single SP panic may occur on the SP that owns the clone private LUN.[122892] SnapView clones. The protected restore log from the peer SP is not merged into the local protected restore log during an SP reboot.[123818] SnapView clones. A clone s fracture log is not transferred during a trespass operation if the clone is involved in a protected restore operation.[124437] Effect: If an SP is booting while a synchronization or reverse synchronization operation is started on the peer SP, a single SP panic may occur or the synchronization or reversesynchronization operation may not copy all the necessary data to the destination LUN. Frequency of occurrence: Very Frequent (if clone group source LUN is unowned) Effect: If the LUN specified as the source during the creation of a clone group is unowned (owned by an SP that is down and has not trespassed), any clones added to the clone group will become out of sync. Subsequent clone operations will fail. Trespassing the source LUN while the SP that owned the LUN is still down will cause the clone to transition to the synchronized state without having any data copied to it. Frequency of occurrence: Very Frequent Effect: The logs used to track changes to a source and its clones cannot be read from or written to if a clone private LUN is unavailable for I/O. Prevention/resolution: In this release, clone private LUN errors will not cause a single SP panic. Instead, an error message will be posted to the event log when clone private LUN errors occur. This message will contain information on the error that occurred, how to prevent this error from recurring, and how to recover from the error. Effect: If a clone group involved in a protected restore operation is trespassed to the peer SP, write requests to the source LUN while the protected restore is queued may not cause data to be copied from the clone to the source. Effect: If a clone group involved in a protected restore operation is trespassed to the peer SP and then both SPs reboot during the same protected restore operation, the protected restore operation may not copy all the necessary data to the destination LUN. 10

11 Fixed problems SnapView clones. Possible memory corruption caused by clones closing a handle twice. [124536] SnapView sessions. SnapView stops all sessions for a LUN whose logical block capacity is not a multiple of 64 Kb and I/O is issued to the last block of the LUN. [122570] SnapView sessions. SnapView may bugcheck stopping a non-persistent session if the session trespasses during the stop operation. [114925] SnapView sessions. SnapView sessions will stop and the reserved LUNs may change state to unowned when the LCC for an enclosure has failed or is replaced. [91459, ] SnapView sessions. Rolling back a session may fail with an unrecognized error code 0x37. [108966] SnapView snapshots. Using multiple active snapshot devices for a single source LUN may cause SnapView to not track data updates properly if the session trespasses. [120045] SnapView snapshots. SnapView may bugcheck when destroying a snapshot device. [116252] SnapView and MirrorView /A. A MirrorView /Asynchronous (MirrorView/A) group may fail to synchronize, indicating there are not enough reserved LUNs. [120047] SnapView and MirrorView/A. SnapView may result in an SP bugcheck under heavy I/O load when using MirrorView/A. [121883] Effect: Closing a handle twice may set bits in a section of memory unowned by clones resulting in a memory corruption. This could result in a variation of unexpected behavior. Frequency of occurrence: Frequent if the LUN is a Windows Dynamic Drive. Effect: The sessions on the LUN will stop and must be restarted.. Effect: The SP will bugcheck and reboot. Effect: The SnapView reserved LUNs for the peer SP would be displayed as unowned. Effect: The source LUN would be marked private. Effect: The session would need to be deactivated and activated and the updates reapplied. Workaround: Activate only one snapshot device per session at a time. This does not restrict having multiple snapshot sessions active on the storage system.. Effect: The SP will bugcheck and reboot. Effect: The MirrorView/A group would fracture. Effect: The SP would bugcheck and reboot. 11

12 Fixed problems SnapView and MirrorView/A. A MirrorView/A LUN may enter the Admin Fractured state and remain fractured even after performing a synchronization. [108962] SnapView and MirrorView/A. A MirrorView/A LUN may permanently fracture. [109370] SnapView and SAN Copy. SnapView may bugcheck during incremental SAN Copy mark operations. [115728] Effect: The mirror would not be accessible. Effect: The mirror would remain fractured and need to be destroyed and recreated.. Effect: The SP will bugcheck and reboot. 12

13 Known problems and limitations Known problems and limitations This section contains information and/or limitations that could adversely affect the performance of the storage system if any listed workaround or fixes are not implemented. Visit the EMC Powerlink Issue Tracker website at for the most recent updates and information on previous SnapView releases. Generic problems (apply to all platforms) SnapView clones. Starting a protected restore while I/O is being written to the source, may cause erroneous mirroring of I/O to the clone. [142780] Frequency of occurrence: Rarely during a specific event. Effect: The clone or source may become unusable. Prevention/resolution: If the recommended procedure of unmounting the source before starting the reversesynchronization is followed, this problem will never occur. SnapView clones and SAN Copy. Navisphere CLI and Manager return an error message while creating a clone group. [77906] SnapView clones. If a clone group is created using an unowned LUN as the source, a subsequent reboot may cause the LUN to become unowned again, resulting in unexpected clone behavior. [121767] SnapView clones. A single SP panic may occur when trespassing clone groups with unfractured clones. [117368] Frequency of occurrence: Always (If selected LUN was previously part of a SAN Copy session, this will always occur.) Effect: The software returns the following error while creating clone group: Creating Clone Group failed. Error occurred while adding Clone driver to LUN s extended attributes. This error could mean (among other things) that the LUN is, or was once, part of a SAN Copy session. Prevention/resolution: Use the Navisphere CLI setfeature command to remove the SAN Copy feature from the LUN. Effect: If a clone group is created and the specified source LUN is default owned by an SP that is failed, the source LUN will be trespassed to the functioning SP. If that SP reboots, the source LUN may become unowned causing the clones in that clone group to behave unexpectedly. Prevention/resolution: Only perform the creation of clone groups while both SPs are available or ensure the LUN being used as the source is owned by the available SP. Prevention/resolution: Limit the frequency of clone group trespassing and keep the clones in a fractured state. 13

14 Known problems and limitations SnapView clones. A reverse synchronization operation may get stuck and not make any progress. [122906] SnapView clones. A LUN expansion on a clone may not automatically continue after recovering from a double-disk failure. [124324] SnapView clones. A clone may not be able to be fractured or synchronized if the owning SP is unable to process administrative operations. [125565, ] SnapView clones. A single SP panic may occur if a clone LUN is trespassed during an NDU operation. [127122] SnapView. Once you remove a LUN from the SnapView reserved LUN pool, it is unowned. [75223] SnapView. When the storage system terminates a SnapView session due to an unexpected event (trespass, reserved LUN exhaustion, SP reboot), a warning message is not posted to the management station. [59416] Prevention/resolution: If a reverse-synchronization operation is stuck and not making any progress, fracture the reversesynchronizing clone and reissue the reverse-synchronization operation. Prevention/resolution: If a clone LUN expansion does not restart after recovering from a double-disk failure, fracture the clone and perform a synchronization operation to the clone. Prevention/resolution: Manually trespass the clone source LUN to the peer SP and reissue the operation or reboot the SP that is unable to process administrative operations. Prevention/resolution: Administratively fracture all clones prior to performing an NDU operation. Frequency of occurrence: Whenever a LUN is removed from the SnapView reserved LUN pool. Effect: The LUNs are unowned, and the LUN must be trespassed to allow an SP to take ownership of the LUN. Prevention/resolution: To start using a LUN that has been removed from the SnapView reserved LUN pool: 1. The LUN must be explicitly trespassed using Navisphere, which forces an SP to take ownership of a LUN. 2. Add the LUN to the attached host s storage group. The attached host can now access the LUN. Frequency of occurrence: Always Effect: When the system ends a SnapView session, Navisphere Manager will display offline next to the SnapView session's icon in the Enterprise window. Prevention/resolution: Check the SP event log to determine the cause of the termination of the SnapView session, and correct the condition that generated the session termination. 14

15 Known problems and limitations SnapView with MirrorView. A SnapView session cannot be started and a snapshot cannot be created on a MirrorView secondary image LUN during the synchronization of the image. [67991] SnapView. The listing of the SnapView reserved LUN statistics may display negative values. [78395] SnapView sessions. Heavy I/O to a SnapView session may cause the storage system to respond slowly to Navisphere requests. [78394] SnapView persistent sessions. SnapView persistent sessions may trespass when a storage processor is rebooted even if the attached host did not issue I/O requests to the sessions. [82215] SnapView rollback and dynamic disks. A SnapView session that contains a dynamic disk that is rolled back to the production host using SnapView cannot be imported on the production host using admsnap. [88012] SnapView rollback. If a rollback operation is initiated on a LUN while the peer SP is rebooting, then it is possible for the rollback to fail and the LUN to go private. SnapView reserved LUNs. Configuring reserved LUNs on the system drives may cause the storage system to respond slowly or reboot one SP. Frequency of occurrence: Always Effect: The operation fails and the command must be retried after the synchronization completes. The software produces two distinct error messages (one for starting a session, and one for creating a snapshot). Prevention/resolution: Starting a session or creating a snapshot on a MirrorView LUN that does not currently have a snapshot will cause a restacking of the device to insert SnapView, which is not allowed during a MirrorView synchronization. This prevents the creation of an inconsistent view of the data. ly Effect: The save area usage statistics are inaccurate. Prevention/resolution: Trespass the SnapView sessions to the original owning (default) SPs. ly Effect: The storage system responds slowly to Navisphere Management requests. Prevention/resolution: When this has been observed, the SnapView source or snapshot reserved LUNs were created on the PSM LUNs. Resolve this problem by creating the LUNs from a different RAID group. ly Effect: The persistent session will trespass. Prevention/resolution: The LUN(s) can be trespassed back to the default SP. Frequency of occurrence: Frequently Effect: Dynamic disks must be imported using the Disk Administrator or the Microsoft Diskpart utility. Prevention/resolution: Import the volume using the Diskpart utility. Frequency of occurrence: Rare Effect: The LUN becomes unavailable to its host. Prevention/resolution: Do not request a rollback of a LUN unless both SPs are up and fully operational. If you do encounter this issue, please contact your service provider for assistance in recovering. Frequency: Infrequent Effect: Configuring the reserved LUNs on the system LUNs will force Snapview to compete for the system resources. Excessive load on these LUNs may cause poor response time or one storage processor to reboot. Prevention/resolution: Do not allocate reserved LUNs from the system LUNs. 15

16 Known problems and limitations SnapView reserved LUNs. SnapView does not properly trespass allocated reserved LUNs that are metaluns. [106392] SnapView reserved LUNs. Adding 100 LUNs to the reserved LUN pool takes a very long time. [100808] Frequency of occurrence: Frequently Effect: Some components of the reserved LUN will be owned by different storage processors. Prevention/resolution: None at this time. Frequency of occurrence: Frequent Effect: The operation may take a long time to complete or timeout errors may occur. Prevention/resolution: Add LUNs to the reserved LUN pool in multiple operations with smaller LUN counts. Platform-specific problems SnapView and VERITAS. SnapView save area usage may be significant when synchronizing a VERITAS mirror. [75026] Clones and Solaris. Clones copies each sector of the LUN to the clone LUN and can result in the format command not displaying the volume label correctly. Frequency of occurrence: Always Effect: SnapView save area allocation is significant and may exhaust the save area for the storage processor. Prevention/resolution: 1. On the production host unmount the file system and then start the SnapView session using Navisphere CLI. 2. Make sure that the snapshot save area free capacity is larger (5% larger should be sufficient) than the size of the VERITAS mirror image. This is because the synchronization being done by the software on the second host will write the entire mirror and you will need the extra SnapView save area space to hold the data. 3. On the second host, once the snapshot has been imported to VERITAS, break the mirror prior to letting VERITAS start. An alternative workaround is to create a snapshot save area LUN that is larger (5% larger should be sufficient) than the LUN you will mirror. This will avoid exhausting the reserved LUN pool. Frequency: Infrequent Effect: During the format process, Solaris writes a label on each LUN. This label includes a vendor ID specific to the manufacturer of that LUN, and geometry information specific to the vendor, LUN size, and other LUN characteristics. Solaris reads this information whenever the disk is opened, either for raw I/O or by a mount command. If the disk is partitioned, then Solaris uses the geometry information in the label to determine the locations of partitions. When a clone synchronizes or reverse-synchronizes a LUN, it copies all modified blocks, possibly including those that comprise the label. After the synchronization operation, values in the label may be incorrect with respect to the source or clone LUN. The Solaris format command uses this label and may display incorrect information for the LUN. The data on the LUN is not impacted and this failure is harmless. Prevention/resolution: None. 16

17 Known problems and limitations SnapView rollback and Solaris. Solaris may panic if the host mounts the source LUN during the rollback operation. [133005] Frequency: Very Infrequent Effect: The Solaris host will panic and reboot. This has been observed only on early Sun systems, such as the Enterprise Prevention/resolution: Before mounting the source LUN on the production host, allow the rollback operation to complete. 17

18 Known problems and limitations Configuration limitations The configuration guidelines for SnapView x.xx are listed in the following table: Parameter CX700 CX600 CX500 or CX500i Clones CX400 CX300 or CX300i Per storage system 200 a 100 a 100 a 50 a 100 a Per source LUN Clone groups Per storage system Clone private LUNs Per storage system (required) Snapshots b Per storage system Per source LUN SnapView sessions b Per source LUN Reserved LUNs Per storage system a. Includes MirrorView primary and secondary images. The source is no longer counted toward the image limit. b. The limits for snapshots and sessions include SnapView snapshots or SnapView sessions as well as reserved snapshots or reserved sessions used in other applications, such as SAN Copy (incremental sessions) and MirrorView/Asynchronous applications. 18

19 Technical notes Technical notes This section contains information that will help with the installation, use, and management of the storage system. It provides generic information that applies to all platforms and platform-specific information, except for Hewlett-Packard Tru64 systems. Generic notes (apply to all platforms) Aggregate LUNs for the reserved LUN pool. Aggregate LUNs are now available to be used in the reserved LUN pool. This was restricted in earlier releases. Deprecated commands for this release. The following CLI commands are deprecated for this release. They will no longer be supported in the future: Snapview get cachechunksize Snapview set cachechunksize Snapview listcache (use reserved lunpool list) Snapview addluntocache (use reserved lunpool addlun) Snapview rmlunfromcache (use reserved lunpool rmlun) The get/set chunk size commands are no longer supported because chunk size is no longer changeable. The other commands have been replaced with the reserved lunpool commands. SnapView and SAN Copy. SnapView sessions are created to support incremental SAN Copy sessions. These sessions count towards the eight-session limit for a source LUN. SnapView Persistent sessions. All persistent sessions on a source LUN that were created prior to version 2.3 must be stopped before an incremental SAN Copy session can be created on that source LUN. Once all of the sessions are stopped on a source LUN, the SAN Copy session and SnapView sessions (persistent and non-persistent) can be started in any order. SnapView Persistent sessions. Starting with SnapView version 2.0, persistent sessions are available, which survive host trespasses and SP reboots. 19

20 Technical notes SnapView - Reserved LUN model. As of SnapView version 1.3, the snapshot reserved LUNs are dedicated on a per-source-lun basis instead of on a per-sp basis. For details on how the reserved LUN model works and to determine an appropriate snapshot reserved LUN size, refer to the EMC SnapView Administrator's Guide for Navisphere (P/N ). SnapView - Upgrading. To ensure a correct and orderly upgrade process, the installation software sets the storage-system cache sizes to 0, and disables caching, as part of the software installation (NDU) process. After the upgrade, you must redefine the cache settings to appropriate values (possibly less than the previous values) and then enable caching. SnapView clones. If SnapView clones enter a degraded mode, you will have to reboot the SP to clear the condition. SnapView clones Synchronization. On a CX400 storage system, you should perform clone synchronization operations using either a medium (which is the default) or slow synchronization rate. SnapView clones. Percent Synchronized value gets reset to 0 percent if a source LUN or a clone LUN is expanded when a synchronous or a reverse-synchronous operation is in progress. The data previously synchronized or reverse synchronized is not resynchronized if this happens. SnapView Memory budget and cache usage. SnapView version and later removes the limitation of the memory budget. This means SnapView can now exceed the capabilities of the memory budget, eliminating the cache LUN or Copy-On-First-Write upper limits. In other words, SnapView no longer imposes upper limits on the amount of data that can be modified on the source LUN. However, SnapView sessions must still have free/available reserved LUN space. A session that is stopped will free the associated space used on all of the reserved LUNs that were allocated for that session. Once the last session on a source LUN(s) is stopped, the reserved LUNs will be returned to the reserved LUN pool. SnapView - Statistics. The session statistics for I/O to the source and snapshot are not persistent and therefore are reset to 0 upon reboot or panic. This behavior is similar to the FLARE I/O statistics, which reset with every reboot. Note that cache statistics should be correct after a reboot, but session I/O statistics will reset to 0. [78941] SnapView - LUN limit. For CX700 storage systems, the total number of LUNs plus snapshot LUNs should not exceed 2348 LUNs (

21 Technical notes LUNs are storage-system LUNs and 300 LUNs are snapshot LUNs). For CX600 storage systems, the total number of LUNs plus snapshot LUNs should not exceed 1324 LUNs (1024 LUNs are storage-system LUNs and 300 LUNs are snapshot LUNs). For the CX500-series storage systems, the limits are 1174 (1024 LUNs and 150 snapshots), for the CX400-series storage systems the limits are 662 (512 LUNS and 150 snapshots) and for the CX300-series storage systems the limits are 612 (512 LUNs and 100 snapshots). Neither of these values includes the PSM LUN, which the software requires before using the application. The total number of objects that can be put in storage groups is 256. Neither the storage-system software nor Navisphere enforces the maximum LUN or maximum snapshot limit. If you exceed these limits, the following may happen: Some LUNs may be inaccessible to the host. Attempts to fail over LUNs to the peer SP may not succeed, causing the LUNs to be inaccessible. Depending on the operating system, the system will react differently when you attempt to access an inaccessible LUN. For example, Novell NetWare will fail to boot if any LUNs it expects to access are inaccessible. SnapView Chunk size. SnapView supports 64-KB chunk size only. SnapView Simulation Mode. SnapView Simulation Mode was removed in SnapView version 2.10.X. It is no longer required with the enhancements to remove the SnapView memory budget limit. SnapView Non-persistent sessions and SPs. SnapView sessions are per SP and not per storage system, so you should not start a nonpersistent session on a LUN that has failed over to the other SP, because that session will stop when the LUN trespasses back to the SP that owns the source LUN of the session. Admsnap and SnapView Non-persistent session trespass. If, for any reason, the snapshot LUN is trespassed, the SnapView sessions for that LUN will terminate. This is normal because SnapView is not resilient to non-persistent LUN trespasses. 21

22 Documentation Documentation The following documents apply to this product release and are located on the EMC CLARiiON Storage-System Hardware and Software Documentation CD (P/N ). Part number Publication EMC SnapView for Administrator's Guide EMC SnapView Command Line Interfaces Reference EMC Storage-System Software Installation Guide (on Powerlink only) Documentation updates There are no updates for this release. Software media, organization, and files The following table lists the applicable software media for this product release: Product CD part number Description SnapView SnapView Enabler CD-ROM Installation The SP names of the CLARiiON storage system must be unique for the NDU of the SnapView software to be successful. All active SAN Copy sessions must be stopped prior to the upgrade being performed. 22

23 Troubleshooting and getting help Troubleshooting and getting help Where to get help This section provides specific instructions for contacting EMC Customer Support and obtaining additional information about EMC products. EMC support, product, and licensing information can be obtained as follows. Product information For documentation, release notes, software updates, or for information about EMC products, licensing, and service, go to the EMC Powerlink website (registration required) at: Technical support For technical support, go to EMC WebSupport on Powerlink. To open a case on EMC WebSupport, you must be a WebSupport customer. Information about your site configuration and the circumstances under which the problem occurred is required. 23

24 Troubleshooting and getting help Copyright EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. However, the information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners. 24