Product Announcements

SRM 4.0 is here! The wait for vSphere and NFS support is over!

October 5 is the day that you can now use the new version of SRM to protect vSphere hosts as well as the 3.0.3 and 3.5 that it protects today.  In particular, I love using the vSphere Linked Mode support with SRM as it is a little easier to use one client for both the protected and recovery sides instead of the two clients we require now.  This article is not about the new features however, but about how to upgrade.  

 But some things to touch on first. It is actually 4.0 since our marketing people decided it would be easier for customers to see SRM and vSphere version numbers to be in sync.  This also means in the future you will not have to wait long for SRM to work with the next major releases of vSphere like you did this time.  It has something else for you to be aware of, in that SRM 4.0 requires you to use vSphere Virtual Center 4.0.  You can still protect VM’s hosted on 3.0.3, 3.5 and now 4.0 but you must use VC 4.0 and not VC 2.5.  From now on SRM will require the current version of VC to work with.  As well, SRM 1.0 licenses are not compatible with SRM 4.0.  We do not use Flex LM with SRM any longer so you will need to log into the Customer license portal to download your new SRM licenses.

So lets talk about upgrading.  You have several choices.  You can install new, with a new database, upgraded VC, and protect your VM’s with new Protection Groups and Recovery Plans, or you can upgrade.  Upgrade means to upgrade your VC, SRM, and database, and this will keep your existing PG’s and RP’s.  This is the quickest way to upgrade and keep your protection.  Doing a net new install will be generally slower.  For that reason, I recommend doing an upgrade as it will have the smallest outage in your protection.

If you would like to have a new SRM server but with your old configuration that is a little harder.  You will need to do an upgrade in place on your old SRM server, and than after that is complete and functional, you can install a new SRM server, and point it at the upgraded database.  If you want a new SRM server this is the ONLY way you can do it safely.  If this sounds a little confusing, call our Support team and we can help you with it.

While the two links below have more information about the upgrade, I did want to suggest some things. 

  1. Log into the license portal to get your new SRM 4.0 licenses
  2. Log into the SRM download page to get any updated SRA’s – not all SRA’s are necessary to be upgraded.  As a guideline, if you are going to use NFS you MUST upgrade your SRA, but if you are going to continue with iSCSI or FC you may not need to upgrade.
  3. Read the release notes, and the KB article.
  4. Start with full backups!  And test SRM so you know it works before you upgrade.  A test failover is fine here as a test of operation.
  5. Upgrade the protected side VC.  
  6. Upgrade the protected side SRM / database and plug-in.
  7. At this point you can still do a full failover if necessary so that means so far your ability to recovery has not been impacted.  You cannot protect other VM’s or anything else.  This situation is as if your protected side disappeared.
  8. Now your DR outage occurs!
  9. Upgrade your recovery side VC.  Optionally this is where you might enable Linked Mode.  I certainly did.
  10. Upgrade your recovery side SRM / database and plug-in.
  11. Install the new licenses on both sides – if you have protected VM’s on both side.  The new licenses are entered in the License Settings field in the Advanced Settings, which is accessed by <right + clicking> on Site Recovery Manager  in the navigation pane. 
  12. Perform a test failover to make sure everything works.  At this point your test failover should work, but you still have ESX hosts at the same level, VM’s have not been touched, and the only change is the VC and SRM instances that have been upgraded.  All your VM's should be still working fine.
  13. You can now wait to upgrade your ESX hosts as necessary.  I recommend starting the upgrade at the Recovery side so that your production can failover easily.  Meaning the ESX 3.x at the protected side can failover to the ESX 4 hosts at the recovery side.  But don’t upgrade the Virtual Hardware or tools yet.
  14. Ater the recovery side is upgraded to ESX 4, you should do the protected side.  But do not do Virtual Hardware or tools upgrade yet.
  15. Once both sides are upgraded to ESX 4, test SRM with a test failover.
  16. Now you can upgrade Virtual Hardware and Tools.

You are now completely upgraded, however be aware that you do not have to upgrade your hosts right away.  SRM will protect them at 3.0.3, 3.5, and 4.0.  And remember that ESX 4 VM’s can only failover to ESX 3.5 IF their VH and tools have not been upgraded yet!

Release notes –
Upgrade KB article –
SRM download –

Use the comments to let me know how your upgrades go!


Related Articles