VMware Live Recovery Reviews

We are not an end-user. We are a solutions provider to companies.

All of its components are very competitive compared to other solutions. The application, the DR health check, and the scale-out file system are all great. They tailored a lot of technology in the VCDR, which is good. It's a very good solution overall.

The initial setup is very straightforward. 

The solution is stable. 

Technical support is very proactive and helpful.

The solution has proven to be easily scalable. 

They need to have their own cloud, however, unfortunately, since the solution has been acquired by VMware, I doubt that will be happening.

It is impossible to acquire Datrium data nodes, unfortunately.

It would be ideal if they added advanced analytics or AI to the solution.

We've been working with the solution since before Datrium was acquired by VMware. 

In terms of stability, recently, we encountered an issue, however, it has been addressed immediately by support. It's now resolved. For the most part, the solution is stable. 

The scalability is pretty good. We just have to ask for additional space. Eventually, it will be guaranteed on demand.

There are many users on the solution. It's a big organization.

One of the good things about the solution is that it has very proactive support there. They are helpful and responsive and we are pleased with the level of assistance they offer.

We did not previously use a different solution. 

The solution is very straightforward and easy to set up. The deployment is quick and easy. In our experience, the solution only takes four hours to deploy. 

We're integrators and therefore can implement the solution for our clients. 

We looked at other solutions, however, the product is a very good technology. We have seen its many advantages as compared to other solutions. For example, the solution has been HCI disaggregated.

I'm not sure which version of the solution we're using. 

We're an integrator. Our clients use the solution. We are not end-users. 

I'd rate the solution at a ten out of ten.

We vetted out that data center a number of years ago. We were told SRM would improve our footprint within the data center and that was attractive to us at the time so we went with it.  

We are using VMware SRM but we are also currently looking into alternatives that could replicate the benefits that SRM currently provides for our on-premises installation. Once we are in the cloud, we are looking at whether or not we need dual availability zones. We also are looking at what functionality we could get from not having to change RPs (Recovery Point) as we do now with SRM.  

I would not be able to tell you the features and benefits that are best for the Engineering Teams. That would be more a question for my Engineering Manager and those guys. I am in service delivery and I am familiar with the product but not with hands-on use.  

The decision to move to another product is a matter of room for improvement around functionality and requirements that we had with AWS and moving to the cloud. We are not going to be procuring any more licensing for SRM when we make the move to the cloud. We were looking at a cloud-native solution in order to provide the same functionality as the SRM provides but in the cloud. That is just a matter of the changing environment.  

If the functionality of SRM could be replicated in the cloud, that would be the improvement we are looking for in the product.  

I have been using SRM (Site Recovery Manager) for probably six years.  

I have contacted technical support multiple times. I would not say that I am satisfied. They are not very good and need to make an effort to improve.  

The initial setup and installation were pretty straightforward. It was ten plus years ago so I do not remember the exact details, but I do not remember it being difficult at all.   

The cost of SRM is on par with market rates. So I think the costs for this product are fine.  

I personally will not continue using the VMware SRM solution. That is not a question of what is best. Our position moving forward is that we will not be having a footprint in the VMware space. If someone had the ability to focus on lots of things with using VMware in the cloud then there no issues at all with the product and this is a good solution for that purpose. The product functionality is fairly high-quality. Our decision is more based around the direction that we are taking. We will be cloud-based and we will be using AWS predominantly as our cloud-provider solution.  

On a scale from one to ten (where one is the worst and ten is the best), I would rate this solution overall as an eight-out-of-ten. It would not be closer to a ten because there is still some work that we need to carry out with regular maintenance and then there are the increasing license costs. An eight seems about right.  

We are a solution provider and this is one of the products that we implement for our clients.

VMware is being used for disaster recovery to protect two sites.

The most valuable feature is the automation, where you press a button and everything fails over seamlessly. It is quite good.

When used in conjunction with storage replication software it is not possible to separate and failover an individual VM. When the VMs are sitting on the same storage LUN, the granularity is not sufficient.  Ideally, we should be able to choose one virtual machine and separate it from the rest.

If the price were more competitive then it would be very good.

I have been working with VMware SRM for about five years.

It is stable for now. I haven't had any issues.

It is scalable, although the downside to scaling is the cost.

When I first contacted technical support, I had some issues. However, as time went on, the support has improved and I now think that it is okay.

Prior to using VMware SRM, we were doing everything manually. Failover of VMs was done manually from promoting the replicated LUNs to read write and then bringing them up in the DR VMware environment.  It was a lot of manual work when dealing with hundreds of VMs.

The initial setup is all right and we have had no issues with it.

The cost of SRM is a little bit high, especially for smaller companies.

Yes Veeam and RecoverPoint for VM

In summary, this is a mature product that works very well. It is easy to set up. I like the fact that it has a bubble test feature that allows you to test your configurations without actually failing over. However SRM is very pricy.

I would rate this solution a seven out of ten.

We are a system integrator in Morocco and this is one of the products that we implement for our clients. Our customers use VMware SRM to replicate sites for the purpose of disaster recovery. SRM is a recovery manager and we combine it with NetApp to provide recovery solutions.

The most valuable feature is the simplicity of operations. You have two main buttons, where one is red and one is green. The red button is used for real disaster recovery and the green button is used if you want to simulate it.

The interface is user-friendly.

The storage replication adapter (SRA) is quite good because it allows SRM to work with storage arrays from any vendor.

I would like to see a detailed history of the events for each site because I have found difficulty with that. The two vCenters have to be synchronized, which sometimes gives us problems because Keberos does not tolerate more than five minutes in time difference.

I have been dealing with VMware SRM since 2009.

The recovery point (RPO) is set to 24 hours, which means that this is being used daily. Our backup happens at 8:00 pm every night.

VMware SRM is scalable.

Most of our clients are in Morocco, and 80% of them are bigger companies with a lot of users.

Technical support from VMware is good and I would rate them an eight out of ten.

The initial setup is definitely simple.

The last project that I worked on took two weeks to deploy. This included installing NetApp, vCenter, ESXi, and the initial application.

We have an in-house team that includes me and two other people. We also do maintenance for some of our clients.

In the past, with version 6.0, there were two versions of SRM. There was a version for Windows as well as an appliance. However, all of our customers are now moving to the appliance.

I recommend using this product because it integrates well with replication technology from any vendor using the SRA.

I would rate this solution a nine out of ten.

We use this product primarily for our DR drills, which you can do quietly during office hours. Sometimes we use it for site migrations or planned outages.

The most valuable feature is disaster recovery testing.

The reports are very good.

The configuration process could be improved.

I have been using VMware SRM for about five years.

This is the most stable solution that I have seen. It is used on a daily basis, although we are only monitoring it intermittently. It monitors our critical workloads in the background.

It is easy to scale VMware SRM.

We have been in touch with technical support once or twice and we are happy with them.

We did not use another solution prior to this one.

The initial setup is simple and it takes approximately four hours to deploy.

There is not much in terms of maintenance and we do not have that role assigned to anybody.

We had an integrator assist us with the implementation.

We went straight to this product without evaluating other options.

This is a product that I would recommend for people with a VMware stack.

I would rate this solution a ten 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.  

Our primary use is for our client. It's a system integrator frame. I have clients for whom we manage their data centers. Or, we do their integration and implementation. Basically, we use it to replicate their virtual machines, their user site, and their company site, and maybe to configure it and schedule their recovery. We use it for doing recovery tests from time to time, quarterly or yearly, for some of our clients. To test for a situation whereby a danger or a disaster could be affecting their data that is being replicated. This is good to do. Periodically, we run those tests and recover those virtual machines, and they try to work from their recovery sites to ascertain that everything is okay.

What I like about VMware is its capability to schedule, write and configure the recovery and scheduled steps, such that you don't have to come in and start manually trying to recover the entire machine. You just push a button to recover the VMware and everything is done.

What I think can be improved is the data replication aspect. For example, I know of another repetition solution called RP for VM. I don't really know how to use it since I've never used it before, but I've read about it. I know its features and I've spoken to some IT practitioners who have experience with RP for VM, who work with Dell EMC, and they gave me the feeling that RP for VM is better than VMware replication technology. The argument is that RP for VM has the ability to get your application going even when there is a loss of connectivity. Whereas in VMware you have to have something like 50% connectivity for the configuration. So in that respect, RP for VM has that feature which makes it better than VMware solutions. I guess VMware should make sure they are on top of their virtualization and data replication solution, more than every other company.

Overall, I can't point to any other thing, apart from whatever feature makes some people think artificial DNE is better than the replication application and SRM. If they can just take care of that then I don't think there's anything else.

I have been using VMware SRM for close to 6 years now.

I would say that it's stable. I think everything depends on how you design and manage your environment. For example, when it comes to data replication on the disaster recovery side, part of the challenge that most of our clients have is the link between the production site and the APR site. Sometimes the link will be having challenges and data replication won't work for a few minutes, or something like that. But I don't really think it's an issue with the VMware solution. So, I don't really have challenges with it. If you properly take care of your environment the virtual machines will not have issues. In your scenario, maybe you didn't configure your cluster very well, or your GRS is not working properly, or some virtual machines are not giving results - then most likely you are going to have challenges.

I have not scaled it before so I am not able to give feedback on that.

The environments we have deployed it on are enterprise environments, like the fashion wear industry, dotcom companies, and some other companies also.

The only time we've contacted VMware support was in a case where we had some virtual machines mistakenly deleted and they needed someone who was very experienced in VMware virtualization, someone who understood working from the command line in the process. They needed to do some troubleshooting from the command line. I was very new to VMware virtualization solutions at that point, so I had to contact support. But anyway, that was a long time ago, about 4 -5 years back, and I have not been in contact with them at support.

The initial setup is not that difficult. I would not say it's difficult because you just experience it when deploying some VMware solutions, especially a replication plan. The first time it's not always easy. But once you get the hang of it and get it right the first time, then you don't really have issues. Such as, do you need to go there and provide a key? I wouldn't say it's that difficult - it's not so straightforward but it's not that difficult. It's not complex for me.

I've done the deployment for different clients. So I would say the first time was not easy. But, for me to do it right now wouldn't take time.

My advice to people considering this solution is that they should just go ahead and get it. I think that is the best virtualization solution out there. Some people say Nutanix is better. I think VMware is the best. 

I would also advise making sure your virtual environment is well taken care of. I don't think there are any other challenges that you're going to have. It's necessary that when you see it side by side, to have an operations manager help you find problematic areas and possible issues you are going to encounter in the future.

On a scale of 1 - 10, I give it a 9.

Our primary use case is for the end-users. I work as a VMware software engineer and we have about 50 people using the solution. 

Some of its valuable features are that it's easy to use and the interface is quite simple as well. It's really a reliable and a good product.

Cost is definitely an area where the product could be improved, I'd definitely say it should have cheaper pricing.

Definitely the product could be faster and of course in IT everything is about pricing. 

We've been using the product for the past year. 

VMware SRM is very reliable and stable. 

The product is very scalable. 

I'm satisfied with the technical support we've received.

The setup is relatively complex because of how we use it so the setup can take some time.

We pay an annual licensing fee for the product. 

I would recommend the product to anyone requiring a disaster recovery process. 

I would rate this product an eight out of 10.