DELL EMC Unity OE Version 188.8.131.529309879
What’s New in DELL EMC Unity OE Version 184.108.40.2069309879
This release (DELL EMC Unity OE Version 220.127.116.119309879) has no new feature but there is lot of fixes for problems in the previous versions. DELL EMC recommends that updating Unity OE to this version to preventing impact of the below problems in production environments.
OE Upgrade process is very simple and reliable in EMc Unity storage array compare to EMC VNX. Just you should check and correct multpathing configurations in operating systems. Based on my experiences even you have Oracle Database servers in your environment, there is some configuration on Oracle DB that should be applied before doing storage OE upgrade process.
Read the below articles from Red Hat and Oracle about Oracle ASM heartbeat timing and apply proper configuration on Oracle then start OE upgrade process:
Fixed Issues in DELL EMC Unity OE Version 18.104.22.1689309879
Looking the release note, EMC has fixed 19 issues in this release. If you faced with issues and if not, applying this release assure you about storage array reliability.
- An SP reboot occurred due to a race condition when accessing the mount point vnode to get user file system information if the file system had been unmounted.
- During initial copy or data re-syncing after the synchronous replication FC link recovers from a disconnection, user may see the session status change to non-recoverable error and cannot be recovered by a pause or resume operation.
- If KMIP servers are reconfigured, but the KMIP configuration settings on the storage system are not also updated, a dual-SP reboot will result in both SPs going into Service Mode.
- Some UEMCLI operations, such as LUN creation, can take an extended time to complete (such as up to 100 seconds).
- When many files were being created and deleted at the same time, autoshrink was triggered and tried to reclaim space, and the file system sometimes went offline.
- Service command svc_dataprotection delete operations sometimes failed.
- An SP reboot occurred during an upgrade.
- An SP reboot occurred when it did not receive a MAC address from the SSH client while deciphering an SSH packet.
- On a NAS server configured with multiple network interfaces, there was a condition that caused the SP to reboot when the NAS server was being shut down. This led to SPA rebooting when it tried to come back online if SPB was already in Service Mode.
- High latency was seen on VMWare datastores during XCopy clone operations. VMs on ESXi hosts with PowerPath installed also sometimes temporarily lost access to LUNs.
- A single SP reboot occurred during an NFS IMT migration when there was some instability in the network.
- Data Reduction was not enabled after a NAS server import session was created, even if during the session creation Data Reduction was selected.
- On [email protected] systems, refer to DTA 525499 before upgrading or installing any new software on your storage system. If a traditional pool has been created, and later destroyed, then another traditional pool created on the same drives, a data loss may occur the next time a storage processor is rebooted for any reason. This situation can be avoided by following the guidance in DTA 525499.
- When trying to remove all LDAP servers not returned by DNS, an SP reboot occurred.
- While running an NDMP backup for an asynchronous replication destination, the following could have occurred:
- A non-failover/failback destination: The VDM replication session refreshed while the backup was running, causing the backup to fail.
- A failover/failback destination: The NDMP backup session failed over and resumed, then the NDMP backup was run on the original destination and failed back and the VDM session refreshed, causing the NDMP backup on the source to fail.
- A file system went offline when a normal empty file changed into a directory file after FSCK implementation. The following error was reported: Unexpected state VNON in lookupComp.
- After an NFS or CIFS import session was cutover, if the import session was canceled and there were network connectivity issues between VNX and Unity systems, the cancel operation stopped responding.
- Hundreds of file synchronous replication sessions were running from Site A to Site B, and asynchronous file replication sessions were running from Site A to Site C. Site A went down, and a user cabinet failover was performed to Site B for the synchronous replication sessions. When Site A recovered, the replication connection with Site B could have been disconnected. Validating the Site A-to-Site B connection failed. A reboot of Site A recovered the connection.
- After a CIFS import session cut over, shares were inaccessible.