VMware Site Recovery Manager (SRM) automates disaster recovery for VMware infrastructure, and future versions of VMware SRM are in development.
Mike Laverick got an exclusive look at future VMware SRM features, and he discusses them in this series. Part one explains the possible addition of host-based replication. This section covers future SRM features -- such as planned migration and virtual machine (VM) start-up groups -- and how these capabilities may change the way customers use VMware SRM.
Planned migration in VMware SRM
When you have forewarning of a disruptive event, such as electrical grid maintenance, VMware SRM can execute a planned failover. But there is an interesting and subtle change in the recovery-plan dialog box: VMware will now refer to a planned failover as "planned migration."
You could argue that this change is a question of semantics. But I see it as further evidence that VMware has big plans for SRM beyond disaster recovery automation. I think the long-term plan is that the "R" in SRM will be dropped, so it becomes more of an overall site-management tool.
A company might want to move VMs among various sites for various reasons. If a building lease is up, for example, an organization could consolidate data centers at other sites rather than renew the lease there. Additionally, many mergers and acquisitions result in the consolidation of facilitates, as businesses eliminate unnecessary staff and operational resources.
Reprotect Mode in VMware SRM
When VMware SRM was first released, failback was possible, but it required several steps.
For some time, Site Recovery Manager customers have wanted automated failback , and future versions of SRM will likely ship with a new failback process that VMware calls Reprotect Mode.
Prior to the Reprotect Mode, administrators had to clear stale objects in the vCenter inventory and recreate objects, such as Protection Groups and Recovery Plans.
The new Reprotect Mode speeds up the failback process, and between this feature and planned migrations, you can see that VMware is making VMs more portable. Most VMware customers are used to moving VMs between physical servers with vMotion, and many users would like to extend this portability across sites.
Doing so is already possible with long-distance live-migration technologies from EMC and NetApp, but they are limited to top-end customers. The tools require specialized technologies, and they are limited to certain distances and use a ton of bandwidth.
With an effective planned migration and reprotect process, however, customers could move VMs from site to site much more easily.
VM start-up groups
Currently, the lack of a VM grouping mechanism is an annoyance of Site Recovery Manager. Protected VMs are added to a list, and each one needs to be moved by hand to a series of categories (i.e., high, low and normal). There isn't a way to create objects that show the relationships between VMs or groupings.
A new grouping feature will allow customers to more effectively show the dependencies among VMs from a service perspective.
IP settings in VMware SRM
Another area of improvement is in the management of IP addresses. In most cases, \two sites will have different IP subnet ranges. According to VMware research, nearly 40% of SRM customers are forced to reassign IP addresses to VMs.
Sadly, a minority of customers have a stretched VLAN configuration, in which both sites believe they are on the same continuous network, despite being in different geographic areas.
One way to make sure that VMs with a 10.x.y.z address function in a 192.168.1.x network is through network address translation technologies, which keeps VMs from having to change IP addresses.
VMware SRM has always offered a way to change the IP addresses of Windows and Linux guests through vCenter's Guest Customization feature. Guest Customization is normally used in the deployment of new VMs to ensure that they have unique host names and IP addresses when cloned from a template.
In Site Recovery Manager, vCenter's Guest Customization merely changes the IP address of a VM. Early in VMware SRM, a command-line utility dr-ip-exporter allowed administrators to create many guest customizations, with a CSV file to store the specific IP details. But it was difficult to see the original IP address in relation to the recovery IP address.
When SRM carried out a failback process, the VMs needed their IP addresses changed back to the original address. For Windows guests, Microsoft Sysprep triggered the IP reassigning process, and it was particularly slow.
With future releases of SRM, we will see a better method of handling the reassigning IP address to VMs. It will be neater and quicker, with the parameters held in a single dialog box.
Join the usability group
We can expect a lot of good things from VMware SRM. I've only scratched the surface, and I can't wait for the beta program.
The VMware UE Team is recruiting SRM administrators for one-hour interviews. VMware wants to know how administrators use VMware SRM, and it wants feedback on future SRM user-interface designs. Also, the UE Team is recruiting SRM administrators and vSphere administrators for Site Recovery Manager usability testing.
If you're interested, email firstname.lastname@example.org.
About the author
Mike Laverick (VCP) has been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users, and has recently joined SearchVMware.com as an Editor at Large. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish VMware user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere4 and VMware Site Recovery Manager.