Wow is this an exciting release! The SRM and VR developers went all out and I’m thrilled to share the details of their accomplishments with you. They focused on a number of enhancements that customers have been asking about and did a fantastic job delivering. In this post, I’m going to cover these features at a high level and then get into more detail in future posts in the coming weeks. Let’s get started!
New HTML5 User Interface
As you can see from this beautiful screenshot, SRM now has a slick new HTML5 based “Clarity” UI. This new interface supports all the functionality of the previous UI and the SRM and vSphere Replication interfaces have been merged to allow for easier navigation and improved management. Work has also gone into improving workflows and making the interface easier to use. For example, when configuring VMs for replication with vSphere Replication, as part of the same protection workflow the VMs can be added to a new or existing Protection Group and a new or existing Recovery Plan.
This merging of the interfaces of SRM with vSphere Replication extends throughout the new UI. It improves usability and reduces the time required to execute common workflows. The integration is designed in a way that it works regardless of if SRM or vSphere Replication are used together or if either product is used on its own. When SRM or vSphere Replication are accessed the new HTML5 interface opens in a new browser tab. This allows it to support the next new feature…
Flexible Site Pairing – vCenter Decoupling
SRM and vSphere Replication 8.1 have been decoupled from specific versions of vCenter. This means that SRM and vSphere Replication 8.1 can be installed with vCenter 6.0U3, 6.5, 6.5U1 or 6.7. And the same version of vCenter does not have to be run at both sites (eg Site A running vCenter 6.0U3 and Site B running vCenter 6.5). SRM and vSphere Replication 8.1 also work with VMware Site Recovery, the DRaaS offering for VMware Cloud on AWS.
This flexibility makes installation, upgrades and ongoing operations with SRM and VR much simpler and easier for customers. For example, a customer running vCenter 6.0U3 with SRM 8.1 could upgrade vCenter to 6.5 or 6.7 without impacting SRM or requiring any changes to it. This enhanced interoperability greatly reduces risk and simplifies administration.
Simplified Upgrade Path
In combination with being decoupled from a specific version of vCenter, SRM & VR 8.1 also support upgrades from more than just the previous release. Customers can now upgrade to SRM and VR 8.1 from SRM and VR 6.1.2, 6.5 or 8.0. This combined with vCenter version flexibility makes it easier than ever to utilize the latest version of SRM. It reduces the time required and the number of steps needed which combined together reduces risk and simplifies management.
Configuration Import/Export Tool
This one is huge. A lot of customers have asked for this and we listened. SRM now has a simple, easy to use tool for exporting and importing the entire SRM configuration. This allows customers to use it to backup and recover their configuration as well as to migrate between database types (eg. Export from MS SQL Import into vPostgres embedded DB). This tool is run from the command line on the SRM server at either site and it exports/imports the entire configuration.
Here is a quick summary of everything that is exported/imported:
- Protection Groups
- Recovery Plans
- Priority groupings of VMs
- VM dependencies
- IP customization settings
- Network, Folder, Resource and Storage Policy mappings
- Including IP subnet mapping rules
- Placeholder VM information
- Advanced settings
- Local and remote site addresses
- Array Managers with SRA information
Having this functionality reduces customers risk and increases manageability.
Support for more Protection Groups
SRM 8.1 now supports up to 500 Protection Groups per SRM pair, up from 250 in previous releases. This additional capacity provides flexibility for customers with large numbers of applications looking to organize their Protection Groups around individual applications.
Support for FT Protected VMs
SRM 8.1 now supports protection for VMs that require the use of Fault Tolerance. There are a few restrictions; array-based replication only, both primary and secondary FT VMs must be located on the same array consistency group and the recovery VM is recovered without FT enabled. Even with these restrictions, this added resilience should be enough to support the most critical applications.
SRM 8.1 exposes two additional APIs:
- Configure and Retrieve IP Customization Settings
- Add/remove Datastores from Array-Based Replication Protection Groups
These APIs in addition to those already exposed, make it easier than ever to automate and interact with SRM programmatically.
vSphere Replication Appliance move to Photon OS
Last but certainly not least, vSphere Replication 8.1 marks the move from SLES to Photon OS for the VR Appliance. Photon OS is a lightweight Linux distribution optimized for vSphere with a security-hardened kernel. It will provide enhanced security, stability and make upgrades and patching the appliance easier. This translates to a more secure, stable and easy to manage solution for customers.
Thanks for making it all the way through that list with me. I look forward to getting into more details on all these features in upcoming posts. I hope you are as excited about this release as I am, Happy upgrading!
13 comments have been added so far
Does vSphere replication 8.1 have the ability to support growing and adding virtual disks to a protected/replication VM yet?? Growing, adding, subtracting replicated disks is a HUGE PITA compared to without replication or with other offerings on the market.
We hear you and this is something we’re working on resolving.
Hi Thomas! Yes, this is a popular request. I believe Engineering is taking a look at this. As with any roadmap items, there is no guarantee on when and even if it will be delivered.
I’m a big fan of VVOL’s but without native SAN replication support (VASA V3) in SRM, it just about kills any use of VVOL’s in enterprise shops. What is the point of having a storage policy that states replication requirements if you can’t use SRM to recover that VM in a disaster. I know that vSphere Replication can do the replication, But SAN replication has more capabilities and is generally faster. Not to mention that SAN replication takes the load off of my hosts so they can work on what I bought them for, running applications.
We hear you and this is something we’re working on. Please see: