SRM 5.1.1 and vSphere Replication 5.1.1 released

As of this evening, both Site Recovery Manager and vSphere Replication have been updated and the 5.1.1 release is now available.  I strongly recommend this build as even though there is little in the way of new functionality, it is almost completely filled with things that make SRM and VR work better.

Some of the fixed issues, for example, are things like:

• All sorts of timeout problems ranging from multiple operation timeouts to reprotect timeouts to HBA rescan timeouts
• Custom vCenter https ports now work better with vSphere Replication
• Pairing SRM servers using custom certificates and VCVA now works
• Re-protect using vSphere Replication is more resilient

Two things in particular that I want to highlight though are really nice to see are listed below.

For a long time we’ve seen some situations where an SRA might respond as having completed an action, but the storage device was not fully ready yet.  This would lead to undetected datastores, timeouts, missing datastores or VMs.  The solution has always been to set the advanced setting “storageProvider.hostRescanRepeatCnt” to a higher number, to have SRM rescan the devices a number of times (sometimes many times depending on your situation!) to make sure all the devices are being picked up.  This worked usually just fine, but introduced extra load on the systems as all the devices get scanned and rescanned  and takes time and introduces unnecessary load on the hosts and the arrays.

With 5.1.1 we have introduced a new advanced setting under “storageProvider” called “storageProvider.hostRescanDelaySec” that will (instead of rescanning X number of times) have SRM *delay* X number of *seconds* before issuing a rescan of the devices.

This is a much better way to do this.  It’s a non-intrusive no-load way to have SRM pause if needed between the SRA completing its task, and rescanning to look for devices – just in case you’ve got one of those arrays that takes its time to settle down despite the SRA saying it’s completed.  It’s not necessary for everyone to set this – you’ll know if you need to if your devices aren’t showing up correctly despite the SRA and SRM saying storage devices have been attached and mounted.

So those of you who have previously used storage.Provider.hostRescanRepeatCnt, please switch over to using storage.Provider.hostRescanDelaySec when you move to 5.1.1!

The other thing that is very nice, is that we now have an upgrade path from 5.0.2 to 5.1.1!  Our previous releases chronologically ended up with 5.0.2 being released *after* 5.1, so we had no upgrade mechanism to move from 5.0.2 to 5.1.  The 5.1 code had never been aware of 5.0.2 and there was no testing or upgrade code in place to do so.  With 5.1 we can now do so.  So those of you who have moved to 5.0.2 now have the option of doing an in-place upgrade to get your system to 5.1.1.

That said, you can also upgrade from any of 4.1.2, 5.0.2, 5.1 or 5.1.0.1, so lots of options there, but 5.0.2 is the one sore thumb that gets healed with this release.

Again, as always, my personal recommendation is to upgrade your protected site first in order to retain failover ability with a static version at the recovery site.  You’ll need to upgrade your protected vCenter first to 5.1, then SRM from 5.0.x to 5.1.1, then your recovery site vCenter, then your recovery site SRM.

And don’t forget – if you’re upgrading SRM to 5.1.1 and you’re using vSphere Replication, you’ll also need to upgrade your VR appliances to 5.1.1.

Take a look and peruse closely the release notes, then go do your upgrade!