VMware Live Recovery Reviews

We use it for disaster recovery.

I like how VMware SRM is able to automate and orchestrate disaster recovery.

The price, in general, could be lower.

I've been using this solution for probably three years now.

It is a stable solution.

It is scalable.

My experience with technical support has been fine.

The installation is straightforward if you have the required skill level. It took about a week for the initial setup.

The price could be lower, in general. My clients pay for an annual license.

I recommend VMware SRM and rate it at eight on a scale from one to ten.

We use SRM for our failover strategy. It is for disaster recovery on failover.

Our systems fail over using SRM. So, we do a big bang DR, which is biannual, and we fail over our fairly massive Epic electronic health record (EHR) and our core applications. It takes us about 30 minutes to fail over using SRM, which is pretty good. In most hospitals that have Epic installed, Epic does the audit to make sure that we can fail over if something were to happen. Normally, sites will have a DR solution specific to the EHR, but right now, our pain point is the third-party tier-one clinical applications.

We've had configuration issues on occasion. We start to fail over, and then we have to call it off because the configuration is not right, or the data stores aren't configured correctly in the secondary data center. Oftentimes, it is just the experience level of the team, and we have to bring in the vendor to help and validate our configuration.

I have been using this solution for probably five years.

Their support is excellent.

I would rate it an eight out of 10. There is some complexity there, and that's where I would bring it down from a 10.

I use VMware SRM for DR testing and VR.

The solution is simple to use and has effective automation.

VMware SRM does not have the capacity to do DR tests. We had issues whenever we were doing tests with the root cause analysis. We had 70 to 80 percent successful results because the vCenters were overloaded and that was the reason that we were having capacity issues.

We have been experiencing an additional problem when adding a regular VM in the replicated storage. By default, it will show an error. However, there is not any monitoring mechanism that would show you are not supposed to have a regular VM which is non-VR in the replicated SRM storage. Whenever we used to do testing we had to figure out that a regular VM is there and remove it manually.

I have been using this solution for approximately seven years.

The stability should be smooth, and as for the capacity, we should be able to run the test successfully. However, from our research and DR test results, we came to the conclusion that we have to run the DR test during the non-production hours. Logically, they should be able to be done during the production hours, but that is not the case. We have to ensure that the vCenters are free and are not doing regular work for us not to have any issues during the DR test.

There needs to be better stability during heavy capacity in future releases.

The solution is easy to scale.

The solution is used extensively in our large organization.

When we first started out using this solution we encountered a few issues and used the support but we now know how to fix most of the issues and have not used them. Additionally, we have our own team for support.

The installation is logically simple and in the medium range of difficulty. However, you need to make sure you have the proper infrastructure.

I have evaluated Veritas and Zerto.

I would advise others looking into implementing VMware SRM not to totally be dependent upon it. Review other solutions, such as Veritas regulatory platform and Zerto. There are newer VM DR options coming out regularly and they should not have only one solution.

I rate VMware SRM a six out of ten.

We are consultants in disaster recovery software. We implement VMware products for our clients.

It is easy to implement for my clients. 

It's a very nice product.

I would like to see this solution be more scalable.

We currently use our security in addition to VMware SRM.

I am certified in VMware and VCloud. 

I have been using VMware SRM for ten years.

We have no issues with the stability of VMware SRM.

VMware SRM is scalable, but it can be improved.

We have 15 to 20 customers who are using SRM. We have customers not only in the US but in the UK also.

They provide very good technical support that is affordable.

We are also using Zerto.

It is very easy when it comes to integrating with a data center or an appliance, but it's a bit complicated.

The length of time it takes to deploy depends on the database we are accessing. It can take two hours to deploy.

We have two senior persons to deploy and maintain it.

I am not involved with the pricing. 

We have a procurement team and sales team that work with the vendors.

I would definitely recommend this solution to others who are interested in using it.

I would rate VMware SRM an eight 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 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.