A new quarter, a new VNX Uptime Bulletin! This month is all about target releases of code and associated bugs. It’s important to keep up to date with current code releases; not only because certain newer models of disks/modules may not be supported by old code, but also because EMC is constantly fixing known problems and bugs. This VNX Uptime Bulletin headlines with VNX OE 33 updates and continues with target code for R32 and R31.

R33? Upgrade to 05.33.000.5.038 or later

If you’re running code older than R33.038, you need to upgrade ASAP. Among other fixes, there is a critical fix for an unscheduled reboot that could occur after as little as 80 days of runtime. If you can’t upgrade straight away, perform a staggered reboot by rebooting one SP and rebooting the other SP a day later.

If you’re running block dedupe, upgrading is highly recommended as well since your block pool could go offline in older code. And finally, your SP BBU self-test could run every day instead of the normal weekly test. Doesn’t sound too bad at first, but apparently some FRUs could go offline and that’s not so funny. Moral of the story: if you’re not on R33.038 -> upgrade!

Unisphere Service Manager Automatic Update Notification

A new feature in Unisphere Service Manager (USM) 1.3.2.1.0051 is the auto-notify feature. What’s that you say?

Now that’s useful! After logging in to a system, Unisphere Service Manager will show this popup for 15 seconds if there’s new code available. If you happen to be getting coffee you can hover over the red exclamation mark and the pop-up will re-appear.

If you’re running R32, keep reading…

VNX OE R32 also had a case of unexpected (rolling) reboots. This has been fixed in 05.32.000.5.201 and was discussed in VNX Uptime Bulletin Q1 2013. In the meantime, additional symptoms of the original bug have been discovered. If you’re running any code older than R32.201; time to upgrade. Current target release (and also the latest release available for R32) is 05.32.000.5.209.

The latest release doesn’t fix two problem: expansion of VNX Thick LUNs with compression enabled will incorrectly allocate space in the storage pool. If you compress a thick LUN, space reservation is no longer needed since it will now behave as a thin LUN. A software defect does however still reserve this space once you expand the LUN, which will cause a couple of problems for your pool. The recommendation is to NOT expand any compressed thick LUNs until the problem is fixed. Should you need to expand anyway, first decompress the LUN (disable compression and wait for it to complete) and then expand and compress the LUN again.

The second problem has to do with creating snapshots via the CLI. This results in an incorrectly allocated Snap Mount Points (SMPs) allocated to SPA, if you happen to forget to specify a default owner in the command. This will cause unwanted back-end traffic and trespasses if the original LUN is owned by SPB. Quick workaround for this: don’t use the CLI to create snapshots, use the GUI for the time being.

And for the R31 users…

If you’re running code prior to 05.31.000.5.720, the Unisphere GUI might stop functioning after 497 days of uptime. Check out KB article 90301 to verify you’ve hit this bug and how to work around it. Basically a controlled reboot will fix it; as a precaution you’ll have to disable write cache which unfortunately will result in a pretty hefty performance penalty during the corrective action. So if you’re running R31, do upgrade to the target release which is 05.31.000.5.727.

For more detail, read the full VNX Uptime Bulletin over here.