VMware SRM's platform agnostics should support on-cloud usage as well. VMware SRM has to add a couple of features related to the cloud.

We are limited to 50 VMs.

The main limitation is the fact we can just activate the product in a disaster scenario. Sometimes we need to activate some VMs in the backup or disaster recovery sites, even if our main site is okay. However, in our current environment, we cannot do this due to the limitations of SRM.

The back sites sometimes are very, very complicated. It is the nature of the product. Sometimes we use vMotion to achieve this kind of objective.

There is room for improvement in the replication interface and functionality. Every time you open a remote site, you need to sign in again.

Ideally, single sign-on after integrating with vCenter should provide secure credentials that avoid re-entering passwords for every remote site access. It takes time every single time.

It has a ton of features, but ease of use could be improved. It gets better with automatic configuration over time, adapting to access. If you bring in a storage test application, maybe an automatic plug-in to the adapter, say for HPE or other storage providers, would be helpful. We wouldn't have to go to the provider's sites to download them.

The product itself is smooth, but timing issues arise due to replication lags in multiple areas.  When this happens, we encounter errors. In our most recent environment, we left the virtual machines running at the recovery site, hoping to avoid redeployment.

There is room for improvement in the automation and orchestration aspects of this solution.

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.

They could enhance the automation features for the product.

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.  

Currently, the recovery manager is primarily for only VMware environments or virtual machines running on VMware. Suppose the recovery manager can be extended to a non-VMware environment. In that case, we can integrate all of the tools in an IT environment together and function using one single recovery manager. Allowing for integrations with non-VMware products and environments will really help.

The primary site lacks adequate equipment, such as power backup and cooling, which can lead to downtime during issues like power outages or overheating.

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

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.

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

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

It is important to understand that Broadcom's acquisition of VMware is one of the major problems attached to the solution right now to understand what needs improvement in the product.

The product's dashboard is an area of concern where improvements are required.

The solution's technical support needs to improve since the support team takes too much time to respond when my company contacts them.

Currently, there is a limitation of consolidating only 15 sites per SRM.

Ransomware recovery or early detection could be incorporated into VMware SRM.

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.

In my opinion, the integration with Peer Persistent Storage could be improved.

The solution is on the expensive side. 

VMware SRM is not a popular product anymore since all the other backup products can provide the same functions as SRM. With Veritas, Arcserve, or Commvault, you can take care of the replication part. VMware SRM is not a popular choice among users anymore since it is a highly costly product while also being complex to configure. When it comes to backup products, you can use RTO and RPO, so there is no need to have a separate solution like SRM. In general, the drawbacks of VMware SRM, where improvements can be made, stem from the fact that it is an expensive and complex product.

It would be good if this solution could integrate configuration management software such as Chef Infra.

In my view, if VMware comes up with an appliance-based solution like vCenter Server (which was also Windows-based), it will be much easier for deployment. It will also save Windows Server Operating System licensing costs, which for most of the organization recur annually.

The solution must provide better integration with third-party vendors.

There could be an integration between VMware SRM and Nutanix products, which can benefit many users.

Perhaps the array replication or vm guest customization features. Perhaps more features are needed to allow

For recovering VMs in situations where replication on production site has been paused for (ie: 1 week or more)

The weakness in VMware SRM is visible when, in our company, we try to do some cross-platform programming. For cross-platform programming, we might need some external tools, like Veeam or Commvault, for cross-hypervisor replication. It is not so easy to integrate it with other solutions. The aforementioned details can be considered for improvement of the solution.

The technical support is not quick enough to respond when a user tries to contact them. For improvement, the support should respond quickly to a user.

Cross-hypervisor restoration support or multi-platform support would be some of the best traditional features I would like to see in VMware SRM's future releases.

The two main areas for improvement in VMware SRM are pricing and administration guides. Pricing is always a consideration, and it could be improved. The administration guides can be complicated and difficult to use, so it would be helpful if it was made easier. Administrators don't want to find themselves in a situation where they can't find what they need, so it's important to make sure that the tools are easy to use.

I would like to see this solution be more scalable.

We currently use our security in addition to VMware SRM.

VMware introduced the two next versions of the solution. They are SRM 6.5 and 6.7. I don't have any experience with these two products. However, if I was to talk about version 6, which we are using, at that time we faced a problem specifically when we create recovery plans. After the creation of the recovery plan, sometimes an issue happened in the GUI, in the Center. I'm not sure if that has since been resolved.

We've faced issues with the licensing. If you don't choose a specific license, you can only cover around five or ten virtual machines.

The biggest issue for us is that this product does not have any demo for customers. They should offer demos so that clients can try it out before they commit to buying a license.

I would say VMware has room for improvement with this product. I am sure it is probably better in their 7.0 version, but there are still some bugs in the 6.O version that relates to using it with different browsers. I think a lot of what I run into is related to the 6.0 version. I believe a lot of those bugs have been fixed in the UI once you upgrade to 7.0.  

I don't have any notes for improvement.

I'd like the installment and configuration to be more seamless.

The user experience could be more friendly.

It's, by definition, a complicated product. 

We'd like the entire solution to be more automated. We'd like as much automation as possible. 

The solution is very expensive. 

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.

If you have a failover case, you need to work on it manually. It would be helpful if this could be automated. It would simplify things.

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.

The product's stability could be better.

The price, in general, could be lower.

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 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.  
  

In my opinion if Vmware added some function to detect the business critical applications like oracle, exchange to help monitor these applications for disaster recovery .

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.  

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.

• SRM may hit some OS issues related to IP changes, but they are usually OS related, especially in the 2008 realm. SRM runs a batch file on the OS through tools that will change the IP stack. If something fails with that, or it hits duplicates or hidden devices, it can cause issues.
• Veeam had some weird issues redoing the Server 2008 VM IPs and this requires a MS hotfix. Apparently, that is an MS issue. Though, SRM does not require any hotfixes.
• One thing which is lacking from the SRM is reporting.

An improvement for SRM would be better interface compatibility with other products.

Technical support needs improvement, they are not very responsive.

You should be technically skilled enough so that you don't have to rely on its support. It's not easy when you don't get the support that you would expect to receive from VMware.

The interface is not easy to use and can be made more user-friendly.

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. 

There are sometimes performance issues when working with outside links, and it would be better if this were improved.

You need a lot of knowledge to work with the interface because it is not really easy to use, and it would be great if the dashboard were simplified.

DR drill report is good but needs to be improved, and the replication monitoring feature is not available.

The challenge it has is with the speed of failing over. Sometimes it can cause a bit of downtime during switchovers. Sometimes you realize that when you are failing over you can have downtime due to the fact that you're stepping down on one side and powering up on another side.

Yeah, I would like more tools to help with editing the embedded databases. I have run into some issues where human error, not something that VMware themselves would have ever planned for, but human error, has caused the system to get out of sync. And the only way to correct that would be to actually manually edit the database, which you could do if Site Recovery Manager were on a Window server but now that everything's gone to this, Linux appliance, this sealed up appliance, it's very difficult to actually edit the database. Or maybe just have a reset button for them to be able to put everything back to a normal state. Maybe that's all they would need to do.

Flexibility to choose different PITs would be nice. Also, ability to give VMs different priority per Recovery Plan would be useful.

I would like to see the database come built-in to the product. I would also prefer to the SRM server come as a virtual appliance instead of a windows vm. I would also like to see a way to control bandwidth usage.

Automatic guest customizations through a GUI is a missing feature. Also the new version of SRM is web-only and is not that stable as the old client version.

We had couple of times that the web interface crashed and needed to restart the services.

The solution could improve by removing some of the limitations we have been facing. There could be better integrated.

Unfortunately, SRM is not stable and it therefore requires continuous monitoring. If there are any issues associated with the Center, SRM doesn't work well and as a result, it generates a lot of tickets and productivity drops. 

I haven’t yet checked out latest version because we’ve been moving away from it, stuck using it for replication clients and it doesn’t work with all storage vendors. There are issues with versioning.

It looks good, but synchronization is, sometimes, a problem. Hence it should be totally dependent on storage.

Nothing I have run into as of yet.

The setup documentation needs to be improved greatly.

I can’t think of any right now, honestly.

vSphere Replication feature

Storage integration.

Stability, speed.

Smaller sites or sites with mixed storage platforms rely on vSphere replication for DR purposes so additional scalability in this tool would benefit from this.

The configuration process could be improved.

I would like to see better integration with other storage solutions. I would hope to see that within the next two or three years.