All Posts

I have a plan, but I wanted to run it by the community: Unregister my new VSRA/SRM boxes gracefully Go into /mob and remove the plugins for SRM and VSRA Re-register When I was connecting my new ones it mentioned it was going to remove my broken / old ones, which it did, but I assumed it would go through and unregister. It seems like it doesn't because the db is still holding on to old replications / and groups. 

Log in to the vCenter Server that is hosting the SRM/VSRA -> Administration > System Configuration > vSphere Site Recovery Manager. > Protection tab > Select the protection plan that you want to delete > Click Delete > In confirmation box, select Force Delete checkbox > Click Delete Keep a few things in mind that you cannot delete a protection plan that is currently in use, Also if you delete a protection plan, any virtual machines that are protected by the plan will be unprotected Further after deleting the plan, you will need to recreate it if you want to restore the virtual machines that were protected by the plan.

  There could be several reasons why you might be facing issues running a custom script on the SRM (Storage Resource Management) server. Here are some common factors to consider: Permissions: Ensure that you have the necessary permissions to execute scripts on the SRM server. Check the user's privileges and make sure they have the appropriate access rights to run scripts. Script Location: Verify that the script is in the correct directory or location on the SRM server. If the script is not in the expected path, it might not be found or executed properly. Script Syntax Errors: Review your custom script for any syntax errors or typos. Even a small mistake can prevent the script from running successfully. Double-check the code for accuracy. Missing Dependencies: If your script relies on external libraries or dependencies, ensure that they are installed on the SRM server. Lack of required libraries can lead to script execution failures. Script Execution Policy: Some systems have execution policies that restrict running scripts from certain sources. Check if the SRM server's execution policy is allowing the script to be executed. Logging and Error Messages: Check the logs and error messages generated during the script execution attempt. They can provide valuable insights into the specific issue you're facing. Interpreters: Ensure that the appropriate interpreters or runtimes are available on the SRM server for the script's programming language. For example, if it's a Python script, Python should be installed. Firewall and Security Settings: Check if there are any firewall rules or security settings that might be blocking the script's execution. Make sure the necessary ports and permissions are open. Resource Constraints: Verify if the SRM server has enough resources (CPU, memory, disk space) to run the script. Resource limitations can cause script failures. Script File Permissions: Ensure that the script file has the proper permissions set to be executed by the user attempting to run it. Regards Routers network team

IIRC the scripts are not run as the admin user so the automation may not have permission to see/read/run the script in it's current location. The script is run as the SRM user so make sure that has the correct permissions... see doc link below https://docs.vmware.com/en/Site-Recovery-Manager/8.7/com.vmware.srm.admin.doc/GUID-4F084B4F-DE9C-4A76-8AD2-19F4A76E81A3.html Thanks, vFouad

Hey all, A small update here, VMware and HPE Nimble both fully engaged and are collaborating on this, We will have an update when there is a fix for this issue. Please rest assured this is a high priority issue, and we are working to solve the compatibility issue as soon as possible. In the mean time, the workaround detailed in this thread seems to be the best option for right now. Please feel free to reach out if you need any more information on this issue. vFouad

Hi all, just to add Nimble support looked into my SRM 8.7 issue and after running some commands on our Nimble HF40 arrays (which did not resolve the issue) advised me to "Reach out to VMware and ask about BUG PR 3246483"

Hey all, I'm trying to get this chased down from the VMware side, and want to reach out to Nimble engineering to see if there is anything we can do to facilitate them updating their SRA code, If one or Two of you could share your HPE-Nimble SR Numbers with me, via direct message, I can get the process started on our side. Thanks, vFouad

Hi you do Not need to wipe anything , we just turned off the new 8.7 virtual servers , and setup 2 new 8.6 srm virtual servers, registered with vcentre and installed the SRA , we only have 4 protection plans so it was very quick to rebuild these ,  the virtual servers are still on the same replicated nimble volumes . So they get picked up by srm once you add the volumes / storage back into SRM hope that answers your questions !  

__If the Socket timeout error is seen, please modify the following file on both SRM appliances with the parameters given below:--> /opt/vmware/dr-client/lib/h5dr.properties : responseTimeout=120000 connectTimeout=120000 socketTimeout=120000__ Restart dr-client service using following command once this change is done: # systemctl restart dr-client

Hi , yes we have done the same, downgraded to 8.6 and it all works fine now. Although the VMWARE support matrix says its not a supported combination it all seems to work. The HP engineer said its an issue with the HP SRA, I still have my case open with HP, which they are aware of and are fixing. But no ETA. As soon as the new SRA is available i will drop a note on here . Cheers Mark

Hi, Chiming in on this as we hit the same issue when trying to perform test failovers. We are utilizing Nimble as the storage solution also. We downgraded to SRM 8.6 after hearing this was a possible bug with 8.7 from VMware engineering. The plan ran smoothly afterwards. I'm chasing a bug ID for reference but thought I would share.