VMware Live Recovery Reviews

We are using this solution to serve our customers in different sectors.

We are using VMware SRM as a disaster recovery solution for our customers. We are working with vSphere, vSAN, and other infrastructure VMware solutions. VMware SRM is completing the solution.

VMware SRM is very effective between two sites with identical twin storage, you can have synchronization between the two sites. 

We have had an issue when some customers have traditional designs and sites. For example, on one another site, they are using hyper-converged, using VMware, or Nutanix. We have a problem with the synchronization between the storage for site to site. This is the main issue. We are adding some other tools to support the synchronization to allow the movement of the workload from site to site easily.

Not all customers have VMware in all workloads. Some customers have a difference, VMware environments, such as Red Hat or Nutanix. VMware SRM is very effective for VMware customers. However, when you have other workflows with other vendors, you can not always use this solution.

I have been using VMware SRM for approximately 12 years.

VMware SRM we mainly use for our mid-size business customers. For small business-sized customers, we have different solutions we can deliver, such as Veeam. If they are a small customer that does not have a professional DR site we have a variety of solutions we can deliver depending on the customer's needs.

Enterprise businesses have many VM and the amount depends on the design of the data centers, which storage is being used, or is it hyper-converged or converged. We are choosing the best solution depending on the customer's need.

When comparing the difference between VMware SRM and Dell EMC RecoverPoint there are many differences between them both. VMware SRM is an automated tool for disaster recovery, RecoverPoint can do a similar job but it has better protection more than an automated tool for moving VMs. 

With our customers, we are delivering both solutions, Recovery Point and SRM, because they already had the Dell EMC storage and owned Dell Recovery Point, we only added the VMware SRM tool for moving the VMs and storing them from site to site, as an automated tool.

Dell RecoverPoint has the edge over VMware SRM in one area because they can work with other vendors, not only Dell EMC. Some customers have workloads on the cloud, Dell RecoverPoint is very effective for them.

I have used Veeam and other solutions.

The price of VMware SRM depends on how many VMs the customer has to move. There is a difference between the standard and enterprise license. I'm presenting the standard license to my customers because the total of VMs is not more than 50. The customer needs only the standard license and the cost is very effective for him.

I rate VMware SRM an eight out of ten.

We use SRM to invoke DR and to move workloads across the DR side.

The thing I like the most about SMR is the reduced cost of management.

VMware SRM lacks certain functions that other platforms have, such as better prioritization of allocation of resources and Boot profiles.

I've been using VMware SRM for a long time, almost ten years.

It's a good and stable product. They do a lot of testing.

I think it's scalable. When you work for big organizations, I don't think that's much of a problem. There are multiple and fairly large clusters. That's one of the ways that we reduce cost because we are building things like sequel clusters. Approximately 5,000 people use SRM at our company.

The technical support is great. VMware staff help with deploying and testing. In terms of building storage clusters, metro clusters, stretch clusters across sites so that, you get all of the benefits of a local cluster, but they're deployed between the lines and the DR side. It's a fantastic technology and VMware provides you with their best people.

Positive

Before VMware SRM, we were using Veritas Volume Manager and Veritas Replication Manager for stand-alone. When we went to virtualize, we moved to SRM. I did a lot of work with IBM PowerVM and it had some nice features. It had things such as better prioritization of allocation of resources and Boot profiles where you could put one VM across another so that it grabbed the resources. You could do things such as have thin DR VMs without much allocation of CPU or memory, and then as you boot them, they start to grab all of that automatically from all of the non-prod. Functions like that were quite good in Power VM, which aren't quite as present in the VMware world. PowerVM is extremely expensive to use and that's why everyone is shifting towards commodity computers.

I'm an architect so I did not install SRM myself, but I think there were no issues with installing it since it's a pretty standard tool nowadays. It does not require much maintenance. We are still running some old versions of VMware as there was a challenge around Oracle licensing. We are moving the Oracle workloads off of it now and addressing the architecture to get rid of the copies of the legacy versions of VMware. 

SRM is quite pricey and the license is renewed annually. I think that they do a lot of ULAs, the universal license agreements, where you pay a set amount and get unlimited usage. That's how it usually goes with big companies. Occasionally, they do true-ups to work out how much you've got and whether ULA pricing is appropriate. It might be too expensive for smaller organizations.

I would advise new users to start off with manual processes and document exactly what they want to come up with in the right order. Get your IT continuity plan defined very closely and with a great amount of detail. Then start to automate with your SRM tooling to make sure that things are brought up in the right order and ensure that if one service fails and you need to bring another one across for latency purposes, you really understand all of those requirements before you start to just implement SRM and marching on without really understanding how the services tie together and the dependencies between them.

Overall, I would rate SRM an eight out of ten.

We use this solution to run our applications and our server functions.

We find the back up feature of this solution to be particularly valuable.

We would like the patching management function of this product to be improved.

We have been using this solution for around 10 years.

We have found this solution to be very stable so far.

We have found that the technical support team are not always competent enough to help with our issues, and often have to escalate them.

Neutral

We found that the initial setup for this product was quite easy.

We implemented this solution using a third-party team.

The level of licensing required for this solution is dependent on the server instances in use.

I would advise organizations who wish to use this solution, to ensure that their threat protection software is in place and up to date, as there isn't any threat protection embedded in this product.

I would rate this solution an eight out of ten.

It was working very well with VMware since it's a VMware product. We didn't have any issues. It was quite smooth when doing drills, when we were trying to recover VMs from other sites.

There's an option where you can test VM, when you can test the drill. That option was very valuable.

It's easy to set up. 

The solution is scalable. 

It is stable. 

Technical support can take some time to respond. We'd like a faster response. 

In the previous year, we were using SRM, and then we shifted to another software called CR2. We're replacing SRM. However, we used SRM for a few years. It's been about four years. 

The solution is stable. Its performance is reliable. There are no bugs or glitches and it doesn't crash or freeze. 

The product can scale well. It's not an issue. 

We have three or four people on the solution right now.  They are mostly infrastructure engineers. 

We don't have plans to increase usage. 

Support is good, although we would like them to be faster. 

Positive

We had a simple vertical setup. We have VMware engineers at our disposal, and their expertise made it easy.

The deployment took one to two days. It was not complicated. We only needed one or two people to handle the deployment and maintenance tasks. They are engineers and junior staff. 

We pay a yearly licensing fee. 

We have some nodes which are still running VMware. We currently do have some nodes still running VMware like ESXi 7.0, however, not for production. It's right for testing purposes.

I'd rate the solution nine out of ten. 

I'd recommend the solution as it is very stable and does the job. 

The primary use case is for disaster recovery. We use the solution for two different sites, as well as our virtual machine backup. In a situation where one of our data centers goes down, our servers can go up on the other site.

The most valuable feature of the solution is the automatic recovery of the virtual machine if it goes down. In the event the VM goes down, we can either power it up automatically or manually depending on how we have the solution configured. When configured to power up automatically, the copy in the VM will power up.

The solution currently has a five-minute RPO, meaning if the VM goes down we can lose up to five minutes of data which is a big deal when it relates to database replication. The solution can be improved by reducing the RPO time to zero.

I have been using the solution for five years.

The solution is stable.

The solution is scalable. We only need to add a host whenever we want to expand our cluster.

The initial setup is straightforward and user-friendly. Depending if everything in the network layer is okay, we can configure VMware SRM for both sites in less than an hour or less. The replication process will depend on the size of the VM, so if the VM is large enough, the replication process will take some time. However, the configuration of SRM is straightforward.

The implementation was completed in-house.

We have a standard enterprise license for the solution.

The cost may be based on the number of simultaneous replication which is the limitation of the standard.

I give the solution a nine out of ten.

The deployment and maintenance can be done by one engineer.

I am the consultant solution architect, and sometimes I am the deployment engineer.

I seldom ask for support from VMware because most of the problems are caused by bugs, which we can usually fix ourselves by consulting the knowledge base on the VMware website. However, there are times when the problem is at the hardware level and VMware is not at fault - for example when there is a bug in the VMware version used by the hardware vendor. In these cases, we need to ask for support from the hardware vendor.

VMware SRM is a great solution. I always recommend the solution because it is a native replication solution for VMware. Although there are other solutions such as Zerto, they may deliver a lower RPO in certain cases. I believe Zerto is a better solution than VMware SRM, but when it comes to functionality, and for regular customers, VMware SRM is enough.

I mainly use VMware SRM for automation, creation of VMs, and monitoring.

VMware SRM's most valuable features are its convenience and its use of stretched clusters.

SRM has to be installed on two separate data centers, so both have to be coordinated very well, which becomes complicated when configuring the software for disaster recovery. It would be much simpler if there was just one centralized, cloud-based place to manage both sites.  

I've been using VMware SRM for five years.

VMware SRM is stable.

VMware SRM is quite scalable.

The initial setup is complex and took almost a week to deploy. I would rate the installation experience as two-and-a-half out of five.

We used an in-house team.

VMware SRM is quite expensive.

If you're able to overcome the initial hump of setting up VMware SRM, it works very well. I'd give VMware SRM a rating of seven out of ten.

We are in technology and services but we also do enterprise architecture and strategic planning. We always work on the customer side, but we work very closely together with key partners and key vendors in the industry. This includes VMware, but other vendors as well. We realize solutions on the customer's behalf and we are also always solution-oriented and committed to delivering what the client needs. That is why we work intensively and closely with vendors like VMware.  

With VMware SRM, we had a technical account manager before coming on with them and level three support all on standby just in case we were to encounter issues. We just happened to encounter a lot of issues.  

We integrated the product at the same time partly because of discovery and partly because we want to stay vendor agnostic. We work with whatever the client has if it is a viable product. One might be using Hyper-V and another one might be using KVM (Kernel-based Virtual Machine) or Xen Project or AHV (Acropolis HyperVisor). We treat them equally to do what they need and also work with other parties, like Red Hat or Nutanix or whatever other solutions are necessary. Of course, we take our experiences from every client and every project with us on to the next opportunity.  

What I like the most about SRM is the delta sync. We typically approach a project from an architecture perspective and we do service grouping. For example, take a situation where we plan to do a migration. We decide to go with a setup where there is a front-end portal server, there are duplication servers and there is one back-end database server. This means there are four separate VMs each representing one particular service. To get the services across, we have to wait until we have the full image replication complete. By the time we kick it off, the replication has already begun to trickle in. You can parameterize a little bit. When you really want to do the migration — probably during a service outage on the weekends as it is for production — the majority of the data is already migrated to the other side. That helps a lot because you do not need to have a tremendous service outage with this model compared to doing it in a more traditional way.  

Of course, VMware SRM not the only solution that is capable of doing this anymore. But if you have a heterogeneous environment — environments are not equal on both sides — this solution can be an advantage. In our situation, we had completely different technical specs and technology foundations at the source and target. In this case, the product is really is an enabler on the condition that you have the same hypervisor on the other side.  

I would say a lot could be changed to improve the product in terms of troubleshooting and supportability. I think about every two weeks, we had an incident somewhere in the software stack. There were problems that we faced with the vRA (vRealize Automation) multiple times. We had to fix the problem and redeploy it more than once to get it to work properly. Then we had to completely redo our replication. That is a big drawback because it means we had to cancel other plans that had already been scheduled.  

To summarize it briefly: users need a lot of enhancement to the quality and functionality of the software for it to be very useful.  

For support of VMware version 3, a more recent patch needs to be released. There were a few times that fixes were released but we have already upgraded to those latest levels and the known compatibility problems are not fixed.  

The replication advantage the product has does not work for all VMs. For example, if you have a large difference in change frequency within a VM and the VM is big — in one case our VM was 42 terabytes — the data just does not get across in the migration. So the product is really not able to handle either very big VMs or a very large change frequency. I remember we tried it with one Data Mart SQL database where we do continuous ETLs (Extract, Transform and Load). The data reloads on a daily basis. The replication takes too long to complete. The next afternoon after the migration started, we were more or less at 50%. By the evening, we were at 70%. We scratched the data reloaded and started all over again. We found no means to accelerate that. By the time you appear to be progressing, you have to redo the migration. So that is another disadvantage when trying to use SRM.  

There are a lot of minor things that need to be in place on both sides of the migration to make it work. If something goes wrong in the middle of the migration, you will have a tough time trying to troubleshoot it. The product has an insufficient method of logging, an insufficient level of operability, and an insufficient level of detailed technical tracing. This lack of information makes it so you can not immediately pinpoint the issues to troubleshoot them. It cost us multiple weekends of lost time while trying to troubleshoot because we do not get this information from the product.  

But the things I would like to see for sure in a new release are:  

• Fix all minor connectivity issues with auto-recovery.  
• Auto-diagnose, auto-identify, and auto-correct issues as they occur and at least try to fix the issues a few times before allowing it to fail. If the fix is not successful then at least inform users that the fix attempt was made and the particular area where the issue is suspected so that users do not lose hours to troubleshooting.  
  
• Open up the solution to be more environmentally agnostic. It should not be so strongly integrated with vCenter. It should be loosely coupled with vCenter and allow other solutions.  
• Make the product more robust and much faster. Many replications we have initiated took two weeks before going to the switchover. A lot happens in two weeks. It seems like an eternity when you have no idea why replications stalled over that long of a period of time.  
  

I was using this between 2018 and 2019. I have been using it total for a year-and-a-half.  

The solution is not stable enough. If there are glitches in the process, it is not auto recovering from the issue. It is not even attempting to bring back a steady operational state. So stability is not sufficiently addressed.  

The product promises to be scalable. You can add multiple vRA's — as many as you want per what you want to do. But then again, you are bound by physical constraints. For example, if you want to have multiple vRA's with multiple targets, that does not work. They have to all be directed towards one individual target. It could be multiple data stores, but it still has to be directed to the same target.  

In one case, we wanted to extend to an additional target, so we initiated two targets. Of course, the targets had two different configurations, two different data stores, and so on. That will not work. So that is where scalability ends.  

We had to do a complete reconfiguration with new targets. Then push everything over to a new target, then destroy it again, and bring it back to the first. We have done that on a few occasions, back and forth, and it is quite a cumbersome process. It should not be the case.  

Again this particular case was kind of an advanced setup. But we also have tried some multiple vRA's with just one target. But even there we have encountered synchronization issues because they need to keep in sync, and it may not happen.  

Internal software synchronization issues amongst the vRA's paralyze the replications. There are some bugs in this functionality as well. We tried to patch them up using fixes provided from the VMware lab. Eventually, we ended up on version 6.5.1. Later on, those patches disappeared, apparently because VMware understood the patches did not fix the problems — or maybe created more.  

Because of all these issues, we are no longer using the product for the moment. This is because of all the problems and the fact that there is an ongoing license cost as well. I think at the peak we had 10 users. These were admins and engineers. I was using the product as a solutions design architect. But right now I would never use it unless it is for disaster recovery or rehearsal or something like that.  

The advice that I would give to other people who are looking into implementing this solution is that every software product comes with flaws. Products can evolve very rapidly. I think in our case that it was quite a good learning experience. It was a good learning experience for VMware as well — as they acknowledged. They said they would work on improvements in the various areas I brought up to them, and I liked that they will be making the effort.  

But if considering this product, I would also look at other compelling products, like Zerto, for example, or other replication tools like the Sun virtual platform. You could look at the ease-of-use of Nutanix. Their process for replication is very different compared to what SRM offers. But the ease-of-use comes with constraints. You do not always have the choice to have equal foundations for both source and target. Then there are backup solutions like Rubrik and Veeam. There are certainly alternatives out there that are categorically different product types with other ways to accomplish similar things. But a lot of what is potentially a viable choice depends on the use case.  

My recommendation would be to prepare carefully. Mimic your own live environment in testing as close as possible to the existing architecture with the vendor. Let the vendor prove that they are value-added resellers. Make sure you have tested in a representative set up at their facilities and can achieve what you are trying to achieve before going on to attempt to deploy and use it in your own environment.  

I do not think SRM is fully ready yet for a hybrid context where the workload is working across multiple clouds and on-premises. It is an evolving product.  

In a simple situation, the setup is a piece of cake. However, as soon as you start to work across various deployments based on various levels, the setup is much more cumbersome and much more complex. You need to deal with the interoperability issues like checking the vCenter on the left side and the vCenter on the right side, what is the ESX (Elastic Sky X) level, et cetera. You may need to downgrade your expectations accordingly, to make it still work.  

Also, if you have network routing in between two completely different, distinct environments, that can give you quite a lot of headaches as well. To give you an idea: in the initial setup of one migration, we could just not connect both VMs end-to-end. The site manager would not connect. The vRA's were connecting, but the site manager was not. It turned out to be a network routing issue. In actuality, the "issue" was not an issue. The routing was just was working like it should, following the default gateway. It just could never connect to the other site manager.  

At times you really need to go back down to the very basics yourself, and even then there may be no clarity about why it will not connect. It follows the route, the stage-gate goes through, and the connection does not happen.  

Then also the checkpoint restart is a problem. There is no checkpoint restart. What I mean by that is you can have eight VMs to migrate over a coming weekend and something goes wrong after the process is initiated, or somebody made a mistake in the service grouping. When you see this problem, you think you just need to remap, recalibrate, and then relaunch it. But there is no history track of what is already replicated. The service grouping does not reflect in that result. You need to start all over again. So there is no checkpoint for the restart. There is a checkpoint for an individual VM, but not for multiple VMs.  

As far as the time it takes to deploy, that will vary. We have had different levels of complexity in our deployments. We initially had a simple setup that was done in two days, but there were no different networks involved, no different vCenters, and also it was intra-cluster. When done like this it was very easy.  

It was a completely different story for the more complex setups. I think it took us about six weeks with a lot of effort. There was a lot of alignment, a lot of verification, a lot of troubleshooting, and a lot of diagnostics to get it working end-to-end on both sides. It was really too much time to take with that kind of project.  

On a scale from one to ten where one is the worst and ten is the best, I would rate VMware SRM as about a five. I am not open to giving a positive recommendation as the product stands. It is a little generous to give it a five considering all the issues.  

This review focuses a lot on the weaknesses of the product. But we were actually able to use the solution to get quite a lot of server images successfully, especially if the servers were relatively small, like a parasitic thermal server or an ordinary file server. That type of project went fine. So, if your use case is entry-level, beginning, and maybe intermediate, I think you will be fine using the product. But even if you do not have a lot of complexity and you try to work with this in a really big enterprise and a multi-region, multi-datacenter environment, you will have a lot of challenges ahead for sure.  

We have used it as a migration tool in support of a big transformation. I would think twice before using it for continuity on a permanent basis. I might think three times before more enhancements to the product are made successfully to enhance the utility.  

VMware SRM is deployed with some clusters. However, if the customer uses a three-tier architecture or other configurations, SRM might not be applicable. The expectation is not always to achieve 100% coverage. SRM is used for virtual machines with stringent SLAs or critical business applications. SRM is often sold in packs of 25 virtual machines, and deployment and functionality testing are conducted based on customer needs.

The simplicity of VMware SRM is one of its most important features. SRM console is straightforward to manage. It offers simplicity in monitoring, managing, and deploying, making it a unique value proposition. Additionally, Nutanix solutions also provide a simple GUI, which helps in operational efficiency.

The solution's recovery processes are very simple but not intelligent because one can easily monitor the replication progress and how the application is going. There is a workflow defined for doing their testing.

I have been using VMware SRM as a partner for ten years.

VMware SRM is a scalable solution due to its ease of documenting virtual machines. The process is straightforward if a customer already utilises 25 virtual machine licenses and requires more. They can execute the addition of the following 25 licenses. Then, they can enable those licenses and add the corresponding virtual machines to their application jobs.

It depends. We have customers using both twenty-five virtual machines and those with more than one hundred virtual machines. Therefore, the usage of VMware SRM varies from customer to customer, resulting in a mix-and-match environment.

The initial setup is very straightforward, depending on the kind and number of virtual machines.

A customer is expecting 25 virtual machines to deploy from the SDR. So, it should not take more than two days of work. If fine-tuning is required, it may take additional time, depending on the bandwidth. It's dependent on the infrastructure and varies case by case based on the bandwidth capability. Data will replicate faster with higher bandwidth, whereas lower bandwidth will result in longer replication times. Depending on the scenario, with good bandwidth, it could be a matter of only 24 hours.

Furthermore, the primary site's data size and change rate also play significant roles. If there are frequent changes at the primary site, it will naturally take more time. Additionally, the size of the primary data is another crucial aspect to consider.

The challenge is the licensing has changed from physical software to core-based, from perpetual to subscription-based.

The pricing for VMware SRM can vary significantly based on factors such as the customer segment, brand, and specific requirements.

The solution is straightforward to deploy and easy since it provides all the SRM functionality, such as security manager, with a seamless experience. 

We need to simulate for DLP . We need to freeze the application and do audio testing, and if there is an update on our data site, we need to provide feedback.

Specific solutions are pure-play SRM solutions. This solution acts as a recovery manager because the providers understand the workflow, prepare it, and know the dependencies. For instance, they understand the dependencies between virtual machines and applications, databases, ADA DNS, CSV, etc., and document them in the workflow. This documentation ensures the workflow can be executed properly, leading to a minimal Recovery Time Objective. ADR minimize RTO through automation, improving the workflow within SRM and eliminating the need for third-party solutions for security and other aspects.

Once we receive an order, we initiate thorough planning and documentation. We prepare a comprehensive flow-level design and engage with the customers for confirmation. With a clear understanding of the entire expectation cycle, my team can effectively deploy the solution, ensuring seamless integration.

Maintaining VMware SRM involves setting it up correctly and regularly monitoring it for infrastructure changes. Once appropriately configured and monitored, it operates smoothly unless there are changes at the customer site, such as patch deployments or alterations to authentication or access rights. These changes can potentially lead to application failures. Therefore, ongoing vigilance is necessary to ensure the seamless operation of the solution. Bandwidth issues can also affect performance, so addressing such concerns is essential.

I strongly recommend confirming with the new Broadcom team whether their VMware SRM licensing has changed since the acquisition of Broadcom. They've consolidated their SKUs from over a hundred to ten if there have been significant changes in SRM licensing, features, or functionality.

VMware SRM offers simplicity in disaster recovery solutions. However, it's primarily optimized for VMware environments. If a customer prefers a non-VMware-focused solution at their data centre, SRM may face challenges. Converting virtual machines in such cases can be complex and cumbersome. 

Overall, I rate the solution an eight out of ten.